DQG Tiny 18650 + Narsil + Nichia 319 = Ultimate Compact EDC

A short while ago, I decided that I wanted to make the most fully-featured EDC pocket-light of which I could reasonably conceive.

After thinking of a few ideas and reading around lots of threads on here and r/flashlight for inspiration, I decided that I wanted an 18650 light
which would output up to approx 1000lm, and that it must have a CRI of at least 80, and be neutral white (somewhere around 4000-5000K). And it must be as compact as I can physically make it.
I decided to go with the most compact 18650 light of which I’m aware, a DQG Tiny 18650, to maintain good portability without sacrificing runtime.

I settled on a Nichia 319A for the emitter, as it would have a sufficient CRI (min. of 83), and according to a graph below, it would output approx 1000lm at 3A. Unfortunately, even at 3A, it has a forward voltage of 3.25V.
Linear drivers are most common in single-cell lights (the S2 above is 7135s, the 2C V2 is an LD2 driver), but with a full charge there would be a 0.95V drop across the driver. At 3A, this results in 2.85W burned in the driver. That would make 7135s VERY unhappy, and would (to me at least) be an unacceptable waste of energy in such a small EDC light.

I decided therfore to use the lowest-dropout buck driver that I could get my hands on. After it became very apparent that 90+% efficient buck drivers designed to work on 4.2V and being smaller than 19mm diameter were hard to find, I settled on an LD-29 driver from Fasttech, and hoped that I could trim it down to 19mm.

HKJ’s review of it demonstrated an approximately 0.5V overhead needed to sustain the 2.8A output. With an XML2/XPL, that would cause high mode to decrease as the battery falls below 4V. With a 319A, however, that drop instead starts at 3.75V, at which point, the battery has very little capacity left anyway.

Unfortunatley, the LD-29 is a power-switch (‘clicky’ type) mode-change driver, and the DQG has an e-switch (‘momentary’ type). Also, the LD-29 only has three alright-spaced modes, the lowest of which is ok in itself, but is far too high to be ‘moon’, and it has no other modes or functions (apart from the low-battery shutoff and an optional blinky mode).
I wasn’t sure what to do, so searched around for info about the LD-29 (in hopes of reprogramming it somehow - it hadn’t arrived from china yet, so couldn’t test it), and I stumbled onto this thread:

where Wight had poked around the MCU pins while operating, as I had planned to do, and had deduced which pins did what.

So, I knew how to replace the MCU with something re-programmable, but I hadn’t decided on a firmware with a mode set and UI that I’d like.
Once again, I read through the Firmware Repository index file, and saw that many of the nicer more fancy e-switch firmwares were designed for the Attiny85, as it has much more ROM, RAM, and EEPROM space than the standard Attiny13. After some more reading, I decided that the closest to what I wanted was Tom_E’s “Narsil” firmware. (I had previously planned to put a small UV LED in as well, but decided against it after realising that there was not sufficient room)

I had to use the low voltage Attiny85 (the 85V) as the LD-29’s regulator outputs 2.5V to the MCU . This is so that a given PWM output of the MCU will always produce the same average output voltage, as the control input for the buck controller chip is actually an analogue voltage level, and the MCU PWM is fed to an RC low-pass filter - essentially turning the PWM output into an 8-bit DAC. Because the MCU VCC is always 2.5V, the voltage output of the ‘improv-DAC’ for a given PWM value will always remain constant independent of battery voltage.

I programmed it with Narsil a modified version of Narsil which took me two weeks to fully debug and test, and soldered it into the LD-29. To summarise the changes, the ‘brightness mode sets’ and config have been removed (except for thermal limit calibration), and another table has been added to the ramping system, simulating a ramp behaviour but between discreet brightness ‘steps’ (this also involved a lot of modification to the ramp-handling code, which I won’t detail here). The ‘on-board LED’ function was re-purposed to switch an ‘enable’ pin on the LD-29 which puts the buck control chip into a low-power state when the light is off and idle (this reduces quiescent current from 3mA to 0.45mA, which is still not as good as many other drivers, but is acceptable, and is significantly less than it would otherwise have been). I also configured the ‘blinky’ modes to be strobe, 2 sec beacon, and an improvised but somewhat effective ‘virtual lightning mode’. It is set up to always use thermal step-down, and I have tweaked the code so that step-down works with both continuous ramp and step mode, and so that repeated step-downs happen sooner if the temperature does not drop fast enough. Also, for the sake of convenience; the last used brightness level (in either mode), whether ramp or step mode is active, and the thermal step-down limit are all saved in EEPROM, so when I change the battery, it turns back on exactly as it was. EDIT because I forgot: the ‘firmware version blink’ mode after the ‘battcheck’ and ‘tempcheck’ modes was not of any use to me, so I changed that to toggle between ‘continuous’ and ‘step’ ramping modes, with either a short smooth ramp up or three consecutive increasing steps to indicate which mode it had just been switched to (shown in the video).

