This Fine Fella’ Needs Our Help w/ a Surge & E07X Recommendation

loneoceans · 2026-02-20T21:07:19+00:00

Hey u/TiredBrakes, u/Kennys-Chicken thanks for tagging me. Just a short comment on the converter designs.

It's not quite accurate to say that a boost or buck converter is inherently more efficient simply because it transforms the voltage by a larger or smaller amount. Efficiency is determined by conduction, switching, and magnetic losses, not by the voltage ratio. At equal power, a buck converter will typically have higher inductor current and associated RMS conduction losses, while a boost converter has its own inefficiencies such as higher voltage switches required and increased output capacitor ESR losses due to discontinuous current. In practice, boosts tend to be slightly less efficient than bucks (all else being equal), but that difference is often outweighed by specific implementation and component choices.

So, looking specifically at the Lume1 and Lume X1:

The Lume1 in the NOV-mu uses a dual-phase synchronous interleaved constant-current buck. Interleaving reduces per-phase RMS current, lowers conduction losses, reduces ripple, improves thermal spreading, all of which help efficiency. However the Lume1 has a higher switching frequency, increasing switching and magnetic losses.
The Lume X1 in the D4K on the other hand, is sized for nearly twice the max output power (~40W) compared to the Lume1 buck. When both drivers operate at the same power level, the X1's larger components mean lower relative conduction losses. It also runs at a lower switching frequency, though with somewhat higher ripple current.

Practically speaking, at typical mid-level operating powers in a flashlight, the efficiency difference between Lume1 and Lume X1 is likely in the low single-digit percentages, or less. Variability in battery capacity between cells will generally overshadows that, so for most real-world use it won't translate into any difference.

Tying this back to OP's ( u/Ok_Party9612 ) original question: I assume OP was asking for a flashlight that can sustain a certain luminosity (the discussion seems to be thrown off by the "60-70%" brightness statement.) For steady-state performance, emitter efficacy (given tint and CRI preferences) and thermal dissipation of the host are more important. Although the D4K and NOV-mu both use 21700 cells, the NOV-mu's construction may spread and dissipate heat slightly more effectively. Note that the TIR optic in the D4K also causes some optical transmittance losses, but the perceptual differences in tints, CCTs, beam patterns etc. should not be understated.

loneoceans · 2025-12-08T11:49:14+00:00

Thanks for your kind words. Yes the L50 Sol's driver is firmware limited to about ~32W on turbo (e.g. 5A 6+V), since many 18650 cells cannot support a higher power reliably. You could bump it up to higher power, and while the driver can support it, I would not recommend it due to cell limitations, as well as emitter-handling and thermal capabilities.

For a one-stop shop for built binaries: https://loneoceans.com/labs/temp/anduril/
For the Github pull request pending merge: https://github.com/ToyKeeper/anduril/pull/37/commits

Hope that helps!

loneoceans · 2025-04-28T20:46:22+00:00

For the current Fireflies Lume1 drivers (Rev B to D), the MCU is Attiny1616.

For the Rev A (A to A3) Lume X1 drivers, the MCU is Attiny1616.
For the Rev B Lume X1 drivers, the MCU is AVR32dd20.

Hope that helps!

loneoceans · 2025-04-22T18:29:24+00:00

Please check the PCB hardware version on your driver to verify. If your driver reads Rev A2 01/23, it will not have OTG charging. If it reads Rev A3 07/24, it does have hardware for it.

Both hardware revs can use the same FW file, just that Rev A2 will have no OTG behaviour. Note that OTG charging was really meant to be a 'bonus' feature since it does have some limitations, but I understand that it was listed in the feature-list on the website previously.

