Multi-year always-on LED replacements for gaseous tritium light sources

Similar projects worth following
TritiLEDs are always-on battery powered LED glow lights for general night-time marking use. Radioactive gaseous tritium light sources (GTLSs) are allowed in the United States in several consumer product categories, including watches, compasses, and gun sights, but general-purpose markers are considered "frivolous" and are prohibited. Leveraging advances in LED efficiency, battery capacity, and microcontroller technology, TritiLEDs run from 1 to 25 years depending on battery choice, and while larger than typical GTLSs, can replace expensive and sometimes illegal tritium lighting in a variety of applications (including the frivolous). Version 1.0 of the hardware and software is complete and released under an open-source (CC-BY-SA) license. Version 2.x is a work-in-progress and will be documented here as it is developed.


This is a project born of frustration. As an amateur astronomer and astrophotographer, I often find myself stumbling around expensive and fragile equipment in the dark. A few years ago, I went looking for glow-in-the-dark markers I could attach to tripod legs and other gear to avoid costly accidents. I quickly dismissed traditional glow-in-the-dark (phosphorescent) materials because of their short half-life and the need to "charge" them before use. Chemiluminescent markers (glow sticks) are better in this regard, but are too expensive to continually replace, and end up in landfills after one night's use. Radioactive markers (especially tritium-based), with their constant glow and multi-year half-life, are technically almost perfect for this application: you can stick them to equipment and you're done. The problem with tritium markers is that they're not legal for manufacture or sale as general-purpose consumer devices in the United States (watches, compasses, and gun sights are exceptions). Even where they are legal, they are still quite expensive. This leaves electronic markers, but these often share similar shortcomings with other glow-in-the-dark technologies: constantly charging or replacing batteries, short-duration illumination, or high long-term cost. What I wanted was a small constantly-glowing LED that I could put somewhere and not have to service for a year or more. Unfortunately, most portable LED lamps are designed as flashlights - they emit a relatively powerful beam for a short duration (hours or days) per battery or charge. There's a race in the industry to make brighter and brighter lights. I wanted to go the other way: relatively dim lights, useful in dark situations, that maximized runtime.


Lithium battery powered devices are more dangerous than small tritium light sources, despite the NRC's paternalistic approach and the general public's fear of "radiation." According to the Energizer CR2032 datasheet, an ingested lithium battery can lead to serious injury or death in as little as 2 hours. Further, improperly stored coin cell batteries can short out and cause fires or burst and cause chemical damage. These batteries must be kept out of reach of children and pets at all times, and following Energizer's advice, batteries should be held in compartments with captive screws or other childproof latching devices. While the neat little glowing LEDs may look like a fun thing for a child to play with, children should not be allowed to play with these devices.

Version 1.0

TritiLED V1.0 is superseded by the much more efficient V2.x designs, and is no longer recommended. This older version uses a relatively expensive (but nearly ideal) Luxeon Z LED, and runs for a little over a year on a CR2032 battery (verified). Alternatively, it can run for 5 years (estimated) on a pair of lithium (Li/FeS2) AAA batteries, or 15 years (estimated) on a pair of lithium AA's. You can see the details in the project logs.

Version 2.x

Version 2.x improves on the earlier design by driving the LED at close to maximum efficiency using a simple inductor-based boost circuit. This design also features:

  • Selectable brightness / run-time trade-off
  • Bright blinking modes (constant / fast blink / slow blink) with constant runtime
  • Inexpensive LEDs in many colors
  • Hand-solderable SMD design

Due to the higher electrical and LED drive efficiency, the V2.0 circuit will run for 5 years on a CR2032 (minimum brightness). The brightness can be increased at the expense of run time. Alternately, higher-capacity lithium cells can be used; I'm developing a derivative of this circuit in #Quarter-Century Lamp that's expected to run continuously for 25 years.

The design is currently in it's third board spin (V2.2). If these boards work as expected when they return from the fab, I'll release all the design files (MIT License).


Eagle library for components used in TritiLED designs

lbr - 26.51 kB - 04/27/2017 at 19:46


JPEG Image - 1.28 MB - 09/08/2016 at 18:31

Preview Download


python code for modeling LiMnO2 and LiFeS2 primary cells running low-drain devices

x-compressed-tar - 4.28 kB - 09/03/2016 at 16:32



octave code and data files for calculating scotopic luminous flux for selected Luxeon Z LEDs

application/x-compressed-tar - 10.07 kB - 08/27/2016 at 15:39


initial octave code for LED current drive waveform efficiency optimization

x-zip - 1.74 kB - 08/16/2016 at 19:05


