TK's Emisar D18 review -- 3x18650 photon grenade

I’ve got that HK Onyx 4, man does that bass hit!

<—- all about dat bass, bout dat bass, bout dat bass ….

and lumens. :smiley:

I found the Onyx 4 on sale and loved it, talked my wife into getting me a second one for Christmas. Paired up, sweet stuff right there! She dropped her Pixel and shattered the screen so I got her the new Pixel 3, use the old one as a glorified MP-3 player to run the Onyx 4 duo. Works like a charm! [in an odd twist, I put a screen protector on it AFTER it was broke to keep all the pieces in the frame]

Toykeeper’s “RPP Test” doesn’t make sense to me. Reversing the multimeter leads is not the same as putting the batteries in backwards:

From Toykeeper’s first post:

Reverse polarity protection (my DMM measured 0.00A with the leads connected backward, so RPP seems to work)

So this morning I went coffee free to modify my friends light. Took almost 3 hours to change the SST-20’s to Samsung LH351D W6 5000K emitters. But alas, the tiny Lisa optics don’t fit over the LH351D dome so I sliced all 18 emitters. Only to find out that, sliced, these actually lose lumens over the original set up. Nice tint, still a pretty tight hotspot (although larger than the 20’s) but still hot quick. Disappointing for all the effort. Beautiful now in candlelight mode and the color goes well with the gold host.

I tried.

She tested current flow. You put the DMM probes on the driver pos and neg. Power will flow one way, reverse the probes and power does not flow.

Maybe you can explain exactly why it does not make sense. Maybe there is an element I’m missing.

All stock d18 xpl hi 5000k and 6500k are hitting about 13000 lumen… sst20 6500k is hitting 14000 lumen…

The spec says 10,000 lm for the 3000K and 4000K version. Yours appears to be brighter than expected.

Thanks for graphing this! I’ve been wanting to measure it to get an actual graph, but I don’t have anything which samples fast enough.

The D18’s candle mode is a bit higher amplitude than it was intended to be though. I calibrated the settings for a FET+1 driver like a Q8, with 65 levels on the +1 portion… but the D18 has only 50 levels on its +1 part of the ramp. So its ups and downs span a wider brightness range than it would on a Q8.

At some point, I really need to make the amplitude scale per build target, so it’ll be pretty much the same on all lights. Or maybe make the parameters editable real-time in the firmware. But it hasn’t been a priority. There’s a lot of other stuff to do first.

Side-firing LEDs thru strategic gaps designed into the replacement TIR holder PCB are a possibility although that would likely be a dimmer glow than is desired - assuming they’re available in desirable colors / efficiencies.

If it’s the tail PCB you’re talking about, I don’t think brass screws would help. It’s already using bare aluminum to bare copper, so the screws shouldn’t be a large factor:

I connected a bench power supply to the light, with a DMM in the middle to measure current. Connected with forward polarity, everything worked normally. Connected with reverse polarity, I measured no current flow at all and the light wouldn’t respond. Connected forward again, it was still fine. No damage.

A DMM by itself can’t test this, but it wasn’t the main device involved. Connecting a power supply backward was the real test.

Thanks for testing this!

I’m quoting it and repeating it just in case anyone missed it. This is very useful information for others who might want to try a similar mod.

Sometimes yes. Perhaps I used more flickery candles as a reference point. At first I thought I had made it vary too much, but when I compared it to actual candles it was actually less severe than some real ones.

There are a few things I’m not totally happy with in the algorithm. For one thing, it gets more subtle as the base brightness level is increased, so there’s hardly any point using it at brighter levels. Also, it doesn’t scale itself for each build target yet, so it varies based on the hardware used.

And I’d also like to make it smoother, but that has turned out to be trickier than I hoped. I have a function to set intermediate brightness levels in-between the 150 ramp steps, kinda like interpolating between pixels in an image… but sometimes it ends up looking good, sometimes it makes the animation lag, and sometimes it’s still just as choppy as the current method. Perhaps I’ll try again sometime.

Regardless, I still enjoy it in the bath. And that sounds nice right now. Plus, I’ve already posted way too many comments in a row. Biab.

Okay, this makes a lot more sense. :+1:

Interesting info, as always. I usually use mine at…well…the output level of a candle, so it sounds like I’m using the range where the flicker is most accentuated.

Regardless of whether further improvements end up getting made or not, even where the feature is now is really cool.

I really like Anduril’s Candlelight right down at the base setting, it has the most variability there and brightness is easily adjusted by adding more lights. :smiley: I find that the use of at least 3 lights really makes for a realistic experience. Doesn’t matter what size or power level, I often use the SP-03, Q8 and Thorfire TK05, very different lights but the program makes it just not matter.

Thanks TK, again I think you are working too hard…

Spec says 10k lumens for the 95 CRI SST-20 4000k but mine is the XP-L HI 4000k. XP-L HI is supposed to be brighter than even the 70 CRI SST-20

XP-L HI is only better at like 3-4+ amps per LED. Especially V2 that you have. If you look at tests the SST-20 is pretty good at lower amps but flattens out sooner

Skylumen measured around 13000 lumen for the xpl hi 6500k/5000k whatever device he is using… i measured 14000 lumen for the sst20 6500k with th TA tube calibrated.

Someone can explain why sst20 is pushing higher lumen than xpl hi…

In general these are close because SST-20 has lower Vf - therefore it’s driven higher. I’m not sure but I think SST-20 output shouldn’t be higher. Explanation? Different sphere, that difference is well within the error margin.