I had not seen it. Thanks, very helpful. And thanks Mitosis for identifying a fix.
Loosened screws, pressed in batts, tightened screws. A simple fix.
I hadn’t seen how low parasitic drain from the Auxillary LEDs takes the battery voltage. Has that been measured, and is it safe since it can’t fit cells with a PCB? Thanks
The default configuration in Anduril sets the ceiling to the highest regulated level, which on most models is level 125 of 150. This can be changed to whatever you want though, and regardless of the value it uses, true turbo is still available by doing a double click while the light is on.
I’ve heard a few people report that, but I’m not sure what exactly causes it. The only time I’ve seen the lowest level flicker was on the first FW3A prototype, and swapping out a 7135 chip fixed it. I haven’t seen any flickering on any of my Fireflies lights though.
Another way around it is to set the lowest level a bit higher. Using level 3/150 should work.
To configure the ramp to go from 3/150 to 150/150…
Then just wait for it to fall out of ramp config mode.
The stepped ramp also has a third option, to set the number of steps.
It’s 150 levels, not 250. Same as Narsil. This number was chosen because Tom wanted the full ramp to take 2.5 seconds from one end to the other, and the light’s timer runs at 62 fps (0.016 ms per tick), so that works out to about 150 frames or 150 steps.
I’m still trying to find the reason why some units flicker on the lowest level and some don’t. It may be that one of the 7135 chips isn’t quite right, or maybe there’s some electrical noise somewhere causing interference, or maybe things were flashed with the wrong fuse values, or maybe there’s some sort of weird timing interaction between the PWM cycle and the ADC cycle, or … I don’t know. But I haven’t been able to make any of my Fireflies lights flicker like that, so I haven’t been able to test theories.
I have seen some odd behavior on the aux LED board though, during specific parts of the ramp. So I think there may be some sort of feedback going on which is weak enough that it only affects the most sensitive parts at only a few specific levels. But I don’t have an electrical scope to look at the behavior of that in detail.
The aux LEDs turn red at 3.3V and turn off entirely at 3.0V. The amount of power drawn while off drops to a very low amount which I think is lower than the cell’s self-discharge rate.
The main LED driver also has low-voltage protection, causing it to shut off when the battery is too low.
So there isn’t much risk of having the battery drained below safe levels.
Thank you, very helpful to know.
Ever since I learned my Astrolux S42 breathing mode can deplete the battery to 2.38V, I am concerned with any type of drain when the torch is “off”. I do a head lockout on the S42.
The ROT66 has redundant protection and with the low draw you mentioned gives me comfort enough to not lock out the ROT66 when not in use. Happily too as the Aux LEDs are pointless if you can’t leave the torch “on” to admire.
The S42 was very badly designed, in general. But the breathing mode, in particular, is something I’ve avoided on purpose. It’s a nice-looking effect, but it greatly increases standby current. It’s implemented by drawing a slow triangle wave on the PWM duty cycle value, which requires running PWM while the light is off, which requires leaving the MCU on instead of going to standby. So the “standby” current is about 4 to 5 mA.
I usually aim for standby current in the range of 0.2 mA to 0.001 mA. So… no breathing mode.
The ROT66 with aux LEDs runs a bit higher than that, like 0.2 mA to 0.5 mA, but that’s pretty okay with a multi-cell power source like it has. That should last about 2 to 5 years on standby… and the user can turn the pots on the aux LED board to reduce the brightness as far as possible.
Thank you, very helpful! Can ramp to turbo now and flicker is gone by setting the low just a little higher.
Okay, I corrected my earlier post and let the fellow in the video know it’s 150 steps.
I do get confused that it’s 150 steps, but I think it’s in the code where you have 255 levels. :disappointed: Ah, confusing.
It’ll get more confusing when we get drivers with 16-bit PWM counters. Then it’ll be 0 to 255 sometimes and 0 to 65535 sometimes. But probably still 150 ramp steps, because that number seems to work pretty well.
Ah so that’s what you meant by 125/150 earlier. I’m gonna try experimenting with maybe 120/150 or 115-110/150 to see if I can get a slightly lower output that will manage heat better.
Man, the temperature calibration was a good 10c or so off on my particular ROT66 from the looks of it. I didn’t have a thermometer on hand to get a completely accurate reading of my room temp, but I do know it was around 18-22c, so I dialed in 22c just to play it safe. My ROT66 read 35c!
I also changed the temp limit from 45c to 55c.
I also set the ramp ceiling from 125/150 to 120/150, and now it manages what looks like a 1100/1200 lumen output for at least 10 minutes without any heat issues. It did get warm, but it never got super hot, so I think I found the level where it can shed heat well enough on the SST20 4000k version.
You didn’t have the light running beforehand, did you? If so, the lights internal temperature might have been higher than its external temperature. I mention it because a lot of people forget about this.
I let it rest 30 minutes. It wasn’t cold to the touch like my other ROT66, but at the same time it had ample time to shed any heat. I’m going to go back later on and re-calibrate the temp again when it is cold to the touch to get it completely accurate though.
Why are you still messing with cr@ppy 8 pin MCUS ?
The days of DIY, or shabby “commercial” manufacturing, maybe with a hotplate or toaster oven, are surely over.
Sorry but this is reality.
Prove me wrong., please.
Re-calibrated the temperature sensor to be more accurate once the light was cold. The factory setting was still a good 7-8c off though.
The proof that you are wrong is right in front of you, if you could only be bothered to open your eyes and look.
I can’t say why these specifically, but we’re using such basic MCU’s probably because until recently, we weren’t using much of their capabilities. I mean, at one point, as far as I know the norm seemed to be essentially a convoy style Nx7135 single channel 3 or 5 mode light… doesn’t really need much of a chip to control that. Anyway, apart from the limitations we’re starting to have (and, after all - it’s not as if an atmega is gonna fit in a d4) they’re not that bad. Easy to program, for one thing.
My ability to resist finally broke down last night. My wife is probably not going to let me live down buying another light, but oh well. I went with black on the hope she’s less likely to notice it.
I’m really looking forward to my first experiences with Anduril and SW45K ranked emitters. The only other 219B light I have is just R9050 binned, I think.
It will be hard for her not to notice with the lit up auxiliary board! My wife was drawn to it right away like a magnet.
So true…. LOL! 
I'm still working on my cover story. Maybe if I mod my Convoys with illuminated tailswitches I can confuse her.
My fall back would be to distract with a gift, but she's not a jewelry person, so I've got to figure out something else.
I keep hoping that if she sees the right copper, brass, anodized titanium, or otherwise fancier lights, she'll catch the bug. So far, it hasn't worked.