View all 9 files

  • PIC Programming Adventures

    Ted Yapo11/20/2016 at 04:40 0 comments

    I received a batch of V2.1 PCBs this week - this was the board where the reverse-battery-protection MOSFET was backwards. Rather than leave it out, I decided to use a 100-ohm 1206 resistor instead. This limits the current in case of reverse insertion, and protects against rogue PIC code holding the pulse MOSFET on. The resistor is actually a decent fit on two pads of the incorrect SOT-23 MOSFET footprint:

    This resistor is designed in as part of the V2.2 board, in addition to a properly-connected P-channel MOSFET to handle reversed batteries. I usually give boards a quick look under the microscope after reflowing them on the skillet, if only to remove the occasional solder blob, and everything on this one looked fine.

    When I went to program this board, though, I kept getting errors - the device ID was always read as 0,and if I persisted, programming failed. At first I thought that there was flux on the programming pads so the pogo pins weren't making good contact. I cleaned the pads with alcohol, then shined them with a pencil eraser, but no luck. I finally soldered wires to the pads to connect directly to a programming header - same problem.

    Then I started to wonder about that resistor. Here's how it looks in the circuit:

    The ICSP connections are shown as bubbles. For programming the TritiLEDs, I power the PICs from the programmer - they only consume microamps when they're running, so there's no problem. I think what's happening is that the Vdd to the chip takes a little while to come up, having to charge the 10uF cap through the 100 ohm resistor. This prevents the PIC from going into programming mode when the Vpp line is raised.

    After some searching, I found the MPLAB IDE setting for "Apply Vdd before Vpp" with the PICkit3. With that set, the board programs just fine. Elapsed time to debug problem: 3.5 hours. This included some very close observation of this new batch of boards - discussed below. The Vdd programming pad is on the other side of the resistor on the V2.2 board, which is why I didn't see the same problem there.

    There's another problem with these boards besides the reversed MOSFETs. The boards have a HASL finish - this can be a problem for battery contacts - with the CR2032 holders I'm using, one of the contacts is a pad on the PCB. Memory Protection Devices, which manufactures many coin cell holders, recommends nickel or gold finish for these contacts in their application note. I think I'll have to pay for ENIG going forward. It's not as good as "hard gold," the thicker coating usually used for edge connectors, but it's probably much better than HASL. Even if the thin ENIG gold were to wear off, there's nickel underneath (some thickness, anyway). Another reason to use OSH Park.

    I actually got two batches of boards in the mail this week - one was the V2.2's from OSH Park, which looks like it may be the final PCB design for version 2 - I'd like to assemble a few more of them and run some more tests before I declare victory. The other was the V2.1's from This was my first experience with this service, and they seem OK - quality maybe a little worse than iTead (not even in the same league as OSH Park), but they're cheap and they warn you over and over that their boards are dirty. You can see the mis-alignment of the soldermask and silkscreen in the image above - look at the programming pad (now blobbed with solder). They do offer your choice of soldermask color for no extra charge. Even though the electrons don't care sometimes you do.

  • These LEDs are too blue...

    Ted Yapo11/09/2016 at 01:23 0 comments

    So, in the quest for the Goldilocks LED, I decided to measure the spectrum of the two Chanzon 3W LEDs most likely to be the best for nighttime visual markers: cyan and green. My first impressions of the cyan LED was that it was significantly more blue (shorter wavelength) than other "cyan" LEDs I have seen. To get to the bottom of the issue, I dusted off my Project STAR spectrometer I bought years ago and coupled it to a webcam:

    Also shown is the fluorescent tube I used for calibration, producing the following image:

    Calibration for this spectrometer consists of sliding the transparent plastic scale to line up the bright mercury emission line at 546.6nm with the calibration mark. Additionally, you can see that the other strong lines end up where they belong.

    Here's the spectrum for the cyan LED:

    It shows a peak around 495 nm. The "specifications" for this LED state between 490 and 505 nm (no binning; you get the luck of the draw), the latter being almost ideally aligned with the dark-adapted eye sensitivity curve. I was hopeful that these numbers represented the spectrum at high current, accounting for the blue-shift seen in InGaN LEDs, so that at lower currents, they would emit longer wavelengths. Even so, this LED is still the best of the bunch for visibility in the dark.

    Here's the spectrum from the green LED:

    The peak here is around 520 or 525 nm, which as discussed before represents a good trade-off between day and night vision sensitivities.

  • Version 2.1: 5 Years on a CR2032 in 19 Different Colors

    Ted Yapo10/31/2016 at 21:05 14 comments

    Here's the latest version using the inductor boost topology, along with the matching programmer board. With a barebones program loaded, this particular unit should glow for almost seven years on a CR2032 (consuming 3.6 uA) - it runs for seven seconds after the battery is removed just from the 10uF of capacitance on the board. Adding code for blinking modes (selected with the button) and some "safety" instructions which periodically re-initialize RAM in case of radiation-induced soft errors brings the runtime down to just over 5 years.

    OK, now the fine print. Three of the 19 "colors" are infrared, so you can't see them with the naked eye. However, they work great as markers with a cheap Gen 1 night vision scope (which I'm certain is bombarding me with X-rays every time I use it). Another "color" is ultraviolet, which should be useful for charging phosphorescent materials, but I haven't tried it yet. Finally, the barebones program has a 32Hz blink rate, which is noticeable in the daytime (surprisingly, the flicker isn't noticeable in the dark, at least to middle-aged eyes). Increasing the blink rate to 64Hz eliminates the flicker, doubles the brightness (to around the level of the V1.0), and increases current draw to 9.1 uA, or about 2.7 years on a CR2032. Further brightness increases come with correspondingly shorter battery life.


    I'm currently testing the hardware and software. I know at least a V2.2 will be required, since there's a hardware bug in version 2.1; the reverse-battery-protection p-channel MOSFET source and drain got reversed somehow (I should fire my PCB designer). Interestingly, the device still works, except it offers no protection from reverse battery insertion. Unfortunately, I bought a bunch of boards already, but there's enough room on the board for a quick re-work, or the MOSFET can be omitted entirely.


    I added programming pads on the board to mate with a matching programming adapter board (see below). This is the first time I've used pogo pins, and they're working great. I thought there would be some issue with aligning the boards during programming, but it's very easy to hold them together. Right now, you need a Microchip programmer to plug into the adapter, but I'm considering using @jaromir.sukuba's Arduino-based PIC programmer idea to eliminate the need for a separate programmer. I added a hole in the top so you can see the LED during programming.


    This project was called "TritiLED" because I wanted to make substitutes for GTLS tubes. Since the 5-year version is less bright than the previous versions, it seems best to evaluate it in the original application. After all, you can just keep turning down the brightness to extend the runtime. Here it is compared with a 150 mCi (that's milli-Curie, not micro) tritium compass manufactured in 2016 and a LumiNox watch from 2015. The compass contains the brightest GTLS tubes I have ever seen, and the TritiLED is still many times brighter. It is certainly functional as a nightime marker.

    With the lights on, the glow from the compass and watch has disappeared, but the TritiLED is still visible:

    There's no need to keep the light dim, though. The Maxell CR2032 datasheet lists the "nominal" discharge rate at 200uA (1000-hour rate), which is about 40x as bright as the one shown above. With larger cells/batteries, this circuit can produce a maximum of about 2000x as much light, which would be around 10mA drain (about 350 hours from 2x lithium AA's).

    Circuit Design

    Here's the design for version 2.2:

    Q2 protects the circuit (and battery) in case the power is connected incorrectly - it only allows current to flow with the proper polarity. Unlike a simple blocking diode, the MOSFET introduces almost no voltage drop in this circuit, maintaining high efficiency. The PIC12LF1571 sleeps most of the time, periodically awakened by the internal watchdog timer to pulse the LED. GP4 and GP5 are paralleled to provide more current drive to switch...

    Read more »

  • Intermission

    Ted Yapo09/03/2016 at 23:09 0 comments

    I'm taking some time off from this project, and mostly wanted a placeholder so I can remember where I left off - I have a bad habit of "taping over" memories from suspended projects. So, this is just a jumble of thoughts I'll update as they come until I start this thing back up.

    The Energizer Cylindrical Lithium Primary Battery Applications Manual has some great info about this unique battery chemistry, and discusses the two-stage discharge seen in the graphs, temperature performance, etc. The only thing I don't like about these batteries is the need to use spring contacts, which are notoriously unreliable. I would like to spot-weld tabs on them. A homebrew spot-welder may be in my future. I guess I should ask Energizer if they produce tabbed versions first.

    The previous lumens/watt calculations I did for the Luxeon Z LEDs use the datasheet-reported output at 500mA, so they're a valid comparison assuming the three LEDs share a similar efficiency curve, which is doubtful. I need to actually run the tests to compare these LEDs properly.

    I should compare the battery model to back-of-envelope calculations. I should also add a model for ultra-capacitors, which would be trivial. Of course, just running with a capacitor (if you have one) would be a quick test, since the energy density is low.

    The V1.0 design isn't protected against reverse battery insertion, which is easy to do with coin cells. This paper from Ti discusses adding a MOSFET to protect the circuit with minimal loss. Assuming I end up using a MOSFET for the LED driver, I might be able to find a dual version cheaper than two individual parts.

    I didn't think to compare the efficiencies of different LED colors - it turns out that green LEDs have traditionally been less efficient than other colors, although this information is probably dated. It would be interesting to survey the field and see where the most efficiency (electrical-to-eye-sensitivity) ones are. The luminosity curve probably dominates here, so even inefficient LEDs near the eye sensitivity peak win.

    It might be interesting to consider smaller batteries. The CR2032 has decent capacity and is widely available, but is a little bulky compared to the other components (at least until I start using larger LEDs).

    I need a way to make some simple absolute intensity measurements. All the data I have been able to collect so far for LED intensity has been relative. If I can measure the absolute output at even one current setting for an LED, I can calibrate the relative intensity measurements. This would allow comparison of the intensity of different LEDs. I think I'm going to build an integrating sphere with a 12" hollow styrofoam sphere and barium sulfate paint. It should be easy enough to get a reading for the total output at high current, which will be enough to calibrate the whole relative curve.

    Jim Williams wrote a few applications notes detailing his designs for very efficient fluorescent LCD backlight drivers. The technology is different, but the idea of measuring and optimizing electrical-to-optical efficiency is the same. There are probably some good clues in there.

  • Estimating Battery Lifetime

    Ted Yapo09/02/2016 at 22:16 0 comments

    I've created a model for common lithium primary cells to predict the run-time for very-low-drain devices. Here's the estimated intensity of the V2.0α circuit run from a CR2032 cell. The light lasts for over two years, with the brightness only dropping about 10% in the last six months.

    To estimate the performance, the first thing I did was make a better prototype, shown here consuming less than 13uA from a not-quite-fresh CR2032:

    This prototype uses an SMD 1mH inductor, which was glued to the top of a V1.0 PCB. In this case, the PCB just acts as a mount for the Luxeon Z LED, which has to be reflow soldered - no other components of the V1.0 circuit were populated. The circuit is the same as shown in the previous log, using a PIC12LF1571 and a ZTX618 transistor as switch. No RC snubber network is used. This breadboarded version uses almost 1uA less than the solderless-breadboard one. I haven't directly compared the brightness yet, but it seems similar. The difference may be due to the new SMD inductor vs the previous through-hole one.

    LiMnO2 Battery Model

    I've been using a simple model for LiMnO2 batteries (the "CRx" series like CR2032's or CR123A's) for some time. The model seems to work pretty well under the following assumptions:

    1. current drain is averaged, by capacitance if required, to near-DC: no strong current pulses
    2. average drain is less than 0.0005C. This is around 100uA or less for a CR2032 or 800uA for a CR123A.
    3. temperature is assumed to be constant around 20C
    4. battery shelf-life is not exceeded. The model considers the battery dead after the shelf-life has elapsed, regardless of the predicted remaining capacity. Shelf-life for LiMnO2 batteries is commonly considered to be 10 years, while that of LiFeS2 cells (lithium AA and AAA) is 20 years.

    I based the model on the following curve from the Maxell CR2032 datasheet, which shows the cell voltage vs used capacity for a 1M resistor (solid line; ignore the lower pulsed discharge curve):

    I digitized this curve and wrote some python code to model the battery from this data. The battery object is initialized with the nominal cell capacity (in mAh), so that different sized cells can be modeled. Three functions complete the battery model:

    • battery.dead(): reports true once either the remaining capacity drops to zero or the shelf life is exceeded
    • battery.voltage(): returns the cell voltage based on the remaining capacity using interpolated digitized data from the above curve
    • battery.use_amp_seconds(amps, seconds): decreases the remaining capacity of the cell by amps * seconds

    The model is intended to be used in an integration loop, as shown in the following code for simulating constant-resistance discharge. At each time-step (chosen to be one hour here), the battery voltage is estimated based on the remaining cell capacity. The current draw of the device (in this case a resistor) is evaluated given the source voltage, and this current is used to decrease the remaining cell capacity. The loop continues until the battery reports dead.

    #!/usr/bin/env python
    import sys
    import Li_battery
    # constant resistance discharge
    R = float(sys.argv[1])
    # integration time step in seconds  
    timestep = 3600.
    battery = Li_battery.LiMnO2(220.)
    t = 0
    while not battery.dead():
      voltage = battery.voltage()
      print t/3600., voltage
      current = voltage / R
      battery.use_amp_seconds(current, timestep)
      t += timestep

    Using this program, I was able to re-create the following plot from the datasheet for constant-resistance discharges:

    The curves match very well, and the model is able to re-produce the expected run-times and voltages with two exceptions. First, the predicted voltage for the 15k curve is too high - but, this resistance results in a nominal drain of 200uA, or 0.0009C, which exceeds the valid range of the model (violates assumption 2 above). For high-drain devices, which deplete the battery relatively quickly, you might be better off just testing the real device than trying to model...

    Read more »

  • Version 2.α

    Ted Yapo08/30/2016 at 18:33 0 comments

    I breadboarded a first cut at a more efficient circuit this past weekend. Consensus is that it appears a little brighter than the 1.0 circuit (not measured with the camera yet), and a back-of-the-envelope estimate says it will run for two years on a CR2032 battery (a better analysis is coming in the next log). It consumes 49% less current than V1.0, and can be made to blink bright flashes instead of a constant glow while maintaining the same current draw. The circuit incorporates some good ideas suggested by Jaromir and Tony. Here's the mess of a prototype:

    Pulse Circuit

    The design started with an analysis of the efficiency of sawtooth current drive waveforms for the Luxeon LED, as I did for a 5MM LED earlier:

    With sawtooth waveforms like those produced by the inductor-LED circuit I had simulated before, the best LED efficiency is seen at around 13 mA peak current. After a little experimentation with PIC clock speeds and inductor sizes, I came up with this circuit that generates peaks of around 15 mA (roughly estimated from peak LED forward voltage and the measured I/V curve):

    The design is based on discussions I've had with Tony about single-shot boost converters, and it works pretty well, as long as the LED doesn't have a reverse-protection diode inside (this one does not). A 1 mH inductor is huge for a switching power supply, but all of the four different through-hole styles I had in this value worked in the circuit to some degree. One was superior, though - I will need to find an SMD version with similar properties. As discussed earlier, pulses from the PIC turn on the transistor to magnetize the inductor, then the inductor "discharges" through the LED to create the light pulse. For these tests, I used a modern PIC as suggested by Jaromir. So far I've only used a PIC12LF1571 I had on-hand; I am also going to try a PIC12LF1552 which is supposed to have a slightly lower sleep current.

    The ZTX618 is an awesome transistor (at a premium price), with super-high beta and super-low Vce(sat) - evidence of this can be seen in the waveforms below, where the collector of Q1 drops to 38 mV during the pulse. The high beta allows a high value for R1, limiting the wasted base current. D2 is critical to achieving high efficiency with this circuit - without it, Q1 turns off slowly, wasting power at the critical peak inductor current. Here are the waveforms observed at the input, driven by a single PIC output pin (channel 2, cyan), and at Q1's collector (channel 1, yellow). The supply voltage of 3.04 V (channel 3, magenta) is shown at the same offset as channel 1.

    Two things are immediately apparent. First, you can see the trick to lighting LEDs with these small current pulses - use multiple pulses every time the PIC wakes from sleep. Here, the PIC is waking every 16 ms to output two pulses. Waking every 8 ms to output a single pulse is less efficient because of the overhead involved in starting the PIC clock each time. Waking less often to generate more pulses is even more efficient, but the blinking becomes noticeable. Push this far enough, though, and you get a very brightly flashing beacon at the same power. Pulsing the LED 128 times every 1 second produces a nice attention-grabbing display using around the same average current.

    The second thing evident is that the circuit rings like a bell after each pulse. The delay between the pulses is actually chosen to coincide with the ringing, so that the next pulse starts on the down-swing of the oscillation. Fine tuning this delay seems to add a few percentage points of efficiency. You can see the spikes in the spectrum at 145 kHz and the second harmonic at 290 kHz here:

    A PCB made for this circuit probably wouldn't make an efficient radiator for these LF frequencies, but since one of my hobbies is hunting LF navigation beacons, I wanted to clean this up. I had previously dealt with this kind of ringing in another circuit following the advice in the Ti Applicaton Report SLPA010 "Reducing...

    Read more »

  • Calculating Scotopic Luminous Flux

    Ted Yapo08/27/2016 at 13:17 0 comments

    I'm working on a new circuit (really!), but did these calculations last night, and thought the results were interesting.

    LED datasheets often quote the luminous flux in lumens, based on the daytime visual sensitivity curve (photopic vision). This is calculated by integrating the LEDs spectral radiant flux with the photopic luminosity function, and reflects how bright the LED appears to daytime-adapted eyes. For nighttime marker use, we are interested in "scotopic lumens" which would more accurately measure how bright the LEDs look to dark-adapted eyes. I scraped the LED spectral curves from the datasheet and with some numeric manipulation in an octave script, calculated the scotopic luminous flux for the three Luxeon Z LEDs I have been looking at:

    Color Photopic Lumens (datasheet) Scotopic Lumens (calculated) lm/W (photopic) lm/W (scotopic) Electrical Power (W)
    Cyan (LXZ1-PE01) 68 782
    46 528
    Green (LXZ1-PM01) 108 618
    71 407
    Lime (LXZ1-PX01) 199 642
    142 459

    The datasheet lists the output at 500 mA, so I multiplied by the forward voltage (from datasheet curves) for each of the LEDs to get the input power.

    The lm/W (electrical watts) columns in the table are the most interesting. For true dark-adapted vision (like in a cave or really good astronomy site), the cyan LED wins at 528 lm/W - but, this LED is poor for daytime vision. During the day, the lime LED is far superior to either of the others at 142 lm/W - and it takes a close second place behind the cyan at night. If you're making a glow marker and want it to be generally useful in all lighting conditions, the lime LED seems like the best choice. The only downside: it costs $4.20 vs $2.76 for the others. The marketing department over at Lumileds has their act together.


    Here's how I calculated the values in the table. Math and/or photometry nerds may want to check my approach; others may feel the desire to skip this entirely :-)

    The datasheet provides the photopic luminous flux (in lumens) and a normalized spectrum for each LED. I digitized the spectra with Engauge Digitizer, shown replotted on the same graph here:

    The datasheet lists the photopic luminous flux, , for each LED in lm. This is calculated by weighting the spectral flux, , by the dimensionless photopic luminosity function, :

    To calculate an analogous scotopic luminous flux, ,we can perform the same integration, this time weighting by the scotopic luminosity function, :

    This would be straightforward, except that the spectral flux isn't given directly in the datasheet. However, we can calculate the spectral flux from the given luminous flux and the dimensionless (normalized) LED output spectrum, which I'll call . The spectral flux is proportional to the normalized spectrum:

    Substituting this, we can solve for the constant C:

    and then evaluate the scotopic luminous flux:

    The raw data files and the octave script I used to perform these calculations can be downloaded here.

    Update: writing this log revealed a scaling error in the original octave code; I've re-run the numbers and updated the code and table.

  • How to design an LED glow marker

    Ted Yapo08/25/2016 at 21:55 0 comments least my first crack at a comprehensive approach. Here's a model for the parts of the system that can be optimized:

    Electro-chemical (a.k.a. batteries)

    This one is pretty easy. Of the four readily available lithium battery chemistries, three take top spots for highest energy density in primary batteries. All of them have decently flat discharge curves (nearly constant voltage over life), and work in cold temperatures.

    Chemistry Voltage (Nom.) Wh/kg Wh/L Example
    Li-MnO2 3 V 280 580 CR2032
    Li-(CF)x 3 V 360-500 1000 BR2032
    Li-SOCl2 3.5 V 500-700 1200 TL-2450
    Li-FeS2 1.5 V 297 - Energizer L91

    [ data from Wikipedia: Lithium Battery]

    Lithium thionyl chloride (Li-SOCl2) has the highest energy density (mass and volume). You can buy them from DigiKey, but they're expensive, toxic, and can explode when shorted [wikipedia]. They have an awesomely flat discharge curve and work in extreme cold. I have a few to play with, but I don't think they're practical for this use.

    Lithium managanese dioxide (Li-MnO2) are the "CR" lithium coin cells we usually think of (e.g. the ubiquitous CR2032). According to the wikipedia article, they rank third in energy density, but I think the table is wrong (see below); from the datasheets, they appear to be in second place. They're cheap and I've seen them in department stores, home improvement stores, pharmacies, and supermarkets.

    Lithium carbon monofluoride (Li-(CF)x) are the "BR" coin cells compatible with the "CR" series (e.g. BR2032). The datasheets show a 190 mAh rating for the BR2032 compared to 240 for the CR2032, so I don't understand how the energy densities in the table can show this chemistry as superior. In any case, they're available, but nowhere near as common as the "CR" batteries, and so I'm ruling them out.

    Lithium iron disulfide (Li-FeS2) are the lithium "AA" and "AAA" batteries, most commonly found as Energizer brand. As replacements for alkaline batteries, they have a higher capacity, work better in the cold, are much lighter, have a flatter discharge curve, perform much better at high discharge rates, have amazing shelf life (20 years), and cost a lot more. Because of their superior performance in digital cameras, they're also widely available. The real downside for glow markers is that they're only available in larger sizes (no coins), and worse, you need a pair of them because they're approximately 1.5V.

    Rechargeable batteries are interesting, but they suffer three problems. First, they have low capacity and high self-discharge compared to primary chemistries. You can recharge them (maybe from solar or other energy scavenging sources), but their service life isn't very long - think about how many years you get out of a cell phone or lithium camera battery before it no longer holds a charge and you need to replace it. With the discharge rates of glow markers, primary batteries can outlast rechargeables even if you are re-charging them.

    Super-capacitors might be more interesting if you have a power source to periodically charge them (solar?), but they have terrible energy-density compared to batteries. If you have a few cloudy days in a row, your light might go out.

    Bottom line: "CR"-series coin cells where size is a concern, "AA" or "AAA" lithium batteries for high brightness markers or super-long-term use where the size can be tolerated.


    For any light output level which is below the LED efficiency peak, it makes sense to run the LED in a pulsed mode near the most efficient point. So far, I've used microcontrollers to control the LED pulse, and this is the most flexible approach, although I am exploring using ultra-low-power timer chips as well. With a microcontroller, there are two basic contributions to inefficiency: sleep current and active current.

    Obviously, choosing a micro with the lowest sleep current makes sense. Active current is a little more complex. My first thought...

    Read more »

  • LED Efficiency Spread / New Ebay LEDs

    Ted Yapo08/23/2016 at 19:53 3 comments

    Now that I have a first prototype of #Automated LED/Laser Diode Analysis and Modeling running, I decided to see how well matched the relative efficiency curves are for a set of LEDs from the same batch. I have 8 of the ones I have been testing, so I cut them off the tape and labeled them:

    Running a sweep in the analyzer takes a few minutes for each LED, so it was short work to plot all of the efficiency curves:

    Since I am not sure how repeatable the LED/sensor optical coupling in the scanner is yet, all of these curves are normalized to have their peak at 1.0. It could be that some of them are more or less absolutely efficient, but at least we can see how we would do choosing a single current for driving any of them. It's not a bad cluster, with the exception of the magenta curve (LED A2), which peaks a little low. Even so, if we chose 1 mA to drive any of these LEDs, A2 would still be at 95% of its peak efficiency.

    I think it makes sense to run some curves like this with any candidate LEDs. Unfortunately, most of the LEDs I've been looking at have to be surface-mounted, so I need a board for each sample. I guess I can initially evaluate a single sample of each type of LED to narrow down the field, then have 10 cheap boards made to evaluate the spread for a few candidate parts.

    Ebay LEDs

    I found some LEDs claiming 490 nm output (very close to the dark adapted peak) on ebay. These are "3W" units, similar in power to the Luxeon Z I have been using, but cost around $0.80 each:

    and some "1W" versions:

    They claim a 120-degree viewing angle, which is the same as the Luxeon Z. I can't wait for them to arrive so I can test them. They're also hand-solderable.

  • Miscellany

    Ted Yapo08/19/2016 at 13:28 13 comments

    I had some news and a few ideas I'd like to get out there, even though I haven't had enough time to flesh everything out yet.

    New Team Member

    I'd like to welcome @tony ozrelic to the team! Tony and I have been discussing some promising new circuit topologies for the design (more about this below). I'm really excited that people are experimenting with these things!

    Lime Luxeon LEDs

    I ran across another Luxeon Z LED - the LXZ1-PX01 in "lime" color. This LED is interesting for a few reasons. First, it boasts an output of up to 200 lm, compared to around 70 for the cyan, or 100 for the green. It achieves this impressive performance by using a blue or UV emitter (not sure which) and a greenish phosphor, similar to the construction of white LEDS. The lumen ratings are relative to the photopic curve, of course, so it may not be as efficient for dark-adapted eyes (scotopic vision). When I find some time, I'll digitize the spectral curves from the respective datasheets and evaluate them against the photopic and scotopic sensitivity curves to see how these LEDs might compare in the dark. In any case, this sounds like an interesting LED to test. The bad news: $4.20 each. Ouch.

    DIY Phosphor LEDs

    So, the lime LED got me thinking. What about driving a UV LED with a TritiLED-like circuit, and using it to excite a glow-in-the-dark phosphor? If the phosphor has a decent persistence time, you don't have to worry about rapidly pulsing the LED - maybe a few times a second would be enough to continuously re-charge the glow. I have some glowing plastic stars left over from making bedroom ceiling constellations and a bag of activated ZnS powder from spinthariscope experiments that I can run some tests on. You might even be able to convert wristwatches with phosphorescent hands to tritium-like performance with a strategically-placed pulsing UV emitter.

    I have no idea what level of efficiency to expect from this kind of setup, but it seems like a fun thing to try. The really bad news: UV Luxeon Z (LHUV-0390-0400) emitters are $15 each. Bigger ouch.

    New Topologies

    Tony sent me an interesting pulse circuit he came up with:

    It's a wonderfully simple single-shot inductor boost converter. The forward voltage drop of the series LEDs is large enough to prevent current flow between pulses. To pulse the LEDs, the transistor is briefly turned on, ramping up current in L1. Once the transistor switches off, the inductor voltage rises to maintain the same initial current flow, now into the LEDs. As we saw two logs ago, the sawtooth-shaped current pulses generated by a circuit like this can be adjusted to give nearly optimal LED efficiency. Very convenient.

    I couldn't sleep after I saw this circuit, and ended up playing around in LTspice with simulations until I came up with this variation using a single LED:

    If you took the two photon arrows off the LED symbol, this would be a solenoid/relay driver circuit with a protective catch diode. Turning the transistor on energizes the inductor, which then discharges through the LED after the transistor turns off. It just doesn't get any simpler than this. Tony built one of these, too (I'm still in simulation-mode), and reported that it was brighter than the two-LED version. It would also be cheaper, especially with Luxeon LEDs.

    The one thing that might drag efficiency down here is the base current, which is wasted. Using a MOSFET might help, but driving the gate capacitance might negate any gains - I'm not sure yet. Another alternative which I've been playing with in simulation uses a Darlington pair with a couple of diodes to improve turn-off time. This circuit forces the base current of the driver transistor through the inductor, so it's not wasted:

    Here, D1 and D2 speed the turn-off and seem to improve the overall efficiency, at least in simulations. This idea is only half-baked, so shoot holes in it if you can.

    In any case, some version of this single-shot inductive boost idea seems like just the thing for improving efficiency....

    Read more »

