EmonTx crashing, any way to get logs?

I’m trying to work out why my new emontx keeps crashing. It’ll work for a day or couple of days then stop sending updates. Alas I can’t see any logs being sent to the emonpi from it unless I’m missing something?

Absolutely nothing unusual is going on when it dies - the last update currently was 22 hours ago, so about 6pm… maybe slightly increased power usage when I got home from work? Only a power cycle seems to fix it… there are no lights showing (the blue light goes out a few seconds after power cycling and doesn’t appear to come back on).

Welcome, Tony, to the OEM forum.

I don’t think the emonTx has a blue light anywhere?

And to answer the question, the emonTx only sends data to the emonPi (via the GSM radio), it does not store any data, nor send any other information.

Both @TrystanLea and I tested the new library extensively before it was released (I’m guessing that you bought your emonTx after 18th October just gone), but the sketch I used isn’t the one that’s factory-loaded in the emonTx.

Mine was shipped on the 23rd, so would I presume be the latest version.

I’ve seen some threads that have had increased reliability by adding a 5v power source so I’ll try that.

Sorry to heat that the EmonTx is crashing @TonyHoyle, it shouldn’t crash on the ACAC adapter alone but let us know if its any better on USB power.

Are you sure the LED is blue? The LED should be red so I wonder if something went wrong there that we missed?

It is red… I clearly remembered blue but maybe got confused with the emonpi or something.

USB power added. It’s just a wait now to see if it fails again…

I’m looking for a possible cause of your stoppage. Can you tell me exactly what hardware you have;
a.c. adapter model no, and whether you have anything else connected apart from c.t’s.

From what I’ve been able to determine so far, there’s not a single obvious cause.

3 c.t’s, a recently purchased emonTx feeding to an emonpi in another room (which has been running without issue for years, but I needed 3 inputs so switched to this configuration).

The AC adapter was supplied with the emonpi… it’s an IdealPower model DB-06-09. It says its output is ‘9VAC Max. 6VA’

Since adding the USB supply the emontx has so far been stable.

I note the AC voltage around here is all over the place (15v variation in a few minutes sometimes) but I wouldn’t expect that to be an issue assuming the emontx is just deriving 5vdc from it… I’d never have even noticed if I hadn’t started graphing it :stuck_out_tongue:

That might turn out to be significant. The a.c. adapter actually goes directly to the 3.3 V supply, but in order to minimise the amount it disturbs the waveform that is being measured, there’s a very delicate balancing act between getting enough power to operate the emonTx and not drawing so much current that the wave shape is distorted too much.

Thanks for that information.

Even powering with the AC adapter now the emontx is crashing every few days. It seems to be getting worse… I’ve given up at this point… will have to try to go back to just the emonpi, which doesn’t have enough inputs but is reliable.

I’ve been running extensive test but I’ve so far been unable to pin down the cause, other than it is happening during the process of transmitting the data.

I’ve also been testing a slightly modified version of the demo sketch (that comes bundled with the emonLibCM library) but using the “transmit-only” code lifted from the 3-phase sketch in place of the complete JeeLib - and that appears to be rock solid. As I write, it’s sent 173331 messages without resetting or locking up - just before the holiday it reached 525190 messages until I got fed up of waiting for it to fail, so I recommend you try that approach.

My tests with the power supply failed to make it lock up - every time, it recovered gracefully with only the message count and energy accumulators reset to zero as evidence.

Interesting… is the binary for that available?

No, nor won’t be from me, I’m afraid. However, you’ll be pleased to learn that it’s run for the equivalent of over 400 days in normal usage without failing, I’m now testing it with a slightly improved “rfm.ino” and that so far had sent nearly 250,000 messages without a problem.

Unfortunately this doesn’t apply as described. You can’t define RF12_433MHZ as empty because of the line byte RF_freq = RF12_433MHZ; which needs a value. All the other RF12_ values need defining too as they’re read in various places in config.ino. However this breaks rfm.ino which treats them as flags.

I’ve compiled it by hacking out lines until I could get it to compile, but no idea if it still actually works. A pull request would have been many times easier to deal with… but whatever…