Close

First Circuit Ideas

A project log for Quarter-Century Lamp

Designing a battery-powered light to glow for 25 years

ted-yapoTed Yapo 11/03/2016 at 03:105 Comments

So, here's the first circuit idea; it's a modified version of the latest TritiLED design:

The battery is a pair of Energizer L91 "1.5V" lithium cells, which are actually 1.7-1.8 V when very lightly loaded. R1 limits the battery current in case the PIC gets stuck for a while and holds Q1 in a conducting state. Without R1, the full battery voltage winds up across the coil, which has a DC resistance of a few ohms at most (exact inductor not chosen yet) - enough power to cause burns or ignition. With R1 in place, the current is limited to 3.6/100 = 36 mA, and the dissipated power (mostly in R1) is limited to 3.6^2/100 = 130 mW - a small resistor can dissipate this all day if needed. 100 ohms in the power supply wires sounds like an efficiency killer until you realize that the whole circuit will draw around 15 uA (exact value TBD). At 15 uA average current, the drop across R1 is 150 uV, for an efficiency loss of only 0.05%. Not bad for keeping the inductor from possibly catching fire. In practice, I might want to use a 47-ohm resistor in each of the battery leads for redundancy - although they usually fail open, so this might not be the best idea. Of course C1 keeps the reserve power needed for the LED current pulses so the pulses aren't reduced by the inclusion of R1. I might add some extra capacitance at C1, which is a ceramic capacitor - there's no place for electrolytics in this type of application.

In the TritiLED circuit this is based on, two output pins are directly paralleled to provide more gate drive, and no gate resistor is used. This sounds OK unless the software goes awry (cosmic ray strike) and doesn't switch the two output lines at the same time - then, they "fight" outputting different levels, drawing lots of current, and possibly damaging the internal drivers. In this version, the outputs are again paralleled for greater drive, but each has its own resistor to mitigate problems if they somehow switch separately. Additionally, the resistors limit the peak current the drivers need to output, reducing stress on the PIC. The exact values are TBD.

I have the particular MOSFET at Q1 since it's the one currently in the TritiLED design. I have previously built these circuits with low-Vce(sat) BJTs, but the MOSFETs are a little more efficient. Unfortunately, I haven't yet found comparable low-Vgs(th) MOSFETs in through-hole packages. I'm strongly considering doing the whole circuit on a through-hole PCB, because I see many references that claim through-hole is more durable. I don't particularly care about size (the batteries will dwarf the circuit, anyway) or cost (only building a few) so through-hole is probably a better bet. The biggest reason to avoid SMD, however, is my lack of a proper reflow oven. While reflowing boards on an electric skillet might be OK for prototypes, it's completely inappropriate and untested for high-reliability devices. On the other hand, I have soldered tens of thousands of through-hole connections, and am confident that my through-hole joints will not be an issue, especially if I inspect each one under the mircoscope. I will be using eutectic 63/37 leaded solder (tin whiskers are for cat robots).

There's no mode switch like on the latest TritiLEDs - a mechanical switch is likely to fail (especially the crappy SMD ones), or conduct ESD or mechanical stress to the board. Maybe worst of all, the internal "weak" pullups on this part consume 80uA when shorted to ground. Weak pull-ups, my ass.

I'm thinking about a die-cast powder-coated aluminum enclosure with a little machining to let the photons out. I love 3D printing as much as the next guy, but expecting some case I printed to last 25 years? Nah.

Discussions

Andrew Bolin wrote 07/05/2017 at 23:01 point

Found your project via the newsletter. Not sure if you're still working on this, but one thing to consider: there's 3 more I/O pins available. You could run another set of LED, inductor, and FET from the other 3 pins. 

You would have to use a bit (literally) of memory to alternate between the two, which of course would increase your power draw. I don't know by how much, but it may be worth it for the increased reliability.

  Are you sure? yes | no

Ted Yapo wrote 07/05/2017 at 23:40 point

This has been on the back burner for a while, but I am still thinking about it.

Using the extra pins is an interesting idea - you gain redundancy of the external parts this way.

I had been thinking of running multiple microprocessors, actually.  I suspect that a cosmic-ray strike could send one of them into a state that would need an external reset - so I was thinking of a way to have a pair (or triple) of micriprocessors provide watchdog and fail-over capabilities for each other.  After thinking about this for a while, my head started hurting, and I forgot about it.

The other idea was to have a custom LED made.  I got the good people at Chanzon to build me some custom LEDs before - quite affordably, actually.  In this case, I was thinking of putting three cyan chips into a case made for an RGB tri-chip LED.  Then, you can have three redundant LED emitters sharing the same optics.  The LEDs could either be all on (in the limit, using three completely separate circuits, including separate batteries), or could be used in a standby mode (mechanism TBD).

  Are you sure? yes | no

Andrew Bolin wrote 07/06/2017 at 00:11 point

Yeah, processor redundancy is hard to do with ultra low power. Simple schemes can fail, and robust schemes use power. You probably already know this, but a very common scheme is one bit sent each way, where one device inverts what it receives. e.g. CPU A sends a 0 to B, B inverts it and sends a 1 to A. A now sends a 1 back to B, and B sends 0. If either device sees no change for x time, they can reboot the partner.

Wow, custom LEDs! I'm amazed that it's remotely cost-effective. There is of course still a failure point (the common lead), but I guess LEDs probably fail in the semiconductor rather than internal wires breaking.

  Are you sure? yes | no

Ted Yapo wrote 07/06/2017 at 00:22 point

Here's some info about the custom LEDs: 

https://hackaday.io/page/2492

  Are you sure? yes | no

Michael Stoiko wrote 07/06/2017 at 20:27 point

Something to also consider before going that far for redundant emitters:

https://www.broadcom.com/products/leds-and-displays/light-bars/single-color/hlmp-2755

  Are you sure? yes | no