View all 21 project logs

Enjoy this project?



pkobla wrote 6 days ago point

Hi Ted,

regarding choice of MCU. I've been programming PIC and MSP430 for low, really low power applications, but have now ended up with a Cortex M0+, the NXP (Freescale) mkl03z8vfg4.  Less $ than the msp430. Farnell (Denmark) lists them at $0.49/100s.  8kB flash, 2kB RAM, ADC etc. You  don't need to go assembler but can stay with C. 

Regarding the issues that have been discussed earlier about power use and time used during startup or wakeup. The mkl03 has a mode, VLPR, where wakeup latency from sleep, using an internal clock timer interrupt, is 7-8us and consumes about 2uA while sleeping. All inclusive. You can go lower, down in the  nA ranges,  but at a cost in latency, etc. Code may be placed and executed from RAM. When executing from RAM the "cost" per 1MHz is about 90uA. Instructions execute in 1 cycle except branches. HW multiplication in 1 cycle. The core clock can be scaled from around 25kHz up to 48MHz.  Power consumption scales accordingly. The internal clocks are pretty accurate and stable over temperature. It'll run from 3.3V down to 1.8V or is it 1.4V? All numbers are from memory, but read the datasheet. I've been around most features and the datasheet numbers are conservative compared to what you measure in real life. One drawback is the packaging. It's QFN with a 0.5mm pitch. Another of course is the learning curve which is steep coming from the msp430. Took 3-4 weeks for me to feel comfortable. IDE: I use IAR. Most people use CodeWarrior I guess. As for debugger I am using, or re-using,  the one that comes with the msp432 Launchpad which has an CMSIS-DAP mode which is supported by IAR and it works fine. IAR also supports the ST-Link-V2. A $2 Chinese ST-Link-V2 debugger has worked well too. With CodeWarrior you have to use something else than these 2. IAR does not cost anything if code is < something. I think it's 5k.  All-in-all, pretty amazing that you can get an ARM dev env up and going for a 1 digit dollar amount. Even more amazing that with ARM Cortex you can mix and match different IDEs, Cortex MCUs from different vendors, and debuggers.

