Giters

milesburton / Arduino-Temperature-Control-Library

Arduino Temperature Library

Home Page:https://www.milesburton.com/w/index.php/Dallas_Temperature_Control_Library

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Odd behavior when not using parasite mode

kfine100 opened this issue · comments

commented

Hi, I am using the DS18B20 to measure temperatures every 5 seconds on an ESP32 processor using the Arduino environment. I am not in parasite mode, but have connected VDD to 3.3V and DQ to 3.3 V thru a 4.7 K pullup resistor.

I get temperatures with this code:

sensors.requestTemperatures();  // Request temperatures
float tempExt_C     = sensors.getTempCByIndex(0);

and the odd thing is that the first reading is OK, but all subsequent readings do not change, even when the sensor is heated. It is clearly reading only the first time.

Looking at the DQ line on the scope, the first reading take 185 ms (Normal for my 10-bit resolution) but all subsequent communications take only around 20 ms. They are clearly not real reads.

I found I could correct this behavior by calling

sensors.readPowerSupply(deviceAddress);

Which returns Parasite Mode = false. This extra call corrects my problem but I do not understand why.

Also, the unit occasionally returns -127 C which I believe means the read failed. My voltage seems to be a solid 3.3 V so I am not sure why this is happening either.

Anyone have an idea about either issue?

Kevin

commented

@kfine100

Most important command in readPowerSupply() might be the _wire->reset()

If you do a oneWire.reset() before the getTempCByIndex() does that "fix" the problem too?

commented

Thanks for getting back to me so quick, Rob.

I replaced

sensors.readPowerSupply(deviceAddress);

with

oneWire.reset();

The second does not have the same happy effect as the former, but reverted back to the short "reads." It seems like the magic in readPowerSupply does not lie in the reset.

Any other ideas?

All the best, Kevin

commented

The only other thing readPowerSupply does is _wire->select(deviceAddress);
can you try?

oneWire.select(deviceAddress)

commented

OK, I tried and IT DOES NOW MEASURE each cycle with oneWire.select(deviceAddress)

So, it needed the address set.

However, there is a mystery. When I look at DQ it only takes 36 ms to measure, jumping around a bit. My guess is that it is a successive approximation digitization strategy, and since it is already near the right answer it only takes one or two steps. (I am at 10 bits of precision, which can take as long as 185 ms.)

Thanks Rob. Any idea on the occasional -127's?

Kevin

commented

Thanks Rob. Any idea on the occasional -127's?

bad wiring?
bad sensor,
long wires? pull up does not fit length of the wires (try 2K2 or even 1K ) ?

The timing you got cannot be correct and it looks a bit like the device answers before it settled the measurement.
Do you also get too short times at other resolutions?

commented

At 12-bits it takes 670 ms compared to the max time of 750 ms in Table 2 of the data sheet.

The Temps are behaving correctly. I was rather proud of my theory of successive approximations; don't you think that could explain short measurement times?

How dare you question my wiring! No, heh, that could definitely be it. They are short but they are wires out in the open. The -127's happen about 1% of the time, so I just ignore it when I get a number under -100 C.

Thanks for the help. Kevin

commented

670 ms sounds OK to me (90% of the datasheets max time)

The hypothesis is fine (all reason to be proud) , and the question is can you prove that the sensor behaves that way?
What predictions can you make from the hypothesis that can be tested in experiment to confirm (reject) the hypothesis?
some questions pop up: (and my expectations from hypothesis)

  • What do you expect when slowly heating the sensor? => same time
  • What to expect when heating/cooling it quickly? => longer time
  • Is the short time seen at every stable temperature? => yes after the sensors mass is at the same temperature...
  • Is the short time seen on all resolutions? ==> datasheet states that every bit extra doubles max sampling time
  • Do we see it with more than one sensor? ==> ?
commented

You seemed so sure that 36 ms was too short that I thought you already knew the answer!

My theory stinks. If you look at Table 2 in the data sheet each new bit takes as long to measure as all the bits before it. That would mean if it only had to repeat the last bit it would take at least half the time which is 92 ms > 36 ms.

I agree the way to do it is REAL SCIENCE, hypothesis-predict-test. I might get around to doing that!