Measuring two temps

I have a string of 12 DS18B20s connected with two of these. When I hook this up to my emonPi it returns 12 temperatures as expected. So far, so good.

When I try to connect them up to my emonTH2 using the multiple_ds18b20_external sketch from here, things don’t go so well. Most of the temperatures come back as 85 degrees, while a couple come back as 0. I gather that 85 degrees is what you get when you initialise a DS18B20 but haven’t told it to read a temperature.

I’m going to check the cabling between the emonTH2 and the breakout block, but is there anything inherently different about the connectivity on the two devices that could account for this?

One thing is that the emonTH2 is battery powered (for now), while the emonPi is mains powered. Could there be something there?

Here’s what comes back on the serial monitor. Note that the pulse count at the end is consistently garbled when the DS18B20s are connected… When I power it up without the DS18B20s the pulse value is returned correctly.
temp:251,tempex:850,tempex:850,tempex:850,tempex:850,tempex:0,tempex:0,tempex:0,tempex:850,tempex:850,tempex:850,tempex:850,tempex:850,humidity:425,batt:22,pulÿÿÿÿÿþÿ

Thanks,

David

[edit] technically, the breakout blocks are from Sheepwalk Electronics and not from the shop here. In addition, I’ve wired the emonTH2 directly in to a 3rd breakout block rather than wiring the emonTH2 into an RJ45 plug and connecting that way.

How long are the cable runs to each sensor? What you’ve written implies they are ‘star’ connected. That’s OK with short cables, but bad when any sort of length is involved.

The sensor is handled in three stages: first, power the sensor. Second, you (or the Dallas temperature library) command it to “convert” the temperature. This replaces the power-up value in the temperature register (85 °C) with the measured temperature. This takes a comparatively long time, up to 750 ms, but all sensors can do this simultaneously. The third and final stage is you command the sensor to return the value in the register with the “read scratchpad” command, and clearly this is done by stepping through the list of sensors one at a time.

As every sensor except the first is coming back with 85 °C (I don’t believe the three 0 °C - I think those could be 850 and characters have gone missing), I suspect the battery power is failing after the first sensor has been read (and possibly after each sensor) and all the remaining sensors lose power for an instant, reset and hence return 85 °C. I would certainly suggest replacing the batteries with a mains USB power supply, if only to prove that’s not the problem.

I don’t think

is strongly related, I think that’s the serial comms failing because something else is happening and breaking the message up. A short delay( ) (experiment with the duration) should fix that.
It might also help to have a short (2 - 3 ms) delay in the loop between reading each sensor. It won’t materially slow things because each sensor takes about 14 ms to read.

I trust you’ve checked continuity and all the GNDs are connected together with negligible resistance, the same with all the 5 V and all the Data.

Thanks Robert.

In my original post, the temp:251 value is generated from the onboard SI7021. The external temperatures (from the DS18B20s) are written as “tempex”

The cable lengths are either 1 or 2m for the DB18B20s. The RJ45/ethernet cable between the devices are under a meter each.

I have connected up a single DS18B20 and retrieved a temperature correctly. The '0’s below are correct since they represent a probe that does not exist. The garbled pulse count remains, but it’s not important for the moment.

temp:226,tempex:250,tempex:0,tempex:0,tempex:0,tempex:0…

For my next step I’ll try powering it with 5V and see if this makes any difference. If not, then I’ll add in a lot more debug output to the sketch and see what is being returned at each of the 3 stages you outlined above.

David

The battery voltage “22” represents about 1.1 V per cell, it should be OK given the power supply regulator being used, but though that should be capable of supplying 12 sensors (@1.5 mA max each), the symptoms you see do point towards a supply voltage problem.

Bear in mind that “printing” could interfere with the OneWire bus transaction, and vice versa, as both are time-critical.

Hopefully a silly question: you do have compatible values here:

const int TEMPERATURE_PRECISION=11;  // 9 (93.8ms),10 (187.5ms) ,11 (375ms) or 12 (750ms) bits equal to resplution of 0.5C, 0.25C, 0.125C and 0.0625C
#define ASYNC_DELAY 375              // 9bit 

because asking for the temperature before it’s ready will surely give you a 85 °C error. You must get the precision, hence the resplution [sic] and the delay correct.

Setting the delay to 180 ms when it needs 375 does indeed give me “850” on all but the last two sensors.

Hmm…
An error in the sketch:
Line 136

byte allAddress [4][8];                                              // 8 bytes per address

allows only 4 sensor addresses! Seems like the sketch hasn’t been properly checked. :anguished:
The ‘4’ should be ‘EXTERNAL_TEMP_SENSORS’

And I found that with more than 6 sensors, the “batt:” print was corrupted, cured by adding a 10 ms delay before printing it. I expect that will work for your pulse count too.

With all those sorted, and running on the programmer power, and telling it lies because I have only two physical sensors, so I copied the two addresses I have into the remaining array elements, it read 12 “repeated” sensors quite happily:

OpenEnergyMonitor.org
emonTH FW: V324
Loaded EEPROM RF config >
Int RFM...
RFM Started
Node: 23 Freq: 433Mhz Network: 210
Int SI7021..
SI7021 Started, ID: 21
SI7021 t: 24.46
SI7021 h: 49.98
12 DS18B20

'+++' then [Enter] for RF config mode
(Arduino IDE Serial Monitor: make sure 'Both NL & CR' is selected)
waiting 5s...
temp:244,tempex0:231,tempex1:288,tempex2:231,tempex3:288,tempex4:231,tempex5:288,tempex6:231,tempex7:288,tempex8:231,tempex9:288,tempex10:231,tempex11:288,humidity:505,batt:4

Odd numbered sensors are the same physical sensor, as are even numbered ones.

My added code:

void copyallAddress(byte d, byte s)
{
  for (byte n=0; n<8; n++)
    allAddress[d][n] = allAddress[s][n];
}

and when the sensors have been searched:

  copyallAddress(2,0);
  copyallAddress(3,1);
  copyallAddress(4,0);
  copyallAddress(5,1);
  copyallAddress(6,0);
  copyallAddress(7,1);
  copyallAddress(8,0);
  copyallAddress(9,1);
  copyallAddress(10,0);
  copyallAddress(11,1);
  numSensors = 12;

If you attend to the array overflow problem (if you hadn’t spotted it), and have a solid power supply, then if the problem persists, I suggest abandoning the “star” wiring configuration and wire the sensors in “daisy-chain” with the absolute minimum length of stub between the One-Wire bus and the sensor itself.

Thanks Robert. I thought I had replied a few days ago but I guess not.

As you suggested I added in a delay (after printing the temperatures, but same effect) and the serial print corruption went away.

I also built the connections up from scratch, starting with 1 probe and added in extra probes while re-compiling for each count (even though technically not necessary, but just to be sure).

It’s all working now - mains connected emonTH2 with 12 probes reporting temperatures to my emonPi.

I have 5V supplied via the header on the other side of the board using a breakout from a regular 5v barrel connection power supply. I tried wiring it via the screw terminals but something didn’t work properly. I can’t remember what it was. I will likely try it again to see if it was my wiring.

Next on my list - working out how to suggest/make changes to the sketch via git, to correct the problems with the array size and add the delay. That’s for another thread.

1 Like

No need - I’ve written to Trystan (as the modifications were his originally) to advise him of the problems. I don’t think he’s seen it yet, though. (He tends to be quite busy.)