As for a smaller battery holder: On aliexpress search for "CR2032 shrapnel" <sic>

Hope you and other readers may find this useful,

Peter K

  Are you sure? yes | no

Enrico wrote 01/14/2017 at 13:48 point

Hi, I am quite ignorant on spectrometer instruments: what is the one you've used to see the wavelenght? My best choice up to now was a broken CD/DVD... 

  Are you sure? yes | no

Ted Yapo wrote 01/14/2017 at 15:58 point

I don't know that much about it, either.  The spectrometer I used was one of these:

purchased a long time ago for less money.  It's more of a student demonstration than a serious instrument.  You could probably build one that gives similar results with materials you already have around - including the DVD grating.

There are some good spectrometer projects around here.  For more refined designs, see @David H Haffner Sr's projects.

  Are you sure? yes | no


[this comment has been deleted]

Ted Yapo wrote 11/30/2016 at 13:58 point

Yes, yes, I do need an SOIC8 test clip!

I hadn't seen them before, either.  I bought an SOIC socket when I started this project so I could program parts before soldering them, but the test clip is much better.

It would be nice to save the real estate I'm using for pads now :-)

How well does it work on less-than-perfectly-mounted chips?  When I hand-solder SOICs, sometimes it's a bit blobby.

  Are you sure? yes | no

