V2.2 Release

A project log for TritiLED

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

Ted Yapo 07/12/2017 at 04:5223 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 from the datasheets.

This adds up to $8.35 in materials for single-unit quantities (battery not included: add $0.29 for that). If you build 100 of them, you can get it down to around $6.27 (batteries included :) The older inductor was only $0.68, but DigiKey has 0 in stock with a 22-week lead time - that would save almost $1. The MOSFETs could probably be substituted with cheaper parts, too.

You could save some money by removing the P-channel MOSFET. Reversing the battery might harm the PIC then, but wouldn't cause anything to overheat because of the 100R resistor. You could substitute a shunt diode as a reverse-battery protector, too. After the resistor, it would conduct with a reversed battery to spare the rest of the circuit. You just need a diode with low reverse leakage - even the 1N4148 has a 50uA maximum leakage! The B-E junction of BJTs is supposed to make a better diode for this kind of thing. Still, maybe you shave 10% off the parts costs, not that impressive.

Assembly Instructions

Here's where all the parts go on the board. There are only a few you can screw up: the two MOSFETs, and the 1206 R and C, so watch out for those.

You could probably hand-solder most of the parts: I haven't tried to hand-solder the inductor; I think you'd need to make the pads larger to be able to do that. I assemble them by applying solder paste with a 22ga blunt needle, then placing the components with tweezers. I reflow the boards on an electric skillet by letting the skillet warm up to around 180C (measured with an IR thermometer), then place the boards on the skillet. As the skillet continues to warm past 220-230, the solder melts, and I take them off.

The battery holder is hand-soldered on the back of the board after reflow.


(20170716) I fixed the components in the library to produce a correct solder stencil (removed paste from the ISCP pads and added it to the inductor footprint). I have ordered a stencil (for $7.75 with shipping) from OSHStencils, as shown below, but haven't tried it yet - I'll update this log when I have. The gerber file (GTP extension) is in the github repo as well as the updated Eagle files. OSHStencils doesn't seem to have a sharing option like OSH Park, but it's very easy to upload the GTP file and have a stencil made.

This is my first solder stencil, so we'll see how it goes...


