close-circle
Close
0%
0%

TritiLED

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

Similar projects worth following
close
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 2.2 of the design is complete and released under an MIT license.

Concept

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.

Hazards

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. This version achieves about 39% electrical efficiency. 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 (at program time)
  • Bright blinking modes (constant / fast blink / slow blink) with constant runtime
  • Inexpensive LEDs in many colors

Due to the higher electrical and LED drive efficiency, the V2.2 circuit will run for 5 years on a CR2032 (minimum brightness). The brightness can be increased at the expense of run time. At approximately 2.5 year run-time, the circuit achieves about 70% efficiency. 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 V2.2 is considered complete, and may be the final design of the 2.x series. Details of the design can...

Read more »

tritiled.lbr

Eagle library for components used in TritiLED designs

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

download-circle
Download

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

eye
Preview
download-circle
Download

Li_Battery_Model.tgz

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

download-circle
Download

luminosity_calculation.tgz

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

download-circle
Download

efficiency_cal.zip

initial octave code for LED current drive waveform efficiency optimization

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

download-circle
Download

View all 9 files

  • CR2354 Editions

    Ted Yapo08/29/2017 at 18:02 3 comments

    I built some experimental boards for use with solder-tabbed CR2354 cells:


    The PCB is designed to fit into a "3g" polystyrene jar, available cheaply on Amazon.  These jars provide some water resistance - I imagine sealing the threads with some silicone caulk (or even epoxy) should thoroughly waterproof them.  The CR2354 cell barely fits into the jar - you have to bend the positive tab a little to get it in there.  The solder tabs make battery changes more difficult, but with a 560 mAh capacity, the cell should last around 5 years.  The soldered battery connections also eliminate any issues with contact corrosion over time.

    There is no switch and hence no blinking modes.  In fact, the circuit has been stripped down to what I consider the bare minimum:


    The assembled version shown uses a Luxeon C "lime" LED, which claims 152 lm/W - it's a bright yellow-green color, and very visible in daylight, but not as bright as some of the other cyan LEDs I have tried for dark-adapted eyes.  I have some cyan and green (530nm) Luxeon C's to try next.

    Here's an assembled one next to a V2.2:


    One problem with this PCB is that because the LEDs have a low profile, the inductor blocks some viewing angles on one side.  The problem isn't terrible, but I thought I might avoid it by moving the LED to the other side.  There is just enough space created by the battery tabs to clear the components on such a reversed board.  Here was my first attempt:


    The LED is on the other side of the board:


    This creates a clean look and avoids issues with low-angle visibility, but introduces another problem: the board has components on both sides.  You might be able to do this with a reflow oven, but I couldn't do it with a skillet, so I reflowed the LED, then manually soldered the rest of the components on the other side.

    For this board, I also decided to try a new LED: the Osram Oslon SSL150, which boasts high efficiency and great viewing angles.  Unfortunately, I didn't realize that this LED also contains a parallel reverse protection diode.  This protection diode conducts whenever the MOSFET turns on, drawing huge (but brief) spikes of power.  Unfortunately, this raises the consumption from around 14 uA to 850 uA!  So, instead of five years of service, you get around one month.  I won't be using these LEDs going forward.

    I have a few more "reversed" boards like this being fabbed now - for Luxeon C and Cree XP-E2 LEDs.  I like the little jars a lot.  They're not as sexy as a custom enclosure, but they're functional.  I'm hoping to get a chance to test water-proofing them soon.  The deepest I can probably manage easily is around 50ft at the bottom of the Great Sacandaga Lake.

    I also picked up some "5g" jars, which are large enough to contain the original CR2032-powered V2.2's with room to spare, and will also fit tabbed CR2477 cells, which will run markers for around 10 years.  The CR2477's are expensive, but 10 years is a long time.

    The PCBs shown here (and more I haven't tested yet) are in the GitHub repo.  I'll probably remove all the ones with SSL150 LEDs, because they're not worth building.

  • V2.2 for sale on Tindie!

    Ted Yapo08/29/2017 at 16:52 0 comments

    You can now buy V2.2 TritiLEDs on Tindie!

    I have had people ask before if they could buy kits or assembled units, and I always had to say no.  Now an enterprising individual has started producing them and making them available for sale - using the design files in this way is permitted by the open-source license (MIT).  It's good to see: this is how open-source is supposed to work.

    I should point out that I have no official affiliation with the seller on Tindie (Kontakt).  I designed the original, but it's someone else who is selling them.  This is all good, with the one exception that I can't provide support for any devices you buy from someone else.

    So, if you want one (or more), you can now just buy it (them).

  • V2.2 New LED Editions

    Ted Yapo08/16/2017 at 17:37 0 comments

    I wanted to experiment with some new LEDs, and decided that making new PCBs was the shortest path to victory, so I created 3 new editions of the V2.2 PCBs this morning.  The first uses the Luxeon Z LED from V1.x.  I mostly created this version because I have a small stock of these LEDs who keep complaining that I never used them.  Interestingly, all three LED packages I added today are smaller than the Chanzon package, and would allow a PCB shrink, but I kept everything else on the board the same for compatibility with existing programmers and cases.  I think V3 will be smaller.


    I also created a Luxeon C version.  The "C" LEDs claim a much higher lm/W rating than the "Z" for some reason, so I am exited to try them.  I have some cyan, green, and "lime" ( a phosphor-based green ) versions on order.  If I had an integrating sphere and calibrated spectrometer handy, I could compare LEDs in a more principled way.  As it stands, the best instruments I have at the moment are my own eyes, and a side-by side board comparison is probably the best I can do for now.


    I initially dismissed phosphor-based white LEDs for this project because I'm obsessed with stimulating receptors at 505nm.  I might be off-base here: a few of my collaborators have pointed out white LEDs with outstanding (photopic) efficiencies in excess of 200 lm/W.  Of course, since lighting is driving the LED industry, white LEDs will continue to improve preferentially, while price gets driven down by competition and economies of scale. So, I'm going to try a few.

    Efficient white LEDs are available in 5630 packages, so I made a board for those:


    I'm particularly interested in two LEDs carried by Digikey, the Samsung LM561C, which boasts 212 lm/W (photopic) at a 5000K color temperature, and the Osram Duris E5, at 205 lm/W and 6500K.  They're both less than $0.50 in singles, compared to the $0.80 Chanzon's and $2.75 Luxeons.

    The design files and gerbers are in the GitHub repo, but I haven't shared the OSH Park links yet since I haven't tested the boards.  I may have screwed up the packages - it wouldn't be the first time. Once the boards come back and I verify they work, I'll open them up and post the links.

    I also fixed the inconsistent value of C2.  In some places it was 1uF; in others 100nF.  Either value will work fine: I finally made them all 100nF.  I think.

    Update 20170817

    I added a Cree XP-E(2) edition in the GitHub repo.  This will accept the original XP-E series LEDs, or the improved XP-E2 versions.  The XP-E2 green claims 113 lm/W at 525 nm, and these LEDs are available in a variety of colors (no cyan, though).  I'm guessing that at 525 nm, it achieves a nice balance for either photopic or scoptoic vision.  I'm also going to try a phosphor-white version.

    Again, once I test the board out, I'll share the PCBs on OSH Park.  I know the footprint is OK on this one since I've made other boards with XP-E LEDs on them.  On a test board, this LED looks a little brighter than the Chanzon green, and has better viewing angles.  The only issue is that the lower profile of this small LED means the inductor (and other parts on the board) block low-angle visibility for certain directions.  Something to think about.

  • A Quick One: Tapped Inductors

    Ted Yapo07/29/2017 at 15:59 11 comments

    I have been thinking of ways to avoid the issues of the inductor/LED arrangement, which constrains the current pulse width.  This morning, I worked through some LTspice simulations using tapped inductors to get different input/output current ratios:

    In the schematic, L1 and L2 are magnetically coupled by the K1 coefficient (1) simulating a tapped inductor - this isn't the same as two separate coils.  In this case, L1 is smaller than L2, so the input current pulse will be larger than the output.  As a consequence, the output pulse will be longer.  In this example, the input current pulse reaches a maximum of 120 mA, while the output pulse maximum is 30 mA:

    The ratio of the current pulses is determined by tap position.  Tapped at the bottom of the coil, this is the original circuit which produces equal input and output current.  Moving the tap "upward" makes the input pulse larger while reducing the current in the output pulse and extending the duration.

    This could be useful for matching the output to the optimum current to drive a particular LED.

    Of course, this presents some difficulty for using off-the-shelf inductors, the majority of which are do not come with taps.  Homebrew inductors are easy to make, though, and it might even be possible to add an extra winding on a commercial inductor to create the tap.

    I don't know how practical this all is, but it's another possible trick to use.

  • V2.2 Analysis: 70% efficient

    Ted Yapo07/27/2017 at 19:40 0 comments

    I found some time to "follow the energy" in the V2.2 design using a PCB designed just for testing.  The interesting addition to the circuit is a 1-ohm resistor in series with the LED:


    The resistor allows the LED current waveform to be captured on the scope.  A second channel captures the voltage across the LED, while a BPW34 photodiode near the LED monitors the actual light output.    The 50-ohm shunt resistance is important to speed the response of the photodiode.  Note the unusual connection of the scope ground - this requires a floating scope, in this case created by running the TritiLED from a 12V battery and an LM317 adjustable regulator to supply 3.00 V.

    The resistor does waste a small amount of power (calculated below), but doesn't affect the results very much.

    The signal from the BPW34 is not calibrated, but is just used for triggering and to see exactly when the LED is emitting - this resolved the question of whether the LED actually emits any light during the ringing after the pulse.  It doesn't.

    All measurements were taken with 3.00V supply and a 2-pulse program from the GitHub source code.  The inductor has a 30% tolerance, so these measurements should be considered "typical" in the datasheet sense - meaning I saw this once in the lab :-)

    I measured the current consumption at 13.54 uA without the scope connected.  This increases to 13.96 uA with the probes connected.  I don't know exactly how to treat this difference, so I have expressed the efficiency estimates in a range below, assuming one or the other current as a reference.

    Here are the waveforms from the three channels.  You can see the two pulses that happen at a nominal 62.5 Hz:


    The top (yellow) trace is the LED current (1mV = 1mA).  The peak is about 19.8 mA.  The middle (cyan) trace is the voltage across the led: note that this voltage is inverted, so the LED is lit on the "low" section of the trace.  The bottom (magenta) trace is the light detected by the BPW34.

    Efficiency Calculations

    Below, I compare the power dissipated by various components to either 3V * 13.54 uA = 40.6 uW or 3V * 13.96 uA = 41.9 uW.

    Please make sure these calculations all make sense.  They went pretty quickly, so I may have missed something.

    PIC Power Consumption

    I modified one line in the assembly code so that the PIC clears the MOSFET gate line instead of setting it.  This prevents the LED pulse, and results in a current drain of 2.95 uA, or 3V*2.95uA = 8.9 uW.  This means the PIC is consuming between 8.9/41.9 = 21 % and 8.9/40.6 = 22% of the power.  This bounds the overall efficiency of the circuit to around 78% maximum.

    This also means that even if you succeed in driving the oscillator current to *zero*, you can only improve the run-time (or brightness) by 22/78 = 28%.  So instead of a 2.5 year light, you get a 3.2-year light. Probably not worth increasing the cost to do, but sure, I'll take 28% more of anything.

    End-to-end Electrical Efficiency

    I downloaded the waveforms as a CSV file and used octave to numerically integrate the power going into the LED.  The LED gets 123.38 pulses of 23.7 nJ each per second for an average power of 29.2 uW.  This is between 29.2/41.9 = 69.7% and 29.2/40.6 = 71.9% overall electrical efficiency.  Call it 70%.  This is in-line with the 78% bound based on the PIC consumption.

    Overall, 70% doesn't seem too bad.  You see optimized DC-DC converters at 95% sometimes under ideal conditions, but for such a simple circuit, it seems OK.  You're not going to be able to double the run-time again.

    Current-sense Resistor

    A similar numerical integration of I^2R in octave shows that the sense resistor is consuming 0.37% of the power.  That's in the noise as far as this rough analysis is concerned.

    What's more interesting is this gives us a way to estimate the loss due...

    Read more »

  • V2.2 Release

    Ted Yapo07/12/2017 at 04:52 33 comments

    I am going to maintain and update this log as I add material on building these.

    UPDATE 20170716: fixed library and PCB to produce correct solder stencil

    UPDATE 20170713: added more info about the battery holder and inductor substitutions, with links to the original parts, and info about the case screws.

    UPDATE 20170712: added assembly instructions

    UPDATE 20170712: added the 3D printed case design



    I should have done this months ago - V2.2 fixed the reversed MOSFET of V2.1, and is basically a complete design, so here it is.

    I was going to re-do this in KiCAD, but I got frustrated with it again (third or fourth time), and just paid the $100 for a years worth of Eagle. The hardware and software design is in the GitHub repo.

    You can order TritiLED V2.2 boards and V2.x programmer boards from OSH Park. If you have an SOIC-8 programming socket, an SOIC-8 test clip, or don't mind temporarily soldering wires to the ICSP pads on the boards for programming, you don't need the programmer boards - they just let you connect the ICSP lines with pogo pins.

    The V2.2 circuit adds a 100-ohm resistor in the battery supply before the reverse-protection MOSFET as discussed in a previous log:

    Here's an assembled one with a Chanzon 3W cyan LED (right) next to a V1.0 with a Luxeon Z cyan LED:

    The light output from the V2.2 is much more than that of the V1.0, even though the surface of the LED on the V1.0 looks brighter - this is due to the smaller apparent area of the Luxeon LED. The V1.0 will run for a little over a year, while the V2.2 will run for over 2.5 years with the full software program. This full software includes blinking modes selected with the switch, as well as code which periodically re-initializes the PIC to re-write any RAM values that may become corrupt over time (e.g. from cosmic rays). A separate "barebones" software image can be loaded that dispenses with mode switching and periodic re-initialization, and runs at a slower 32 Hz blink rate to achieve an estimated run-time of over 5 years on a CR2032 cell. This software produces a somewhat dimmer output with noticeable flicker, but it is very usable as a marker. Both software versions are in the GitHub repo, and can be tuned to produce brighter output at the expense of run-time.

    Bill of Materials

    I need to add a BOM in the GitHub repo, but here are the components listed out

    The inductor and battery retainer are substitutions from the original parts I used. The battery retainer is a slight upgrade, being gold instead of nickel. The original nickel part is also available:

    (1) Linx BAT-HLD-001-TR CR2032 battery holder. DigKey part # BAT-HLD-001-TRCT-ND $0.73 each.

    I have not received any of the gold battery holders yet; from the datasheets they appear to be exactly the same except for finish material.

    The inductor is simply more expensive, but with the same size and specs: the old one is not stocked at DigiKey anymore. They are in-stock at Mouser:

    (1) Bourns SRR6028-102Y 1mH inductor Mouser part #652-SRR6028-102Y $0.68 each

    Again, I haven't tried the Wurth inductor on boards yet, but they appear to be identical parts...

    Read more »

  • CMOS Relaxation Oscillator Fail

    Ted Yapo07/10/2017 at 03:13 23 comments

    UPDATE 20170710: see below

    I have long considered trying to remove the microprocessor from the design, and decided to take a few minutes to test out some ideas. I had the parts for this experiment sitting in a box for over a year...

    The board has two 74AUP14 Schmitt-trigger inverters in SOT23-5 packages mounted on #Ugly SMD Adapters glued to the ground plane. The first inverter is used as a relaxation oscillator, while the second is used after a differentiator as a short pulse shaper:

    The 1n capacitor has a terrible tempco, so every time I read it, I get slightly different frequencies - especially if I had recently soldered the board, or touched the cap. The output of the first inverter is a nice square wave at around 65Hz (yellow trace):

    Zooming the time scale, we see the output of the second inverter (cyan trace) is a clean 12us pulse on the falling edge of the square wave:

    With a little tweaking, this would be a perfect waveform to drive the MOSFET/inductor boost circuit. Except for one thing: the circuit consumes 160 uA! This is without driving an LED, and is already an order of magnitude more than the "standard" TritiLED program running on a PIC. Craziness!

    The problem is that the inverters (74AUP1G14's) consume a lot of power when biased into the linear region, which the relaxation oscillator is always in (the culprit being shoot-through current between the high- and low-side MOSFETs). I was really surprised by this result because the 74AUP is advertised as the "lowest power" family, and the datasheet specifies 0.5uA quiescent drain maximum at 25C. With the feedback connection on the first gate broken, I actually can't detect *any* current used by the circuit with my DMM, which has 100nA resolution.

    The pulse shaper seems to consume a negligible amount of current by itself: now I'm wondering how to make a really low-power oscillator.

    For the time being, I'll stick with using a PIC15LF1571, but it's still fun to consider simpler options.

    Ideas?

    UPDATE 20170710

    I tested the current drain on the first inverter. I removed the 10M resistor, and briefly charged the 1n capacitor by connecting it to the 3V supply. The capacitor takes about 30 seconds to discharge due to a combination of internal leakage and input current into the inverter. When the capacitor is charged to 3V, or fully discharged at 0V, I read zero quiescent current for the inverter (again, the meter resolution is 100 nA, so I assume the current is less than 50 nA). During the 30 seconds while the capacitor discharges, the current draw increases to a maximum of 220 uA, then falls back down to "zero".

    This is why they tell you to ensure than all unused CMOS inputs are tied to either Vss or Vdd. Being in-between can cause some hefty current drains.

    SECOND UPDATE 20170710

    @AlliedEnvy lent me a clue in the comments - reduce the supply voltage. The circuit oscillates with supply voltages down to 0.25V (at the temperature in my office, anyway), and seems pretty stable above 0.4V. Interestingly, the power consumption drops off dramatically with supply voltage. At 0.95V, it draws 1.0uA, while below 0.75V, the current drops below the 100nA threshold on this DMM. I'll have to drag out the good HP meter to investigate more closely.

    So, the shoot-through current in the middle of the input range is a strong function of supply voltage. To investigate this, I made this quick model in LTspice, using the N- and P- parts of and FDS9934 to make an inverter. I just chose those because it was the first complementary pair I found in the library:

    You can see how the shoot-through current gets reduced here. The top (blue) curve shows the current drawn from a 3V supply as the input voltage is swept from 0 to 3V - it peaks near 1.4V at 800 mA for these particular MOSFETS. The other color curves show the same thing for lower supply voltages stepped in 100 mV increments. By 2.3V, the maximum current is below 10mA. By 1.8V, it drops...

    Read more »

  • Safer TritiLEDs: One simple trick prevents catastrophic failure

    Ted Yapo06/28/2017 at 15:00 0 comments

    So, @Elliot Williams has been playing with similar ideas over on his #ATtiny45 EverLED project. There's some neat ideas over there, including the use of a different microcontroller, inductor sizing, and LEDs. One of the interesting additions he made was a pull-down resistor on the MOSFET gate to avoid the possibility of an un-driven gate being pulled high by whatever voltage fields are around. This can happen when the microcontroller output pin is tri-stated. If the MOSFET is held in a conducting state, the battery is shorted across the inductor and everything gets hot. Elliot mentioned that this happened for him during programming. Of course, the possibility also exists that during the lifetime of the circuit (which may be many years on a single cell), a cosmic ray strike or degraded flash memory could cause a similar problem with the microcontroller code, holding the MOSFET conducting, and possibly causing problems with excess heat or chemical leakage from the cell. It's very unlikely, but also very cheap and easy to protect against.

    When I re-used this circuit in #Decade Flashlight, I added a resistor in the power supply line to limit current in this case:

    The 10uF capacitor provides storage for the current pulses - in fact, the TritiLEDs run for a few seconds after the battery is removed just from this capacitor.

    The 100-ohm resistor limits the maximum current through the inductor and MOSFET. Assuming a 3V battery, the current is limited to 30mA, which will quickly drain a CR2032, but only allow 90 mW of power to be dissipated in the loop - that's low enough not to cause any damage. In practice, the internal resistance of the cell and the parasitic resistance of the inductor make the limit a little lower.

    So, it's safer now, but what about efficiency? The TritiLEDs consume from 4-30 uA or more depending on how they're programmed. Let's assume we tune one to about 12 uA, which will run for two years or more on a CR2032. The voltage drop across R1 is then V = IR = (12e-6)(100) = 1.2 mV. Since the current through the resistor and the rest of the circuit is the same, the ratio of power in the resistor to that used by the circuit is 1.2mV / (3 - 1.2mV) = 0.04%. This is ridiculously small, and essentially doesn't change the efficiency or brightness of the circuit at all.

    The addition of this resistor is one of the things I'm rolling into the 2.3 board. I've also added them to all of the versions I have made for friends. If you build some of these circuits, please consider adding a resistor in the power supply like this. The value isn't critical - in the above case, the loss is around 1% even with a resistor of 500 ohms.

    Sorry about the clickbait title :-)

  • 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 dirtypcbs.com. 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.

