New Emisar Tint-Ramping flashlights available!

Yes, no need for 2 separate controls. I use 2H periodically such as when I’m on a given level of brightness and want to go down, 2H accomplishes that. Otherwise you do 1H to go up a little then 1H to go down to the level you want… taking longer.

I use it. That’s why I added it. :wink:

I just got my KR4 channel switching / tint ramping light. Kr4 is my favorite EDC, and this light is awesome. I really bought it for channel switching, but the ramping feature may be cool, too. Though, I feel like a Newbie again, trying to figure this out.

I have questions :( -

-Looks like tint ramping does the cct change in a series of small "micro steps" instead of "smooth"? Is this normal?

-When on channel switching mode, 2C "turbo" runs both sets of LED's at once? can this be "turned off"? (with two similar sets of LED;s this is nice, but with a Nichia and Osram mix for example, i dont want this to happen, and im going to reflow mine to 219b/W2)

I have other questions, but i need to use with this light more first. Thanks for starting this thread. if my questions should be asked somewhere else, i apologize!

-Artie

the forum/website is not allowing me to quote right now, but regarding the end of post #66 by TK -

I use 2H for ramp down all of the time. As much as i use 1H tbh. So, for me it would be a solid No vote for 2H to control ramp, therefore making Ramp Down a different control. Just wanted to throw my 2 cents in is all.

Thank you! for everything you've done to make these new, fantastic lights, possible.

I always use 2H to decrease brightness and would not want this feature to disappear since I appreciate being able to decrease brightness without having to increase it first (especially while using stepped brightness mode instead of ramping).

There are more non-tinting lights than lights with tinting and adjusting the brightness is done more often than adjusting the tint.

Tint ramping uses 256 steps. However, there are not 256 units of brightness to allocate, so the effective resolution is different depending on how bright the light is at that moment.

For example, at the very lowest brightness, just 1 unit, it can split that between the two sets of LEDs as 1:0 or 0:1. At 2 brightness units, it can be 2:0, 1:1, or 0:2. And at 3 units of brightness, it can be 3:0, 2:1, 1:2, or 0:3.

The number of tint steps is: brightness + 1

So in a bright mode, let’s say you’re at PWM level 200 out of 255, there would be 201 different tint steps available.

It just translates that 0-255 “tint” value into hardware control parameters automatically. So if you have the tint set to 50% and the brightness to 10%, it would convert that to 5+5 on the two sets of LEDs. This ends up with pretty coarse resolution toward the bottom of the ramp though.

At the bottom of the ramp, if you had red and blue LEDs, the tint steps between would look something like this:

I hope that makes sense.


As for turbo turning on both sets of LEDs… yes, there is a way to turn that off. Set the ceiling level to 100% power (this is the default), and change the turbo mode to “no turbo”. That way, it’ll never go above the ceiling. Or change the turbo mode to “Anduril 2 style”, which only goes above the ceiling if you ramp up to it first and then try to activate turbo.

The color model it uses is a lot like a house. Go too far above the ceiling, and it hits the roof. Then to go any higher, it must slide sideways toward the peak. When it jumps to full power turbo on both channels, I call that “200” power. But you can make it stop at 100 instead.

The instructions for setting the turbo style are in the text manual. Just look for “turbo style”. It’s on the “Ramp 10H” menu, option 4. The values it accepts are 0 for “no turbo”, 1 for “Anduril 1 style”, or 2 for “Anduril 2 style”.

So… make sure you’re in advanced mode, turn the light on, do 10H, let go after the 4th blink, and then just wait for it to fall out of the menu. That should put it in “no turbo” mode.

I use 2H to ramp down, but I would not need to if

From On, 1H Ramp (up, with reversing),
if reversing did not time out and stop working

I would like reversing to work consistently, no timeout, like this:
From On, 1H ramps up, 1H again ramps down, 1H again ramps up

that is how the Nitcore D10 accomplishes ramping in both directions

the way it is now, I sometimes double tap too soon to reverse, and get ceiling instead… other times Im too slow, and the light ramps up, and Up again, when Im trying to go down

the comand for revesing is inconsistent atm… because it has a short time limit

Awesome! thank you so much for this amount of info! the "less smooth" tint ramp at lower levels totally makes sense when explained like that, thank you! i was at a low level.

And the Turbo style menu, huge help! i had no idea! much appreciated. i will mess around with the different options now. thanks again!

This is exactly how it works at the moment. Every time you release the button the direction is reversed. And after a delay it is reset to go up the next time.

But then it’s not 1H & 1H but 2C. To ramp you have to hold the button long enough, on every ramping light I know. Otherwise it’s either 1C to switch it off or 2C for turbo or 2H (!) to ramp down.

The current behavior is very consistent.

Sounds like enough people use 2H to rampdown, the UI should be left as-is. :sunglasses:

I just need to practice 3H more. :stuck_out_tongue:

Im not sure you understood me.

Im asking to eliminate the reset until the light is turned OFF

imo there should be no reset while ON.

hope that makes sense. If you have any experience with the Nitecore D10, that is the ramping direction reversing system Im suggesting.

Yes, it makes total sense. That's how Narsil worked, and I changed it to eliminate the need to remember which way the ramp was pointed. I was always having to ramp the wrong way and turn around, and I didn't like that.

If you'd like to restore that behavior in Anduril, open up ramp-mode.c and look for this part:

    else if (event == EV_tick) {
        // un-reverse after 1 second
        if (arg == AUTO_REVERSE_TIME) ramp_direction = 1;

Comment out that last line, and it won't reset the ramp direction any more. It'll remember as long as the battery is connected.

Or you could set AUTO_REVERSE_TIME to a different value in a config file, like config-default.h. The default is about a second (or 0.66s in more recent versions)... but it can be as high as ~17 minutes. That way, it would behave how you want during a session, but you wouldn't have to remember anything from more than a few minutes ago.

I do the same thing with brightness memory. I configure my lights to use a memory timer of 10 minutes, so it'll do last-ramped during a session, and then reset to my favorite default between sessions. No more nasty surprises when I pick up a light and click once.

Excellent! Good to know this is possible. Thanks, TK! I do see how having no timeout would be another approach and certainly works if someone is accustomed to it. I’m comfortable with 2H for down, 1H for up. Makes logical sense.

thanks for sharing how the reset time could be eliminated

> That’s how Narsil worked,

That would be bad.

I would not like never knowing which way the ramp was pointed when first turning the light ON.

Ramp reversal should reset after OFF, so 1H always starts by ramping UP after first turning the light ON.

That is the way the Nitecore D10 ramp reversal works, and it is consistent. 1H Always ramps UP First, after ON.

I do not know how to reflash my FWAA, so I will just keep using 2H for ramp down.

Ah. For that, you’d also need to add one line. In the “enter state” event for ramp-mode, set the ramp direction to 1. Then it would reset to up every time it enters ramp mode, like when turning the light on from standby.

I misunderstood earlier, thinking “OFF” in all-caps meant completely powered down, not just sleeping.

youre brilliant
and the amount of detail youre juggling is mind boggling

my main point was to suggest that 2H is not needed for ramping down, IF the D10 style auto ramp reversing was On by default

then 2H could be available for Tint Mixing, if desired


specific to the FWAA
I got the impression it is a reflashing dead end

and has too little memory to deal with the new low modes
and there is no hex file available

is it actually possible to flash a FWAA to do the ramping things you are describing, and if so is there a hex file available (is hex the thing)?

I dont really comprehend the flashing process, as it applies to my FWAA and iMac…

I do agree that the FWAA could use a mix of LEDs to create a blend with lower DUV…

Im also wondering if one of the 3 FWAA LEDs could be a W1… does it fit a XP footprint… would it work with a couple of 219b, despite different vf?

can we enable Tint Ramping for the FWAA?;;; (in my dreams)

I should learn to check my own code before telling people what it does. It already sets the ramp direction each time ramp state is entered… so if you took out the line quoted earlier, it would remember only as long as the light is on in the ramping state… and it’d reset each time you return to ramping state. So, removing a single line would make it work like the D10.

About the FWAA, it has no flashing pads so it’s a pain to update, and no BLF firmware people were involved so it doesn’t have its own firmware build target. Lumintop is using code for some other light, I think. You’d have to use the version check function to find out which build… and hope it’s recent enough to show the model number. Reflashing is possible, but it’s not easy like a Hank light.

The “new low modes” only work on drivers which are capable of 16-bit PWM with variable pulse frequency modulation… and the tiny85 doesn’t do that. So the entire Lumintop FW series isn’t compatible. Maybe someday if I ever implement delta-sigma modulation, but I haven’t done that yet.

Tint ramping requires driver hardware and a MCPCB designed for it, so the FWAA is physically incapable of doing that.

thanks for all your time and info

fwiw, though I dont know what it means
the FWAA version check says:
202019270312

Soo.. anybody knows what kind of driver is the new dual channel Emisars using ? Is it a FET + n linear regulators, or has it changed to a buck driver ?

Just can't seem to find any info by searching the forum or the internet. Not even pictures of a teardown or something.. I guess the light is still too new :|

Also, just as a side question, would anyone know for sure if the RGB indicator lights in the switch of the Noctigon K1 are actually the "AUX" lights on the front of the D4's ?

I'd like to buy one of those switch PCB's from Hank if he'd sell them and also buy a channel switching D4SV2 and use the switch RGB led's from the K1 in the D4SV2.

Well, this is no secret and known since day one: It’s a linear driver. The current depends on the emitters: 2*3.8A for E21A, 2*5A for 219B and 2*9A for everything else.