Ds18b20 and emonTX3CM firmware

Hardware emonTx
41

You are not wrong.

HW setup is exactly the same. Used an Arduino IDE (V1.8.9) with fresh EmonTxV3CM and EmonLibCM downloads and latest OneWire and Dallas. Built V1.7.

Doesn’t work!!! I do this time get a 302 rather than 25 for the first Temp reading though.

emonTx V3.4 EmonLibCM Continuous Monitoring V1.70
OpenEnergyMonitor.org
Loaded EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

Calibration:
vCal = 268.97
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 9.96
pulses = 0
pulse period = 100
temp_enable = 1
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF off
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
AC present
MSG:1,Vrms:246.28,P1:83,E1:0,T1:302.00,pulse:0
MSG:2,Vrms:246.38,P1:84,E1:0,T1:0.00,pulse:0
MSG:3,Vrms:246.37,P1:81,E1:0,T1:0.00,pulse:0

I do wonder if it is picking something up from the EEPROM - is there any way to erase it just to be sure? In this case it is picking up the RF Off setting.

If my test sketch works - if proves the HW is fine so the only thing left is a problem with the EmonTX sketch. As I have eliminated PIO as a variable, all I can think of is that there is something extraneous left in the EEPROM.

[edit]
Question - to turn off temperature sensing, is it t,0,0 (as in the keys to be pressed) or should there be a space as well between the two 0s? I can’t actually get it to acknowledge either.

Ah so t0<space>1 results in this change!!! (and it is repeatable after reset with no save)

MSG:69,Vrms:246.47,P1:80,E1:16,T1:0.00,pulse:0
MSG:70,Vrms:246.32,P1:84,E1:16,pulse:0

But after that it does not appear to respond to any t0 command (with or without space)

reset TX

t0<space>0 & s

reset

temp_enable = 0
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF off
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
AC present
MSG:1,Vrms:246.29,P1:84,E1:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:2,Vrms:246.37,P1:83,E1:0,T1:0.00,T2:0.00,T3:0.00,pulse:0

Why does it now give 3 blank readings?

42

So in good Sherlock Holmes fashion, look for differences and eliminate the impossible.

Flashing the HW. Not using Arduino but avrdude. Command used is…

avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:EmonTxV3CM.ino.standard.hex

-e seems to be the command to clear the EEPROM but do I then need to reload the bootloader? The Wiki is far enough out of date that I don’t fully trust it.

43

Worst case standby power across temperature and voltage is 5uW so self heating when not dong anything is unlikely to be a problem. I have confirmed you can warm things up a bit by doing back-to-back conversions though. Rather than hijack this thread, I’ve continued that discussion here.

44

@Robert.Wall, could the printing of the Temperatures and Pulse be on the basis of the enabled flags?

Keeps it clean if they are not enabled.

45

Not all commands echo back to the terminal (I’m gradually picking those up).

The syntax is on the screen and in the notes, observe the spaces.

If you use the ‘max’ demo, that’s much more informative as there’s no unnecessary logic in it. And even better, comment out the RF stuff if you don’t need it. That will remove even more possible influences.

[Must go shopping now. :unamused: ]

1 Like
46

That’s Trystan’s sketch. Originally, a lot of logic like that was introduced, but it seemed to be in an attempt to force emonLibCM to behave exactly like emonLib(DS), which it never was designed nor intended to do. All I did to get it to work reliably was take out the unnecessary stuff, leaving what I deemed to ‘harmless’ as it was.

Even the part you quote is questionable, because the sensors always fill the array from element zero, so the last sensor is always in element [getTemperatureSensorCount() - 1] , so that snip could be done as it is in the demo sketch.

47

The demo sketch is totally unaware of the EEPROM. That’s part of the reason I suggest using it as the reference.

And if you like, as you’re only interested in serial output, comment out all the stuff that starts RF12_. That will rule out the radio.

To rule out anything associated with switching the OneWire power, wire your sensor to pin 2 rather than pin 5 on the screw terminals.

I used the latest 1.8.12. But no apparent difference from 1.8.10 or 1.8.7, whilst 1.0.3 & 1.0.5 need too much work to back-port. So it’s unlikely to be that.

Error value “302” means the sensor reports < -55C or > +125C but the checksum was good.

The Dallas library is returning the sensor address and count of sensors. That’s all it’s used for. Both those are only done at start-up, or when configuring, so although searching for sensors is a slow process, they’re not the time-critical parts.

OneWire is used to access the bus, but as that works for the sketch that uses all Dallas library, that’s working - at least some of the time.

It can’t be a sensor that takes a long time to convert. If it was, it would return 85 °C.

The checksum is good, otherwise it would show 304 °C

It’s looking to me as if the array that receives the temperatures gets corrupted, or the array is not big enough. In the demo sketch, it is big enough - for 6 sensors.

I can’t quite see how all that adds up.

48

Ah that has got me somewhere.

