In software development there is a type of defect called a heisenbug. It is named after the physicist Werner Heisenberg, who stated that the more precisely a particle’s momentum is measured, the less precisely its position can be known, and vice-versa. Likewise, a heisenbug is one which disappears when you add code or try to debug it using external tools.
When I posted about the intermittent problem with the Glowbek, I had no idea whether it was a hardware or software defect. Turns out, it was somewhere in the middle.
The controller I’ve been using is an Arduino clone – specifically, a Freetronics Eleven. This particular clone has removed the low-impedance path between digital pin 13 and ground by using a FET to control the LED instead of simply plugging the LED where it fits. Why is this significant? Well, when I was programming and testing the drum, the “D13” status LED would stay dark — I noticed no problems at all. But when running off a battery, the LED would start dark, then gradually increase in brightness. The drum also never stopped responding when the LED was dark.
I had initially ignored this, as I didn’t see why there would be a connection between some random floating gate and the input line (which is pulled down). I opted instead for adding a “heartbeat” to the code, so that I could see whether the CPU was hanging somewhere, so I set DDRB 5 to output and played with the sensor.
For a solid 10 minutes.
As it turns out, what I had inadvertently done was eliminate the floating gate. It was now held either low or high by the ATMega. And simultaneously, the input problem had disappeared.
I’m still not completely sure how a floating gate connected to an input pin managed to interfere with the already pulled-down analog input for the piezo sensor. The input circuit looks something like this:
Perhaps something messed with the ADC (or one of its comparator input voltages) once the gate reached a particular charge. What I do know is that floating gates are not good things, and in agreement with some advice given to me by people with far more experience in embedded design than I, that anything not used as an input should be held somewhere.