DS18B20 sensor, datasize

Hello.
I’m working with the DS18B20-sensor. I installed the library and everything works. When I look at the examplecode and shorten it down to what I need, I found it declare 12 bytes for data, but further down in code, it only reads 9 in a for loop. I tryed to change the declaration to only nine and it works just fine. I have seen at least one more example code where they declare for 12 and only use nine. Why is that?

#include <OneWire.h>

// OneWire DS18S20, DS18B20, DS1822 Temperature Example
//
// http://www.pjrc.com/teensy/td_libs_OneWire.html
//
// The DallasTemperature library can do all this work for you!
// http://milesburton.com/Dallas_Temperature_Control_Library

OneWire  ds(10);  // on pin 10 (a 4.7K resistor is necessary)

void setup(void) {
  Serial.begin(9600);
}

void loop(void) {
  byte i;
  byte present = 0;
  byte type_s;
  byte data[12];                   // Here is the declaration for 12 bytes
  byte addr[8];
  float celsius, fahrenheit;
  
  if ( !ds.search(addr)) {
    Serial.println("No more addresses.");
    Serial.println();
    ds.reset_search();
    delay(250);
    return;
  }
  
  Serial.print("ROM =");
  for( i = 0; i < 8; i++) {
    Serial.write(' ');
    Serial.print(addr[i], HEX);
  }

  if (OneWire::crc8(addr, 7) != addr[7]) {
      Serial.println("CRC is not valid!");
      return;
  }
  Serial.println();
 
  // the first ROM byte indicates which chip
  switch (addr[0]) {
    case 0x10:
      Serial.println("  Chip = DS18S20");  // or old DS1820
      type_s = 1;
      break;
    case 0x28:
      Serial.println("  Chip = DS18B20");
      type_s = 0;
      break;
    case 0x22:
      Serial.println("  Chip = DS1822");
      type_s = 0;
      break;
    default:
      Serial.println("Device is not a DS18x20 family device.");
      return;
  } 

  ds.reset();
  ds.select(addr);
  ds.write(0x44, 1);        // start conversion, with parasite power on at the end
  
  delay(1000);     // maybe 750ms is enough, maybe not
  // we might do a ds.depower() here, but the reset will take care of it.
  
  present = ds.reset();
  ds.select(addr);    
  ds.write(0xBE);         // Read Scratchpad

  Serial.print("  Data = ");
  Serial.print(present, HEX);
  Serial.print(" ");
  for ( i = 0; i < 9; i++) {           // we need 9 bytes,                      Here only nine is used!
    data[i] = ds.read();
    Serial.print(data[i], HEX);
    Serial.print(" ");
  }
  Serial.print(" CRC=");
  Serial.print(OneWire::crc8(data, 8), HEX);
  Serial.println();

  // Convert the data to actual temperature
  // because the result is a 16 bit signed integer, it should
  // be stored to an "int16_t" type, which is always 16 bits
  // even when compiled on a 32 bit processor.
  int16_t raw = (data[1] << 8) | data[0];
  if (type_s) {
    raw = raw << 3; // 9 bit resolution default
    if (data[7] == 0x10) {
      // "count remain" gives full 12 bit resolution
      raw = (raw & 0xFFF0) + 12 - data[6];
    }
  } else {
    byte cfg = (data[4] & 0x60);
    // at lower res, the low bits are undefined, so let's zero them
    if (cfg == 0x00) raw = raw & ~7;  // 9 bit resolution, 93.75 ms
    else if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms
    else if (cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
    //// default is 12 bit resolution, 750 ms conversion time
  }
  celsius = (float)raw / 16.0;
  fahrenheit = celsius * 1.8 + 32.0;
  Serial.print("  Temperature = ");
  Serial.print(celsius);
  Serial.print(" Celsius, ");
  Serial.print(fahrenheit);
  Serial.println(" Fahrenheit");
}

Im just curious why declare for 12 when 9 is used and works just fine?

/Björn

Baloo76: found it declare 12 bytes for data, but further down in code, it only reads 9 in a for loop. I tryed to change the declaration to only nine and it works just fine. I have seen at least one more example code where they declare for 12 and only use nine.

I think you are alluding to the resolution. Between 9 and 12 bit, there is a very big difference in the time taken to aquire the data. If you are sampling at about once per second 12 bit is fine but, if 9 bit is OK for you, there is no need to change.

That Miles Burton stuff is confusing junk, and an obsolete catch-all. I have no idea why it would declare 12 and then 9, but I'm not surprised to hear that. The best thing I did was ditch it and use the stuff from Hacktronics, which is somewhat more job-specific, and a lot more concise..

I'm absolutely understand that conversion of 9 BIT takes less time then 12 BIT. But here it is not talked of BITs, it is declared and used BYTES. The bits is included in the first two bytes of that byteArray.

As I said I found another example code that also declared 12 bytes but only used 9 of them in a for loop.

/Björn

Look at the data sheet - only nine are needed. I expect the use of twelve is due to some confusion about the nine to twelve bit resolution that the device has. Someone published code with this mistake and others have copied it - you can safely use your nine byte version.

Baloo76: But here it is not talked of BITs, it is declared and used BYTES.

Probably a meaningless mistake but everything works so no damage has been done. As I said, the code is junk. The device defaults to 12bit so, if you are not properly setting the resolution and I suspect that is what is happening, you are probably getting 12bit results. Clearly you understand the timing issue and you have already a delay (1000), so there is no problem using 12bit, and it's the obvious thing to do.

for people coming from 32 bit platforms it is not as strange as it looks at first sight. Some programmers allocate/declare all their variables in multiples of four bytes, so if one need 9, 10 or 11 bytes in an array they declare the array 12 in size. This enforces all variables to lay on addresses that can be mapped easier by the compiler.

Thank you all for your answers. robtillaart: I find your answer most logical and I think it is a very good reason!

I thought it was me that missed something, but now I know. :)

/Björn

I think the answers about bits were a red herring.

I agree that there is no obvious reason why that data[] array needs to be 12 bytes, in your code. It is likely that the code was adapted from some other code relating to some other device, not relevant to you, which did provide 12 bytes of data.