Dan Julio wrote 11/21/2016 at 00:56 point

This is a neat project, Ted.  I thought of it this week as I walked up to my house in the early evening winter dark and surveyed all the dead solar LED lights that used to light the way...  How is the light output of V2.1/2.2 compared with a "typical" solar garden light (with, I assume, the right kind of white LED)?   It would be nice to have a set of lights that don't fail after a year...  Which would seem to be the case pairing your board with a couple of lithium primary cells.  I wonder if one could get enough light out of an energy harvesting setup using existing solar light solar cells, a super-cap and your board.  One could even add a sense input the PIC to turn the light off during the day.

  Are you sure? yes | no

Ted Yapo wrote 11/21/2016 at 01:54 point

I'm running them pretty dim compared to typical garden lights, I would assume.  I haven't compared them head-to-head, but the typical garden light is probably a hundred times brighter or more - it's the difference between a light being visible as a marker and being able to illuminate other objects (like a walkway).  I might have an old garden light in the garage I can take a look at.

But, there's no reason not to apply the same principles to a garden light.  If you take the 3W LEDs I've been using, they have an efficiency peak when run at around 10-15 mA (each color is a bit different), and they're pretty bright at that current.  If the garden lights aren't running near this current, they're wasting energy.  So, you could make a smart garden light controller to run them at peak efficiency.  Even so, I think you need the capacity of rechargeable batteries - supercaps still don't have the energy density required.

