h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

It seems my previous light design wasn't as ultimate as I had hoped.

Despite working fine in home-made light units (secondhand headset and cable, and cheap helmet-mounted battery case), some commercial setups using using swappable helmet-mounted or waist-mounted batteries can cause problems.
This is because the cable from the headset plugs into an external socket built into a battery box, and over time, the contacts in the sockets on some batteries can become corroded or slightly displaced to the point where contact isn't very good.
Just general moving around (let alone banging into cave walls) when wearing one of these setups can result in an intermittent connection. With regular bulbs in the headset, this makes the bulb flicker. When (like me) you use a microcontroller chip to control brightness levels in the lamp beams, having power randomly connecting and disconnecting can be a larger problem.

Even though strictly speaking, someone else having a bad battery connection isn't *my* problem, it could still be a barrier to them buying a lighting unit from me that isn't bad-battery-resistant, and it's an interesting challenge to try and make a digitally-controlled device as insensitive to constant supply interruption as a bulb is.

I have an idea how to tackle the problem. Since it can't just be a case of modifying the controller program unless I want to lose functionality, success depends on how much extra electronics I need, and whether I can squeeze them into an already small space.

Also, it's a little annoying when a commercial lighting system is in some ways less robust than a homebuilt one, and not possible to do much with if it does start to degrade. At least on my personal hacked-together system, if a plug fails on one of my battery packs, or on the end of my cable (mechanically well protected *inside* my battery box in any case), I can easily replace the plug with a new one for a minimal price. If the connection fails underground, I can still bodge something together that should work until I can get back to safety.

It seems my idea of a solution for the battery problem does work, within the limits of the testing I've been able to do so far.
It only adds a slight complication to the electronics to add resistance to bad battery connections, and leaves the option of the lamp operating virtually the same as previously, if desired.

In hindsight, the solution was so obvious, I'm not sure why I thought it would be difficult. It's amazing how perspectives can change in a couple of days.

So what was the solution in the end?

My design uses a PIC 12F675, which has 16 bytes of EEPROM.
Since a beam controller enters a SLEEP mode (very low power consumption) when its beam is turned off, I write a 0 to a particular EEPROM location just before entering sleep mode, and write something different there after waking from sleep.
All I have to do in the power-up sequence is check if a jumper is present to select the bad-battery-proof mode, and if so, set the beam on at high power if its switch is closed (regardless of EEPROM state), at medium power if the switch is open (and EEPROM is no-zero), or off otherwise.

The reason I didn't think of this before was that the chip I originally used didn't have EEPROM built in, and also had a problem that required me to use the (now) free pin for something else, so it wasn't available to connect a jumper to, so I'd got stuck in the mindset that I didn't have the option of changing how the controller worked.
Without the free pin to connect a jumper to, I would have had to lose some useful options and features I had with the most recent previous design that I wanted to keep. I could have made a bad-battery-only version of the controller, but I'm wary about having two circuit designs or sets of code. As it is, with the jumper not present, the lamp that behaves precisely like the previous one except for a higher power consumption when off (which actually has good and bad effects), and that is correctible by setting one configuration bit differently when programming without changing the code as such.

Though I tested the design thoroughly on a breadboard, when I built the first proper unit up yesterday, I had a strange ocasional bug when supplying interrupted power whereby both (fully independent) controllers in a lamp would power up on medium power when they should have powered up off. The fact that they seem to be affected simultaneously suggests it's something to do with the timing of the on-off pulsing that sets them off.

I think I've realised while writing this why that might be, and possibly how to correct it, though if I'm right, it's unlikely to occur much in practice. It often seems to be the way - trying to explain to someone else gives me a slightly different perspective on a problem. Cheers.

Still, if a lamp is going to misbehave occasionally, I'd rather have one that misbehaved on rather than misbehaved off.

Glad to be of help I tend to find that explaining the problem (or solution) helps me understand what's going on more as well.