Fireflies ROT66 Flashlight

You may be onto something here.

The general culture on BLF is less about ranting from the sidelines, and more about diving in to fix things ourselves. If you want something, build it.

That’s the problem, with the hardware. Very few have the skills, interest, determination, fabrication and test equipment, to bother with these, frankly not very interesting if you have a day job, things. Never mind give the designs away for free.

So it is just going to continue to be dreary derivative AMC+FET designs I think. With increasingly esoteric firmware options that few will ever use.

With maybe some flashy subsidiary lights.

I’d like to be wrong about this, but perhaps it is time to focus BLF techies energy on a new decent useful driver.

Comfychair had his day, but that was a long time ago, and it seems we are still living with it.

Buck or boost, or buck-boost, efficient, straightforward modes, minimal component count, open for firmware development with e.g. pogo-pin pads, perhaps even accessible for DIY assembly with crude tools.

Except I think that ship has sailed and, once you take a look at the good commercial suppliers, you might decide that they usually have an edge over BLF torches.

Summary:

BLF still has a place if it can rejuvenate hardware development, and open up and interest firmware development again to more than just one contributor.

Contribution from LED assessors (e.g. Maukka, Djozz) is key. Nevermind the hardware, the LED performance is absolutely the most important thing, as it progresses.

Assessment of cells is important, however it really is not so important if the torch has a good circuit design with a driver that doesn’t just rely on shorting the cells across the LED for max output. E.g. a properly considered linear or buck driver could deliver far better performance, overall,and maybe HKG’s curves would show better use.

This is the Fireflies ROT66 thread – not to minimize your observations of the BLF culture – but perhaps they belong in their own thread :wink:

Agreed, just poking and prodding to try to stimulate some forward-thinking discussion. On this thread because Fireflies appear to be interested in doing things differently and better, and this is just their first one. And they might be monitoring.

There is another one from them on way, and I have posted similarly acerbic comments on that thread, in the hopes that it might stimulate some useful debate, and thoughts.

PS: when I said DEL, I meant Wight. Doh. Sorry.

I also received it yesterday. ROT66 Aux led board .

Can Aux led turn off or choose brightness?
.

I like the SST20 4000K CRI95 of ROT66, this is my first SST20.

What is the difference in color temperature between the SST20 4000K CRI95 and the 219B SW45 R9080? Is it worth buying 219B again? (if ROT66 219B
Compared with D4S 219B?)
.
.
.
.
PS…
Understand that the lantern can not be turned off, only the tail cover can be turned off. Perhaps the new version can, but it seems to only open and close. :person_facepalming:

The thing is, acerbic comments are rarely productive. They’re more likely to backfire than to accomplish anything, hence the responses being “calm down” instead of “heck yeah”. Intentionally posting acerbic comments to stimulate debate is awfully similar to the definition of trolling, and is unlikely to have a positive result.

If you truly want to create positive change, it takes more than just complaining. Look for feasible pathways from what you have to what you want, then pick one and start a journey.

I don’t think the ROT66 aux LED board can be dimmed or turned off by firmware, because there are no more pins on the MCU to attach anything to. I will probably be able to test it soon though.

About the color temperature, it is a very personal preference so only you can answer that question. Some people love 4000K, some people hate it.

Do you have a picture of it? If it has the trimmers on the board then you can adjust the brightness with a screwdriver.

There’s only one option of controlling on and off through the firmware and that is to wire it in parallel with the switch lights.

The alternative is to wire it to stay on continuously.

 ROT66 MCU pin layout
           ----
   Reset -|1  8|- VCC
 eswitch -|2  7|- switch LEDs
     FET -|3  6|- Nx7135
     GND -|4  5|- 1x7135
           ----

As JasonWW said, the aux LED board could be connected to pin 7, to make it mirror the behavior of the switch LEDs. Otherwise, it’ll just be on all the time, which I think is probably the case. It has its own controller and everything, so it’ll change colors based on voltage.

I’m very curious to find out how much power it uses. I heard 50uA for the aux LED board’s LDO and controller, but I haven’t seen measurements of the total standby power.

Touché. I’ll back off for now.

Thanks, but unfortunately, these loosening / tightening steps didn’t work. Stretching the spring a little bit and adding a sticker did help though. Well I dislike the battery carrier design…

Got my ROT66 with Samsung LH351Ds + Lee Zircon 804 filter from Vinh:

The hotspot is massive in comparison to the Nichia version of the ROT66. CCT seems similar to my H600FC MK4, but slightly more rosy/less green. I probably wouldn’t like LH351D without the filter.



Nice comparisons. The LH351D with filter looks great. Did you take lumen measurements? I read the filter reduces output by about 20%. Also how do you know it is 98CRI?

