Fireflies ROT66 Flashlight

Thank you for sharing these details.

Which CCT and CRI of SST20 model do you have?

I would very happily buy a 14×7135 chipped SST20 4000K 95CRI model, if it would be confirmed as available. Do you see any chance, that this will happen?

Both versions have the thermal “sane level” set somewhere up in the FET modes, above the highest regulated 7135 level. But it’ll regulate to whatever level is sustainable with the current settings, as long as it’s at or below that hardcoded level.

The ROT66’s original code, if I recall correctly, used about 700 lm as its stable level… and people seemed to think that was a pretty good choice. The new code sets the “sane level” or “stop panicking” level at around 2000 lm, and then tries to regulate normally below that. Basically, when it’s hot (or getting hot), it’ll quickly ramp down to the “stop panicking” level and then run normal PID below that to search for a sustainable brightness. Where it stops depends on the user’s thermal settings and environment.

That is exactly the model I have.

There isn’t much reason to limit SST20 to only 7x7135 chips. Probably not much reason to limit the 219B version either, honestly. At 350mA per chip, with 9 emitters, that’s 4900mA total or only 544mA per emitter… and the 219B, the weakest emitter being offered, can handle about 1500mA without issues. Meanwhile, the SST20 can handle all 4900mA with just one emitter.

So even with 14x7135, the highest regulated mode is driven pretty conservatively. The emitters are nowhere near their maximum power, and the only risk there is heat.

The XPL HI problem on the first version comes from the fact that the lights bezel does not get screwed till it rests on the head

The o-ring pushes on the optics which pushes on the emitters, if bezel screwed only with few torque its all fine
But if you screw down the bezel till it stops mechanically the pressure on the LEDs is too much damaging them

I guess they wanted to stop people screwing the bezel tight damaging the emitters

So that means Fireflies should glue only the XP-L HI version and not the other versions.

I would second that notion. There’s no reason to glue the 219B and SST20 versions. I think I’ma have to order a…4th ROT66, I’m so obsessed with the idea of putting an 804 filter over the 4000k hcri SST20. This time I’ll comment for them not to glue the bezel.

I’m a madman.

Not considering your audience :wink:

Yes, you’re right. We have already made some modifications to the host, not a problem to tighten the bezel now

So this means you won’t be gluing the bezels of future lights?

we will glue bezel by default. But we will add an option for un-glued choice.

Can you please have that apply to the driver as well?

A word of caution about modding this light. With the aux LED board installed, it’s tricky to access the driver. The LED wires are very stiff, the other wires are fragile, there are tiny components near the main wires, and there is not much space to work in. So the insides are not as easy to access as some other BLF lights.

Experienced modders should be fine, but for someone who hasn’t done it before I’d suggest starting with something easier.

That’s unfortunate. It would be really nice to be able to optionally disable them through some other means than untwisting the tailcap. One case I have in mind is when using the light in moonlight, unless even then they’re not bright enough to influence the main emitters’ tint noticeably.

The presence of 2.5V in the light is a bit puzzling to me, but I suppose that must just be due to a resistor controlling current to the button LED’s.

I don’t suppose the aux LED board uses an ATTiny. If it does, perhaps its feasible to customize its firmware so the aux LED’s can have a few modes controlled by loosening and tightening the tail cap. But then that’s an extra program to develop in addition to the Anduril / Narsil customizations.

I’m not sure what controller the aux LED board uses, but it’s very small and says “EDM2” on it.

The 2.5V channel is actually 3.95V coming from the MCU pin, but then it goes through something to lower the voltage, and then it goes to feed the button LEDs. The aux LED board could probably be powered from the same pin, but it would need to be hooked up before the voltage-reducing parts… and that requires changes to the driver PCB.

How does the MCU maintain 3.95v on the pin if the battery voltage is say 3.2v?

Lexels drivers use a resistor to reduce switch led current. You could tap in before the resistor.

If we look at the driver:

At 9:00 we see the R_ ind and R_perm. The perm is a source of permanent power for a switch light. The ind is the MCU controlled output. You can probably power the aux board from the ind if you tap into the right side of the resistor. The left side is the output.

It doesn’t. It’s basically just battery voltage minus ~0.25V.

I’ll try it, but it’s very small.

Okay, managed to get the wire connected there, and it’s working. It turns red at about 3.55V now instead of 3.30V, but that’s okay. Also, it can’t do the “low” mode like the button LEDs do, so it turns off instead.

This is what I was trying to do earlier, but while squinting at the driver I didn’t see a good place to attach anything. The inward side of that resistor is just barely big enough for a thin wire though.

Maybe low mode would work if you increased the LED brightness with the trimmer.

No, low mode is way too low for the aux LED board to work. It turns off when it senses low voltage, and the “low” mode is far below its “off” threshold.

Anyway, I did some quick measurements. My light box is not calibrated with anything resembling a reputable reference light, so these numbers should not be taken very seriously, but here is what I got at some key levels:

219B version:

  • 115/150: 780 lm (highest regulated mode)
  • 125/150: 1353 lm
  • 130/150: 1822 lm

SST20 4000K:

  • 115/150: 923 lm
  • 125/150: 1485 lm (highest regulated mode)
  • 130/150: 1911 lm

Levels 115 and 125 are the top of the Nx7135 regulated modes, depending on which driver is used (7 or 14 chips).

I included level 130 because it is the “panic” threshold. Above this level, any overheat condition will cause the light to quickly ramp down to level 130. Below this level, it does normal PID regulation to search for a stable level.

From Lexel’s description there is an LDO regulator on board, which could account for the 0.25V drop. It also supposedly drops out at 3.0V, which seems a bit high to me, but safe.

Presumably the aux. MCU has some way of sensing Vbatt before the regulator. Otherwise it would be rather pointless. Given that it only does one trivial job anyway, it seems to be rather a waste. Perhaps if serial comms. could be established with the prime MCU via the button LED circuit, there could be some potential for clever tricks.

Not really sure what the purpose of the regulator is, (or the MCU) but heigh-ho.

@Fireflies: could you tell us how to unscrew the glued driver retaining ring without damage, please?!

The aux LED board expects a direct connection to the battery. This allows it to measure voltage directly. It then has its own LDO for powering the LEDs at a consistent brightness.

The 0.25V drop is from the diode the MCU uses for reverse polarity protection.