I have 5 separate emonTH v2 collecting data; 4 with the external DS18B20, and 1 without (ie internal sensor only). All 4 of the units with DS18B20 tend to drop signal to the Rasp-pi once every 1-2 weeks(battery reset always recovers), while the unit without the DS18B20 has never lost signal. Issue is not due to being indoor vs outdoor, and not due to battery being cold or voltage low, and not due to long distances btw emonTHv2 and emonPi. It’s tempting to assume issue may be due to additional noise pickup from DS18B20 acting as antenna, or something relating to emonTH with DS18B20 attached.
Has anyone else seen this issue? If issue really rf noise pickup on DS18B20 cable, has anyone had luck using chokes on the cable?
Not that it’s any help whatsoever - I can’t remember ever seeing a problem like this reported in the forum - either version of emonTH and including the old forum.
I know you think it’s not, and the additional current drawn by the DS18B20 is small compared against the RFM69CW when transmitting, but my instinct would be to look for a power/voltage problem first, as this is likely to be easier to find or positively rule out. Are you able to monitor the battery voltage while it is taking the reading from the sensor and transmitting the data? Have you ruled out tarnish on the batteries and battery box connectors? I’m only saying this because I know it’s possible to hang the Atmel '328P when the supply voltage drops briefly.
How long are the cables to the sensors? Is there a reason to think you are in a ‘noisy’ place in the 433 MHz band?
The data rate on the OneWire bus is relatively slow, so the choice of r.f. choke should not be too critical. This is the request to the sensor to read the temperature. The horizontal scale is 200 µs/div.
Hi Robert,
Thanks for the advice and data. I also put a bead on one of my units, and it still failed. You’re correct that I don’t have any solid evidence of noise. (I do have solar panels with micro-inverters that may be a noise source, but I assume they are not noisy at night.) My DS18B20 length is normal as shipped (~4 feet I think) for 3 units, while the 4th unit has a 20 foot extension. I have measured the battery voltage on all units after they fail, but have not measured the battery voltage during transmission. I can try that if it’s important, and I have an oscilloscope to capture it. Here is a short summary of fails since I started documenting them:
and here is detailed log, with voltage measurements of battery while in base (I call it ‘insitu’).
Both AA batteries always measured, but both always identical to within 0.01Volts, so I only list one voltage. Some are alkaline, some are the so called Li batteries, but this doesn’t seem to be relevant to the failing.
I did notice (I think) that the shield in DS18B20 cable seems not to be connected to anything, ie not connected to base circuit; perhaps(?) it is connected to the metal cap encapsulating the sensor, I didn’t check that. Any other advice is welcome. It’s all frustrating as I need stable temp data for analysis, and weather station data Glyn gets for me is anomalous, and can be easily 3-4deg different from my sensors. Finally, here is 1 month’s worth of temp traces - if you look closely one can see at least 7 fails in this time window (ignore the wild purple data in first week):
I need to disconnect and reconnect the battery in the base unit, then all is good. I will try connecting to external voltage source - I haven’t done this only bcs it is rather inconvenient, but at this point I need to.
Sounds like the micro is getting locked up - are the batteries still ok? Might be worth checking with a fresh set. There’s no watchdog running as it does add some power consumption, so there’s not that mechanism to automatically restart.