You can check out this other log for ways to program the PIC. You need a programmer (PICkit3's are available cheap on ebay), and some way to attach to the IC or board.

Experimental Case

I put together an experimental case design in OpenSCAD. A case is important to protect users and the environment from the battery. Without a case, the battery might become loose and be a hazard to children or pets, or the contacts could short on nearby conductors. You must not leave these devices anywhere as markers if the battery is not secured in an inaccessible manner. The case uses screws to keep the battery where it belongs.

Here is what it looks like in OpenSCAD. You can see the details better in the rendering, because I usually print them in black, which doesn't photograph well:

And here is a printed one next to a bare board

The switch I used comes in various actuator lengths. If you choose a short one, it will end up recessed in the case. This will keep you from accidentally changing the mode: a toothpick or similar instrument is required. If you choose a longer length, it can protrude from the case and be easily accessible.

The OpenSCAD and resulting STL file for this design are in the GitHub repo.

The case requires (6) screws. I used #2-28 x 5/16" plastic thread-forming screws available on Amazon.

Moving Forward

The V2.2 design works well, and I think 5 years on a CR2032 is probably "good enough." What I'd like to see is smaller and/or cheaper designs. I can imagine forking the design to move in both directions: a cost-is-no-object tiny version, and a cost-reduced, but maybe bulkier one.

Moving back to a chip-on-board LED would help with the size, although the Luxeons I like (Z and C) are $2.74 each in single quantities.

Using a smaller inductor would reduce size and cost and increase efficiency. The problem is that the PIC, in its lower-power 500 kHz oscillator mode, isn't fast enough to produce the short current pulses required of low-value inductors.

New Architecture

What I'd like to try next is using the PIC running at 31kHz, which is the lowest-power clock it can do, still waking from sleep periodically using the WDT. This should dramatically reduce the PIC overhead current drain. To shape the short pulses for the MOSFET drive, I'll try using the 74AUP1G14/differentiator trick from the previous log. That part of the circuit had negligible current drain even with a 3V supply. Moving to an external pulse shaper will allow shorter current pulses than the PIC can do at low clock speeds. Shorter current pulses will, in turn, allow lower valued inductors which are cheaper, more efficient, and physically smaller. In this way, you still retain the flexibility of a programmable part but may be able to reduce the current overhead.

I think I feel a V3.0 coming.


Michael Stoiko wrote 11 hours ago point

Another promising chip for you:
I was looking for external nanopower WDT to solve the issue of the WDT oscillator consumption. It's already MADE to toggle a MOSFET at specified intervals, the pulse duration is programmable, and other than the startup resistance read, consumption is 35 na.

Importantly, singles are under a buck at digikey.

EDIT: I realize the 100 ms minimum time is an issue with the flicker fusion rate. I'm wondering if at 35na one could run either two or a signal delay with another FET to the inductor.

  Are you sure? yes | no

MarkRD wrote 10 hours ago point

If I read the datasheet right, the minimum width of the DRV pulse is 20 ms. That's over 1,000x too high. Ted's working around the 10 us pulse width area.

  Are you sure? yes | no

Michael Stoiko wrote 10 hours ago point

I knew there had to be something was missing. Tired eyes missed the prefix. The search continues

  Are you sure? yes | no

AlliedEnvy wrote 2 days ago point

Had a few more thoughts towards v3. How about using the PIC's comparator peripheral for a pulse shaper? Could keep it off most of the time, and turn it on for just a few cycles when needed.

Or similarly, you could possibly power up a pulse shaper circuit from a IO pin before sending the edge to trigger the pulse.

Also thought about building a monostable or Schmitt from discretes. It's kind of a pain, with a bunch of parts, but maybe you can better tune the circuit how you want it to act.

Hmm. I dunno if the 31kHz oscillator is going to be a net gain. The datasheet says it takes 500us to wake up with it. For 7.3 uA @ 3V, that's ~11 nJ for each wakeup, compared to ~2 nJ for 500kHz (5us wakeup, 133uA @ 3V). Worth testing though.

  Are you sure? yes | no

MarkRD wrote a day ago point

An integrated comparator isn't going to be optimized for low power. The datasheet for PIC16F18313 (the one I've got on my hard drive) says the typical current consumption is 31 uA, which is way too high for this. Other PICs will probably have similar spec.

The pulse shaper doesn't use much power anyway. It's the oscillator that takes the bulk of the current since it's constantly flipping state. Reducing frequency will reduce its power consumption, at least down to the point where the static power starts to become more significant than the dynamic power.

  Are you sure? yes | no

AlliedEnvy wrote a day ago point

> An integrated comparator isn't going to be optimized for low power.

Yup. What I'm hoping is that it's designed for enough speed to get short-width pulses out of it. The power usage can be mitigated quite a bit by disabling the comparator for almost all the time.

The PIC12LF1571 datasheet spec's 4.2uA typical @ 3V for the comparator in its low-power mode, and 21 in normal (faster) mode. If you enable it for (say) 100us every 16ms, that's only an additional ~26 or ~131 nA current draw for the peripheral (depending on mode).

> Reducing frequency will reduce its power consumption

While awake. But most of the time is spent asleep, with the osc stopped, waiting for the WDT to wake the PIC. When awake, we only run for a few (dozens?) clock cycles anyway. The issue I raised is that it takes 100x as long to awaken using the LF osc compared to the MF osc, which might offset the ~20x power reduction.

  Are you sure? yes | no

MarkRD wrote a day ago point


Forgot about the low power mode for comparator. I don't think juggling that on and off will be very useful (10 us Mode Change to Output Valid time), though the low power mode coupled with the PWM method I tested below could be useful. Connect the PWM output to a pin, then hang a voltage divider and an RC low pass filter off that pin in parallel. The voltage divider output goes to the comparator's + input, the LPF output goes to the - input.

