TK's Emisar D4 review

Yep, once I saw your graph TK I went and checked my cells with just a ZTS cell tester and they were low.
I have a lot of quads and none drain cells this fast,
What is the voltage the LVP kicks in at…? And it does do a three blink just before the drop I’m guessing…? I’m going to get voltage readings next time this starts to happen. Maybe it’s tripping early.
Thanks TK, appreciate your help, I think case solved… happy I don’t need to tell RMM anything now…
I would have really looked stupid, ah have you checked to see if your cells are charged, NO, let me go look… ha ha… Oh man, these lights did suck those Aspires bone dry fast, but that Aspire was in the XPL 1200 mAH just like that, wow or I lost track of time, really stupid no matter how I look at it frankly.

Edit: Nice beam shots, mine look like quad stars with 4 points to the profile,

LVP is configured for step-down at 3.0V and shut-off at 2.8V.

If you’re seeing 3 blinks before the step-down, it’s definitely LVP kicking in.

Ya, I had somehow put some partially charged cells in with fully charged cells, do I need say more…?
Thank you TK… :blush:

Did a little GITD on one light tonight but didn’t use the right camera settings for the pic,

Thermal regulation update

If you recall, the original thermal protection behavior looked like this. It took way too long and got way too hot and never tried to step back up again:

As a quick check, I tried decreasing its timeout so it could respond faster. It responded faster and didn’t get quite as hot, but it still exceeded what I’d consider a safe temperature, then went down too far and never came back up.

So I decided to go with the original plan and rewrite that part from scratch.

I changed lots of things, but the main thing new method does is try to predict what the temperature is going to be in the future… then react based on that. This helps eliminate the effect of the time it takes for heat to travel from the emitters to the sensor. The correction is proportional to how far the prediction exceeds the thermal ceiling, so it adjusts a lot faster while heat is increasing quickly.

Also, it does regulation instead of protection, meaning it will also try to step back up if the temperature gets too low. But step-up is intentionally slow to avoid oscillations.

So, here’s how the first test went. It was certainly faster, but it over-shot and then took too long to recover.

I slowed it down and tried again, but it slowed down too far. This time it got too hot and took too long to drop to a safe level.

After fixing that, I checked again and behavior was better but it was awfully noisy / bumpy. I also noticed a bug where it could step down then up immediately, or vice-versa. That shouldn’t happen.

After fixing those issues, I tweaked some other things and increased the sensor resolution (ish), and tried again. This time it turned out reasonably well. Not perfect, but not bad. It dropped fast enough to prevent skin burns, then gradually adjusted from there. It didn’t even overshoot.

Some of the dips and bumps here were due to me holding the light and changing hands in an attempt to keep it somewhat heat-sinked, but I think in the future I’ll just point a fan at it.

Note, I didn’t recharge the cell between tests… so by the time I did this last test it was starting at only 3.7V. I’ll have to do that next time. For now though, I think this is a good improvement.

I’m also going to have to be extra-careful when I reflash the driver, because I’ve already managed to break one of the switch wires and pull out the other one. I don’t want to have to repair that again.

A dab of glue on the wire helps

Hi Toykeeper. Is this light still in the works and having the kinks worked out or are you just making adjustments on you own personal light.

I see on Mountain Electronics website that he is expecting stock in the next few days.

I would prefer a light that had the kinks worked out.

Would it be best to wait for a revised edition of this light, or is what you received final production?

Thanks in advance. Looks like a real winner of a light!

Just a side note, one of a personal nature or observation… those glow in the dark stickers are ridiculous to put on a surface with that much heat! I have repeatedly fixed lights for people that used them, after they burn and blacken and cause black spots or total destruction of emitters. Just a personal observation of course, a note saying you won’t find any light of mine with paper/plastic on the mcpcb. Also, nobody needs to bother to ask me to fix one with that junk on there, won’t do it anymore. So now that that’s been noted, we now return you to the regularly scheduled program already in progress…

Thank you for the awesome review! Can’t wait for this to go live on Hank’s store.
I have couple of questions.
Is there any chance driver retaining ring will be used on production units? Is the switch pcb easily accessible and is the rubber cover any standard size? I’m thinking it could be easily modified with status LED. And what are those D4 siblings you mentioned (if you can talk about it).

Cheers!

See post #203 and pic of D1S in post #206: New 4XP Noctigon MCPCB for quad optic

Since the firmware is open-source, any chance of calibrating the temp sensor in the driver specifically for the Emisar in future production runs?

Available in a few days?

Sounds like it’s going production as-is. Still, even as-is, this sounds like a great light. Thinking of buying a Nichia one and a 5D one.

Too bad this light isn’t available stock with high-CRI nichia, XPL2 (unsure if those fit under the optic), or 5A2 XPL HI. On the upside, it looks like swapping the emitters should be easy.

XP-L HI in this light has a square beam pattern. it’s not bad with Nichia but with the dedomed emitters it’s pretty bad. One way to fix that is to use the new mountain electronics’ new quad mcpcb. The board offsets the LEDs and the beam pattern’s much improved over the TPAD/Noctigon boards.

