I have 2 X EMONTX's both running the v1.91 discrete monitoring sketch. They both lock up every few weeks which I fix by bouncing the power. Unfortunately the older one of the 2 has now locked up after less than a day so I need to work out what's wrong. The activity LED is no longer pulsing when the lock ups usually happen.
i note that the compiler gives a low memory warning when it finishes, could this be an issue with the lock ups? The one that's currently locked has a 3 line addition to the code to allow it to read my wind sensor via the repurposed 1-wire power pin, and I've recently unplugged it's 1-wire sensors
we're in the middle of summer right now and it was around 30 degrees where the EMONTX is when it locked, and less than 24 hours since it last got a power on reset.
Could this be heat related?
Where should to start to troubleshoot this?
Re: EMONTX locked up possibly heat related
It could well be heat-related. Whether it's a component or whether it's the assembly (by that I mean differential expansion has fractured a track/via/soldered joint is going to be hard to determine. Short of waiting for your winter or moving it to a cooler place and seeing if the fault recurs less frequently, it's hard to know what to suggest.
The only known fault that causes the sketch to stop is where the radio module fails to respond. Usually, that's down to poor soldering, so you could check that.
Re: EMONTX locked up possibly heat related
Is it the module to board soldering that needs checking or the soldering on the module itself?
im guessing the, on compilation, low memory warning is nothing to worry about?
Re: EMONTX locked up possibly heat related
Arduino lockup can also be software related.
The Low memory warning from the compiler indicates that the remaining, initially unallocated space in RAM is lower than a threshold defined in the compiler.
This free RAM will be used for auto storage (parameter adresses to functions, local variables in called function) and heap storage.
Heap storage is used for dynamic allocation (malloc on C-level).
If dynamic allocation is used frequently, it might end up in fragmented heap storage,
and the software will crash, but in an Arduino-case, the result of the crash is "no response" or lockup.
Normally libraries used doesn't use massive dynamic allocation.
Using String-type variables is an easy way to solve text manipulation, but starts the journey into possible fragmentation, as the String-type uses dynamic allocation frequently.
Also the usage of Serial.println("something useful information")
should (normally) be replaced by Serial.println(F("something useful information"))
and in this case saving 28 bytes RAM by storing the string in PROGMEM.
This is useful for all solutions that are based on the core Print functionality or similar.
JEELABS has an old article about this, http://jeelabs.org/2011/05/22/atmega-memory-use/
I have not analyzed the libraries involved in the EmonTX setup for usage of dynamic allocation, but in the normal Emon sketches a number of c-strings can be moved to PROGMEM by using the F()-macro
/Per-Ake
Re: EMONTX locked up possibly heat related
thanks for the memory article, it's curious that this happened after I unplugged the 1-wire sensors and rebooted. I wonder if there is something odd happening with no 1-wire sensors and reading the analogue pin followed by converting the result before transmitting it which is what I've modified the sketch to do.
I've just reconnected the sensors due to a separate issue and will see how long it lasts before it dies again. It's still very hot here so it should give me a clue what's going on.
Re: EMONTX locked up possibly heat related
6 1/2 days on and since plugging the 1-wire sensors back in and power cycling its behaved flawlessly. Either there was a power spike that only crashed one of my 2 EMONTX's or it doesn't like running sketch v1.9 with no 1-wire sensors.