Both start low, and the comparator output is low. When the PWM output goes high, the voltage divider assumes its value almost immediately, and the RC filter lags behind. Output goes high. Once the RC voltage passes the divider's voltage, output goes back low. When the PWM output goes low, the divider's output goes to 0 while the RC filter decays to 0, leaving the output low until the next rising edge. The comparator's internal hysteresis should (hopefully) prevent a glitch pulse from occurring when both are at GND level.

Since voltage dividers and LPFs are both ratiometric, the width of the output pulse would be independent of the supply voltage, and can be precisely defined by balancing the time constant of the RC filter against the output ratio of the voltage divider.

"While awake. But most of the time is spent asleep, with the osc stopped, waiting for the WDT to wake the PIC."

In the previous log Ted explored a Scmitt trigger relaxation oscillator, so he's not wedded to using a microcontroller for this. Regardless, in order for a digital circuit to keep time there must be some oscillator running, and the slower it is the less power it will use.

The WDT is clocked off the LPINTOSC. If you've got the watchdog timing your sleep duration, there should be any wakeup delay if you use LPINTOSC for FOSC as well, since it was never turned off. Furthermore, generating the pulse with peripherals greatly reduces the amount of times the microcontroller would need to wake up. While the PWM and Comparator modules are generating the FET pulses, a second timer can be clocked with a longer period to wake the CPU to perform its housekeeping or RESET tasks. Or the Watchdog can be configured to reset the CPU on expiration.

  Are you sure? yes | no

MarkRD wrote 3 days ago point

Another option to consider for V3 is using a PIC with an NCO peripheral. In pulse frequency mode you can get fine control of the frequency of the pulse, as well as specifying the number of clock cycles the pulse is active for when the accumulator rolls over.

The disadvantage of purely digital clocked topology like this is that the minimum pulse width is constrained by the clock period. You can't go less than one clock period. I tried to come up with some topology using discrete logic that had a master-slave flip-flop creating the delay for the edge detector circuit I posted before, but that would require either a separate, faster oscillator just for the flip flops or a frequency divider to create the slower pulses. Faster oscillators of course chew through more power.

The disadvantage you've found with the analog techniques is either the comparators are too slow or the Schmitt Triggers leak and have inconsistent thresholds.

Quite a stumper.

  Are you sure? yes | no

Ted Yapo wrote 3 days ago point

I haven't used a PIC NCO - I wonder if they run in shutdown, and if so, if they consume less power than the WDT?  With the PIC, the best I've been able to do is sleep as much as possible.  This means using a pulse frequency just above the flicker fusion rate - the 16ms WDT timeout is the closest.  Then, you have to choose the PIC oscillator frequency when it wakes - the fastest oscillator that is quickly stable is at 500 kHz, giving you an 8us minimum pulse. At this frequency and pulse width, to get the "right" amount of light, you end up with a  1mH inductor, which is expensive, bulky, and inefficient (~5 ohms resistance).

Ideally, to use a smaller inductor, you need two things. First, a shorter pulse width, which means running the PIC faster, which consumes more power, and means you have to waste time waiting for the faster oscillator to stabilize, wasting more power.  Given the constraint of keeping the peak current matched to the LED, the smaller inductor delivers less power per pulse, meaning you need a higher pulse frequency, so you get to sleep less, and that wastes more power.  I think the design is in a "sweet spot" given the current PIC offerings.

There might be a trick or two I'm missing in this basic analysis - maybe you can start the "high-speed" oscillator with a large divider so it consumes lower power until it is stable, then switch the clock divider to get a shorter pulse width.  I have to do some more experiments with this.

But, an analog solution might be best - no flash to degrade, no RAM to get screwed up by cosmic rays, etc.

The other thing I've wanted to do was use a feedback loop to control the inductor/LED current.  The problem is that sensing low currents is generally inefficient, inaccurate, or slow (choose one).

  Are you sure? yes | no

MarkRD wrote a day ago point

Initial results yesterday were...not good. Like 75 uA.

Then this morning I realized "DOH!! I forgot to turn stuff off with the PMD!". Stay tuned for round 2.

  Are you sure? yes | no