Sorry, I didn’t take any photographs of those steps, but the finished driver is shown below.

I trimmed a ~20mm Noctigon down to ~18mm with LOTS of filing, and cut a slot in the side to fit the switch in.

I also drilled holes through the DQG’s small integrated shelf and the Noctigon to pass the LED wires through. The smaller wires for the button were passed through a small gap between some SMD components and the shelf.

The switch was filed to size and soldered on, and the shelf and Attiny85 were covered in a thin layer of thermal grease (for heat transfer and temperature monitoring respectively).

The noctigon was installed, soldered, and press fit into place, with the switch fitting snugly in place.

Much fiddly assembling later, and voila! A small 18650 light with good light output (5000K/83CRI), plenty of it (900+lm), and a UI exactly as I like it.

Moon with and without a mild diffusing filter:

White wall hunting:

Here’s a comparison between a (supposedly) ‘neutral white’ Cree XPL-HI in the S2 from Fasttech (which I’d estimate at 5-6000K with a straw-ish hue), which will have a CRI of approx 70-75, and the DQG, which is an SM503 bin, 83 CRI Nichia 319A (5000K) :

Note that the colour of the stems is ‘light brown’ rather than ‘yellow’, and the leaves are a more true-to-eye shade of green in the right-side photo. Also, the red of the petals is brighter and more vibrant on the right, despite that light being ~150lm less than the left. This is also more true to life, though I personally find the camera’s depiction of the shade of red is not exact, as the petals appear slightly pinker to my eye (though that is under cloudy daylight, which is closer to 6500K). The above photos were taken at night, so the difference between my perception in daytime and the camera’s ’daylight’ white balance should be equal for both photos. The camera’s ‘daylight’ white balance will be around 4500K (for direct sunlight), so that explains why it looks different to a cloudy day. The camera was set to manual, the same ISO, shutter speed, and (daylight) white balance for both photos.

It’s raining heavily at the moment, so no beamshots for today. I’ll take some tomorrow if the weather improves, and update this then. The reflector is from a Jetbeam JET-1 MK, and there is a mild diffusion filter, so if you’ve ever used an AA/14500 light with an XML or XPL size emitter you already have a good idea of what the beam profile looks around the house or outside. It’s a nice balance between the floody spill and some mild but usable throw, with a diffuse, smooth transition between the two.

Here is a short video demonstration of the UI and mode operation (I forgot to show a few things like lockout, but they are the same as normal Narsil, also there are a few 10s pauses in the middle when I demo ‘lightning mode’ the most interesting stuff is after this, so don’t think that the video has ended :smiley: ):

Thanks and credit where due to:
And anyone else I may have forgotten, for the data/projects that helped me to make this,
and for their continued contribution to making BLF a better place.

Well done! Lots of work. That’s a really nice EDC you’ve created there.

How much is shipping to the US? :smiley:

Interesting. That sounds like it took a lot of work and involved some relatively deep changes. Are you planning to share the code?

Also, have you seen my FSM thread? It has some things pretty similar to what you changed — discrete ramping instead of mode sets, simpler config, faster thermal regulation, and lightning mode.

I will happily share the code, but it is not currently annotated properly, as I didn’t bother to correct or update Tom_E’s annotations where the code was altered, and I did not annotate any new additions or changes. Going back through and annotating it will take some time, and I’m busy with Uni stuff at the moment, so I don’t have much free time, but I will get around to it.

