Emontx intermittently transmitting zeros

Tags: #<Tag:0x00007f56b7b75da8>

Just got my new emonbase and emontx v3 connected, with emontx running on 3 AA batteries. I’ve added the feeds ok, but emontx is only intermittently reporting valid values. It keeps reporting zeros, then some valid values then zeros. Have I missed something in the setup? The batteries I’ve put in are rechargeable. Is it continually rebooting because the batteries are low or something? The spec for emontx says you can remotely monitor battery level. Is there a link that shows how to do that?

Note, I was charging an electric car at 4.4kw at the time so the 4k+ values received sound right.


The count down (10 → 0) in the first byte is the factory test as the emonTx is powered up.
Here’s the code:

    rf12_initialize(nodeID, RF_freq, networkGroup);                       // initialize RFM12B/rfm69CW
    for (int i=10; i>=0; i--)                                             // Send RF test sequence (for factory testing)

      PayloadTX tmp = emontx;
      #ifdef RF_WHITENING
          byte WHITENING = 0x55;
          for (byte i = 0, *p = (byte *)&tmp; i < sizeof tmp; i++, p++)
              *p ^= (byte)WHITENING;
      rf12_sendNow(0, &tmp, sizeof tmp);

So it sends the numbers 10 down to 0 with 100 ms delay between them.

It should do that once. If it’s doing it all the time, it could be the battery voltage is too low - or the cells’ internal resistance is too great - to sustain the current needed to transmit, or it is the watchdog firing. The first is very likely to be causing a reset, the second certainly will.
I’ve never tested on batteries, so I can’t confirm that. 3 × 1.2 V is however pushing your luck, so that’s the most likely cause.

The sketch you’ve got is specifically for non-battery use, so it doesn’t report the battery voltage. If you’ve got the appropriate USB lead and a phone charger, or you can temporarily run a mains lead out to your meter box and connect your a.c. adapter, it should work correctly.

1 Like

I ticked the box for the 3 AA battery holder when ordering the emontx which, according to the shop, means it comes pre-installed with the low-power consumption firmware for use with batteries. I’ve switched to 3 brand new duracell 1.5v batteries. It is better but still intermittent. I’ve got 3 CTs and the optical pulse counter. When I disconnect the pulse counter it seems more stable, so perhaps the batteries can’t supply enough power to handle the pulse counter.

Is there a way to tell if I’ve got the battery firmware installed? Is there an extra feed available with the battery firmware?

You do in fact have the “DS” (Discrete Sample) sketch - the last line of the screenshot was covered up by the caption - and that’s where the difference is. The test output is the same for both.

In that case, the battery voltage is reported in the “Vrms” slot, which is the 5th variable, 3.48 in your case. It switches to reporting battery voltage if no a.c. input is detected at start-up. 3.48 V is OK for rechargeable cells, but low for alkaline.

The optical sensor takes no current normally, but (according to the shop web page)

Current Consumption - Pulse: 7.5mA @5V for duration of pulse (standard meter 100ms)

3 new alkaline cells should be able to support that, so I’m rather struggling to see why it’s falling over. Unfortunately, my emonTx V3.4 and optical pulse sensor are in use for a test for the next few weeks, so I can’t make any measurements using it.

Are you able to give it a temporary mains supply? The reason I’m keen to see what happens then is there are two separate power supplies: the 5 V USB, FTDI programmer and battery holder feed into a MCP1702 regulator connected directly to the 3.3 V used by the processor and radio, whilst the a.c. adapter feeds into a MCP1754 that feeds into the 3.3 V via JP2, the link right next to the battery holder.

I’m starting to wonder whether you have a high resistance joint somewhere - either in the battery holder itself or a badly soldered joint on the board.

With alkalines, Vrms is 5. I’ll have a go at connecting a USB supply and let you know what happens.

With a 5V 1.5Amp DC supply connected, 3 CTs and the optical sensor, I’m still getting the resets. Does that point to a possible bad solder joint?

They happen about once every 90s, as seen below, until I disconnected the pulse counter, at 15:15, when the resets stopped.

That’s definitely something I’ve not heard of before. Did you notice whether the resets coincided with a pulse from your meter - it certainly looks like that could be what’s happening.

A lot of people have used the optical pulse sensor with that sketch, so I think we can discount a programming error. That leaves a faulty pulse counter or a faulty emonTx. Unfortunately, I can’t think of a test you can do to find out which is faulty - it might even be both as removing the pulse sensor when running on batteries didn’t make the problem go away. I think it’s time to email [email protected], and mention this thread.

How much “more stable” is it with the pulse counter disconnected?

Does it stop resetting entirely?

Can you confirm how frequent the data packets are when it is running? Perhaps attach a emonhub.log that spans 2 resets. The packets should be every 10s but maybe much faster in this instance.

Maybe not, most pulse counting users have an AC adapter rather than running on batteries. See the Reliability of Emon Pi and purchaser expectations thread for a related issue.

long story short …

AFAIK that fix is still in a separate “battery_pulsecount” branch, here are the proposed changes for the then provisional “v3.0”

But the mainstream “master” firmware has since moved on with (another) v3.0 (Zero unused CT’s), v3.1 (serial config prompt) and v3.2 (watchdog) so maybe the installed “battery friendly” DS firmware is currently still not “pulse counter friendly” when running on batteries perhaps, and the symptoms have morphed due to the later addition of the watchdog.

1 Like

I can confirm it seems completely stable without the pulse counter and regularly resetting roughly every 90s with it.

My meter box is on an external wall and has no room inside for sockets anyway. It would be quite a job to get permanent supply to it, hence the need to run off batteries.

Looks like the battery_pulsecount branch never got merged in, good find @pb66. It’s been 3 years since that work was done so would need revisiting and may take some time. Your welcome to try that branch of the firmware if you like in the mean time @richy1995, do you have a USB to UART programmer?

1 Like

I don’t think I ever knew about the “battery_pulsecount” variant - or if I did, I’d completely forgotten about it.


Same here, I’d forgotten about it. Looks like it worked for Penny at the time on the linked thread.

1 Like