MarkRD wrote a day ago point

So it turns out the HFINTOSC is just garbage for this, at least on the PIC I'm testing with (16LF18326, bit fancier than yours). However, with the LFINTOSC I was able to get down to 1.27 uA! The pulse length has to be in integer multiples of 15.8 us though, since it can't go down more than 1/2 clock period.

It's quite a setup.

FOSC is set to the 31 kHz LFINTOSC, Clock Divider setting = 1. BODs and WDT are all disabled. All unused I/Os are set to digital input with WPU enabled. This saved 1 uA!

Everything in the PMD is disabled except TMR2, PWM5, CLC1, and CLKREF.

TMR2 is set for 10 ms period (100 Hz). Current consumption of the PIC isn't that sensitive to the period. I tested 1 kHz and it only increased to 1.38 uA. PWM5 is set to the absolute minimum duty cycle, to be high for 1 clock cycle.

The key to getting a half-period pulse length is to set the CLKREF peripheral to 25% duty cycle, and use CLC1 in AND-OR mode (4-input AND would also work) to AND the PWM5 and CLKREF outputs together. Then the Peripheral Pin Select directly routes the output to any I/O pin you care to chose.

After initializing all the peripherals, I set IDLEN to 1 so that the oscillator keeps running during sleep, and then SLEEP();. I've verified with my oscilloscope that it can keep making pulses while asleep. 

  Are you sure? yes | no

MarkRD wrote a day ago point

And in case you're wondering, cutting out the CLKREF and CLC stuff and directly outputting the 32 us 100 Hz pulse from PWM5 to the pin drops current down to 1.11 uA. Helpful if you're going to use an external pulse shaper.

  Are you sure? yes | no

bulrush15 wrote 07/13/2017 at 17:44 point

Hey Ted, the link for the Tritiled v2.2 log entry, for the Aliexpress LED lights has been replaced. The new link is:

The product on the old link is no longer available.

  Are you sure? yes | no

Ted Yapo wrote 07/13/2017 at 20:41 point

Thanks!  They seem to have split the cyan ones into a separate product listing than the other colors for whatever reason.  I just re-linked to the new cyan one, but your link can get people to the other colors.

  Are you sure? yes | no

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

I dig it. Now, another headscratcher. 

The longevity of the push button. Thoughts on adding ONE more component, but dynamically adjust the light level to compensate for ambient. You automatically shutdown in brightness, too. I'm just thinking on the elimination of moving parts.
Capacitance switch?
Photo-interrupt, with the LED as the light source?
A hole to a phototransistor, AND with the back pulse to the LED, if the hole is covered during a flash, counts it as a button press. Timeout for a "debounce" of sorts.

I've had too many expensive electronics (like night vision devices) break because the entire thing was tanklike and built to last, EXCEPT the damn switch.

I have one monocular that had its IR illuminator switch replaced by the abort button from a clean agent system we decommissioned. That sucker had been in service for 30 years, and with a good cleaning, should last 30 more.

  Are you sure? yes | no

Ted Yapo wrote 07/12/2017 at 19:45 point

Yes, the button sucks as a point of failure.  Sometimes I don't populate it on the board.  The only reason it is there in the first place is to select constant or blinking modes (they moth consume the same average power, so the battery life is constant).  The brightness isn't adjustable once programmed.

I'm not even too wedded to having blinking modes at all, except that they really are attention-grabbing, and you might want that in some cases.  I didn't intend for the button to see much use - more like you set the mode, then leave it.  You could do the same with changing the code, but that would require a programmer.

I have thought about auto-adjusting brightness, but decided it might reduce visibility.  Visibility is a function of ambient light, but also of the eye's adaptation state.  If I walk into a dark room with my eyes light-adjusted, I need the marker glowing brightly to be able to see it; if it has adjusted down with the ambient light, I might easily miss it.  Unfortunately, there's no way for the marker to know the adaptation state of the observer's eyes, so it has to remain bright.

  Are you sure? yes | no