I did make a 10-year flashlight with which I am able to read and find my way around in the dark.  It's definitely not as bright as a garden light, though. You could crank up the brightness to garden-light level, but that would kill the battery lifetime.

If you are willing to go to d-size cells, the energizers claim a 10-year shelf life and 18Ah capacity.  You might get a garden-light to go for a few years on that.  They're lousy in the cold, though.

  Are you sure? yes | no

Dan Julio wrote 11/21/2016 at 02:02 point

I figured that, but since you support multiple brightness levels, thought I'd ask.  One interesting thing is that garden lights really only need to last a few hours each night (since most of us don't get home at 3:00 AM every night...).  I am looking forward to playing around with your design when you release the V2.x files.

I don't know a lot about the garden lights but I did look at one once.  The IC in there uses some sort of boost topology with an inductor to take the 1.2V out of the cell and power the 5 mm White LED.  I have no idea if it is approaching the peak efficiency of the LED.

  Are you sure? yes | no

Ted Yapo wrote 11/21/2016 at 02:35 point

If they're using 5mm LEDs they're almost certainly driving the LED above the point of maximum efficiency (probably around 1 mA).  If they're using the usual 20 mA, they might be throwing away half the energy.  The fix is buying an LED with a larger die area, which adds cost.  I think you could probably make a better light, but marketing it would be difficult (inferior but inexpensive sells).  But that's the joy of DIY - you can make one "the right way" for yourself.

I still have a few tests on the V2.2 to do, and a bunch of measurements, but so far it's looking pretty good.

I am seriously considering a version of the board for solder-on CR2450 or CR2477 batteries.  They're 620 mAh or 1000 mAh, respectively, and you could run the 2.2 circuit for 10 years or more.  But I want to get the 2.2 design out first.

  Are you sure? yes | no

Dan Saito wrote 09/07/2016 at 09:58 point

I wondered if energy harvesting could be a possibility here, so I read some app notes and did some enveloped arithmetic. Solar would work, with the limitations that entails, if that counts as energy harvesting, but RF would not. That’s not a surprising result, but it is disappointing.

Now, if they’re being embedded somewhere, the equation can shift.

One of the uses I have in mind for TritiLEDs is lighting the dials of mechanical clocks. In that application, there’s enough area to work with that harvesting RF may be feasible. Alternatively, energy could be sapped from the clock’s drivetrain. Of course, these would mainly be for the cool factor, because if you have enough space to do something like that, you could just hide batteries large enough to power the LED for decades.

If you don’t care about it working immediately if left on a shelf for a long while, sufficient energy could be gathered from motion, if left in a bag that’s carried around or a vehicle that’s driven.

  Are you sure? yes | no

Ted Yapo wrote 09/08/2016 at 19:05 point

Powering these things via energy harvesting is a neat idea.  Besides finding an energy source, storage options may also be a problem for long-term use.  I don't know that I'd trust electrolytic caps for 20 years, and ceramics are bulky and expensive for larger values.  A mechanical harvester and/or storage mechanism sounds interesting.

As far as RF powering, it depends where you are :-)  I'm 18 km from the 50,000W transmitter of WGY at 810 kHz, and I can run a version 2 from a crystal radio and voltage multiplier:

It's not fully-powered, but it lights up.  I might also be able to get it to light from microwave oven leakage or near a WiFi antenna - I used to do that with red LEDs/UHF diodes/dipole antennas before I knew they weren't very efficient at low-current DC. Probably not practical, though.

  Are you sure? yes | no

Dan Saito wrote 09/09/2016 at 04:41 point

I’m < 2 km from a 25 kW FM transmitter. I’ll have to try that out. It’s a good excuse to build an FM crystal radio.

  Are you sure? yes | no

Ripper121 wrote 08/29/2016 at 15:46 point

Do you found good alternatives for the Luxeon Z LED?

  Are you sure? yes | no

Ted Yapo wrote 08/29/2016 at 16:13 point

I have about 15 different LEDs to test, but haven't had time to run the curves yet - the analyzer over on #Automated LED/Laser Diode Analysis and Modeling is still in a very early prototype stage.  The only real problem with the Luxeon Z is that it can't be hand-soldered - this will keep some people from building them.  It would be nice to find a cheaper part, too, but I'm not sure I'd trade performance for cost here.

You can see a partial list of the candidates under the boards at the end of this log:

  Are you sure? yes | no

Ripper121 wrote 09/05/2016 at 12:12 point

Thank you. Yes i agree you. Performance is the Aim :)

  Are you sure? yes | no

SarahC wrote 08/28/2016 at 06:31 point

