New Emisar Tint-Ramping flashlights available!

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.

Oh, I think I was way too hopeful then, but thanks for the info. I guess my wallet will be safe for a bit longer..

If this was the case you would not be able to choose in which direction the brightness changes because it would always change in the opposite direction from that in which it had last changed.

If you increased the brightness and then decide you need more brightness, you would have to decrease the brightness first before you could increase the brightness.

And likewise, if you decreased the brightness and decided you want even less brightness, you would need to increase the brightness first before you could decrease the brightness.

This would be especially annoying while using "stepped brightness mode" instead of "ramping brightness mode".

The Anduril version check for both of my FWAA lights returns: 2020 09 27 0312 which indicates the version date is 2020 September 27 and the model number is 0312.

Yes, it does aux LED functions. No, it doesn’t fit in a D4S.

According to the MODELS file, model 0312 is a FW3A-219, which is probably the wrong firmware for that light. Lumintop apparently didn’t know what they were doing, and used firmware which isn’t matched to the hardware.

With that firmware, if you go to the default ramp ceiling and then double click for turbo… nothing changes, right?

They used a FET+7+1 firmware on FET+1 hardware, so one of the channels the code tries to control doesn’t even exist. :person_facepalming:

> With that firmware, if you go to the default ramp ceiling and then double click for turbo…

it does go to Turbo on 2C, IF I ramp to ceiling, in advanced mode

otoh, if I 2C to ceiling then no, the next 2C does not give Turbo, instead it toggles to the mode I was on before 2C to ceiling

> They used a FET+7+1 firmware on FET+1 hardware, so one of the channels the code tries to control doesn’t even exist.

I dont know what channel is not working…

the FWAA seems to function fine…
There are no aux lights to control, and no button lights to control…
all the blinkies work, ceilings and steps can be customized… thermal limits and voltmeter calibration works…

what alternative firmware should be used for the FWAA, and what would be the benefit of the change of Firmware?

Oh well.. at least now I know :| I'll probably have to wait for the D4SV3

Cheers!

In this case, what caught my attention about Jon’s data is the blended color report had a smaller deviation from the BBL than either of the non-blended reports.

My concern had been, if the SW45K is already noticeably rosy, and Jon seems to have gotten a particularly rosy one, what if the blended colors end up being outright bizzarely rosy.

What I wasn’t visualizing is that with one very rosy and one fairly neutral emitter, the line actually slants relative to the BBL, enough that the mixed color is actually more neutral than the SW45K alone.

Same chromaticity diagram shown again, but this time with a pink line for SW45 and SW30 both on the BBL, and a blue line for SW45K at roughly –0.0120 DUV, and SW30 on the BBL.

What’s the approximate current for those measurements? I’m used to the least rosy sw45k being more like –0.0080 at 3A, and I was concerned the middle of the ramp would be excessively rosy on turbo. Nice to see the sw27 are respectably rosy given I’ve read otherwise.

Are there any particular emitter combinations for dual channel tint ramping that should be avoided? I see a number of different combinations being tried, but not quite sure what to pick. Seems that many combinations are workable, so I figured it may be better to understand what to avoid (a smaller group).

In general, if you don’t already know what you want… it’s probably best to get a regular single-color light. Then if you can’t quite get what you need from any single LED type, that’s the time to try combining two.

Like, me, I really like tint ramping from XP-L HI 1A to 8A. It’s energy-efficient, has a great-looking beam, has a very wide range, and almost the entire ramp is significantly more rosy-tinted than any single-LED bin.

I also like tint-ramping from 219B sw45k to sw27… because sw45k is really close to ideal for me, but feels a bit too cold. And sw40 isn’t pink enough. So adding some sw27 lets me fine-tune the CCT without sacrificing the rosy tint.

Without having tried the individual LEDs though, and without having done some napkin math or rough plots to calculate what various blends would be like, I wouldn’t know this. I’d have to do it through trial and error instead.

First you need to chose between:
1)CCT ramping setup (same LEDs, warm + cool)
2)Flood + Throw setup (ideally same CCT, 2 throwy LEDs + 2 Floody)

That would be a good starting point.

Somewhere mid-level, probably around 1A per emitter. I typically measure the light at a level that I’m more likely to use in the real world.

I like that these sw45k are slightly warmer and less pink than some other examples I’ve seen. Most of them have an aggressively magenta cast which I tend to find just as offensive as an excessively green emitter. I prefer a tint near or slightly below the BBL. –0.008 is way too pink for me.

The tint in the middle of the ramp on this light is right around what I’d consider too much pink.

Thanks, TK! I can relate to what you’ve said. About the warmest tint I enjoy is 2700k, but lean more towards 3500k. Top end can be about 5000k (for the nature of this LED/TIR setup—definitely OK with 6000k for super throwers). Seeing one person’s example of actively using tint ramping was astonishing. Like having 2 flashlights in one, but even better, as you can control the blend.

Yes, thanks Pavlo. Very important considerations. While temp is often a stated spec on LED’s, I don’t see flood/throw stats codified in any simplified way. Do you know of any content available that helps illustrate the available LED’s for these Emisar lights with their flood/throw characteristics?

You can look at the throw specs of the non tint ramping version of the light.

Osram W1 will be the LED with tightest beam, Samsung LH351d will be the floodiest. You can also add DC fix in front of the second channel to make any LED more floody.