[Solved] Arduino + DS18B20 sticks at 64.00 / 32.00 / etc.

Australia & New Zealand Homebrewing Forum

Help Support Australia & New Zealand Homebrewing Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

mr_wibble

Beer Odd
Joined
21/1/09
Messages
1,114
Reaction score
231
Location
Lake Macquarie NSW
Hi,

I had a problem with my Arduino-based kettle controller box.

Basically it would all work fine, but then you'd look at it some hours later, and the temperature reading would have stopped with the temp stuck at 64.00°C or 32.00°C etc.

I have setup the sensors so the library does not go and fetch the temperature immediately, because this takes around 1900 milliseconds for the 12 bit precision. It's requested, and then the sensor signals when the measurement is ready. This allows you to run through your loop very quickly, and update the temperature when it's available. Given I'm handling button presses and other stuff, I don't want to hold-up the main loop at all.

I think the problem is that somehow the sensors.requestTemperatures() is failing, or never completes. Thus the call to sensors.isConversionAvailable() always returns false, and it's only when this returns true that I read the temperature and request a new measurement. But with a fail-time sometimes hours apart, it's difficult to track down the bug.

To fix it, I had to remember the time of the last successful measurement, and if the delay became too long, re-request it.

I've pasted the relevant bits of the code below. In the real code there's all sorts of interrupt processing for reading a rotary encoder, PID processing, updating an OLED display, etc. etc. So maybe some of that is fouling the library. At first I suspected I was simply running out of RAM (of which there's a bit under 2k). I moved all my strings to PROGMEM, and added a log of memory use - it's rock stable with > 800 bytes free. So not a memory leak.

The code now looks roughly like this:

#define ONE_WIRE_BUS 4
#define TEMPERATURE_PRECISION 12

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress sensor_address;

void setup()
{
sensors.begin();
sensors.setWaitForConversion(false);
if (sensors.getDeviceCount() > 0 && sensors.getAddress(sensor_address, 0) == true)
{
// everything ok
sensors.setResolution(sensor_address, TEMPERATURE_PRECISION);
sensors.requestTemperatures();
}
else
{
// sensor init failed (is it plugged in?)
alert("Sensor Fail");
delay(16000);
}
}

void loop()
{
unsigned long last_temp_read = 0;
while (1)
{
unsigned long now = millis();
if (sensors.isConversionAvailable(sensor_address))
{
last_temperature = sensors.getTempC(sensor_address);
sensors.requestTemperatures();
last_temp_read = now;
}
else if (now - last_temp_read > 16000)
{
// something went wrong, the conversion should take max a few seconds
sensors.requestTemperatures(); // again! again!
alert("Had to re-request temp");
}
}
}
Has anyone else had this problem ?
It could of course be in my circuit.

cheers,
-kt


Edit: Grammar police
 
I've seen the issues you pointed out.

Basically I reset the bus completely and make a new request.

It shouldn't be taking 1900 milliseconds for the conversion. That's nearly 2 seconds ! The spec sheet says a maximum of 750 milliseconds for conversion if in parasitic mode. My understanding is that its faster when not using parasitic mode.

Might be worth running a test sketch that simply requests temps and times how long the conversions take. Something sounds a little fishy on your system.

Based on my experience, I wouldn't rely too much on the DallasLibrary, which it sounds like you're using. I've found issues where it was not pulling the bus high properly after requests due to the responses from the sensors I was getting. Ended up stripping a whole lot of crap out. of it.

On my system I make a requestTemperature call, which also reads the millisecond clock. My version of isConversionAvailable then checks the millisecond clock to see whether the appropriate amount of time has passed before attempting a read of the sensor. This works very well. I occasionally get an invalid read so simply reset the bus and make a new requestTemperature call.

regards,
garyd
 

Latest posts

Back
Top