Though it is specifically designed for working with that buck driver circuit, so the battery ADC calibration, PWM output ramp and limits, and some other bits of code specific to that driver would all have to be changed to work with a normal FET driver for instance. (eg. I had to code a short PMW output spike as moon turns on because the buck controller needs greater than the moon PWM level to turn on from off, but can sustain it once on, as the moon PWM voltage is really close to the buck controller’s noise floor)

It’s not that much work to get rid of the buck-specific parts, but I have no incentive to do it (Edit: I have a Spark SP2 with an Attiny85 in it running some old firmware [I can’t remember which], so sometime in the near future I’ll put my version of Narsil in that and edit it for something linear), and for now, I’m tired of staring at Atmel Studio :smiley:

I have seen it before, and after a brief glance, assessed that the coding concepts you describe were above my level of understanding. After working with Narsil, I’m starting to understand more of it, but I need to learn more before I can fully understand it and decide if it is for me. I’ll certainly be giving it a proper read soon though.

Very, very interesting. Have you considered doing a triple? 3*219C would be more efficient than 319A, would likely have even lower Vf curve (especially when plotting Vf against output, not against amps). Would be very floody, but that seems to be what you want anyway.
And, if wired 3s, would enable you to use a boost driver and not worry about going out of regulation.

You forgot one curve:

With this cell (if you are using it) 3A discharge curve starts from 4v. (4-3.25)*3=2.25W (0.28W per one 7135).
“With a 319A, however, that drop instead starts at 3.75V, at which point, the battery has very little capacity left anyway.”
As you can see from curve above, there is near 0.6Ah over 3.75v and 2.5Ah under it.
If we devide cell capacity curve in two parts (and left first few minutes and voltages lower 3.2V away), we can see two straight lines.
3.85V to 3.4V - 1.5Ah
3.4V to 3.2V - 0.75Ah
Second part is too low for 3A anyway, so with linear 3A regulator it will be sort of DD with great (90-95%) efficiency.
Now take a look at first part.
Average voltage is (3.85+3.4)/2=3.625V
Total consumption: 3.625*3A=10.875W
Driver consumption: (3.625-3.25)*3A=1.125W
1.125/10.875=10.34% driver losses.
Actually, such set with linear regulator will have:
19% to 10% losses for 0.6Ah
10% losses for 1.5Ah
10% to 5% losses for 0.75Ah
Which is not as bad as you introduce.

Why would you do that, silly? A lot of what makes it interesting is that it runs on a type of driver which isn’t well-supported yet. :slight_smile:

The Thrunite 2C V2 in the size comparison photo is a 219C triple.

One of the main reasons I wanted to make a new EDC was because my previous one (the 2C V2 triple) was ALL flood, and that beam profile wasn’t to my liking.
I wanted an EDC with a balance of flood and throw, for inspecting components or inside mechanical and electronic assemblies in the day, and walking down rural paths and such at night.

A boost driver would likely be less efficient than the buck driver, and would draw more current from the battery for a similar output level, as going up in voltage means going down in current, so you need more current to start with, which would make the battery sag more under load, etc.

:person_facepalming: again…

Good point, though it uses a potential divider for battery ADC, and compares it to the internal reference voltage, which varies noticeably between chips (I tested three which were each approx 3% different from the others.), so that would still need calibrating to a voltmeter for each different implementation. (though I realise this is also the case with many custom drivers)

I’ll try to annotate it and send it to you fairly soon.

You haven’t factored in that the driver does not draw 3A from the battery. I’ve just checked, it draws approx 2.5A on high from the Panasonic cell, and that has a notable internal resistance. The voltage sag under load, and the remaining capacity per loaded volt curve is different for different cells.

Though you do raise a good point, and I’ll do some more testing with some other drivers outside of the light with another 319.

The main purpose of my choosing that driver was actually better efficiency in medium modes (which is the majority of my usage) and the ability to essentially convert a PWM signal into a fixed, ripple-less, constant current.

I’ll do a battery voltage vs output test for different output levels later on today and get back to you.

That’s great stuff - you are my hero - I like the small EDC size of the DQG but its poor switch and weird UI made me not buy another one after 2 of them broke on me…

I was too lazy to even fix it, though I did at least look at it and determine it was more than I wanted to do.