TK's Emisar D4V2 review

I rewrote all the interrupt-related code in November to fix this and several other things which could occasionally happen. Any firmware from 2019-11-20 or newer should be a lot more reliable about the first click from off.

Those changes had an effect on thermal regulation though, so I’ve been working on replacing all the thermal code too.

I read through the thermal regulation discussion earlier in the thread. I’ll wait until that’s sorted to update the firmware.
Thanks, TK!

The issue is that, at least in manual memory mode, the light always returns from turbo to the last ramping level it was at, unless that ramping level is max and the max ramp level was accessed via the shortcut from off. That, to me, is inconsistent and unexpected behavior.

If the light returns from turbo to max ramp if I accessed max ramp by ramping up, it should also return from turbo to max ramp if I accessed max ramp via the shortcut from off. There should not be two different flavors of the state “on and at max ramp”.

It is not only at max ramp. When you double click to turbo, then double click to return, Anduril will return to the remembered ramp level. That remembered level is not overwritten by any shortcut. So you will see the same behaviour if you reset the light (to cancel any previous remembered level) then click-hold to minimum ramp, then go to turbo and back. You will return to the default level after the reset, which is at the top regulated level in standard Anduril. That seems just fine.

Sorry, I’m not following.

Going back from turbo takes me to the last ramp level I was at unless that ramp level is max ramp accessed via shortcut. This creates two scenarios where the beginning state and set of actions are the same but the outcome is different.

Scenario 1:
Start at max ramp (by ramping up). Go to turbo and back, and I’m brought back to max ramp.

Scenario 2:
Start at max ramp (by double-click from off). Go to turbo and back, and I’m brought to the manual memory level I have set.

I’m failing to see the logic in this. I would think that if I’m at max ramp, the light should behave the same going to and from turbo regardless of how I got to max ramp.

Another way of putting it is that, with the current behavior, the shortcut to max ramp is not really a shortcut to max ramp but a shortcut to some special transient mode that happens to have the same brightness as max ramp and whose existence is forgotten when you go to turbo. I’m not sure why this is desirable.

Yes. It remembers the brightness level unless it was accessed by a shortcut.

The reason is because that’s what people asked for.

When the Emisar D4 first came out, it worked how you wanted. It remembered the last brightness level… period. Didn’t matter if it was reached by a shortcut. From off it had min, max, and mem… but people couldn’t access min or max without overwriting mem. This led to inconvenience, confusion, and even burns. Inconvenience because people kept having to manually reset the memorized level to what they wanted. Confusion because if they used moon mode last night then tried to turn the light on the next day, it was too dim and looked like nothing happened. Burns because it’d come on at turbo level in their pockets. It got a reputation as a “nut roaster”.

So a bunch of people asked me to fix it. Specifically, to fix it by making it not remember the brightness if it was accessed via a shortcut.

… and that’s where things are now.

Thanks for the explanation, that makes sense.

I notice now that it also forgets the min ramp if it’s accessed with the shortcut.

May I suggest adding a blink mode that blinks the firmware version? :slight_smile:

Also, what programming cable do you recommend buying? I bought one of these to tinker with the open source firmware so I want to make sure I get the right interface for it.

After the oct firmware it does blink the firmware date with 15 clicks.
Hank sells the programming cable.

Thank you atobe :slight_smile:

This is a question that maybe only ToyKeeper can answer - by the way, a big thank you to her from a happy D4V2 user for the fantastic firmware.

(Low) power consumption being one of the considerations that possibly drove the selection of the levels of illumination for the currently available modes of the aux LEDs, I was wondering if it is physically possible in the existing hardware configuration of the D4V2 to make the aux LEDs even brighter than available using the current “High” mode.

Maybe having the aux LEDs on red (using a brighter “High” setting) could be useful as a source of illumination that preserves night vision for those times when a specialized red light flashlight is not in hand?

If it is indeed possible to have those aux LEDs even brighter, maybe a possible future revision of the firmware could have 4 modes for the aux LEDs - heartbeat,low, high, and turbo, the last mode corresponding to the physically highest possible level of illumination?

Brightness levels of the aux LEDs are defined by the hardware.

Yeah, I’m also dissatisfied with the levels in my D4SV2, particularly low red which is far too low. But can’t help that without a hardware mode. :frowning:

I know we each have different goals and uses for the aux LEDs. Personally, I like the lows being super low. It can be an alternative to trit vials that isn’t too bright on my nightstand. It would be cool if the brightness was adjustable, though.

Does the titanium version step down faster than the aluminium version when using Turbo?

Yes, heat can’t escape the emitter/driver area as fast.

TK,

Are the pre-complied .hex files dated 12/17 & 12/3 ok to use or are those the revisions that needed some thermal code changes? I want to update my Emisar’s and FW’s, but I’ll wait if there are improvements coming.

Thanks.

Aux LED brightness is determined by the resistors soldered onto the aux LED board. The firmware does not control that.

What the firmware controls is two things — whether the LEDs have power, and whether the MCU’s internal resistor is active. This allows for 4 states:

Power On

Power Off

Resistor On

aux low

aux off

Resistor Off

aux high

aux off

That is the full extent of the aux LED brightness levels available while the MCU is asleep.

Those should be fine if you’re careful to avoid letting it overheat, but the thermal regulation in those versions tends to react too slowly.

I’ve been making some pretty good progress with a thermal rewrite, but it’s not done yet. The most recent unpublished code regulates to a stable level very quickly on an Emisar D4, but it’s pretty bumpy on lights with a lower power-to-mass ratio.

Thank you for explaining. The aux lights are already very useful as indicators (locked/non locked, voltage) and quite pretty. It would be fantastic if in a future hardware revision or hardware version they could be powerful enough to be used for illumination : red for preserving dark adaptation, blue/green for use in strobes?, UV would be nice too ;-)

One can only hope!

I have a flashlight with R/G/B/UV in addition to white, all bright enough to use for illumination. It’s pretty neat. However, I’ve found that it isn’t particularly useful.

OTOH, I also made a R/Y/G/B lightsaber with custom firmware, and the colors work a lot better there. Since there are so many ways to use a full spectrum of colors, I made it so the user can design their own patterns in a manner similar to designing sounds on a synthesizer. I should probably get back to that project sometime…