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?
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.
Yes, I do have the USB to UART cable. I’m a bit of a novice with git though. When I tried to “clone https://…emontx3/tree/battery_pulsecount” the repository wasn’t found. I did manage to “clone -b battery_pulsecount https://…emontx3” if that’s what you meant?
Then I ran “$ pio run”, but it failed.
I edited my copy of the src.ino file to change TRUE and FALSE to lower case and tried it again and it compiled and uploaded ok. Seems to be running ok now without resetting. 
Thanks for your help guys.
I seem to be getting similar problems, however not using batteries…
I recently added a second emonTX3 purchased with Node 16 (and CM of course), to monitor extra circuits. I have also updated my emonPi to emonSD-17Oct19. The new emonTX3 seems to operate largely correctly, although it does need calibrating (later…).
My “old” emonTX3 is board rev 3.4.2. I decided to upgrade this to CM firmware, and this is where things started to go wrong (there is a moral here). I am using MacOS (10.11 El Capitan, oldish) and Arduino IDE with a new USB UART cable. I am new to THE Arduino IDE so be gentle please! Fortunately there are many tips and guides on here.
With the IDE connected, everything seems to work pretty well, although there are occasional frame dropouts. I thought this might be RF interference as I have quite a few other 4333mHz transmitters around the house… A problem for later.
HOWEVER, If I disconnect the IDE, the emonTX3 now continuously transmits zeroes which ties up emonhub completely:
It looks like the EmonTX is continually resetting itself? Yesterday it was working normally - without the IDE connected - for most of the time, then went into this state occasionally. Now it seems eminently repeatable. Which is (probably) good, sort of.
I may be doing something idiotic with the IDE and its connection/disconnection?
Also I cannot get it into Config Mode at startup, despite trying everything I can think of. Here is the startup sequence…
Untitled.txt (1.2 KB)
Any ideas would be welcomed.
I wouldn’t have thought so.
That all looks OK. But it didn’t accept “+++”? Have you got the IDE set to send “Both NL & CR”?
There’s no obvious reason for it sending zero values.
@TrystanLea wrote the sketch, so he might have some ideas. The mains voltage isn’t reported as being low, so while I don’t immediately rule out a power supply issue, it doesn’t look very likely.
Arghhh. IDE was set to NL! I was reassured by the fact that the “l” command was working whilst it was running! Odd that “l” works with NL setting but “+++” during startup doesn’t. Will have a look at the code when I have a minute.
OK I have Config Mode working. Thank you. I have done a Reset of EEPROM.
I was looking at this thread (EmonTX Calibration Safety) regarding AC-AC power concurrent with USB-UART. Initially I disconnected the AC-AC charger to load the new sketch, but have left it connected subsequently.
When I disconnect USB-UART the Emontx reboots. Presumably this is normal behaviour?
I think I found the reason. In config.ino the line that tests for “+++” input is:
if ( Serial.readString() == “+++\r\n”)
i.e. explicitly checking for CR NL,
whereas in the main loop the code is simply
Serial.read();
followed by a switch/case statement testing for a single char, so CR NL is not necessary.
It’s not a big deal, just inconsistent UI. And it caught me out 
I’m afraid I didn’t write it.
I can’t say that I’ve ever noticed. I don’t think it’s intentional, but the reset line is in the connector and is controlled by the UART (to put it into programming mode to load the sketch), so I can well believe that if you pull the right-hand end off first (the GND pin is the right-most, Reset is the left) you could get a reset and hence a restart.
Thanks Robert. I tried again to run the emontx3 without USB-UART power, it ran for an hour or so before going beserk again.
I have now swapped AC-AC PSUs between the old and new emontxs, and see how long that goes for.
I noticed the CM firmware doesn’t pulse the LED during transmit every 10s. Is that deliberate? Incidentally, the emontx LED goes full on when it goes into beserk mode and floods emonhub.
Yes - but I don’t know why.
That’s useful information. The LED is turned on almost immediately as the sketch starts up, and is turned off after you’ve gone through (or past) the user configuration and it’s checked which c.t’s are present, but before it reports the findings. So, if the sketch does restart, I’d expect the LED to stay on for 10 s. During that period, it does transmit the factory test sequence of Power1 having the values 10 to 0 in steps of 1, in rapid succession. Is that the behaviour that you see?
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.
Understood. I will try the DS library/sketch. Good practice using Arduino IDE 
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.
