Fireflies ROT66 Flashlight

I had issues with my ROT66 and some of my fellow BLF members were quick to offer assistance . Unfortunately there is an issue with the driver itself. That being said Jack from Fireflies quickly has handled the issue and that kind of customer service is rare nowadays especially considering how busy he must be getting all the orders out. Thanks Jack. Can’t wait to see what your company comes out with next ,Great Job.

Nothing is wrong with my driver, works flawlessly, only problem i have is carrier and driver ring scratching together with metal dust coming out

so someone slipped off during assembly and you got a deep scratch in it and now the carrier bites into it?

sounds like a job for some sand paper

I don’t think there was any mention of a scratch.

Post 836, he already tried sanding it smooth.

Maybe some dielectric grease would prevent grinding?

After sanding both driver ring and carrier, I rub my fingers on the surfaces and its as smooth as a baby’s bottom, then just after a couple screwing off and on the tail cap, the surfaces on both driver ring and carrier is rough again, i don’t understand why…

something is biting in somewhere for sure, I just don’t know how, how can smooth rubbing on smooth cause grinding? i dont know how but it does…

Is it possible one of the screws on the battery carrier is sticking up a tiny bit above the aluminum plate that makes up the top of the carrier?

If so, I think the best thing to do would be remove the problem screw, make sure there are no burrs under it, and if necessary, carefully drill or sand the countersink for the screw a little deeper. If you have trouble removing the screw after having glued it, acetone weakens superglue, but you might want to be careful about getting acetone anywhere but on the top, because I don’t know how it might affect the PCB on the reverse side of that aluminum plate.

The only other thought I had was try putting something low friction, like a couple sheets of waxed paper, between the tailcap and the battery carrier, to reduce the tendency of screwing on the tailcap to make the battery carrier rotate.

i’ve already checked all my screws and all of them are under the surface so none of the screws are touching the driver ring, the waxed paper might work but there’s already a layer of black foam there

I recently received my first interesting flashlight, the ROT66 Nichia. I’m confused about its behavior in turbo mode and how thermal control works in Anduril.

With fully charged Samsung 30Q cells, the ROT66 steps down from turbo mode after about 10 seconds. I notice that if I double-click after it steps down, it will go back up to turbo, but then of course will step down quickly after. It never gets what I would call hot.

I then used the thermal configuration mode to calibrate the temperature sensor (using an infrared thermometer) and to set the thermal limit to 65 degrees celsius. To my surprise, turbo from a cold start still steps down just as quickly as before, and the flashlight still isn’t very hot. But this time, if I keep double-clicking to bring it back up to turbo mode and do this many times, I get about 10 seconds of turbo each time, and the flashlight eventually gets really hot. I entered temp-check mode, and the light’s readout was 85 degrees celsius!

So, two questions:

  1. Why does it step down so fast, well before it reaches the configured limit of 65 degrees? A driver problem?
  2. Why does Anduril allow the temperature as measured by the light to reach 20 degrees beyond the configured limit? This seems like pure software control.

I don’t have an answer for you, but I will say that when it comes to setting temperatures in general, you should make sure the light is cooled down internally. Don’t assume the light is a certain temp based on the exterior. Inside it might be much warmer. People are always forgetting this.

When using NarsilM I will let a light sit for at least a few hours to fully get back to room temp before I try to set a thermal limit.

Obviously, the setup procedure is different for Anduril than for NarsilM. I would verify that your lights temp sensor reads correctly first. Let it sit overnight or at least a few hours. If it’s accurate, then try setting it to 65°C or whatever you choose. Just keep in mind that the temp sensor is built into the driver. So what it measures isn’t exactly the same as the exterior.

Except that doesn’t explain question #2. Even if the internal sensor was calibrated very far away from the true temperature, why would the control software ever let the light get to the point where the temperature sensor reads 20 degrees higher than the configured limit? It seems like a bug. I’ll try to reproduce this behavior tomorrow, but at a lower temp limit for safety.

All of this thermal safety stuff is just a courtesy so people don’t get burned. The light and electronics can survive much higher temps than the human hand. Plus it might not have actually been 85°. You’d have to get a temp probe up in there to verify.