The 804 reduces output by about 15%. The overall output of the Samsungs with filter compared to the Nichias on max is indistinguishable to the eye.

I’m going off of Maukka’s measurements of the 4000k 90cri Samsung emitters + the 804 filter. Granted, different optics can produce slightly different results, but it should be similar.

Likewise. It can’t be much different from e.g. the old lighted tailcap implementations. I.e. cell current lights up the aux. LEDs, albeit through an LDO regulator, but that makes no difference really to current consumption compared with the simple bypass resistor on the earlier designs, except the output is stabilised, so current should not vary much as the cell discharges.

If they can change colour based on cell voltage, that would be nice, but I’m not sure that is what is being offered here.

At the end of the day, keeping some aux. LEDs glowing takes a small continuous amount of power. Perhaps not a problem with a x3 18650 torch, depending on brightness, but certainly for smaller ones. The BLF X5 is such an example, although only having one LED in the tailcap the 14500 cell capacity is insufficient to keep the tailcap glowing for useful periods, hence disconnected on mine.

Just lighting up the switch, as on the Q8, takes minimal current, given the x4 18650 capacity, and is a useful feature.

It is a neat and clever design, for those who want it.

I have a few torches that have a switch LED which indicates cell state of charge, e.g. blue or red, when the torch is switched on. Or can be left on permanently. One even blinks red when off, to warn of low cell voltage. I find this useful. (Nitecore designs)

In other words, I like these as indicators of cell voltage, or as a way of locating the torch in darkness. Putting them in the head, rather than the tail, is an improvement I think, and perhaps the best way in e-switch designs, although just lighting up the switch in two different colours is good enough for me, and should take far less current.

Not enough pins on the chosen MCU though I think.

It has already been revealed that the aux LEDs change color to indicate low voltage. It has its own controller to manage the aux LEDs.

The X6v2 / X5 used an average of about 450 uA to keep the tailcap lit, so a 650 mAh cell would last about 60 days. It was annoyingly short.

Newer designs use less power. The Q8 uses anywhere from 30 uA to 130 uA to keep the button lit, so 4x3000 mAh cells should last anywhere from 10 to 45 years. If the X5 had the same design as the Q8, its 650 mAh cell would from last 7 months to 2.5 years per charge.

If I understand correctly, the PL47 aux LED board has a pot to trim the brightness to the user’s desired level. With it turned up relatively high, like 200 uA (plus 50 uA overhead), it would probably run over 2 years per charge. Or, at a lower level, perhaps over 5 years. But I haven’t measured it yet, so that is only speculation. In any case, rough estimates indicate it should last a useful amount of time.

If we go back to post 274, I believe Lexel means that the ROT66 board will shut down all its leds as part of the lvp. Before that, the inner 4 leds (of red color) will either turn on or blink to indicate low voltage. All 3 rings of leds have trimmers so you can control the drain.

Aah, a separate controller purely to sense battery voltage. That is certainly one way to do it.

The tail LED introduced on the X5/X6 shouldn’t have needed much current (though it was set excessively bright), there must have been some additional parasitic drain due to semi-powering the driver, perhaps through the voltage divider chain (before we increased the component values and then eliminated it altogether with clever firmware).

The bypass resistor was also a heavy parasitic drain when operating at moonlight/firefly levels, consuming much more power than the main LED. I never liked it.

The Q8 was done very well I think, after the hiccup with the first faulty switch PCBs, quickly corrected.

Fingers crossed. I guess it will be down to how well the MCU firmware manages power, and how it senses the voltage (slightly worried about mention of an external resistor change to set the level, suggesting a voltage divider might have returned). The 50 uA base figure suggests it is good, if all that remains is the aux. LED current, user selected with the trimpots.

Turning off completely (?) at 3V is safe

It is ingenious.

A while back, I made firmware for a similar aux LED board in the tailcap… but as far as I’m aware, no one has ever actually built or tested the hardware. The design there was a little different though, with six LEDs going RGBRGB in a circle. The idea was that, every time the user clicked the button to turn the main light off, the tailcap would boot up, spin the LEDs for a couple seconds like a roulette board while it measured voltage, then slow to a stop at a color matching the current voltage. Red, yellow, green, cyan, blue, or purple. Afterward, it’d blink that color like a beacon every few seconds, measuring voltage periodically to update the color.

The roulette bit also served to help the user time the duration of their button presses, to more consistently get short or long presses as desired, or short/medium/long.

Blingy, I’ll admit… but also useful. Would still like to have one.

Now that would justify putting an MCU on the board. I’d certainly buy that.

Puzzled about the name, ROT66. Where did that come from ? I keep thinking ROT13 and wondering whether there is some hidden message …

Edit: and rot is not a good word in English. In other languages, this differs.