Michael Stoiko wrote 07/12/2017 at 20:14 point

Fair point.
I again forget the human element. Damn, imperfect humans!

  Are you sure? yes | no

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

The other option that wouldn't require any changes at all would be a hall effect switch. We use those for the test button on industrial smoke detectors, along with a hefty delay, to prevent accidental use, and to cut down on mechanical failure on a device that needs to be in harsh environments, last a long time, AND be tested multiple times a year. 

  Are you sure? yes | no

Ted Yapo wrote 07/12/2017 at 22:29 point

Oh, in case you didn't see it buried in one of the older logs - you can substitute an IR LED on these boards.  I have tried 730nm, 850nm, and 940nm.  The 730 can be seen as a dull red glow by the naked eye, while the 850 and 940 are not visible.  The 850 looks very bright in a gen 1 intensifier - it's a very nice IR-only marker.  The 940 is much less bright.

  Are you sure? yes | no

Michael Stoiko wrote 07/12/2017 at 23:29 point

Sounds good.

Now i'm wondering, were I to make a an IR beacon, and if we are
ALREADY conceding to a whole microcontroller, why not do the pleasing
slow pulse rather than regular blinking? Modify the timer each time. The only thing is that could be a LOT of red/write cycles internally, unless you use a matrix of times and move the pointer around or something. I still think that cool lighthouse effect is an interesting visual to draw attention.

I'm still waiting on inductors, but I have a few board designs. I'm realizing if I really want to get into the weeds I need to build an automated LED testing rig to use my huge pile of LEDs effectively. So I'm waiting on digital pots, too. Starting from your excellent writeup.
Sorry to spam on here with vicarious building. 

I'm wondering if a second factor could also be explored;
measuring the current+voltage delivered in the circuit versus the
frequency. Optimize the power consumption by the LED, inductor, and MCU.
There has to be a point where parasitic losses drop due to resonance.

I have a few LED backlights that really put out the lumens in a distributed fashion, I'm trying to work out a diffuser so I could remove the directionality from the testing. I have a hunch that some of these backlights already are being run very efficiently, and with a larger visual area might make a very good marker for larger items.

I've got about 5 different (eagle) iterations of boards at this point, due to my hodgepodge of parts in my garage. I will need to do the proverbial "write drunk, edit sober" culling of these, though, as many were attempts to get a fleeting thought out.

I still can't build ANYTHING to test, waiting on parts AND I need to fix my fluke, which suddenly and unexpectedly died.

I'm also still digging through what nanopower devices I can find, and trying to see if I can construct a low frequency oscillator with the lowest possible power consumption.

It might also be useful for boosting voltage in my other solar projects, as those energy harvesting chips are still way too expensive to use in low cost applications.

  Are you sure? yes | no

Ted Yapo wrote 07/13/2017 at 02:01 point

@Michael Stoiko Sure, you could make it pulse - you could probably just unroll your whole loop since most of the flash is unused currently: just repeat the code for  (pulse, re-write WDT timeout, sleep) over and over.  This might be tedious to write, but more efficient than some sort of loop and lookup table.

If you just need to characterize a few LEDs, you can do it manually with a few meters and a light sensor.  It's a bit tedious, but it works.

It sounds like you have some good ideas to try - it will be interesting to see what you come up with...

  Are you sure? yes | no

Simon Merrett wrote 07/12/2017 at 07:23 point

Crikey Ted, I didn't see that ending coming! 

Well done on reaching this milestone - there has been a fair amount of new people interested in #TritiLED and this will probably be the stimulus for several of them to dive in and develop it further. 

I feel your frustration with KiCAD but I'm determined to get to grips with it now that Eagle is tightening up. Everything takes longer so I'm just being more picky about what I want to commit to FR4. 

Now we just wait for TritiLEDs to appear ready-made on Aliexpress...

  Are you sure? yes | no

Michael Stoiko wrote 07/12/2017 at 20:16 point

Then we can hack them into all sorts of other useful timing circuits, and exploit the price break!

  Are you sure? yes | no