Emontx intermittently transmitting zeros

No, I don’t think so. Here is a short (filtered) extract from emonhub.log during berserk phase, I used grep to filter in just the lines containing the string 'values : ’ .

pft-13 brief.txt (16.1 KB)

I think this must be the initial phase of the EmonTX test sequence (value 10) repeated continuously?

Note the timestamps on subsequent frames are just a bit more than 100ms apart!

In amongst it all, the emonhub manages to process the emonPi frame every 5 seconds.

FWIW, before I flashed the old EmonTX to CM firmware, it used to just stop every few weeks or maybe a month or two. I tried a little investigation but to no avail, so I just put up with it and rebooted it when I noticed it had happened. It seems that the CM firmware might have exacerbated whatever was dodgy before?

What I’ve found with the published sketch and JeeLib is there’s a problem that I think (unsubstantiated) is related to how JeeLib checks for the channel being clear before transmitting. I’ve run a simplified sketch with the transmit-only code lifted with minor changes from JeeLib and it’s run now for over 5 weeks at one message per second, without locking up or resetting. So you could be right - it might be common to both sketches but because the CM library is, well, continuous, it has appeared much more regularly. (The DS library only runs for 300 ms per c.t. per 10 seconds.)

That’s interesting. OK I have 2 distinct problems. Let’s take them one at a time.

(1) emontx3 (older one) going “berserk” and flooding emonhub with frames. Having swapped PSUs between the 2 units, it has run for 15h now with no failures, so I am very tempted to buy beefier 9V AC PSUs for the emontx3s - do you have any suggestions?

[edit] it just failed now after 16 hrs, same failure mode, continuously sending the initial factory test frame. I have to either try a beefier PSU or try reverting to the old DS firmware, which do you think is better?

I have also read elsewhere about the emonpi PSU being a little lightweight (1.2A) compared to the standard raspi PSU at 2.5A, so I might try substituting a standard Pi PSU for the emonpi’s, even though I have no reason to suspect it. Belt & braces and I have one lying around.

(2) I am still getting emonhub dropouts from both tx3s, observed from the graphing module (is this a reliable method, though?), around 10-20 per hour. I haven’t spotted any correlation between the dropouts from the 2 devices, although they do seem to come in clusters. This is a stacked graph showing one output from each emontx3, the dropouts are obvious.

It does smack of RF interference to me, but it’s just a hunch. Would you be prepared to share your JeeLib mods? I would be happy to replicate them and try it out.

Incidentally I have switched off the new emontx3 now to see if I can observe dropouts from the troublesome one. Not one dropout so far after 20 minutes…

Can you clarify when you got which emonTx? - The CM skecth started shipping on 18th October 2019, before then, the DS was the default. After, it has been the CM with JeeLib.

I’m a bit reluctant to put a new version out in the field before I’m satisfied that there are no problems. For now, I’d suggest going back to the old DS library and sketch.

Unless the emonPi is falling over, I wouldn’t change it. There’s nothing to suggest a problem with the emonPi, and it would be wise not to introduce a new variable.

From my tests, I no longer believe it’s a power supply problem, unless your supply goes way below 220 V. If it does, then adding 5 V d.c. USB power is the better solution.

  1. May 2017 (PCB V3.4.2) the “troublesome one”, upgraded from DS to CM earlier this week.
  2. Last week (PCB V3.4.3) working fine, shipped with CM and not updated at all.

Understood. I will try the DS library/sketch. Good practice using Arduino IDE :wink:

Ok. Maybe I will try that before I revert to DS. Can’t do any harm. I’ll just need to get a usb mini-micro converter cable…

Regarding observation of dropouts using graphs, I don’ think that is a reliable method so I’m going to put that investigation on the back burner for now.

It may well be a power supply issue. V3.4.2. had a reservoir capacitor in the a.c. power supply that was only good enough for the RFM12B radio. (The RFM69CW takes less power on standby but more when transmitting, and if the mains is low, the d.c. supply collapses.) The V3.4.3 with a bigger capacitor appeared some time after September (I don’t have the exact date).

OK that’s very helpful to hear. I will try adding the 5V power supply once I have received the mini-micro adapter.