Well… it’s hard to say something without fitting components and power calculation, obviously there wont be too much lumens using boost or buck driver. Yeah, a lack of place is limmiting driver’s opportunities. But comfortable interface and rich functionality that’s what can make a real wow effect.

As for Indigo, everyone can use source code without any restrictions. There’s no licence but author is not against, in simple words - do what you want :slight_smile:

Test 4 looks like the best regulation, it goes to a steady level fastest. And well done in preventing oscillations!

Is your thermal algorithm specifically working well in this host or would it work just as well (without oscillations) in bigger hosts?

Thanks for the insight Dale and couldn’t agree more, but this not off the shelf glow stickers or store bought cloth tape, plastic or vinyl, it is a multi layer heat resistant sort of tape capable of withstanding heat to 500C or very close to it, Kapton heat range is only about 280C, the luminescent pigments is in between heat shielded materials, and it all can be easily removed, well sort of easily, depends how long it’s been on as the current adhesive seems to harden with time and the heat I think, generally easily removed by tweezers and then a low grade solvent or alcohol and q tip to remove left over adhesive cling, One material is a 1 mil thick polyimide film in disks, Edit: or in sheet form, and is just short of being actual Kapton being it’s short of the polymers used in actual Dupont Kapton tape then with the silicone adhesive application to bond the layers, and one other layer is PTFE with Teflon then with the luminescent pigments I place in between the layers it works fantastic but time consuming to make and expensive so really only barely practical, it does not melt even when testing it with my jewelers torch (Little Smith), also make glow O rings with hybrid silicone tubing and my own mix of pigments, injected, measured and sealed, and that is also heat resistant as well but not to the extent of this tape, yep have melted a few stickers, tapes, cloth in the process of trying to figure out what works and what doesn’t, there are some very bad products that will melt almost immediately so people need to really search for heat resistance 80C min. if using glow anything in lights for sure, I couldn’t agree with you more Dale…Thanks

It looks like the driver cavity is about 19.3 mm inner diameter and about 2.5 mm deep. The tiny85 is the tallest component, at about 2.0 mm, which leaves 0.5 mm empty space to the shelf. In theory, Hank could make that 0.4mm or 0.5mm shallower to speed up thermal regulation response, but there might not be enough room for the wires.

I agree the UI can make a huge difference. That’s why I’m excited about the firmware being fully open-source. It can have any UI you want. :slight_smile:

Does this mean Indigo is public domain? Usually “no license” defaults to “copyrighted with all rights reserved”, legally. But if the author states that it is released under public domain or CC0, I can include it in the repository.

(note: “public domain” and Creative Commons Zero “CC0” are equivalent)

I suppose I could include it anyway, but it would still need a clear license of some sort. For example, I have DrJones’ luxdrv which is CC-BY-NC-SA… even though the NC (non-commercial) part causes trouble. The NC part means I can’t even look at the code without risk of being sued, because people sometimes sell the stuff I make.

Always wondered what keeps scoundrels in the light industry from just hanging back and watching your fantastic R&D along with many other fantastic advancements that have came from this group then take it and tweak it to their purpose and then use it commercially, seems all they have to do is make some slight tweak and call it their own and register it as such, probably already happens, sort of like watching Manker make such great use out of the driver used in the A6 on, seemed almost every light Manker designed after the A6 and BLF SE X6 & X5 all used those drivers, perhaps some deal was struck way back when,

Nice work TK. :+1:

If I understand correctly, what I have is the first production run. The second batch, I think, will have some firmware updates based on what I’m doing.

It’s pretty nice, but in the first batch you should manage the temperature yourself instead of relying on the built-in thermal protection.

I don’t expect a driver retaining ring. It would make the light longer.

Normally I’d be more upset about the driver glue, but it wasn’t difficult to remove and didn’t really make modding any harder in this case.

The switch PCB is not easily accessible. I haven’t attempted to remove it. However, if you do manage to get it out, the driver already has an unused pad to control an indicator LED. This makes it compatible with Narsil’s indicator features.

If I understand correctly, that’s what I’m doing?

I’m calibrating it for this specific host, but I plan to try it on a SRK and a Convoy triple too… the idea is to update bistro and crescendo with the same algorithm, and maybe Narsil if Tom is okay with that. If things go well, it shouldn’t need much (or any) modification to work in different lights, but that might be overly optimistic. It does at least adjust proportional to the rate of change though, so it will react slower on lights with less power or more thermal mass.

Anyway, I’m not done yet. I hope I can get it to produce a nearly-flat runtime graph for the whole life of the battery, aside from the initial hot peak. It looks promising so far… like, on that last graph, I changed hands to give it a fresh heat sink, and about 15 seconds later it stepped up a bit.

It’ll be interesting to try this underwater, or touch it with ice mid-test.

Oh, also, tiny85 chips don’t use a calibrated sensor. They vary by at least 10 C between individual pieces. So I think I need to convert that thermal toggle function into a thermal calibration function like in bistro.

There are reasons I use a GPLv3 license: The GNU General Public License v3.0 - GNU Project - Free Software Foundation

Some very skilled lawyers created that license specifically to make sure free software won’t be abused. People can make and sell derivative works, but they can’t just take — they have to give too, by releasing their changes under the same license. That’s the foundation of the whole free software information economy. Share and share alike.