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.
May I suggest adding a blink mode that blinks the firmware version?
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.
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?
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.
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.
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 ;-)
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…
Hm… I got mine finally… My ramping is changed into step ramping. Not smooth like it was… Its ramping with modes… Steps. Is it possible? How to change it to thr classical ramping please?
can you please make the AUX LEDS “USABLE”. like we can turn it on to use as reading light or whatnot… right now the aux leds are only for “decoration” purpose for a lack of a better term…
pls make it usable with its own mode… click and hold from off maybe. just an example… just make it usable