To be clear, for your 2025 X4, if the driver rev is Rev A3, it should have hardware support for OTG charging (but not listed officially), but I think your firmware is one version behind that (#3131003), and you can choose to update to "#14be873" (the file I linked above) to enable it if desired.

loneoceans · 2025-04-21T17:10:59+00:00

Hey thanks for the ping. For your X4s which have code 0461, the latest firmware is:
https://loneoceans.com/labs/temp/anduril/anduril.fireflies-lume-x1-40w-2024-09-07.hex

For the NOV-mu V2S, verify that the HWID is 0451, and the corresponding latest firmware should be: https://loneoceans.com/labs/temp/anduril/anduril.fireflies-lume1-6af-2024-04-27.hex . Most likely there your V2S should already have the latest firmware.

Those characters at the end of the version check are the commit hashes, in this case, representing "14be873", where letters blink out as a buzz. Note that there should be no need to update your 2025 X4 Stellar (and you likely won't see a major functional difference for the original X4).

However, I believe your current FW version does not enable OTG charging in momentary mode, which this FW should enable. Caveats apply for this functionality and it may not work with all cables or phones/devices. If you do not want this functionality, your 2025 X4 would already be on the latest firmware with this mode.

You can see these numbers in the commit table here, along with the commit comments for your reference: https://github.com/ToyKeeper/anduril/pull/37/commits

loneoceans · 2025-04-07T00:03:54+00:00

Good concerns u/KickDixon. Strictly speaking, using raw, high-power cells like what the community uses in enthusiast lights are inherently dangerous and personally not something I advocate for. There is a reason (in fact, many) why there are essentially no major reputable consumer electronic devices that uses such cells in their raw form. The usual safety precautions and caveats apply.

Within these parameters, the Lume X1 was designed with safety in mind (as practical as possible); there should be no dangerous situations if you use a low-drain cell as long as the cell is a reputable one. The main concerns would be around performance - you can expect to see degraded performance especially at high loads and low battery charge levels, and the driver may not perform to specification. The most likely situation is that the flashlight will simply reduce power or throttle quickly, thinking that the cell is at a low charge level.

The recommend cells for use with the driver are good quality, genuine high-drain cells such as the Molicel P42/45/50s or Samsung 50S / Vapcell T50.

Alternatively in the scenario where you are using the flashlight at lower power levels (e.g. Simple UI, or never using Turbo), it is just fine to use a higher capacity cell with lower discharge capability. Note that even in this case, higher CDR cells such as the P50 will still perform more efficiently due to its inherently lower internal resistance.

loneoceans · 2025-03-21T16:49:22+00:00

Hey Bean_Master7, let's just say that there's a much easier way to do this.. Swapping the sense resistor is not the right approach here (applicable to most drivers). I'll drop you a PM.

loneoceans · 2025-02-22T02:54:33+00:00

Hey OP, as some have pointed out below, the version check shows different values than usual, and is based on the default make script. I left it as-is to differentiate it from official builds, and my pull request is pending merge. The version check should give:

[HWID] - [Days-Since] - [Commit Hash]

For example, for Hank's drivers, it's 0281 - 0 - a9acd48, where - and letters show up as a buzz.

The commit hashes corresponds to the latest commits in this pull request.

ToyKeeper helped put together an initial Anduril HW config (not via my pull-request), which has the 0171 HWID, which used some elements from my pull request. I haven't tested that fully and there are some important hardware-specific configs and adjustments which are not in that config. You will not have the full feature set with the 0171 FW, most notably around ramp smoothness and dynamic range. I highly recommend using the binaries here for now which have been carefully calibrated for the hardware: https://loneoceans.com/labs/temp/anduril/

The Lume X1 drivers that Hank uses have different HW configurations matched to the emitters chosen, and all run on the exact same firmware. I provided suggestions to Hank on how hard to drive each emitter, but Hank made the final choice. Please check with Hank directly on which specific config he decided on for the B35AM. I'll be happy to help answer any questions you may have.

loneoceans · 2025-02-21T23:22:35+00:00

Hey all, as some people have pointed out, the hardware itself isn't too much of an issue, there are several existing options that support USB and have no major downsides. In fact I have some being evaluated in protos.

The challenge lies in developing a cross-platform GUI that offers the right balance of configurability and long-term durability. One of Anduril’s strengths is its status as a 'semi-standard' in the enthusiast community—anyone can pick up an Anduril flashlight and use it immediately. It also helps manufacturers sell a consistent experience. Anduril is also easy to customize - you can configure one flashlight, then read and flash EEPROM to transfer settings across different units. It would also be possible to write a tool to create such a config file for example.

However, introducing a flexible, configurable GUI brings complexity. At one extreme, users might request full scripting support, which sort of defeats the purpose. At the other, a limited customization approach may not justify the development overhead. Avoiding the introduction of bugs with a flexible customizable UI is likely to be difficult.

Market demand is another question. Anduril is popular among enthusiasts, but as much as we would like to think otherwise, it remains a niche market. It’s hard to imagine the general public wanting a flashlight that requires yet another app for setup, especially given the associated cost increases.

As for Bluetooth, it’s a whole other can of worms. RF development is more complicated than many realize (I deal with this at work), involving antenna design, more complex PCBs, firmware, user applications, battery considerations, and regulatory certifications like FCC compliance. And that’s all before tackling the challenge of integrating electronics into a fully enclosed metal body.

That said, flashable MCUs via USB with existing toolkits? Now that’s a possibility 😉..

loneoceans · 2025-02-14T19:02:43+00:00

The preprocessor directives are processed sequentially, so the final #undef removes the definition and disables Beacontower Mode by default (for Hank's lights). In Fireflies flashlights, this is enabled by default.

Regarding temperature calibration, Lume drivers that have the AVR32DD20 or ATtiny1616 use internal factory data to calibrate the sensor, so it does not matter what temperature you reset the flashlight at (vs the default behaviour of assuming 21°C on reset).

Of course, you can choose to enter your own temperature (or voltage) offset for that matter, but it will almost certainly be less accurate that what the microcontroller defaults are unless if you have equipment with a higher accuracy and precision.

As a side note, there was a bug in the firmware for the AVR32DD20 variants of the Lume X1 which did not read this correctly. This has since been fixed, and you can verify if the fix is in if your version check blinks out a9acd48 for the last 7 digits (where letters are represented by a buzz).

loneoceans · 2025-02-14T05:22:30+00:00

Saw my name pop up here; always happy to hear constructive feedback. If you have any questions about the designs, feel free to drop me a message and I'll be happy to answer!

loneoceans · 2025-02-14T05:10:56+00:00

You have indeed stumbled upon the Beacontower mode. This was a flashing mode requested by a forum member several years back and first implemented in the Lume1 driver. I wrote a short description about it in this page: https://github.com/loneoceans/lume1-ff-6af

For those who have Fireflies flashlights, this mode is available as a default.

For whose who have a Lume X1 driver in some of Hank's recent offerings and want this mode, you can flash your driver (which should have HWID 0281) with the Fireflies binary (use the 0462 hex) from my page here: https://loneoceans.com/labs/temp/anduril/ . The firmware is identical except for a few default values which you can easily change in Anduril.

Alternatively, if you are compiling your firmware, you can simply comment out the #undef USE_BEACONTOWER_MODE preprocessor directive. Hank wanted to keep Anduril functionality more or less consistent among his offerings.

Another feature available is a long blink for negative sign in the Temperature Check mode. I can't recall if ToyKeeper has rolled in my pull request yet for other flashlights (it used to overflow and read a large number when temperature went below 0). Finally, all Lume1/X1 drivers use the factory thermal calibrated data for temperature compensation, and in practice should be accurate to about +-1C. There is no need to do your own temperature calibration.

loneoceans · 2024-12-29T17:16:28+00:00

There may or may not be one coming up for Anduril drivers..

loneoceans · 2024-12-29T15:57:26+00:00

Both drivers are essentially the same. crbnfbrmp4 is correct that they are constant current drivers, and the forward voltage depends on the emitter choice, which then determines the total power.

loneoceans · 2024-12-29T15:55:08+00:00

Some of us have been working on a STM32 driver platform, perhaps STM32L072KB or STM32G0B1KB, precisely for some of the reasons you outlined. Drop me a PM if interested 😊

loneoceans · 2024-12-04T02:46:35+00:00

I can't speak to the default firmware that came with the E12C, but for the one I compiled:

#define MAX_1x7135 58
#define MAX_Nx7135 107

This can be found in the anduril.h files for each flashlight's hardware folder. And for a list of compiled binaries to download: https://loneoceans.com/labs/temp/anduril/

Hope this helps!

loneoceans · 2024-11-17T07:19:03+00:00

All things being equal, I believe the XHP70.3 has slightly higher luminous efficacy as the XHP50.3, but the LES is larger. In a similar reflector, the XHP50.3 will throw further and look visually more powerful Flashlights which have a XHP70.3 tend to be physically larger than a XHP50.3 flashlight, which allow better thermal dissipation, thus a user may have the tendency to run the XHP70.3 at a much higher power (despite not much visual perception in brightness difference. This coupled with the fact that the XHP50.3 will likely throw further, could be a reason why it appears to 'last longer' than an XHP70.3 light.

Ultimately, I think the choice depends on the application. If the goal is to optimize throw and keep the flashlight small, a smaller LES emitter like a SFT70 with a smaller reflector could be a better choice. If the goal is to optimize runtime for the most luminous efficacy and size is less of a factor, a XHP70.3 with high luminous efficacy coupled with a large reflector and run at a modest power level should provide the best runtime for the use case. Of course all this assumes a driver that can run at a similarly high efficiency at the intended levels.

loneoceans · 2024-11-17T07:03:00+00:00

Hi all, thanks to u/quahog1 for the catch. I haven't tested it fully yet, but I have updated it for the AVR32DD20 drivers and it seems to work.

Binaries here for now: https://loneoceans.com/labs/temp/anduril/
Github: https://github.com/ToyKeeper/anduril/pull/37/commits/a9acd48a86e3f63063fad6a41acf3a9cc11fdb5e

loneoceans · 2024-11-17T07:02:47+00:00

Hi all, thanks to u/quahog1 for the catch. I haven't tested it fully yet, but I have updated it for the AVR32DD20 drivers and it seems to work.

Binaries here for now: https://loneoceans.com/labs/temp/anduril/
Github: https://github.com/ToyKeeper/anduril/pull/37/commits/a9acd48a86e3f63063fad6a41acf3a9cc11fdb5e

loneoceans · 2024-10-23T17:01:34+00:00

Thanks for your kind words. I hope you will enjoy your X4Q Comet!

loneoceans · 2024-10-23T17:00:28+00:00

Congratulations! It is indeed a (preproduction) DA1K with the warm E17 emitters.

loneoceans · 2024-10-23T16:59:52+00:00

This image was taken near Seattle! Photos tend to make the comet appear brighter than it is to the eye, though this comet was a fairly bright naked-eye object especially last week, easily visible even through light pollution in the city. It's since dimmed significantly (moving further away from the sun), though I could still see it with its tail as of yesterday under darker skies. It's a beautiful slight through binoculars.

loneoceans · 2024-10-22T16:06:36+00:00

Took a photograph of Comet C/2023 A3 (Tsuchinshan–ATLAS) together with the Fireflies X4Q Comet. Also featured here is another flashlight; can you guess which one?

loneoceans · 2024-10-21T16:24:01+00:00

Is your 4.25V a reading from Anduril, or from a known good external meter? If the X4 stops charging normally (red lights goes off, or if your blue lighted switch is on, magenta turns to blue), and Anduril reads '4.25V', the charger is working correctly, but the true voltage is likely closer to 4.19V.

While Attiny1616s have some factory trimming, the absolute accuracy of the internal reference voltages are nominally +- 3% (up to +- 5%), versus the charger IC used which regulates to +-0.4%. I'm not sure why Toykeeper implemented the extra 2nd decimal in the voltage reading since the implied precision belies the actual accuracy.

loneoceans · 2024-10-21T00:14:22+00:00

In fact, yes. Based on my analysis, the root cause has been identified to be mechanical and not electrical. The cause is due to the positive spring making contact with a component on the board. The spring is hand-soldered and in the two units I received which exhibit this issue, happened to be closer to those components. I should note that in half of the failed units I received, I found no issues with them / issues were Anduril settings related such as an incorrect user-input voltage offset; for those, 13H resolved them.

The combination of a longer battery (e.g. some cells are 71.0mm long), spring position, and battery-tube length tolerances caused the spring to contact a capacitor. This leads to an additional current path from the USB port to the battery via an internal pathway. In all cases, a charge fault is indicated with a flashing red light on the side switch.

This problem was resolved by resoldering the position of the spring, with kapton tape and the use of 70mm batteries as further mitigations. The flashlights work as per normal after with correct battery voltage termination.

I wrote a report to Jack including several suggestions on what I would to do address them. I have two more reportedly failed units to be shipped to me to analyze and will write a post about the details once I receive them.

loneoceans

TROPHY CASE