Hi -

I have a puzzle for which I can only come up with one solution - and I'd like to know if it makes any sense!

I have built some units for a friend based on PIC18F2321 micros. The actual function is not relevant, but they are designed to operate outside, overnight, and to control some high-powered LEDs. The software includes a test of the battery voltage at switch-on in order to confirm that there is sufficient charge to run the units all night. Another function is that, when the units switch off the LEDs, at dawn, before doing so they read the battery voltage again and store it in EEPROM. This helps to check when rechargeable batteries are getting past their useful lives.

Last night I put two of these units out. When I went to bed, they were operating perfectly, having switched on automatically at dusk. When I checked them this morning, BOTH units were flashing 'b' on their displays. Now, the only part of the software that allows this to happen is the initial battery check, which displays a flashing 'b' to indicate that the battery voltage is inadequate to last through the night. Furthermore, the battery voltage had not been saved in EEPROM (don't ask how I know, just trust me!)

The only explanation that I can give for this set of circumstances in the units is that, shortly before dawn, when the batteries were fairly well-used, the units had been reset, before the auto-switch-off and saving to EEPROM function occurred. Having restarted, the self-test had then determined (correctly) that the battery voltage was insufficient for another night's use and displayed the warning signal.

But these two units were sited about 50 metres apart, in open countryside. So the only explanation that I can offer for this is that some form of electrical disturbance had reset both units before dawn. And the only kind of electrical disturbance that I can envisage out here (in a very rural area) would be lightning.

I was not aware of any kind of thunderstorm, but it is not unknown for us to have electrical storms in this area, with lightning, but without (audible) thunder and without rain.

Can anybody else think of a reasonable explanation for this, or does my explanation make sense?

Phil

 

Maybe the batteries just drained, then later recovered enough voltage to restart the micro. Hard to tell really. Maybe get them to measure the voltage every half hour and store sequentially in EEPROM, make sure it can't restart and see what results you get.

 

Given the modest amount of information I gave you, that might seem a reasonable solution! However, These units are trialled regularly (they're designed to trap moths!) and the batteries have more than enough capacity to last the night - though not quite enough to last two nights, hence the test.

So I am quite happy that the batteries had more than enough charge to last through the night - and for two to fail at the same time, having tested correctly on many previous occasions...

Interesting idea but I'm pretty certain that wasn't it!

Phil

 

Battery voltage tends to vary with temperature. Cold drains batteries, so it is possible that, during the night, the batteries drained in the cool air, then when dawn came they warmed up and the voltage was increased enough to reset the microcontrollers. Just an idea, anyway...
Der Strom

 

You've not supplied enough information about your application to come to any reasonable conclusion.

So I'm gonna guess. I think it was moths shorting out the oscillator pins forcing a reset.

 

So I'm gonna guess. I think it was moths shorting out the oscillator pins forcing a reset.

I think you forgot the smiley, Ernie!

Given that the units are sealed in plastic boxes, I think this explanation is probably unlikely.

Battery voltage tends to vary with temperature. Cold drains batteries, so it is possible that, during the night, the batteries drained in the cool air, then when dawn came they warmed up and the voltage was increased enough to reset the microcontrollers. Just an idea, anyway...

Again, not an unreasonable idea, but in this instance I think it's unlikely. The night-time temperatures here at the moment are above 20 degrees (southern Spain) and I have been running these tests for several weeks without incident. I can't believe this would have happened to both units on the same night.

More tests ongoing!

Phil

 

Both NICD and NIMH batteries have a quite flat discharge curve. But then they are at the end of capacity. They dies very quickly. I use NIHM in my outdoor headlamps. And sometimes you really do not get any "warnings" like with alkaline types. Before the light almost out of the blue dies out. Maybe your batteries come to an end. So the MCU somehow got reset due to the high load of the light in your system. But after the reset the lights was not on. And the batteries had enough juice to drive such a light load as MCU as a LCD display.

 

Need the source code to even guess.

Try logging the battery value as often as you can for a night, once per half hour maybe, or whatever the polling cycle is.

Is it written in ASM or C?

 

Also measuring battery "fitness" without some loading is quite pointless. As it may delude to think the battery is better shape than it actually is

 

Radio transmission in close proximity to the units could have affected the microcontrollers of both units. Any chance of someone using two way radio being within a mile of the location?

 

Does switch-on mean a manual switch on?

If not, does the unit have a Light Sensor?

If yes, could the light sensor said it was morning and it started a second switch on cycle. (Some light hitting the sensor; like poorly adjusted headlights or heat lightning)

Tim S.

 

Both NICD and NIMH batteries have a quite flat discharge curve. But then they are at the end of capacity. They dies very quickly. I use NIHM in my outdoor headlamps. And sometimes you really do not get any "warnings" like with alkaline types. Before the light almost out of the blue dies out. Maybe your batteries come to an end. So the MCU somehow got reset due to the high load of the light in your system. But after the reset the lights was not on. And the batteries had enough juice to drive such a light load as MCU as a LCD display.

I take your point. However, after this occurred, there was PLENTY of charge left in the batteries, so I am sure it was not down to that cause. Also, remember this happened to two separate units sited in two different locations. It has never happened before, nor since, with the same sets of batteries!

Phil

 

Also measuring battery "fitness" without some loading is quite pointless. As it may delude to think the battery is better shape than it actually is

Agreed - but if you see my original post, you will note that the battery measurement is made immediately BEFORE switching off the high-power LEDs, for exactly that reason.

Phil

 

Radio transmission in close proximity to the units could have affected the microcontrollers of both units. Any chance of someone using two way radio being within a mile of the location?

This is a possibility. My house is located on a remote hilltop and I act as a relay point for a wi-max network set up by a friend (free internet access!). So there is certainly a fair bit of RF floating around.

But, as mentioned before, this situation has never happened before, and last night I put out the same two units with the same sets of batteries, and everything worked exactly as it should.

Does anyone reckon my original explanation might just have some merit?!

 

Does switch-on mean a manual switch on?

If not, does the unit have a Light Sensor?

If yes, could the light sensor said it was morning and it started a second switch on cycle. (Some light hitting the sensor; like poorly adjusted headlights or heat lightning)

Another good question! Yes, the units do have a light sensor for just this purpose. However, in order to avoid things like car headlights, lightning flashes and even camera flashes affecting the units, there has to be a light level above a certain threshold for 30 seconds before the units will react (ah, the joys of microprocessors!) and, in any case, the sensor only controls whether the LEDs are on or not, and cannot initiate the start-up cycle again.

Phil

 

a chance occurrence of events then. A distant but powerful radio transmission. One of the HF or lower VHF channels that is often reflected by the ionosphere could have been at just the right time and freq and place to have caused the 'glitch'. Being an artifact of atmospheric propagation the event likely would not be repeatable.

 

Maybe a path to consider is that it might happen under unknown circumstances and code a reset function that tries to restore functions to what they should be. Possibly add some electrical screening to the box which might reduce the chances of it happening.
Another thought, are there any pins set as input which are not pulled high or low? I think that can cause resets.