I'm running an emonTH with my gas phototransistor sketch (code) and twice it's just stopped transmitting. After half an hour in each case I've popped a battery for a second or two to reset it, with good results. It ran for around 30 hours the first time, but only 10 the second time (and has been up for an hour since).
It might be a battery issue, but the battery ADC is reporting 2.8V, just under full voltage (I'm using AA primaries I had lying around).
Failing that, I guess it must be an issue with my sketch - perhaps it's running over memory (I made the sketch more complex between runs, so the reduced runtime might reflect increased memory footprint, although I wouldn't have expected so).
Can anyone recommend troubleshooting tactics? I can't access the unit with serial while it's deployed (and it wouldn't be logging anyway) but I wonder if I could add a memory check of some sort and transmit as a debugging input to emoncms?
Is there anything else in terms of the health of the unit that I could transmit?
[edit: looks like it might have stopped calling in again, after just an hour this time. If so I guess that would point strongly to a battery issue, in which case: ]
- is 2.8V not sufficient? How much capacity is expected from 2AA in terms of voltage drop?
- is it possible that the battery ADC isn't reporting voltage correctly? (I could check by changing the batteries and/or with a multimeter)
Thanks,
Re: Troubleshooting a frozen emonTH [solved]
Just a note on a little more investigation, in case anyone follows a similar path:
Pretty basic: we are boosting the voltage from the AAs so there should be no issue with them running down to just 2.8V (see http://openenergymonitor.blogspot.co.uk/2013/10/emonth-update-hardware.html ) and this means it's unlikely to be a hardware issue after all. More likely a problem with the sketch, as you'd hope...
I uploaded a stripped-down version before leaving the house with the debug removed, which I thought would provide a little breathing room in SRAM by not loading all the strings. I also changed a few ints to bytes (desperate measures!) but to no avail.
I'll start reporting freeMemory() to emoncms and see if that looks like a likely culprit. There must be something...
Re: Troubleshooting a frozen emonTH [solved]
OK, freeMemory() reports a constant and ample amount of memory - 1720 - right up to the point the node stops transmitting.
1720 is actually more than I thought was even on the device, so perhaps the function's not that useful, but the fact it doesn't change leads me to suspect there isn't an insidious leak.
There were two while() loops in my original sketch - here and here - and I figured these were natural candidates for hanging up the emonTH.
I removed the first by switching to use sendNow() - although that probably has a loop internally - and 'fixed' the second by incrementing an integer while waiting for the MilliTimer to ping, so the loop can run at most 32k times before returning - just to make sure it couldn't hang.
I loaded this sketch onto a second emonTH but after a few call-ins it also fell silent.
Re: Troubleshooting a frozen emonTH [solved]
I think the next step is to cut down to a minimal sketch that sends emoncms an int counter each time it loops, then carry across the transmission method from these sketches and see if that's enough to hang to device. If I can get it to fail quickly enough I can potentially use serial output to figure out what's going wrong.
Re: Troubleshooting a frozen emonTH [solved]
Got it - calling power_spi_disable() led the sketch to hang. I was also multiplying a delay given in ms by 1000, which didn't exactly help...
Moving that line made everything smile again.