I've looked at the other posts on this topic, but they have different circuits. Here's mine:
All sensors are on individual pins. No parasitic power. All sensors have a 4.7k pullup. Some wire runs are 2", some are as long as 20'. I am using the following code in order to avoid the 750 msec delay in the library (I provide the necessary delay in other code). I store all my readings as integers as degrees F in 1/100ths degrees:
void readtemps() {
// one sensor per line, simple OneWire call
Temp_1 = dallas(A0) ;
Temp_2 = dallas(A1) ;
Temp_3 = dallas(A2) ;
Temp_4 = dallas(12) ;
}
// ----------------- end of readtemps() -------------------
int dallas(int x) {
OneWire ds(x) ;
byte data0 ;
byte data1 ;
long result ;
ds.reset() ;
ds.write(0xCC) ; // skip command
ds.write(0xBE) ; // Read 1st 2 bytes of Scratchpad
data0 = ds.read() ;
data1 = ds.read() ;
result = (data1 << 8) | data0 ;
// round up by adding 1/2 bit
result = (((result * 90)+0x04) >> 3 ) + 3200 ; // degrees F x 100
ds.reset() ;
ds.write(0xCC) ; // skip command
ds.write(0x44,1) ; // start conversion
return result ;
}
The error that I see is that certain remote units (both Nano and Pro-Mini) will consistently read a particular sensor (some 2" away, some further) as all zeroes. This is related to a particular pin on a particular unit. On various units I've seen this on pins A0, A2, D5, and D12, maybe others. I can change the processor or the sensor and I get the same thing. I know when a pin sees the sensor because if I remove it, the input value is -1 (0xFFFF), otherwise it's zero (with the code above that reads out as 32.0).
I've seen some posts that suggest that knockoff sensors need a stronger pullup, so I've tried 2.2K--didn't do anything. 3/4 of the sensors work reliably, the others read zero (reliably). I've also tried hard resets by removing power and restarting; no workie.
But all of a sudden I'm struggling with why declaring "result" as a long works and as an integer, it does not. I'm even dunking a sensor in salt and ice to guarantee that when the C result is negative (high order bits are extended and not lost) that it also works. Yep, the code seems to work for both negative (meaning below 0 Celsius) and positive readings. (Funny the things you notice just just as you hit send.)
One DS18B20 per pin with 4.7K pullups, up to 4 per remote, mostly pins A0, A1, A2, and D12.
the only other connections are power, ground, Rx, Tx (9600 baud), RTC on the I2C buss using the <TimeLib.h> <DS3231_Simple.h> libraries, and a 4x20 LCD on the I2C buss using the <hd44780.h> <hd44780ioClass/hd44780_I2Cexp.h> libraries.
[quote="Dr_Quark, post:1, topic:853232"]
I store all my readings as integers as degrees F in 1/100ths degrees:
[/quote]Possibly where the problems lie, i.e. user error, and God only knows why you don't use a float as delivered like everybody else does. I submit the only time you should ever see zero is when everything is kosher and you are measuring zero degrees. I won't ask why you want the one-wire sensors spread over several pins but, for one, it might not be such a bad idea. You will get something that works here:
integers can hold 1/100ths of a degree just fine and it's easy send two byte across a serial connection. The only time they need to be "floats" is when they are displayed.
"delivered as floats" means you're using the library, which means a 750 msec delay for each call to the function. Total waste of time, unless I'm missing some nuance in reading the chip.
"like everybody else does" is not accurate. There are lots of posts from others who are also avoiding the 750 msec delay and doing their own Dallas function.
When you want to know which sensor is doing what, you either need to track serial numbers (and re-catalog them if you ever change a sensor) or put them individually on a pin. If you've got enough pins for your task, I highly recommend one sensor per pin.
Thanks for the link. I'm familiar with the sheepdog, but it looks like he's updated his page. I'll take a close look.
Turns out can see zero twice, once if you are reading 0 degrees C, and the other time is when the DS18B20 is on the pin but the registers are not responding. Zero.
If you try to read a pin with a dead or missing DS18B20, you read 0xFFFF.
So when you read zero and it's a nice day, you know the chip is there, it's probably alive, but for some reason the registers are not responding.
If your sensors are fake, expect them not to work properly and learn not to
to source semiconductors from untrustworthy sources - these days most are
fake.