View all 29 project logs

Enjoy this project?

Share

Discussions

KSUdoubleE wrote 08/18/2017 at 17:04 point

Nice project!  I made it last week, etched my own board so I had to arrange things somewhat differently to reduce vias since I don't do through hole plating.  I also used a 12LF1501 instead for the processor because I had some around.  Took a little tweaking in the code as it doesn't have a OSCCAL register, but it is working well.  Good job matching the glow/color.

  Are you sure? yes | no

Ted Yapo wrote 09/04/2017 at 16:44 point

I'm glad you found it interesting/useful.  Post a picture if you get a chance - I really like to see these things in the wild.

Having OSCTUNE doesn't give you that much control - just a fine tuning, really.

  Are you sure? yes | no

KSUdoubleE wrote 09/08/2017 at 19:30 point

  Are you sure? yes | no

Ted Yapo wrote 09/08/2017 at 23:47 point

Awesome!  I think that's my favorite build yet.  Do you mind if I post the images in a build log?  I'd like to make a gallery of builds done by others.

  Are you sure? yes | no

KSUdoubleE wrote 09/11/2017 at 13:27 point

Sure that is fine.  Thanks again for sharing your project!

  Are you sure? yes | no

bulrush15 wrote 07/17/2017 at 12:50 point

Ted, would you consider selling a kit we can solder together? I don't know how much shipping is now for Digikey but it's normally outrageous for companies like that. 

  Are you sure? yes | no

