The device goes to sleep when the engine is not running so as to reduce battery consumption. While in sleep mode the INTs can still be triggered (to initiate software actions).
The Issue: While in sleepmode and sometimes during normal operations a standard lighter piezo will trigger the INTs. Also, other nearby switches will sometimes cause false triggers when they are used during normal operations.
I'm looking to redesign the pcb and wanted to get advice on what circuit changes could be used to eliminate the possibility of false trigger.
I've looked at a few options; Schottky Barrier Diode, transient-voltage-suppression (TVS) diode, Zeners. Maybe if I can solve the piezo issue the rest will also be addressed?
Suggestions? Also, space is limited on the PCB so just another consideration.
Project power cables are twisted? Ferrite beads as close as possible to the power cable connections as possible? Signal cables away from thingies? Doing a search on the internet using the words "automotive power protection schematics"?
This demonstrates why using interrupts to service buttons and switches is such an overall bad idea!
You may need to use the interrupt to wake from sleep, but should not use it in any other fashion. Clearly the "software de-bounce of interrupt" is not very effective. Software de-bouncing using polling is far more practical. Of course, you will not be able to prevent an impulse waking it from sleep.
You clearly have a problem with wiring layout and shielding.
Idahowalker:
Project power cables are twisted? Ferrite beads as close as possible to the power cable connections as possible? Signal cables away from thingies? Doing a search on the internet using the words "automotive power protection schematics"?
The project actually controls about 5-8 amps of 12v lights on the motorcycle, so can't do twisted pair cabling. I've thought about an SMD ferrite discreet, but don't have the physical room on the PCB.
Paul__B:
This demonstrates why using interrupts to service buttons and switches is such an overall bad idea!
You may need to use the interrupt to wake from sleep, but should not use it in any other fashion. Clearly the "software de-bounce of interrupt" is not very effective. Software de-bouncing using polling is far more practical. Of course, you will not be able to prevent an impulse waking it from sleep.
You clearly have a problem with wiring layout and shielding.
I agree the choice to use the interrupts for the button was a concern, but I couldn't think of any other way to use the same SPDT Momentary switch to both Wake from Sleep and trigger without false interference. If you have any suggestions, sure would appreciate that!
I also looked at the PCB layout and did find that i have traced the one input not very efficiently to the 328 pin. Will be redoing that.
Bwanna:
I agree the choice to use the interrupts for the button was a concern, but I couldn't think of any other way to use the same SPDT Momentary switch to both Wake from Sleep and trigger without false interference.
It is as I explained.
When you go to sleep, you (first!) enable the interrupt. The interrupt routine does nothing, but when it returns, you disable the interrupt and proceed to poll the switch/ button as the loop() cycles freely (that is, with no delay() or similar effect).
To de-bounce, you poll the corresponding input noting its previous state, and consider it a valid change of state only when the new state is found on every poll until millis() has advanced by the de-bounce interval, generally something like 10 ms by which time it is reasonable to expect that any particular interfering impulse has long since settled.
When you go to sleep, you (first!) enable the interrupt. The interrupt routine does nothing, but when it returns, you disable the interrupt and proceed to poll the switch/ button as the loop() cycles freely (that is, with no delay() or similar effect).
To de-bounce, you poll the corresponding input noting its previous state, and consider it a valid change of state only when the new state is found on every poll until millis() has advanced by the de-bounce interval, generally something like 10 ms by which time it is reasonable to expect that any particular interfering impulse has long since settled.
Paul, I really appreciate the explanation. I didn't see what you were saying. I'll redo the code and giveit a try.
Thanks!