I would LOVE to buy a completed one or two of these... are you selling them anywhere? I had a look online and couldn't find anything. sarah AHT untamed dot co dot uk

  Are you sure? yes | no

Ted Yapo wrote 08/28/2016 at 06:55 point

Unfortunately, I'm not selling them; it would complicate my taxes too much.  The design is all open-source, so if some entrepreneurial spirit out there wanted to start making and selling them, they could do so (hint, hint - not necessarily directed at you).

  Are you sure? yes | no

jaromir.sukuba wrote 08/01/2016 at 07:19 point

Regarding the PIC12F508 - is there any specific reason to use this one? It is build on older manufacturing technology, causing its higher current consumption. In this case, a few microamps at 3V for the complete sleep+WDT current. 

For newer PIC12LF1552, for example, you can achieve less than half a microamp consumption for sleep+LPWDT current.

On the other hand, its current handling capabilities of IO pins are different, though better suited for 3V than 12F508, designed for 5V mainly (replacement for PIC12C508).

  Are you sure? yes | no

Ted Yapo wrote 08/01/2016 at 14:07 point

Thanks for the note!  That's a very good observation, and one I've done some thinking and experimenting on.

I originally used the 12F508 because I had some left over from another project (I actually still have 12C508/09's left from an era before that, too).  It worked well enough for a first iteration, so I stuck with it.

I have tried the newer XLP PIC parts, and have had mixed/bad results.  I haven't written it up yet because I wanted to be sure of my findings before speaking poorly about the newer PICs, but you can read essentially the same thing in Ti's white paper here:

Basically, with the high-speed internal oscillator, it takes a *long* time for the PLL in the PICs to stabilize (~1ms), so very low on-time applications don't really achieve good power savings. If you want an accurate clock (which I need to generate accurate pulses), you have to wait for the PLL lock and waste power.  It's discussed in TI's document. See the image on page 8 - they're using a PIC24F, but I see the same thing with PIC12's and 16's.  The PIC12F508, in contrast, has an "instant-on" oscillator, like the MSP430.

I'm still experimenting with newer PICs, so I haven't ruled them out, but I also have a MSP430 LaunchPad board sitting on my desk (and a few sample MSP430 parts), waiting for me to test Ti's claims.

I also am going to test the new ultra-low-power timer chips in this application.  I have some TS3004's (just waiting for PCB's from the fab): Documents/TechnicalDocs/TS3004.pdf

These are 1.9uA, pulse fast enough to get above the flicker fusion rate, have a PWM control you can use to tune the pulse width.  Achieving an average 1.9uA even with the microcontroller would be decent, because running bursts at MHz rates brings up the average.

I am also looking at the Ti TPL501x parts:

these run at 35nA. Unfortunately, the frequency only goes as high at 10Hz, so they aren't good for "constant" LEDs, but could probably be used for visibly blinking versions.

A lot of my focus has been on improving the efficiency, too.  39% is pretty bad. I got fooled by the relative inefficiency of the LED at very low currents before - I think I can double the runtime with a new architecture (single-shot inductor converters).

About the power handling of the PIC pins - I'm adding mosfets to reduce the voltage drop here and handle the higher current.  The I^2R losses using GPIO pins are killing efficiency.

  Are you sure? yes | no

Ted Yapo wrote 08/01/2016 at 14:25 point

This link shows the problem exactly for PIC8 XLP parts:

  Are you sure? yes | no

jaromir.sukuba wrote 08/02/2016 at 11:19 point

Yes, there are deviations from ideal state, but I believe the overall current consumption will be lower than with the 12F508. This is interesting topic, anyway - I use PIC MCUs all the time, utilizing its power saving modes often. I still haven't met with the oscillator startup time, as the wakeup from sleep takes place only during user intervention - once you turn it off, it stays in sleep mode until you wake it up. Microseconds doesn't play any role in here. On the other hand, waking up every 18ms for a few microseconds doesn't matter much too (the total duty cycle of "high power" time fragments makes its contribution to total power budget quite low anyway), IMHO.

But as usual, devil is in details, so it is not simple to estimate everything with no actual circuit. You design is simple and will try to breadboard it and return back with results.

  Are you sure? yes | no

Ted Yapo wrote 08/02/2016 at 14:44 point

I originally tried it with a PIC16F723A, which I think has the same XLP/Nanowatt features as the newer PICs ( just because I had some of these parts around).  I have some PIC16LF723A's now (just because I have some breakout-type boards for this part).  I think the only difference is the exclusion of the 3.6V internal LDO on the LF version, but I have a test setup that I just need to mount the part for to test it out.

Anyway, I'll re-create my original measurements with the LF version and post the results.  I have some PIC12F1571 (and '72) around I can use, too.  I suspect the oscillator start-up time will also be an issue with these parts.

Taking the '1552, for instance, check out section here on page 38:

when coming out of sleep, I'd want to wait for the HFIOFR (hf osc. ready) bit and the HFIOFS (hf osc. stable) bits of the OSCSTAT register to be set before generating the LED pulses.  These bits indicate that the HS osc has started running and is within 0.5% of its nominal rate.  Before those bits are set, the oscillator speed is AFAIK undefined - not something I would want to rely on to generate a current pulse.  When I tested how long it took to set these bits on the '723A, it was at least hundreds of microseconds of just waiting for those bits to set, negating much of the savings.  I could dig through my notes, but it's probably easier to try it again and post the results.

Yes, I definitely encourage you to try it out.  I could certainly be wrong about these new parts; I didn't look too hard after my initial experiments (and was rather disappointed, because I've been using PICs since the early PIC16F84 days). I'd like to see how it turns out :-)  Very interesting.

  Are you sure? yes | no

Ted Yapo wrote 08/02/2016 at 14:48 point

But actually, now that I think of it, the tests with the newer PICs were with a slightly different driver circuit, so I don't have a good apples-to-apples comparison.  I'll have to make one.

  Are you sure? yes | no

jaromir.sukuba wrote 08/02/2016 at 20:19 point

My first PIC was PIC16F84 too ;-)

For the PIC12LF1572 (and I believe other PIC12LFxxxx are similar, but probably not older PIC12(L)Fxxx) the datasheet states 5us typical, 15us maximal start-up time for HFINTOSC, while consuming approximately 200us at 4MHz. The consumption during power-up transient may be different, but this is subject of experimentation. The good thing is that it's pin compatible to venerable 12F508, so testing it should be somehow easier than complete rework. 

Note that 12F unlike 12LF version contains internal LDO allowing VDD up to 5,5, though at the expense of higher current consumption. It is low delta current, but it gets very obvious when you need to conserve the power (sleep mode).

16F723 is generation older than PIC12LFxxxx and honestly, I never really liked the 16F72x family, it has a few quirks and gotchas I wouldn't expect in 2008 or what was its release date. The newer PIC16(L)Fxxxx (and 8-pin versions 12(L)Fxxxx) do have much better peripherals, better specs, I think even lower price and more consistent scale-up/down migration path, while being reasonable compatible with older models.

No matter what, your tritiLED project piqued my interest and will test it minimally at breadboard and we will see.

  Are you sure? yes | no

Daniel wrote 07/12/2016 at 03:50 point

