Please help…Would anyone know which model/firmware I should use for these drivers. One is a LumeX1 6v 6a the other is the FFL mule V2 I think it’s the same X1 as the other thanks a bunch
Version check (15C) will tell you.
2 Thanks
From the creator himself
https://loneoceans.com/labs/temp/anduril/
Your Fireflies driver ist Lume without X , thats’s the buck driver
2 Thanks
I think FireFly is 0451 but the read out is like nothing I’ve seen before it goes 0451 buzz 0 buzz buzz 1 buzz 5774 I have no idea what that means
It means somebody changed the Version Check format. I think I recall seeing a bizarre format once on a Loneoceans light… because he didn’t like the default. Thinking back, if I recall correctly, he said it was blinking out part of the git commit revision identifier hash, but revision identifiers are hex numbers. Anduril actually supports hex values in the version string, but he didn’t translate the values to what the firmware expects, so digits A through F were just “buzz”.
In other words, the version check value is broken.
It was one of several reasons why I wasn’t able to merge his commits. I ended up having to rewrite a lot of it for the Hank Lume-X1 build. The Fireflies builds aren’t merged because I can’t merge them as-is and I don’t have hardware to use for testing while I rewrite the code. Fireflies hasn’t sent me anything in a long time, and it’s not even possible to buy most of their models… so I can’t test and haven’t put much effort into trying to support their products lately.
We ended up disagreeing about several other things during the Hank Lume project, too. Like, the driver can produce 300+ distinct brightness levels which are dimmer than the aux LEDs on low mode, and 100+ of those levels are literally impossible to see without special equipment like a long-exposure camera. And while that’s neat in an engineering sense, I didn’t think it made sense to devote a large chunk of the ramp to levels which are invisible to human eyes, or less bright than the lowest aux mode. I shortened that part of the ramp quite a bit, to leave more room for the levels which are actually capable of illuminating things. Like, 0.01 lm or more.
Anyway… I’d grab the Hank firmware from the main repository, and get the Fireflies firmware from Loneoceans’ site. Just don’t expect the Fireflies lights to work like everything else.
100 sublumen modes…could they be scaled up logarithmically to improve the candle mode? 
Oh, it has thousands of internal power levels which are under 1 lumen. The 100 levels I mentioned are so dark they are basically “off”.
The driver has three “gears”, like how a bike or car has different “gears” for the engine, and the lowest “gear” gives 2500 levels ranging from zero to like … 0.2 lm or so. I allocated a total of 5 (out of 150) ramp steps for this range. This is the bottom of the ramp in my version:
- 100 / 2500: Just barely bright enough to see the LEDs in a pitch dark room, with the light aimed directly at your face, if you cover the lighted button so it won’t drown out the main LEDs.
- 359 / 2500: About 1/10th as bright as the aux LEDs on their lowest output level.
- 790 / 2500: Slightly brighter than the aux LEDs.
- 1437 / 2500: About right as a low moon level.
- 2500 / 2500: The highest power the low “gear” can provide, and also about average for a normal moon level. Output is about 0.1 or 0.2 lumens… low enough that it’s difficult to measure.
At ramp levels 1/150 and 2/150, turning the light “on” actually makes it darker than the low aux standby brightness, but it can still at least be seen. These outputs are provided for people who have the aux off and want something very very dim.
Meanwhile, Loneoceans set the bottom of the ramp to:
- 1 / 2500: literally invisible
- 2 / 2500: literally invisible
- 8 / 2500: literally invisible
- 25 / 2500: literally invisible
- 61 / 2500: might be able to see it if you look hard enough directly at the LEDs and have really good vision
I didn’t find these to be, um, useful. So I removed that part of the ramp to make space for better resolution in the levels people can actually see.
3 Thanks
Purely out of curiosity, does the smooth ramping leverage those thousands of levels as a scale? I still haven’t played with anduril’s code, let alone even peeked at it yet…
And does the “gear” aspect account for the slight blip around 15-20 lumens?
**and is there a way to reassign or provision those unused levels into the higher gears? I.e. 2500, but cutout the higher 150 and double the available levels from 150 to 300, and get it to rescale the dimming curve accordingly? I’d really like a less turbulent candle mode…and scale the candle max to 17ish lumens, and have it dim from there rather than fluctuating up and down off of an average value?
*****p.s. apologies for the live editing, i keep having more and more questions, lol…
Mostly no, but sometimes yes. Thermal regulation uses those in-between levels to provide smoother adjustments, and so does the sunset timer if I recall correctly, but the 150 step ramp does not. In-between levels are a bit tricky to use, because the details vary so much between hardware models. The UI code uses an abstract model of what a light is, so it can’t rely much on hardware-specific details.
Some lights use a simple PWM level for in-between levels. Some use PWM with more than one power channel or “gear”. Some use PWM in combination with pulse frequency modulation, changing the speed at every ramp level. Some use a hybrid of PWM and delta-sigma modulation. Some use an internal abstraction to divide power between multiple channels for tint ramping purposes. Some use a true analog output with multiple sense resistor and Vref changes. Some use a different type of power circuitry for each set of output LEDs, and sometimes even have more than one active simultaneously. Some have to run at different speeds depending on which sets of LEDs are active at the time. Some don’t have in-between levels at all. Some have 8-bit resolution, some are 10-bit, some are 2-bit, some are 11-bit or 12-bit, some are 15-bit, and some change the effective bit resolution for each ramp step. And nearly all of them have to support dynamic underclocking to make the low modes more efficient.
… and the UI abstraction layer makes it so the UI logic doesn’t really have to care about any of that. But it also means it can’t always take full advantage of every hardware feature on every model.
Probably yes. There is sometimes a visible bump when it changes “gear”. It’s really hard to avoid, because of random variation in hardware components. The parts just aren’t precise enough for perfect gear changes on every individual light. Tune it to produce a perfect gear change on one light, then flash the same firmware onto another light of the exact same type, and it’ll have a bump. Usually the ramp is tuned to make sure it’s a “bump” and not a “zig zag”, because a zig zag looks worse.
On a Hank Lume X1, it has 3 “gears” and each one has 2 internal Vrefs, kind of like a bike having a front gear and a back gear. So in a complete ramp, there are actually 6 gear combinations and 5 gear changes… 1.024V low, 2.5V low, 1.024V medium, 2.5V medium, 1.024V high, and 2.5V high. But the internal 1.024 / 2.5 Vrefs are usually pretty precise, so only the low-med-high primary gear changes tend to be visible.
Some older models also have an intentional blip at key parts of the ramp, like on a FET+7135 driver when it changes from a 7135 chip only to a 7135+FET. This serves two purposes: To give the user a visual milestone, and to make the “gear change” bump less obvious.
Anyway, long story short… it’s complicated. Mostly because it supports so many different types of hardware and needs to ensure everything works on all of them.
2 Thanks
Thanks! I’ll have to start playing around to see what’s what…I appreciate the comprehensive explanation!
Ok thank you I’ll look for the Hank Lume X1 build
If it’s not to much trouble can you send me the link I downloaded the latest releases and I don’t see it Thanks TK
Ah, crap, you’re right. I just realized I forgot to merge the lume x1 branch into trunk. It’s still only in a branch.
I’m not in a position to do that right this moment, but I’ll leave this tab open until it’s done.
Your the best can’t thank you enough
Very impressive from an engineering point of view indeed, but sounds like a waste of ramp steps to me. I agree with your choice, makes a lot more sense this way.
It took a while, but I was finally able to test it on production hardware and get it merged and published. Just the Hank Lume X1 though, not the Fireflies models. The Fireflies ones still need code changes and I can’t test them without hardware.