Enabled after first message, note first temperature is 25 still, but after that fine so saved config

pulses = 0
pulse period = 100
temp_enable = 0
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF off
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
AC present
MSG:1,Vrms:246.50,P1:85,E1:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:2,Vrms:246.12,P1:86,E1:0,T1:25.00,pulse:0
MSG:3,Vrms:246.49,P1:82,E1:0,T1:23.12,pulse:0
MSG:4,Vrms:246.03,P1:86,E1:0,T1:23.12,pulse:0
MSG:5,Vrms:245.94,P1:85,E1:1,T1:23.12,pulse:0
MSG:6,Vrms:246.41,P1:83,E1:1,T1:26.25,pulse:0
MSG:7,Vrms:246.03,P1:87,E1:1,T1:29.25,pulse:0
Saving...
0F 01 D2 29 7C 86 43 CD CC B5 42 66 66 86 40 CD CC B5 42 66 66 86 40 CD CC B5 42 66 66 86 40 29 5C 85 41 00 00 C0 40 29 5C 1F 41 00 64 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

reset - still doesn’t say it is finding the sensor but I am getting temperature.

pulses = 0
pulse period = 100
temp_enable = 1
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF off
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
AC present
MSG:1,Vrms:245.95,P1:87,E1:0,T1:30.62,pulse:0
MSG:2,Vrms:246.10,P1:85,E1:0,T1:29.62,pulse:0
MSG:3,Vrms:246.28,P1:89,E1:0,T1:29.12,pulse:0
49

I’ve lost count of how many times I’ve told you, until it’s got to the end of that user config/calibration and emonLibCM has actually started running (that’s just before it prints “AC present” - it does that with the first set of results), it hasn’t even looked for the sensors, so it doesn’t know how many or what they’re called.

So your issue is with Pin 19 of the Atmel 328P going to the emonTx screw terminal 5, or with I/O 19 getting turned on - or has it been shorted at some time and got blown up?

If you put a 'scope or multimeter on terminal 5, you should see about a ¾ second blip of 3.3 V just before it prints the result.

50

So why is the text there? Just to confuse poor souls like me?

Temperature Sensors found = 0 of 1
51

I have a multi meter so I’ll do that later.

52

It’s absolutely accurate at the time. The same message is used if you’re doing on-line calibration and moving sensors around. You wouldn’t have been confused for as long if you’d read what I write.

53

Can’t be the issue else my test sketch would not work.

54

Testing here, DS18B20 temperature sensing is working, both on the 3.3V and DS18B20 PWR terminals. The serial printout also shows “Temperature measurement is NOT enabled.” even though, temp_enable is equalls to 1, printed just above it. This is expected of course as the function “EmonLibCM_TemperatureEnable(temp_enable);” has not yet been called.

I think it would make sense to remove the call to “printTemperatureSensorAddresses();” in config.ino > list_calibration(); the result would skip the print out of that part.

emonTx V3.4 EmonLibCM Continuous Monitoring V1.70
OpenEnergyMonitor.org
Loaded EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

Calibration:
vCal = 268.97
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 10.00
pulses = 1
pulse period = 100
temp_enable = 1
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF off
POST.....wait 10s
'+++' then [Enter] for config mode
NO CT's detected
AC present 
MSG:1,Vrms:251.90,T1:18.12,pulse:0
MSG:2,Vrms:251.95,T1:18.12,pulse:0
55

It looks like @borpin and I are getting different results when it is powered from the DS18B20 PWR terminal, it does seem to be working for me. Im testing with one of the encapsulated DS18B20 sensors that we sell in the shop, with only about a meter of cable and a single sensor.

56

I am testing with two, both Shop ones. One is a black cable into the screw terminals, the other a white cable terminated in a RJ45 plug. So the black cable is switched power, the white is permanently powered.

I’ve never seen an initial temperature that isn’t in line with the next one 10 s later (i.e. more than a couple of counts different = ⅛ or ¼ degree different).

57

Yes same here. I still wonder if it is an EEPROM issue as I have seen odd things when swapping between sketches. Is there any way to completely clear it?

58

Did you clear it from the config menu? using reset to firmware defaults?

59

He’s previously said he had, but as I wrote earlier:

60

The l is presently common to both parts, during start-up and when running. So it doesn’t quite make sense like that, but I’ll change the l command to behave differently when called at start-up and when running.

When you do l for list calibration before the library has started, you will not get any indication of the number or addresses of the temperature sensors, but you will get the ‘enable’ the setting, i.e. whether the sensors will be enabled or not.

When you do l for list calibration after the library has started, you will get the number and addresses of the temperature sensors, which means you have the information you need to pre-load the addresses into the array. As explained in the library documentation, this has the effect of fixing the address of a particular sensor in the array, hence eventually to a Feed in emonCMS. I introduced this facility precisely to answer the problem where users have had a sensor fail, replaced it, and found that all the sensors had shuffled their places in emonCMS.