Hi,
Having purchased a couple of stalkers v2.3 and a v2.0, I am experiencing the same problem on all units when trying to get an energy monitoring project to work. I would be interested to know if anyone else has had the same experience when using interrupt driven logging utilising both interrupts on the stalker board?
The code is from the energy monitor MKII project pulbished by airsensor.co.uk, a very useful sketch to count pulses from an electricity meter LED.
airsensor.co.uk/component/zo … r-mk2.html
The problem I have is that the stalkers will log successfully for a while, but after some seemingly arbitrary length of time will cease logging (both in terms of counting pulses and writing to the SD card) unless the reset button is pushed.
In both cases, v2.3 and v2.0 the stalker was left powered by the UartSBee rather than by battery / solar so I don’t think it is a power issue.
In one instance the logging ceased mid-way through writing a debug line to the serial monitor located in the alarm interrupt.
I suspect (but could well be wrong) that with two interrupts in play to wake the stalker from sleep (one from a light sensor that fires when a pulse is detected to count the pulse, the other from the RTC at pre-defined intervals to log to SD card) that what is happening is that a second interrupt fires before the first interrupt service routine and any other functions called by that routine can complete.
Looking at the code, though, I can’t really see why this might be the case - the pulse interrupt detaches the alarm interrupt in it’s first line, sets a flag and finishes causing the main loop to resume, which in turn will fire a log pulse function that introduces a delay of 10ms to blink an LED.
I suppose that it is feasible that in rare circumstances, the RTC alarm interrupt may try to fire during this delay should the alarm time coincide.
With the alarm interrupt detached it would fire a blank so that the alarm is never reset to a future time (not really sure how the alarm from the RTC is manifest e.g. a pulse of some duration?).
I would have thought that under these circumstances the writing to the SD card might stop but the pulse counting would continue and the pulse LED would carry on blinking, which it doesn’t.
In the case of the alarm interrupt, both interrupt functions are detached so all that I could see that might happen under these circumstances is that a pulse is missed while the data is being logged to the SD card before logging continues as before and we are none the wiser.
So, any ideas as to what might be causing the stalkers to lock up would be much appreciated? 
- just to add I have uploaded a pdf showing an outline of the sketch and its functions and while testing again today noticed that once the logger failed just before it was due to wake on alarm from the RTC, the RTC interrupt was low where usually it is high at 3.3V. I can only assume that the alarm interrupt fired but it’s interrupt service routine was itself interrupted by a pulse before it could execute the second line, detaching this other interrupt. Then the pulse flag is set and alarm interrupt re-attached without clearing its status or resetting the alarm. But this doesn’t explain why the pulse counting ceases…still confused.
Mk II energy monitor outline.pdf (166 KB)