Ted Yapo wrote 07/17/2017 at 14:11 point

Digikey will ship packages under 8 oz for $3.39 by USPS first class mail, and 1 lb by USPS priority mail for $7.50.  I've used both, and you get a *lot* of SMT components per pound.  You have to order the OSH Park PCBs in multiples of three ($6.15/3), so let's say you order enough parts to build three of them.  That costs maybe $26 with shipping from DigiKey.  So, you might pay $33 for all the parts for 3 of them - $11 each, including shipping.  Rough numbers.

The rule-of-thumb for pricing kits and assembled units is to mark up costs by 2.5x.  If I buy the parts in 100-quantities and order cheap Chinese-made PCBs, I could probably drive my cost down to $4.50 for a kit (guess) - not including any labor, packaging, etc.  A mark up of 2.5x puts my selling price right at $11, *plus* shipping, minimum, assuming my time costs nothing.  You might buy from me for convenience, or because I'm a nice guy with a winning personality and a killer smile, but you wouldn't save any money.

I don't know how many will sell, so I'm not going to buy 1k units to get the next price break (approx $4k outlay), so I can't really do better than that on parts.

Then, next April when tax time rolls around, I've got a bunch of accounting to do - and accounting for manufacturing in the US is absolutely fucking ridiculous. I'm willing to bet that nobody does it correctly at the small scale (including tracking inventory - counting all those $0.01 0603 resistors you haven't used yet).  Manufacturing in the US is so impossibly over-regulated that to do it on a small scale, you are basically forced to break the rules (IRS, FCC, EPA, state nonsense...), or spend a crazy amount of time and money on overhead costs.  A younger me might not have cared; at this point in my life, it doesn't seem worthwhile.

Having said that, the design in GitHub is released under an MIT license.  If someone else wants to sell kits, or PICs pre-programmed with the firmware, or assembled units, they are free to do so, subject to the license.  I recently had someone ask if it was OK to do this, which was genuinely a nice gesture, but totally unnecessary.  I've had my rant about why it doesn't make sense for me - but what do I know - this might turn out to be a nice side business for someone else. 

Edit - I forgot about the LEDs - $7.90/10.  So, adjust the above numbers accordingly - same basic outcome.

  Are you sure? yes | no

bulrush15 wrote 07/14/2017 at 20:23 point

Have you considered these low-power circuits for powering an LED? From Don Kipstein, the guru of lighting. http://donklipstein.com/ledlocup.html. I thought it might provoke a brain storm.

Another interesting link, ultra-low power circuits: http://www.discovercircuits.com/M/micropow.htm

  Are you sure? yes | no

Ted Yapo wrote 07/14/2017 at 22:23 point

There might be something to the first link.  It's interesting stuff, but not knowing how bright he's trying to go for, I'm not sure how to evaluate it.  The basic idea of using PWM at more efficient LED currents is the same, just achieved by different means. Other than that, a few points come to mind:

1. It's a higher voltage source 9V in some cases, 5 in others.  I'm not a big fan of 9V batteries.  They're huge, and even though they're available in LiFeS2 chemistry, the energy density is still lousy.  

2.  The "excess" voltage seems to be dropped across a resistor.  This jumps out as inefficient, but maybe not that bad.  This also won't work when the battery voltage dips below the Vf of the LED.

3. Because of the 9V supply vs 3V, you need to multiply the quoted currents by a factor of 3 to compare with operation from coin cells.  The 45 uA current at 9V is equivalent to 135 uA at 3V from a power standpoint.  This is more than 10x the power of the standard V2.2 TritiLED.  Again, I don't know how much light the two put out compared to each other - maybe I need to build one of the circuits from that link.  On the other hand, I think the TritiLED output is probably sufficient for the intended purpose as-is.

4. Just as a point of reference, the circuits described on that page consume around 40uA from a 9V source.  A 9V LiFeS2 battery has about 750mAh of capacity, so would run such a circuit for about 2.2 years.  This is about 6 months shorter than a V2.2 TritiLED runs off a CR2032.  Again, no idea about the brightness comparison, but a 9V battery is huge compared to a CR2032.  The TritiLED would theoretically run for 47 years on 2x lithium AA cells (about the size of a 9V) - but the battery only has a shelf-life of 20 years, so let's say 20+ years.

The second link has some interesting circuits.

  Are you sure? yes | no

crjeder wrote 07/11/2017 at 14:27 point

Just read about your Project with great interest. Thank You for posting this online!
I can't get one thing out of my mind, though: wouldn't an electroluminescence device work better for efficient dim lighting than an LED?

  Are you sure? yes | no

Ted Yapo wrote 07/11/2017 at 14:49 point

I haven't really explored EL devices for this application, but my understanding was that modern LEDs had an efficiency advantage - and they're constantly improving, driven by the LED lighting industry.  I can't find solid efficiency data though.  My understanding was that LEDs were now the efficiency king, having surpassed fluorescent tubes some time ago.

The short half-life of EL devices (quoted as 3k hours here: https://focuslcds.com/journals/el-backlights-vs-led-backlights-legacy-display-technology-vs-cutting-edge/ ) would be a concern. I've seen this happen with plug-in EL night-lights; they don't last very long. The shortest-lived markers I'm considering these days run for 2 years (18k hours), which is (6)  3k hour half-lives - I'd expect the EL to be completely burned out by the end.  You might get longer life at lower current, but the same is true for LEDs, which get a 50-70k half life estimate at nominal currents.  On the other end, I have some devices intended to run 10 years, and am playing with ideas about 20-25.  I suspect that LEDs have a huge advantage here.

There's the necessity of high-voltage to drive them - this complicates the board, and might create safety concerns.

Finally, I don't see small EL "dots" being widely available.  LEDs are easy to source - especially for the amateur/maker/etc.

I'm open to the idea, but have doubts about all of these issues.  Maybe I'm ill-informed: what are your thoughts?

  Are you sure? yes | no

crjeder wrote 07/11/2017 at 15:13 point

I was asking because you are have definitely more knowledge than me. What I understood is that EL has a higher theoritic limit on efficiency and is long lifed. An other advantage might be that it can be of any shape (just cut the sheet as needed). I was thinking that LEDs are efficient only on the high end (high lumen). But I may be wrong. Have to dig out the efficiency claims of EL...

The driver (DC to AC converter and high voltage) was the main reason I belived that the efficiency for the whole device in the battery operated case is to bad. But again: I don't know and was just asking because you might know..

  Are you sure? yes | no

Ted Yapo wrote 07/11/2017 at 15:37 point

I don't have too much experience with EL - so there may be something to this.

A quick scan reveals that even the EL manufacturers quote about 10x the lifetime for LEDs than EL.  Maybe at super-low power, they both last long enough anyway?

As for the efficiency, this page claims 6 lumens/watt for EL panels:

http://www.edisontechcenter.org/electroluminescent.html

while this Luxeon-C LED claims 76 lumens/watt:

https://www.digikey.com/product-detail/en/lumileds/L1C1-CYN1000000000/1416-1917-1-ND/5872100

Maybe there are better numbers for EL panels somewhere?  I have seen it mentioned that they are more efficient than LEDs for low brightness applications, but this whole project came about because using LEDs naively for low-brightness is very inefficient.  You are correct - with DC drive, LEDs *are* only efficient at the high brightness end.  By driving them at higher currents near peak efficiency with a low-duty-cycle PWM, though, you can regain much of this efficiency.  They're bright and efficient for 0.05% of the time, resulting in an efficient "glow".  I wonder how this changes the comparison?

  Are you sure? yes | no

crjeder wrote 07/12/2017 at 08:59 point

All "high efficiency & long life" claims I've found for EL are from the last milenium. Back then LEDs have been completely different form what they are now (performance wise). So that may explain those claims.

Efficiency values for dim / low power LEDs is also not so great, definitely in the single digit (lm/W) range.  e. g. https://www.digikey.com/product-detail/en/vishay-semiconductor-opto-division/VLMP20D2G1-GS08/VLMP20D2G1-GS08TR-ND/4074306 which has (aprox) 1,75 [edit, was 0.5] lm/W at 2 mA * 2 V (converted candela to lumen with http://led.linear1.org/lumen.wiz)

  Are you sure? yes | no

Ted Yapo wrote 07/12/2017 at 12:23 point

@crjeder Yes, that's why there has been some confusion about why I am using "3W" LEDs for a marker consuming tens of microwatts!  LED efficiency is a strong function of areal current density - too little current, and they're horribly inefficient; too much, and they drop off by maybe a factor of 2 (called "droop").  So, I use large-area LEDs which are very efficient with mA-range current pulses, and reduce the duty cycle to bring down the power consumption.  The rest of the circuit is just trying to generate these ideal pulses efficiently.

  Are you sure? yes | no

Michael Stoiko wrote 07/07/2017 at 13:29 point

As an additional though idea (probably more for instrument faces) I recently acquired and disassembled one of the old 1st gen night vision scopes that runs it's image intensifier solely on the squeeze of a piezo element. I wonder if a dial or marker could be similar activated with phosphor and a button/motion generating the HV needed to excite it.

  Are you sure? yes | no

bulrush15 wrote 07/07/2017 at 09:15 point

Since we're talking about saving power, I thought using tiny amounts of power and boosting it would be related. I found this interesting voltage booster which takes input as low as 250mV and it seems to create enough voltage to light an LED. http://www.ebay.com/itm/LTC3105-Energy-Harvester-demo-module-/332136264440?&_trksid=p2056016.m2516.l5255

Interesting device if the specs are accurate. I'm interested in voltage boosters like this for using thermoelectric generators to charge a battery.

  Are you sure? yes | no

Ted Yapo wrote 07/07/2017 at 14:13 point

I've seen those converters around.  They seem to excel at taking a low-voltage relatively higher-current source and boosting the voltage to something more useful - thermoelectric being the prime example.

The converters aren't necessarily ultra-low-power, though.  The LTC3105 consumes 10uA in shutdown and 24uA when active, according to the datasheet - just to run the converter.  That might be at very low voltage input, so maybe the power consumption is also low, but to put this current in perspective, the lowest-power LED circuit I have been using consumes around 3.7 uA.

But, then again, if you have a source of heat that you can exploit, and it generates more than the converter consumes, it may not matter what the converter eats.

  Are you sure? yes | no

Michael Stoiko wrote 07/06/2017 at 15:03 point

So I have actually been noodling with something similar, but using BPW34 photodiodes as photocells

It's been purely in the "messing around in Eagle" phase, but upon mention of optimizing this using a dedicated analog circuit, i just stumbled upon this chip while browsing.

http://www.ti.com/lit/ds/symlink/tpl5010.pdf

Obviously, the "done" feedback would have to be addressed, which could mess with the pulse width, but I'm shooting from the hip here.

But a 35 na supply current would be a significant savings. Would have to drive that output to a JFET or something, to feed the inductor.

I jumped back into BEAM recently, jumpstarted by https://www.fetchmodus.org/projects/beam/photopopper/
and intrigued by ultra tiny, low energy solar circuits. I think this would be a great candidate for that sort of energy harvesting application.

Theres also the possibility (but this would ditch low cost) of using something like an LTC3588 and a piezo element. If it goes dead for some reason in the field shake it to reactivate. But some of the double layer supercaps are getting to the point where you can stuff a 4 farad, 5.5V capacitance into a 3/4" diameter coin. At these power outputs, that's nothing to sniff at. You ring your little board with 10 BPW34, you are talking decent recharge.

Use the solar voltage to hold a Mosfet like the one above open until it's truly dark, and carefully position it so the glow doesn't switch it back off.

Stick the whole thing on a round PCB in front of your coin double layer cap and go.

I'm not as adept at the piezo generation calculations, but the idea that you could shake to get a glow is also appealing, even if you have to deal with rectifying and voltage spikes and whatnot.


EDIT: Some additional information on coin cells that seems particularly relevant to your design

http://www.embedded.com/electronics-blogs/break-points/4429960/How-much-energy-can-you-really-get-from-a-coin-cell-

http://www.embedded.com/electronics-blogs/break-points/4430050/Using-a-capacitor-to-sustain-battery-life

  Are you sure? yes | no

Michael Stoiko wrote 07/06/2017 at 15:16 point

If my back of napkin calcs are right, and they probably are not, you could ideally charge from 1.2V to 3.2V in about 98 hours at 1000 lx, but could also run for 328 or so hours on such a charge (just using the 40 ua, not recalcing for everything). That's not a terrible ratio, 1 hour of light to 3 and a third hours of glow.

  Are you sure? yes | no

Ted Yapo wrote 07/06/2017 at 18:20 point

What solar cell area are you assuming?  How many BPW34s?

  Are you sure? yes | no

Michael Stoiko wrote 07/06/2017 at 19:19 point

I was looking at 8-10 of them, as my previous goal was similarly glow markers that could be glued to an outdoor surface and could last for a decade or so, at low cost, for things like road markers.

I've just moved, and finally have a workshop after waiting for 5 years to get back to electronics. So I've been mostly amassing parts and modelling (as my new bride prefers we finish setting up our living space before I vanish most nights into my cave). Short circuit current is about 70 ua and voltage is .365v in 1000lux, i've also got some nifty tesla photodiodes that comparatively huge, but hit 500 mv at 6ma in full sun. The BPW34s seem to hit about 475 millivolts (open circuit) @ 1.86mA (short circuit) max in full sun.

The tesla ones are like a dollar apiece though, and the BPWs, if you scrounge, can be had for .31 apiece or so.

I'll look into the TS3005, I see some for sale on Ebay.

I need to trim my exuberance, though, I think I have parts now for every fleeting circuit Idea I've had in the past 2 months, and still have boxes of unsorted components to organize consuming all my workspace!

The other [form factor] that would be interesting would be something tiny, like an Attiny4, with a LED bead stacked on top, optimized to fit on the end of an AA or a 1.5F radial supercapacitor, whatever one's option. As long as the diffused LED has a sufficient viewing angle, obviously. In my {solar} case, using the BPWs to ring the radial cap in 4-5 rings of 4, so it's always getting light from 1 side. Stack them close, you have something akin to a lanyard bead with a wide angle glow on the end.


There's just a lot to explore here with form factors. I'm really happy I found this, because it's exactly what I've been fiddling with, from the UV LED + Instrument Phosphor powder, to the same questions, just from a solar angle.

It wasn't ever really about being practical, in my fashion, though. It was about engineering the hell out of something innocuous for the fun of it. You just took it farther than I had the capability to.

Edit: My newness in actually commenting here is showing; I see below none of the chips or info I suggested are news to you, and this project is probably reaching end of lifecycle for your interest/attention!

  Are you sure? yes | no

Ted Yapo wrote 07/07/2017 at 01:29 point

Interesting.  Now, I'm wondering if some small area of solar cell around 7-segment LED displays could be used to boost the brightness when the ambient light is high; otherwise, the display can fall-back to a default battery-only dimness appropriate for dark conditions.  This might be interesting for #Micro-Power 7-Segment LED Display.

  Are you sure? yes | no

Ted Yapo wrote 07/06/2017 at 18:19 point

I looked at the TPL5010 - I think I have some in a bin somewhere.  The problem is that the minimum timeout is 100ms, which is a 10Hz blink rate and easily visible.  I don't know if you can run the part at faster rates than the datasheet specifies, but it might be possible.  And, yes, tickling the "done" pin is an issue.  I really like the low-power consumption, though - maybe this is a good way to make low-power blinking markers.

I also looked at the TS3005 https://www.silabs.com/documents/public/data-sheets/TS3005.pdf. It used 1.35 uA, and had timeouts down to 1.7ms, so seemed perfect.  I have a few of those around, too, which is good and bad because they're now discontinued :(

I've played with capacitors (I got some of those 4F caps you mention), and it works pretty well.  The 5.5V rating is wasted, though, if you are going to charge them to only around 3V.  I'd like to find some 3.3V caps in the same capacitance range - smaller and cheaper.

You could definitely use solar to recharge the supply, if you knew you were going to get enough light periodically.

I read those articles by [Jack Ganssle] a few years ago.  He was primarily looking at higher current drains, but it's good info.  The oversized 10uF capacitor I use is based partially on the second article.  Thanks for posting the links here; I really should start a references log to put these and other interesting links.

  Are you sure? yes | no

Michael Stoiko wrote 07/12/2017 at 18:21 point

Not to blow you up about various chips, but just ran across this one over lunch. Again looks intriguing. 

https://www.sitime.com/products/datasheets/sit1534/SiT1534-datasheet.pdf

At least for stability and ruggedness sake, it looks very solid.
Miniscule, too!




  Are you sure? yes | no

bulrush15 wrote 07/06/2017 at 09:17 point

I think I'm missing something basic. Is this a special circuit to power a normal LED? Or does the circuit power a special LED? I'd like to try out a couple boards of v2.x if they are not too expensive.

I'm very interested in this continuing. I'd like to see more of this, but focused on a low-cost version. I mean an LED, as a low brightness marker, that can run a year non-stop is a step up to me.

  Are you sure? yes | no

Simon Merrett wrote 07/06/2017 at 12:54 point

The LED is slightly special in that it is at one of the best frequencies to match the spectral sensitivity of the eye in low light environments. But you could use any colour. The LED is "sized"  to the circuit or the circuit is "tuned" to the LED die size. This is all component selection rather than adjusting parts. 

The driving circuit is special in that it is optimised to produce adequate light in the most efficient way. It pulses so that it is on only part of the time (but the eye doesn't notice) which saves energy. When it is on, it glows at an efficient brightness (best photon for your coulomb rate!). 

I'm sure you could "value engineer the #TritiLED but it would all depend on your scale I suppose. Without putting words in @Ted Yapo 's mouth, I'm pretty sure you'd have to do the legwork, although I can say from first hand experience that he's very supportive if you show effort. 

  Are you sure? yes | no

Ted Yapo wrote 07/06/2017 at 18:34 point

@Simon Merrett got it right.  I've been playing with special circuits to drive special LEDs, but you can use these ideas to drive normal LEDs, too.  It just might not be optimally bright or efficient.  [Elliot Williams] did this in #ATtiny45 EverLED where he used the same idea with a different microprocessor and a variety of different LEDs.  Just about any of them will work, some better than others.

I don't know how much cheaper you could make them - I also don't know what the exact cost comes out too now, but they're interesting questions.

I'm re-doing the design in KiCAD now - Eagle finally forced my hand with the new licensing structure.  It's my first KiCAD design, so it may take a little while.  I'm thinking about cost, too.

  Are you sure? yes | no

Alphas wrote 07/06/2017 at 05:51 point

Power loss of the resistor is not calculated correctly.

resistor P = I^2R = 1.44x10^-8W

Assuming 3V on led. P=(12^10-6)(3)= 5.22x10^-4 W

% = 0.052%

  Are you sure? yes | no

Ted Yapo wrote 07/06/2017 at 18:44 point

I think you made a mistake somewhere - I still get 0.04% .

Your calculation yielding 5.22e-4 is incorrect, it should be:  12e-6A * 3V = 3.6e-5W

My original method was to reason that the current through the resistor and the rest of the circuit is the same, so the ratio of powers (efficiency loss) is:

eta = (Vr * I) / (Vc * I)

for the voltage drop across the resistor Vr, and the drop across the circuit Vc.  The I's cancel, and you can just calculate the efficiency by the ratio of voltage drops. I should have been more explicit in the log.

  Are you sure? yes | no

Galane wrote 07/05/2017 at 21:27 point

Zippo made something like this. 6 in 1 Constant Light where the white LED was always on at a very low level, and returns to that after 10 minutes in any other mode. http://www.zippo-windproof-lighter.de/6in1/flashlight.html

  Are you sure? yes | no

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

Thanks for the link! That's very interesting, I hadn't seen those before.  They use 2x coin cells for a 6V supply, but don't mention the battery life.

So, the fact that Zippo made one makes me wonder if there is a market.  The fact that they no longer make them also makes me wonder.

Oh, and I can't find any used ones on ebay :-(

I would like to see what's inside.

  Are you sure? yes | no

Dylan Brophy wrote 07/05/2017 at 20:43 point

Congrats - you made it on the HaD Newsletter!

  Are you sure? yes | no

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

Thanks!  It's funny; I knew something had happened from the stream of like/follow notification emails I started getting.

  Are you sure? yes | no

Dylan Brophy wrote 07/06/2017 at 00:40 point

lol

  Are you sure? yes | no

freefuel wrote 07/05/2017 at 19:03 point
pkobla have you taken a look at the green arrays multi core chip? http://www.greenarraychips.com/home/products/

  Are you sure? yes | no

Adam wrote 06/22/2017 at 13:32 point

Please Please don't let this project be dead. It has been 7 months since the last update and the files on OSH are (I believe) 2.0 not 2.2. Simple instructions, a BOM, the gerbers (or the boards shared on OSH) and the hex are all that is needed for this project to be great and completed, don't let it just fizzle out like this. Also think about the hackaday prize for assistive tech coming up! surely these would be great as markers for those with partial sight loss.

  Are you sure? yes | no

Ted Yapo wrote 06/22/2017 at 16:11 point

To be honest, I didn't see the level of interest that would motivate "completing" this project to produce a final design.  It's more of an idea, and in that sense has been picked up, modified, and used at least three times that I know of, which I consider a success.  Maybe my perspective is different - I'm not sure I've ever built someone else's project as-is.  I look at the schematic, idea, or interesting technique, and maybe get inspired to try something on my own.  Once it gets reduced to "insert capacitor C2 into the holes marked 'C2'", I lose interest very quickly: I have a box of randomly-purchased never-opened kits as evidence.  My approach on hackaday.io has been to target like-minded people as an audience.

I did see some interest in buying completed units, but I don't want make these things for a living.  Any one of seven billion other people could do so.

Thanks for pointing out where I hadn't posted everything you might need
to re-create this project exactly.  I have it on my mental list to
re-work the board to remove the reverse-battery-protection MOSFET and
replace it with a resistor, which provides some additional protection, as discussed in #Decade Flashlight.  Meanwhile, the other MOSFET now has a 2,000 piece minimum order on Digikey, so I'll have to find a substitute.  The code also needs cleaning up.  I wouldn't release them in their current state, but I will accept your criticism and work (maybe slowly) toward posting more complete and usable info.

Oh, The Prize.  I was selected in two rounds of the 2016 prize, and paid with a few months being over-caffeinated, under-rested, and stressed out trying to make quick progress on projects I thought would compete well: I neglected my health and some other responsibilities to find time to work on them. In the end, I think I ended up spending more on parts and boards and miscellaneous stuff than I got in prize money (after taxes) - at best, it was a break-even, although I do have a few big bags of assorted parts I may never use.  This is obviously all my fault, but I learned something about myself in the process. I'm sure many others have had different/better experiences, maybe because they approach projects differently than I do.  The Prize is great, and motivates a lot of people to make awesome stuff, and I'm not trying to disparage it in any way: I've just decided that it's not for me.  This hobby is supposed to relax me - and than means working on what I want, when I want, how I want, and taking seven month (or longer) breaks when necessary :-)  So, I've decided that when a contest comes along, *if* I have a suitable project that is already in a submittable state, I might submit it.

That said, I am not alone on this project.  If one of my collaborators wanted to submit this project to a contest, I wouldn't stand in their way.

I'll just be frank about this: simple instructions aren't going to happen - if you want to build one of these you'll need to know how to assemble  an SMD board and program a PIC, which you can find many other places described better than I would.  I chose the new LEDs based on the fact that they can be hand-soldered, which should help.  You'll also need a PIC programmer and probably an SOIC-8 test clip, which seems to be the easiest/cheapest way to go.

EOR

(end-of-rant)

  Are you sure? yes | no

Jarrett wrote 06/22/2017 at 21:58 point

I feel you on a lot of this, Ted - As soon as "the hard stuff" in a project is complete, I rapidly lose interest. Packaging everything up as a kit so that someone else can blindly follow along is what I do for a dayjob, not something I want to do for fun.

I do have one issue with this, though! You say, "The code also needs cleaning up.  I wouldn't release them in their current state, but I will accept your criticism and work (maybe slowly) toward posting more complete and usable info."

There are about three projects I have on my Github in exactly that state. I promised myself that I would come back and clean up the code, but it hasn't happened yet. New, shiny projects come along, etc.

What I've found is that a working but "messy" codebase sitting on my harddrive doesn't do anyone any good. If I release something as-is, with dire warnings about the code's defficiencies, it at least gets someone a head start if they want to pick it up.

Please do reconsider!

But either way, I have enjoyed this project :)

  Are you sure? yes | no

Ted Yapo wrote 06/22/2017 at 23:18 point

@Jarrett Yes, you have a good point - if the originators of open-source (software) projects waited until it was "done" to release the source, we'd never get anywhere.  My comment was more about the hw side - I think as the 2.x design stands, there's a chance of catastrophic failure if the PIC locks up with the MOSFET conducting, or the MOSFET fails closed.  I have no idea how to assess the probability of these events, but the effect of either possibility can be mitigated with some design changes.  This means a board re-spin, buying parts, testing, then publishing.  This is exactly the kind of thing that makes me reconsider releasing "completed" designs - if someone who needs a completed kit-like design builds one, I feel I incur more liability in case there's a problem.  If I just present an idea, then someone implements their own version of the idea and happens to grow a second head as a consequence, any competent attorney would argue that the growth of the extra head was entirely due to their incompetence.

The sw is easier to just release.  It's actually mostly there in the original log from 8/30/2016:

https://hackaday.io/project/11864-tritiled/log/44864-version-2

It's just not cleaned up and githubified.  I think I hadn't used github at that point for anything - which is probably why this stuff never got in there.

Then there's the Eagle licensing stuff.  I own a 6.x license, but have been doing recent designs in a free 7.x version.  I don't know what to think about the subscription version, except that I don't feel like paying every month for something I only occasionally use, and then only so I can release stuff with a permissive/commercial-use-OK license. It's a mess, and I should really switch to KiCAD, but I might as well start writing with my left hand while I'm at it.  I guess this turned into another rant :-)

Anyway, yes, I can disclaimer all these problems away and release *something* that someone might find useful.  It's probably the right thing to do.  Thanks for the comment.

  Are you sure? yes | no

Ted Yapo wrote 06/24/2017 at 19:22 point

So, just in case anyone else is looking for all these things - github repo, all design files and code releases, easy instructions, etc, they actually exist for a version of this design in another one of my projects.  It's been there for six months , has 276 views, 1 follower, and zero likes.  I don't know why nobody notices that one.  The only significant  difference is that it doesn't have a CR2032 battery holder integrated on the board.

The main project is at: https://hackaday.io/project/19113-decade-flashlight

The circuit and PCB design and theory, along with a detailed BOM are at: https://hackaday.io/project/19113-decade-flashlight/log/50821-circuit-design-led-driver-board

The code is described in: https://hackaday.io/project/19113-decade-flashlight/log/50822-pic12lf1571-code

A 3D-printed case for that particular use (a flashlight instead of a marker) is presented: https://hackaday.io/project/19113-decade-flashlight/log/50823-printed-case

Detailed assembly instructions are given: https://hackaday.io/project/19113-decade-flashlight/log/50824-assembly-instructions

All the design files are in GitHub: https://github.com/tedyapo/ten-year-flashlight

And the boards are shared on OSH Park: https://www.oshpark.com/shared_projects/0BWPH1JP

Until I have a new version of the TritiLED project ready to release, that other one is available, if anyone wants to build one. The only thing you may want to change is the number of pulses per cycle, currently set in the code to 6, which results in a 40uA current drain - about 7 months on a CR2032 (10 years on a pair of LiFeS2 AA's).  You can modify that number to change the brightness & run-time.

  Are you sure? yes | no

pkobla wrote 05/18/2017 at 20:49 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

Simon Merrett wrote 06/06/2017 at 19:42 point

Peter, thanks - I found that useful as an insight into what's on offer in ARM and what the cost of entry looks like.

  Are you sure? yes | no

Ted Yapo wrote 06/07/2017 at 19:43 point

Hmm ... I didn't seem to get a notification about your comment; only saw it when Simon replied.

I have been looking at the Cortex M0(+) for some time, but haven't overcome the inertia of experience and comfort with the PIC to try it out.  It's probably overkill for this particular project - even the tiniest PICs really are, but they seem to be the cheapest and easiest solution at this scale.  I think if you designed an (analog) ASIC for driving LEDs like this, you could improve the efficiency quite a bit.  There's no reason for having a whole microcontroller to blink an LED periodically (which is all this is really doing).

For some more complex projects your suggestion sounds really good.  I'm going to have to dive in and try one out - thanks for the pointers!

As for the "CR2032 shrapnel", I see the parts on aliexpress - small and cheap, very nice.  I hope the use of the word "shrapnel" in their description is a mis-translation of the Chinese "sheet metal" rather than an indication of what people are buying these things for.

  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:

https://www.amazon.com/Science-First-Spectrometer-Project-Star/dp/B008ELSDVA

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

[deleted]

[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: https://hackaday.io/project/11864/log/43675-unbiased-testing

  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

Similar Projects

Does this project spark your interest?

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