You said you kept going back to turbo after it stepped down. So I think it was working as designed (maybe stepping down too soon, though). I would imagine ToyKeeper had to chose whether other not to allow people to reactivate turbo. My guess is she allowed users to “bypass” the temperature limit. Probably with the assumption that you do so at your own risk. People should know not to keep turning Turbo back on once the light gets too hot.

Jason is right, you need to make sure you config the temp right from the beginning for your “baseline”. Remember in Anduril you set the “current” temp then you set the “max temp” (# of clicks + 30 degrees C).

TK programs the thermal config generally under some slightly cooled environment (in hand / small fan). It will overheat much quicker just tail standing or sitting in a hot light box.

There’s no need to concern yourself about this. (You seem surprised and worried?) All we need to care about is external temperature to keep from burning our hands.

(Edit: So please verify the ambient temp is set correct. Then see if it fixes your problems.)

Surprised, yes. Worried, no. I mainly just want to understand [1] how the thermal regulation software for this light works and [2] why turbo mode on my light is not working as expected.

For [1], I realize that I can just look at the source code. After a quick look at the code, I see that temp warnings are issued only every 5 seconds, so that is one plausible explanation for why it overshoots the configured thermal limit so much. I’ll look at the code more later.

For [2], from maukka’s review of the 219B light:

On my light, in stock form it stepped down after 10 seconds, and after adjusting the temperature limit it still stepped down after 10 seconds. So this light does not come close to meeting expectations, and I wonder if it is defective.

Not sure why im replying since you are only listening to yourself but here goes.

They are not all calibrated precisely from the factory for the right AMBIENT temp. This changes everything and is critical for how quickly it steps down.

Hello

I got ROT66 two days ago. It’s very nice flashlight.
I love it. Everything is working fine.

I only have one small problem. I don’t know how to turn off small blue leds and leds inside switch. They are always on.
I really hope these leds can be turned off. I don’t want that they are on when I’m not using FL.

Thank you

Kind regards

I’m definitely interested in input from others and appreciate the responses. I’ve observed similar behavior before/after adjusting the ambient temperature, but maybe I haven’t yet hit the right settings.

Is there a way to “undo” the ambient temp calibration? Or equivalently reset all settings to factory default? I ask because the very first time I tried to adjust the thermal cutoff, I accidentally changed the ambient calibration, and I’d like to undo that.

I wasn't involved in these lights, but certainly I've seen big variations from MCU to MCU, like +/- 15C (maybe more). That's a 30C+ range which is huge.

So if they aren't individually calibrated, roll the dice. What we really should do is force the use of sensor calibration, but the spec sheet says from a 1 point measurement, you will only see accuracy to +/- 10C. They recommend 2 point calibration, meaning 2 temp readings that are somewhat far apart.

The thermal algorithm in Anduril looks at the current temperature, the rate of change, and a sum of several recent readings, and makes a decision based on where it thinks the temperature will be in the near future. So if the light is heating up very quickly, it’ll predict a very high number and regulate downward. This is done to allow it to “steer into turns”, so to speak, on hot-rod lights like the Emisar D4.

Similarly, if the temperature is dropping quickly, it tries to adjust upward to keep the overall temperature close to the limit.

On top of that, it also has an extra cautionary clause on lights which heat up quickly. With this, at the slightest hint of overheating, it drops down to about 200% of the level which was found to be sustainable during testing… and doesn’t ever attempt to go back up above that level. It does normal regulation below that level though. So we end up with three ramp sections:

  • High to turbo: Easily-triggered quick ramp-down to high.
  • Medium to high: PID-like regulation.
  • Moon to medium: No regulation.

Lights with more thermal mass (like the Q8 and the SP36), or with less power (like the Emisar D1S) don’t have that top-most section… they do normal regulation all the way to the top. But it sounds like you’re seeing the quick ramp-down from turbo to high, which is triggered mostly by heating up quickly.

At some point I want to completely rewrite it, but it’s going to be a long, tedious, and frustrating process so I’ve been avoiding it.

IIRC, maukka received one with NarsilM, which uses a completely different thermal algorithm: Every N seconds, check current sensor value. If it’s higher than T, step down by a large amount. So maukka’s results here won’t be the same because his had different firmware.