next topic »

[Reply #15 on:]

Just looked at the DallasTemperature lib to see how they do the readings as the code for reading temp looks quite similar.

Code:

// DallasTemperature lib
int16_t rawTemperature = (((int16_t)scratchPad[TEMP_MSB]) << 8) | scratchPad[TEMP_LSB];

// DS2438 lib
int16_t rawTemp = ( ((int16_t)_scratchPad[TEMP_MSB]) << 5) | (_scratchPad[TEMP_LSB] >> 3);

The shift works in the Dallas lib as the signbit fells in place. This means that the DS2438 lib could be patched easier by the following code:

Code:

int16_t rawTemperature = (((int16_t) _scratchPad[TEMP_MSB]) << 8) | _scratchPad[TEMP_LSB])  >> 3;

return (float)rawTemp * 0.03125;

[Reply #16 on:]

Thanks Rob! Didn't mean for u to spend a lot of time on this but it is appreciated. Only one more simple question. What program do I use to edit this with? Notepad won't work. It adds stray chars. Get all kinds of errors.

Thanks,
Bill

BTW... I have several DS2438s. If you want a couple send me a personal message with you address.

[Reply #17 on:]

It was fun to investigate, I hope the proposed changes work for you.

For coding libraries is use notepad++, it is lightweigth and does syntax highlighting, can open multiple files (tabs). It is not the greatest but very fast also for large logfiles (100.000++ lines)  You can find it at http://notepad-plus-plus.org/

wrt the 2438's I appreciate the gesture but I think you have to pay more on postage than the costs of the sensors

[Reply #18 on:]

Hi Rob,

Sadly your last fix didn't work. Temp stays at 277 deg F. But the humidity still reads properly. Will try the other code you suggested later tonight.

[Reply #19 on:]

@Bill
Could you confirm that the the first patch works?


Strange that the second patch, which stays more to the original code, doesn't work. My testcode with same datatypes did. Could you test a rewrite of the last patch as proposed below? I have moved the rightshift 3 to a division in the return statement, to be sure the signbit is kept...

Code:

int16_t rawTemperature = (((int16_t) _scratchPad[TEMP_MSB]) << 8) | _scratchPad[TEMP_LSB]);

return (float)rawTemp * 0.03125 / 8;

Rob

[Reply #20 on:]

Ho Rob,

OK, so far so good. It has warmed up here so the low temp won't be below 32 f for a few days. I made the last change you suggested and it is reading the correct temp at 51 f. Will let you know what happens.

Again, thanks much for all you help.
Bill

[Reply #21 on:]

Stick the temperature sensor in the freezer. It's colder than 32F in there.

[Reply #22 on:]

I started to but then remembered I have a can of freeze spray that I use to find faulty components on pc boards that break down when they heat up. I will try that later today. That should take the temp down to near 0 degrees F. Saves making a cable long enough to reach the frige.

[Reply #23 on:]

Let me know how the testing goes and I'll incorporate the working patch. Thanks all for reporting the issue and working in a solution

[Reply #24 on:]

The 20ms is between sensing the ready status - you only need to wait 750ms or whatever if you are _not_ polling the conversion status.

Unless you use parasite power it is fine to poll the conversion status regularly - this allows you to do other useful work while the A/D conversion happens.

Original problem was clearly one of sign-extension (a well known 'gotcha' in C style languages)

Basically if you ever shift right or divide a number, then it matters if that variable was declared unsigned or not.  Another related issue is doing tests like

Code:

 byte a = ..... ;
  if (a < 0)
  {
  }

The if is never going to test true because byte is unsigned, and an unsigned number can never be negative...

[Reply #25 on:]

Hi Rob,

Just an update.
The change you suggested is working perfectly.

int16_t rawTemperature = (((int16_t) _scratchPad[TEMP_MSB]) << | scratchPad[TEMP_LSB]);

return (float)rawTemp * 0.03125 / 8;

Thanks.