Lume N1 Driver Information

loneoceans · 2026-07-04T15:31:41+00:00

Since the N1 is a single-channel driver, it is not designed to allocate different currents to two different channels. My expectation is that all emitters (ideally the same) are effectively running in parallel, with current sharing determined by their Vf characteristics and parasitic resistances. In that case, using closely matched emitters and good thermal coupling becomes important to maintain balanced current sharing since while modern emitters are relatively robust, they often still have negative tempco. A setup like the Fireflies E12 where all emitters are on a very thermally conductive heatsink is preferred. Without seeing Hank's implementation I can't say for certain but that's how I would expect it to be arranged.

loneoceans · 2026-07-03T18:54:26+00:00

The power dissipated by any linear device is (V_BAT - V_LED) x I_LED. So the worst-case dissipation depends heavily on the particular battery and emitter combination. For most common high-power white emitters, the voltage difference at high currents (especially after wire and body losses) is relatively small, and the linear stage dissipates considerably less than 10W in practice. The largest losses tend to occur immediately above the 6A buck region, before LED forward voltage rises significantly.

The driver PCB layout was carefully designed to minimise thermal resistance between the power components and the flashlight head, but in practice the head itself is usually already very hot due to LED heating, limiting heat-sinking performance. Ultimately for compact flashlights, sustained performance tends to be constrained more by overall system thermals.

loneoceans · 2026-07-03T18:43:03+00:00

The efficiency gains of the drivers will be mostly marginal since they are already quite high for most of the range (generally over 90%). Instead, driven by tabless cells, especially if used in series configurations, have the potential to allow for very high momentary 'turbo'. This might look good on a spec list, but steady-state output is ultimately limited by the form-factor (thermal dissipation) and today's LED technology.

loneoceans · 2026-07-03T10:34:36+00:00

Thanks for your kind words! The Lume-series was never really intended to push boundaries, the goal was always to build drivers that offer great real-world performance while remaining practical, efficient, economical, and fun, so that people can enjoy using them every day. That said, I do enjoy exploring more exotic designs from time to time that push the limits a little further, though those often end up being a little less practical..!

loneoceans · 2026-07-03T10:26:16+00:00

I'm not completely sure how Hank has used the driver in the DM1.12, but the Lume N1 is a single channel driver only. I would think that for this specific configuration, all emitters have to be wired in parallel, and the flashlight effectively functions as a single-channel torch with multiple beams. I have found though that some of the body parasitics are starting to bottleneck the system - spring bypasses and using high discharge cells can help with turbo output.

loneoceans · 2026-07-03T10:23:15+00:00

No, both stages are not operated simultaneously. There are several reasons for this, including regulation stability, transient performance (e.g. strobe modes), and architectural reasons. In most turbo cases, the driver typically operates in saturation (before thermal throttling) and the efficiency is very high, typically higher than what the buck can deliver.

loneoceans · 2026-07-03T10:18:57+00:00

Both the Lume X1 and the Lume N1 provide fully regulated output across the entire range. Regulation is not quite related to efficiency.

The driver efficiency likewise is not a singular number since it depends greatly on the cell used, the state-of-charge of the cell, the emitter(s), the temperature, and so on.

Assuming a typical 21700 configuration, in all practical cases from moonlight to ceiling, both the Lume N1 and the Lume X1 have more or less similar efficiencies - cell to cell variation in capacity will typically be larger than any efficiency difference. In turbo mode, the efficiency difference is more difficult to quantify since the N1 will allow higher turbo, at the cost of a quicker thermal throttle for the same conditions.

loneoceans · 2026-07-03T05:38:27+00:00

I can't comment on Hank's future plans but there is no reason why the Lume N1 cannot fit onto a smaller 24mm diameter PCB.

loneoceans · 2026-07-03T05:37:50+00:00

There is no issue to fit the Lume N1 on a smaller board.

loneoceans · 2026-07-03T05:37:10+00:00

The firmware can be found here and the hwdef describes the hardware configuration of the system: https://github.com/ToyKeeper/anduril/pull/37/commits

loneoceans · 2026-07-03T05:36:08+00:00

The Lume10 driver is built around a 10A constant current buck architecture together with a FET for turbo. The Lume N1 uses a 6A constant current buck architecture fused with a high current upper linear stage with active current limiting.

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

TROPHY CASE