I think that you may be able to take advantage of some of the properties of the eye to make your project more efficient. Supposedly, the short-pulse integration time of the eye is around 20ms. Anything below that is not registered as a 'sharper pulse' but simply as less bright. This would mean that you could actually run the LED for 20ms at a MUCH lower current, which saves on I^2R losses. I read about this effect somewhere in the past, but have not gotten around to doing the experiments to verify that 20ms is accurate. It may serve you to try it out though!

  Are you sure? yes | no

Ted Yapo wrote 07/12/2016 at 18:29 point

Thanks for the comment!

I'll have to think about it a bit.  I think the properties of the LED are working against you here.  LEDs become terribly inefficient at very low currents, which is why the pulsed version wins over the DC version (you can see my confusion in build log 2).  So, at 20ms long pulses, the overall efficiency is likely to be pretty low, because you're still in uA range of currents.

In contrast, V1.0 runs at a 0.017% duty cycle, so is able to use 100mA pulses, where the LED is very efficient.

I'm definitely going to look more into the human visual system (HVS) side of things, it seems like there's "free" efficiency to be gained there. Here's a reference that shows a 2x perceived brightness increase with pulsed LEDs:

They use 60Hz with 5% duty cycle, which works out to 833us pulses.  It certainly seems like there's some interesting experiments that could be done - you've got the battery, the electrical efficiency of the circuit, the LED color and efficiency, and the HVS to consider.

  Are you sure? yes | no

Daniel wrote 07/12/2016 at 21:24 point

Ted, Blane, maybe this indicates that a smaller LED could/should be used instead?

  Are you sure? yes | no

Ted Yapo wrote 07/12/2016 at 22:05 point

I missed Blane's comment.  EDIT - found it!

Anyway, I am looking for different LEDs.  This one is too expensive and can't be hand-soldered.  I chose it because it has a color very close to the sensitivity peak for dark-adapted (scotopic) vision (and is very efficient).  It's surprisingly difficult to find LEDs like this.

  Are you sure? yes | no

Daniel wrote 07/12/2016 at 22:07 point

What are your requirements?

  Are you sure? yes | no

Ted Yapo wrote 07/12/2016 at 22:22 point

I'm looking for two different LEDs - one for really dark adapted eyes (scotopic vision), with a peak near 505nm, and one for mesopic (in-between) vision, with a peak in between 505 and 555 (the photopic peak).  Best efficiency possible, hand-solderable packages, widest viewing angle (120 degrees or so), cheaper than the $2.76 (qty. 1) Luxeon Z.

Last time I ordered parts, I picked up a few of these:

and these:

which I'd consider for mesopic lights, but I haven't had a chance to play with them yet.

  Are you sure? yes | no

Ted Yapo wrote 06/13/2016 at 18:44 point

I have a couple of log updates planned discussing the full details, but this week is very busy, so it may be a little while. I will post more stuff as soon as I have it in usable form :-)  In the interim, I uploaded an LTspice model for the circuit you can use to explore.  I don't have a SPICE model for the Luxeon Z LED, so I used a different model from the LTspice library - the concept is the same.  If you haven't used LTspice, you can download it here (it's free):

Yes, the voltage is doubled to 6V.  What doesn't appear in the schematic is the drop across Q1 and the internal resistances of the PIC output pins - that's what ultimately limits the current.  I roughly modeled the PIC pins in the simulation, but you can get the idea.

The capacitor voltage only drops a few tens of millivolts during the discharge - fully discharging it each time would mean additional losses of 50% during charging (due to the "capacitor paradox").  At least, unless you charged through an inductor.   I'll explain this more in a log, too.

There is still a bit of mystery for me, too. The rough SPICE simulation would lead you to believe the circuit is about 50% efficient, but I think it must be higher.  When I compare the board running at 26uA to an LED lit by 26uA DC through a resistor, the board is *much* brighter, and I have to turn the DC current up to 75-80 uA to get approximately the same visual brightness (pictures coming). I'll soon have actual numbers to calculate efficiency from a modified board I'll be able to measure on the 'scope. 

There is also research which suggests that pulsed LEDs appear brighter than those lit with DC.  For green LEDs, this effect is supposed to increase the brightness by a factor of two. This may be contributing to the unusual perceived brightness from this circuit:

I think the limiting factor in this design is the low-side driver made from paralleled PIC pins and their relatively high output resistances.  You can replace this with an NPN or N-channel MOSFET to avoid those resistances (and boost efficiency), but then the current varies widely over battery voltage and temperature. 

The 2.0 version uses an inductor in addition the the capacitor to make a single-pulse hybrid buck converter, which will more easily control the LED current, and allow greater electrical efficiency while eliminating the battery voltage and temperature dependencies.  I'm still working on the prototype, and will be posting progress about it.

EDIT: I re-uploaded the LTspice file.  The first one I put up had a different resistor value.

  Are you sure? yes | no

mr.jb.swe wrote 06/12/2016 at 10:53 point

My understanding is that you turn on the led for 3us  55 times per second, the drop out voltage is like 0.3V thus resulting in like 150mA for cyan LXZ1-PE01 ( on average equal to 26μA during a second )

What's your opinion on charging the capacitor with QX7135 ? ( fast enough ? )

I'm interested in being able to switch between extreme low power and a more normal flashlight


  Are you sure? yes | no

Ted Yapo wrote 06/12/2016 at 12:30 point

Assuming 100% efficiency, you should see 150mA pulses.  I (very roughly) measured around 100mA - I'm instrumenting a board now to get a comprehensive view of voltage and current waveforms and estimate efficiency.  I suspect a lot of the loss is in the low-side PIC output drivers - even four of them paralleled is probably not enough.  The other big issue is microcontroller sleep current.  The WDT on the PIC consumes 2.5-5 uA itself, according to the datasheet. I'll work up a full accounting to see where all my power goes.

I hadn't seen the QX7135 before.  I think this is the same part:

It looks like flashlights are driving it with PWM, so it's good for more than DC, but who knows what it does with really fast pulses - you might have to test it out.  The datasheet graphs show "quiescent current" at around 150uA - I don't know if this means that VDD is connected, and the LED not connected, or vice-versa.  One way doesn't matter, the other may blow up your power budget.

The ATtiny13 in those flashlights has a sleep/WDT current similar to the PIC, and a 4.8 or 9.6 MHz oscillator, so you should be able to generate very short pulses, if your LED driver can handle them.  You could also choose a faster WDT timeout to avoid flicker.

  Are you sure? yes | no

mr.jb.swe wrote 06/13/2016 at 14:53 point

I think a just partly understand what is going on.

Is it correct that the led is powered by 6v in discharge mode !?
Looking at the diode curve
that should mean a peak current of several amperes ( outside the chart ).
I'm very interested about more details on what is going on..... ( I first
thought the voltage over  the led was something like 2.7V which should
result in like 100-150mA bursts and in the end an average current of  26μA )

What is the remaining voltage in the capacitor after discharge ? 0V ?

The discharged energy  10E-6 * ( 3^2-0 )/2 =0,000045Ws   

or is this more correct

10E-6 * ( 6^2-3^2 )/2 =0,000135 Ws

Please explain more about the design, and the efficiency you gain with this capacitor "trick"


  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates