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

A project log for TritiLED

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

Ted YapoTed Yapo 10/31/2016 at 21:0518 Comments

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

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


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


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


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

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

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

Circuit Design

Here's the design for version 2.2:

Q2 protects the circuit (and battery) in case the power is connected incorrectly - it only allows current to flow with the proper polarity. Unlike a simple blocking diode, the MOSFET introduces almost no voltage drop in this circuit, maintaining high efficiency. The PIC12LF1571 sleeps most of the time, periodically awakened by the internal watchdog timer to pulse the LED. GP4 and GP5 are paralleled to provide more current drive to switch Q1 faster. Turn-on speed is not really an issue, because at turn-on, there is no current flowing through Q1. At turn off, however, with the maximum current through Q1, rapid switching is important to minimize the time that there is simultaneously voltage across and current through Q1 - any such power is wasted. When Q1 is on, current builds through L1, while D1 is reverse-biased. When Q1 switches off, the current through L1 continues to flow, now through D1 to produce a pulse of light. R1 is included in the testbed board (see below) for measuring the current through D1 and calculating electrical efficiency.

I chose these particular MOSFETs because they were the first ones I found meeting my specs (and in SOT-23 cases). It's certainly possible that cheaper equivalent ones can be found.

The pushbutton switch SW1 allows selection of different modes. A "weak" internal pullup holds the line high when the button is not pressed, and de-bouncing is done in software. Unfortunately, the weak pullup isn't very weak, and pressing the switch draws about 80uA of current - many times that of the circuit itself. Currently, the software allows selection of a constant glow, fast pulse (8 Hz) or slow pulse (1Hz). The average current drain is the same for all modes, so that the pulse modes are much brighter and attention-grabbing than the constant glow.

Pads on the production board (or headers on the testbed) allow for serial programming of the PIC12LF1571. Here's an image of the testbed, which is the same circuit as the circular board, with the addition of a 1-ohm resistor at R1 and more convenient headers for measurement. On this version, I've added clips for testing different LEDs.

Component Tolerances

One of the problems with this circuit is that the Bourns SRR6028 inductor is specified with a +/- 30% tolerance. Otherwise, this series of inductors would be ideal - nice form factor, current handling, shielding, SRF, etc. Since most of the power in this circuit goes into the LED, that 30% inductor tolerance translates into a large power tolerance, and hence a large runtime tolerance. The PIC12LF1571 has an OSCCAL register which can speed or slow the clock by +/-12% which you can use to partially compensate for the inductor tolerance, but that still leaves a lot of possible variation between units. I have no idea about battery capacity tolerance (I've never seen one specified), and it may be that over a period of years, with varying temperature and aging components the 30% inductor isn't the worst variability factor. But, I'm still trying to come up with a software compensation scheme - I've tried dropping N out of every 256 pulses, for instance, as a power fine-tuning, but this introduces a noticeable blink or flicker.

LED Selection

I've chosen to use LEDs from Chanzon for several reasons:

About the only downside is the lack of detailed datasheets. But since I'm figuring out how to measure the LEDs anyway, it doesn't really matter.

Here are the LEDs, with some mounted on boards for testing:

The colors are (in random order):

  1. 940nm IR
  2. Amber
  3. Green
  4. 850nm IR
  5. UV
  6. 730nm IR
  7. Pink
  8. Deep Red
  9. Warm White
  10. White
  11. Royal Blue
  12. Full Spectrum (grow light)
  13. Blue
  14. Red
  15. Natural White
  16. Yellow
  17. Cyan
  18. Orange
  19. Cool White

I've tested most of these 3W LEDs with the #Automated LED/Laser Diode Analysis and Modeling system, and am currently finishing the code to evaluate the efficiency of the various LEDs in this circuit. I know for the green and cyan LEDs, the V2.1 circuit achieves about 98-99% of the achievable LED efficiency, but for some of the other colors, circuit adjustments will be required to get really good efficiency, since the efficiency peak for some of these LEDs is in the 100mA range, as opposed to around 10mA for green and cyan. A combination of different inductor values and different software timing will probably be required. For some LEDs, moving to a "1W" (30x30 mil) chip from the "3W" (45x45 mil) chip may be enough. Luckily all of the colors are available in both sizes.

Next Up

I need to spin a version 2.2 to fix the backwards MOSFET. While I'm at it, I might think about making the board smaller. It's a shame that the CR2032 holder is 30mm across for a 20mm cell; the 30mm diameter PCB certainly seems over-sized. Once I have a fixed, tested design, I'll add design files and code for download.

I'm continuing to measure the different LED characteristics and determine the circuit and software changes to drive the various LEDs efficiently. Of course, some of the colors will be less efficient as markers, but it seems a shame not to support the wide variety of colors available.

Finally, I'm measuring the electrical efficiency of the circuit with the testbed board to see how much more could be gained.


Daniel wrote 05/05/2017 at 20:42 point

Sounds really useful. Would love to put these around the house to avoid bumping into things at night.

Some coin cell holders inherently prevent a reverse battery from making contact.

  Are you sure? yes | no

Ted Yapo wrote 05/05/2017 at 21:47 point

I hadn't seen holders that prevent reverse battery issues, but that's a good thing to look for.  I found that the MOSFET works well for protection - I wonder which ends up being cheaper?  

The best/cheapest answer might be "none of the above," though. I found that a 100-ohm resistor in series with the battery is probably enough protection - at 10uA current drain from a 3V cell, an extra 100 ohms in the supply only wastes 0.03% of the power, and limits the maximum reverse current to 3 mA, which I suspect the protection diodes in the uC can handle safely.  If you left the battery in that way, you'd drain it but it otherwise wouldn't harm anything.  Plus, resistors are dirt cheap.

I have a few of these in places around the house and some strapped to telescope junk. I keep thinking about drilling some recesses in my staircase balusters and popping a few of these in there to light the way.  Maybe I could 3D print a little enclosure that would fit in the corner between the treads and risers instead - I'd have to screw them down to prevent issues with the dog.

I removed the collection I had on the nightstand - the light was keeping me awake.

  Are you sure? yes | no

zakqwy wrote 05/04/2017 at 13:32 point

I've had some luck hacking the wings of CR2032 holders to reduce their width. You lose a bit of physical strength but I've never had one pull off if it's properly soldered. Might be a reasonable solution that avoids moving to a smaller battery or a weird holder.

  Are you sure? yes | no

zakqwy wrote 05/04/2017 at 13:34 point

example showing trimmed but not completely removed wings: 

  Are you sure? yes | no

Ted Yapo wrote 05/04/2017 at 14:35 point

Nice idea - I hadn't thought about trimming them down. They also make through-hole versions that avoid the wing width altogether - but you need holes for mounting.  It might be possible to solder the through-hole version to castellations on the side of the board, or even fold down the wings of the SMT holder and solder it to a row of castellations or just top/bottom planes.

For long-lived projects, there's always the option of tabbed cells you can solder directly; this probably gives you the smallest power source.

  Are you sure? yes | no

K.C. Lee wrote 05/04/2017 at 23:15 point

If the battery holder off one end of the PCB, you could rotate it 45 degrees to save the space for the solder tabs.

  Are you sure? yes | no

Simon Merrett wrote 05/04/2017 at 12:06 point

Hi Ted, I love this project and I would like to use some of it's findings to design a torch for my three year old son. Key goals are and always visible "sleep/snooze" state akin to the tritiled concept so that he can find it in the dark. The button press would then increase the drive to the led to produce a more illuminating output for a couple of minutes and then transition into a slow ramp down in power back to the sleep mode level. Another press of the button would turn the brightness back up. This would stop him from draining the battery all in one go by forgetting to turn it off (I realise this kind of feature is akin to the kind of convenience which results in small children trying to swipe the TV screen like they do with their parents' mobile devices!). 

Talking of batteries, I'm planning on using a decent Panasonic 18650 lithium ion cell so the always-on efficiency isn't as demanding as for tritileds but I do want to drive the LED efficiently for the "on" mode. As I don't want him to hurt his eyes by looking closely at the LED I plan to keep the "on" brightness pretty low (so he can explore dark places but not necessarily a proper flashlight power). 

I plan to use a generic 5mm white LED and have a TSL2591 ambient light sensor. If I'm only trying to find the power / efficiency relationship of one LED can you see an issue with me using this chip instead of the VEML7700 (which is difficult to find in UK)? 

The most unclear part to me is sizing and selecting parts for the LED driver. If I can determine my ideal current, do I just copy the tritiled V2.2 schematic into LT Spice or other circuit simulator (none of which I have used before) and play with the inductor value until I hit a sensible charge/decay mean current? 

When I'm looking for Q1, you mentioned "first ones meeting your specs" can you please confirm what those were? Low RdsOn, low Vgs-threshold, fast response (especially when turning off)? Anything else? Can you see any uC protection issues when driving Q1 directly from GPIOs without a resistor or diode? 

Thank you very much for trailblazing all of this (and I appreciate it has been a team effort more recently)! 

  Are you sure? yes | no

Ted Yapo wrote 05/04/2017 at 15:29 point

First, I just have to comment about safety.  You probably are well aware of the risks giving battery-operated devices to toddlers, but just in case someone else reads your comment without knowing better: you have to be absolutely sure the child can not access the battery directly.  Lithium coin cells can be deadly if ingested - here's what the CR2032 datasheet ( says:

"KEEP OUT OF REACH OF CHILDREN. Swallowing may lead to
serious injury or death in as little as 2 hours due to chemical burns and
potential perforation of the esophagus."

Serious stuff.  I'm sure there are similar dangers with Li-ion cells, so be careful!  I personally wouldn't feel comfortable giving a home-built device to a child.

Having said that, I think a lithium-ion cell might be a little more challenging than a LiMnO2 cell in this application because of the larger voltage drop of the cell.  The Li-ion cell will range from 4.2 to 3.6 V or so over the charge lifetime, so the LED current may vary significantly.  Ideally, you could measure the cell voltage with an A/D and adjust the timing to keep the same LED current.  Maybe this doesn't matter with a rechargeable cell and larger capacity anyway - and you're not going for ultimate run-time.  The LED may simply dim as the battery drains.

I found that for 5mm LEDs that the current required for maximum efficiency is very low (a few mA maximum).  You need a huge inductor (many mH) or very short on-time to create such small current pulses with this circuit.  That's why I ended up going with large-die LEDs.  Even though they are normally intended for much brighter output, the large die brings their optimal current level into the tens of mA range, which is much easier to generate with decently efficient inductors and small microprocessor clock rates.  Even so, I'm using a 1 mH inductor, which is very large for a switching supply - there's lots of wire on there, the SRF is relatively low, and it's probably not as efficient as a smaller-valued inductor.  If you are interested in maximum efficiency, I'd use a larger-die LED, or an array of parallel 5mm ones.

Yes, the TSL2591 will work just as well for measuring the curves.  A simple circuit and two meters will do the rest, like shown here:

Just the bench supply and a series resistor should give you a decent curve - the multi-turn regulator just makes it easier to collect closely-spaced points.

I'd be interested to see the curves you generate.

As for inductor sizing, to a first approximation, the LED current is a function of the inductor size and the pulse width (assuming the supply voltage, the LED forward voltage, and series resistances are fixed). I found that using a simple SPICE model (power supply, inductor, LED, MOSFET and estimated series resistance), I could roughly predict the peak current in the circuit (which I then measured with an oscilloscope).  The inductor I used has a tolerance of +/- 30%, so my simulation didn't need to be that exact - each device may need to be tuned after assembly.  You can change the pulse width in software (rough adjustment) and the oscillator trimming (fine adjustment) to tune the LED current.  If you don't care about absolute maximum efficiency, it probably doesn't matter.  For example, here's the efficiency of one of the LEDs I used vs the peak current for a sawtooth drive waveform (like that of the inductor circuit):

The circuit achieves at least 95% of the LEDs efficiency with peak currents from 10mA to 60mA (or 90% from 5 to 100 mA).  That's a very wide range (although much less current than the 400-500 mA current for "normal" use of the LED).  You should be able to get your circuit within this range with simple SPICE modeling and/or measurements. 

As for the MOSFET, you mentioned the important specs (Low RdsOn, low Vgs-threshold, fast response).  I would ad package and cost.  If your inductor has a high series resistance, though, there's no use finding an ultra-low RdsOn MOSFET :-)

You could add a gate resistor if you wanted; I don't think it's necessary here - there's no need to slow the edges of the pulse, and the small input capacitance of the MOSFET shouldn't be a problem for the GPIO(s).

  Are you sure? yes | no

Simon Merrett wrote 05/05/2017 at 13:17 point

I've tried a simulation in LTspice and this is my schematic:

And this is the plot I get:

The probed voltage and current shown are at the base of the LED, on the same wire as the MOSFET and inductor. I've put both voltage sources on 4V and am pulsing the MOSFET gate at 32ms period square wave (based on ATtiny85 WDT shortest time of 16ms). Varying the LED I use has little effect on I(V2) and varying the inductor values does nothing. 

Does any of it look like I'm getting it near right? Is there a better way you'd recommend to do the simulation?

  Are you sure? yes | no

Ted Yapo wrote 05/04/2017 at 19:31 point

As a first approximation for modern InGaN LEDs, you might assume the peak efficiency is at 5% of the rated current - this is just a guess based on what I remember about some of these LEDs.  

I probably should plot the results of all the LEDs I have measured (current @ peak efficiency vs rated current) to back this statement up.  But based on the graph below, since the overall efficiency doesn't change much in the neighborhood of the peak, maybe this "rule" is good enough. 

  Are you sure? yes | no

Simon Merrett wrote 05/04/2017 at 22:41 point

Thanks for both your quick and thorough replies. I do appreciate you taking the time to reiterate battery safety for the good of everyone - exactly how it should be done. I plan to have the torch sealed in silicone rubber and a control measure/ handshake  between the charger and the battery before power can be received, plus short circuit protection. 

I'll try some ideas tomorrow, including looking at a larger die LED - thanks for helping me put the pieces of understanding together. 

  Are you sure? yes | no

Simon Merrett wrote 05/26/2017 at 14:16 point

Ah, now I can see why you get different modes if you don't let the inductor discharge fully:

This is simulation of course but it explains what happens in the first millisecond - the current peak goes from 16mA to 24mA. A significant difference potentially.

  Are you sure? yes | no

Ted Yapo wrote 05/05/2017 at 15:24 point

Your simulation is a good first start - I see two issues with it that are keeping you from seeing how it should work.  First, I don't know what the default parameters for the NMOS model are - you're better off choosing an actual device that's at least in the ballpark of your intended part.  Here, I chose an FDS6930A, which is overkill, but in the library already.  Also, the 1mH inductor saturates very quickly - your pulse width of 16ms is way too long.  Pulse widths of a few us are required here - even if they have a period of 32ms.  You can generate many pulses in a row with code during one WDT period to increase brightness.  Here's what I came up with:

The 4.5 ohm resistance is the max specified series resistance of the inductor I'm using.  The 39R is to simulate the output impedance of the uC port pin - a rough guess.

Here are the waveforms:

The input pulse (5us long) is the bottom (cyan) trace.  The inductor current is in the middle (yellow), and the LED current is at the top (magenta).  The peak current is right around 20mA.  Note that at 3V, I use a pulse with of 8us to get a comparable current pulse - at 4V supply, you need a shorted pulse.  With the 8us pulse at 4V, I see a peak current of 31mA - again, that will still get you 95%+ efficiency as discussed earlier.

Anyway, you should see waveforms of this shape.

Oh, and you can ignore that little negative-going current spike through the LED at the beginning of the input pulse.  The LED junction has some capacitance, and it takes a little current to charge it up to the reverse bias during the pulse.

  Are you sure? yes | no

Simon Merrett wrote 05/05/2017 at 21:55 point

Thank you - this is all so helpful. Your graphics were so useful in getting to what I now have:

L1 has a resistance of 8 Ohms built into the properties, so I didn't add a separate resistor. The real MOSFET made a world of difference and I wasn't plotting the correct probe points. I copied the same LED as you just to improve consistency. You mentioned your inductor was 30% tolerance and I've found the Coilcraft MSS1210 series has 10% and low resistance (8.2mH has 7.05 Ohms).

Here's the plot:

So, with a 4uS pulse (by the way, the 16mS pulse I did before was because I can't read PIC code!) I get around 2mA peak I(D2) - the LED. I have varied the pulse duration and 6uS gives ~3mA, 8uS ~4.5mA and 10uS ~7mA. So at least there's a software definable element to the current once I've bought the components. [edit] I plotted the wrong voltage in blue, so that is seems inverted. Once I found the correct probe point it looks fine, as per your plots.

Just a question on the negative current on the LED trace. The voltage exceeds the 5V breakdown voltage on many LEDs- is that an issue? I assume that if it does result in a reverse current, the duration is too short to do significant damage to the LED. Thoughts?

So I looked for your 3W Chanzon LEDs and can only see "growlights" on Amazon in the die and package that you are using. Not exactly the colours I was looking for. The Aliexpress store has a variety of other sizes. There's a 5730/5630 white version which has a decent size die and although only 0.5W rated, seems like it's better than the 20mA rated 5mm through hole LEDs.

Thanks again - Will see where this takes me. Having read some stuff about the eye safety of blue LED light, I wonder if a yellow torch made from red and green is a good way forward for children.

  Are you sure? yes | no

Ted Yapo wrote 05/05/2017 at 22:33 point

@Simon Merrett, replying here due to thread-depth limit.

Your waveforms look correct now.  When you get to fine-tuning, you'll find that moving the pulse spacing slightly can improve efficiency a little. Aligning the start of the next pulse with the downswing of the ringing (shown in your blue voltage curve) conserves energy in the system.  I got an extra few percent by tweaking the timing between pulses - but this is something to do with the actual circuit, not in simulation.

The voltage pulse is correct - the MOSFET pulls the end of the inductor to ground, causing the current to ramp up.  When the MOSFET switches off, the inductor discharges into the LED - but this also causes the drain of the MOSFET to exceed the supply voltage (by the LED forward voltage).  I see the same shape waveforms in simulation and on the 'scope.

The maximum reverse voltage on the LED is the supply voltage; keep this under 5V (or whatever the maximum for your LED is), and you'll be fine. The forward conduction of the LED keeps the ringing from being a concern.

Some LEDs have a reverse-protection diode built into the package - avoid these if you can.  The chanzon LEDs I have seen don't have these diodes.

I bought most of mine on aliexpress, but also found some on ebay.

Yes, blue light is a concern - even some white LEDs may emit an unsafe level of blue if you are close enough.  You can get yellow-emitting LEDs, too, although a mix of red and green might give you a little better color rendering (still not great).

The other trade-off involves the uC itself.  I run the PIC at 500kHz clock frequency (which means 1 cycle is 8us, and the width of my pulse).  Increasing the clock speed of the PIC causes it to draw more power, negating a lot of the efficiency gains, even though I get more control over the pulse width.  You will have to experiment with your ATtiny85 to see what effect changing clock speed has.

Looks like you've got it now.  Good luck!  Make a project or otherwise share your progress; I'd be interested to hear about it...

  Are you sure? yes | no

Simon Merrett wrote 05/25/2017 at 22:53 point

@Ted Yapo I have received some orange 5730 orange (claimed as yellow) LEDs from Chanzon. I have used a 3.3mH inductor with low ESR (about the same as your 1 mH) and set the pulse on the N Channel MOSFET to be on for 20uS and off for 10uS. The pulse timing took a bit of playing around with to get approx 10mA flowing through. The rated current is 60mA, so 12mA would be the 20% that you found was a good approximation for peak efficiency. 10mA is close enough to that. 

Here's a picture where I have connected that all up to a 3V3 supply and also a second identical LED (the lower of the two, to the right of the breadboard) which is connected in series with a 110R resistor that also gives 10mA current. 

I'm a bit stuck now. Both these circuits appear to have a similar amount of light coming from the same level of current. What's more efficient about the inductor/MOSFET driver?

Here they are in the dark for comparison:It's pretty much the same. What am I missing here? Also, to add to my confusion, the voltage reading across the inductor driven LED is showing up as 0.13V....

Many thanks if you can shed some light on this (pun not intended). Also please say if you would prefer me putting this into a separate project and just name dropping you with the @ symbol when I want to reach out.

  Are you sure? yes | no

Ted Yapo wrote 05/26/2017 at 01:21 point

@Simon Merrett I'm glad to hear you're still working on the idea and making progress. Something doesn't add up with your latest experiments.  I think measurement error could be part of the issue.  Here are the confusing parts for me:

1) Your MOSFET on-time is longer  than the off-time, which differs from the simulations - see the simulation waveforms - the time to dump energy into the LED is longer than it takes to get it into the inductor in the first place.  I suspect you are running the inductor in a continuous conduction mode - the current through the inductor may never drop to zero..  This might be fine, but I haven't looked closely at what happens in this case - CCM happens all the time in other switching supplies, and my intuition is that it's probably not an issue here.  It's just different and that stands out.  Do you have access to an oscilloscope to examine the waveforms?  I think this would help quite a bit.

2) I think you are missing bypass capacitors on your prototype - with a switching supply like this one, you need some good, low-inductance bypass caps on the breadboard.  This is especially true if you are trying to measure the current draw with a DMM, which may give bad readings if there is noise on the supply - I have seen this effect while measuring these circuits.

3) The ratio of optimal to rated current I have observed is 5%, not 20%.  For a 60mA rated, LED, I would guess the efficiency peak is closer to 3 mA than 12 mA.  This may be different for LEDs not made from InGaN, which is what I mostly looked at (because they are overall more efficient).  The chips in the 5730 packages may still be too small to give enough light at the maximum efficiency point.  I think 5730's are typically rated 0.5W, while the ones I have been using are 3W.

4) The other thing to realize is that if you're driving the LED with DC at the efficiency peak, there's no reason to use a pulsed mode (except maybe to gain the efficiency of a switching regulator vs a dropping resistor).  Pulsed modes only make sense when you need *less* light than the LED produces at maximum efficiency.  So if 10mA were actually the efficiency peak for your LED, and you need that much light, you're better off just driving it with DC.  Whether you can regain some of the power lost in the ballast resistor is another story; a switching converter could help with that. 

5).  How are you measuring the voltage across the LED (the 0.13V)?  With a DMM?  Unfortunately, that won't work  The 300kHz frequency switching is just going to confuse a voltmeter - and you in turn :-)  Been there; done that.  You need an oscilloscope to make these measurements.

6). The yellow LEDs you have may be relatively efficient near their rated current - I have mostly worked with cyan and green LEDs because they are the most efficiently detected by the eye.  I found this data I had collected a while back for a 3W yellow LED (my analyzer is packed away in a box at the moment):

The peak efficiency seems to be maybe 175 mA, for an LED rated at 400-500 mA.  So, in this case, the efficiency peak is closer to 35% of the rated current than the 5% I measured for cyan or green LEDs.  You may be seeing a similar thing for your yellow LED.  The only sure way to know is to measure the efficiency curve.  In this case, though, you can see that pulsing the LED with 100mA or so will still be more 2x more efficient than 10 mA DC.  Short of measuring the curve for your particular LED, maybe you can re-work your circuit using the 35% value.  That could make the difference.

Keep at it; you are getting there.  If you want to start a separate project, that's OK with me - you might get input from others there, too, who may see something I've missed.  I'm also happy to continue the discussion here if your prefer.

  Are you sure? yes | no

Simon Merrett wrote 05/26/2017 at 10:33 point

@Ted Yapo you have helpfulness and an uncanny ability to remotely diagnose the key issues, in equal measure. I'm grateful and in awe!

1) The MOSFET pulse duty cycle does really need looking at properly - I bodged it until I got a 10mA reading on the DMM! I shall go back to this in LT Spice. 

I have this scope - which claims 

Analog bandwidth: 0 - 200KHz, Sampling rate: 1Msps max, Sensitivity: 10mV/Div - 5V/Div, Sensitivity error: < 5%, Vertical resolution: 12-bit, Timebase: 10us/Div - 500s/Div. There's a possibility I'd be able to use it but we're talking about signals at the limits of it's abilities! 

2) Yep, I need to add caps! I have also bought the 6.8mH and 10mH inductors in the same series as my 3.3mH one, so will be interesting to see what the scope sees as I swap those around.

3) Ah yes, 5% for your InGaN. However, 35% for the Chanzon 3W yellows is interesting. I was thinking of paralleling some 5730's up (I've already done this on the breadboard but didn't take a photo of it) to increase the light produced but allow me to spread the source around. This is as opposed to having a single die produce all the light because I don't want my son to be able to shine all of it into a single pupil! 

4) I do want the always-on feature, so having the ability to run efficiently at low current is a desirable aspect of the circuit. If it all gets too much I can always just stick a high value resistor and a white LED across VCC-GND - the wasted current would be negligible if it remained on when the torch was in use and the low light output would (I presume but don't know) contain negligible blue light eye health risk. If I can make the orange light seem brighter for lower current, it would be good but recalling some old reading I did on what people notice (when I was designing ) I think a flash pattern might be more useful for locating the lamp than being continuously on. That would need to be balanced with how distracting the flash/pulse would be in a dark bedroom.

5) Yep, DDM - thanks for getting me away from that fallacy! Will see how the scope goes.

6) I really need to get the TSL2591 out! I have ordered some of the cyan 3W LEDs from Chanzon that you use in TritiLED as they just seem like a great little unit to have in places. When researching for Street Halo, I wondered why we don't allow vehicles to add cyan lights in addition to red and white, to increase initial detection of an object. 

Thanks for letting me stay! Once I get less needy I'll probably transition it to a standalone project.

  Are you sure? yes | no