Will there ever be a fully customizable UI in the future?

Wondering if the people who are more in the know (ToyKeeper etc.) see a fully customizable UI in the future, where the UI can be flashed via software/computer/USB much how like the custom mechanical keyboard scene uses ARM/AVR controllers/processors and open source QMK software to fully customize any key on the keyboard. I know there a few lights that can be flashed with different firmware; but it’s still limited to that particular UI. For example, I would love a firmware that would let me flash an UI that can toggle a more advanced mode and a simple mode with HML and let me set exactly how many lumens each respective level would be (like Anduril and its muggle mode). While I love Anduril UI, it can be tough to memorize how many clicks I need to get into a certain mode or sub menu - would a dual button flashlight be feasible to select different modes via a menu system? For example:

Menu button -

1. Standard
2. Candlelight
3. Lightning
4. Strobes
5. Temp check
6. Settings


The above is meant to be just an conceptual example and not a definitive UI of any sort - and I understand the physical constraints of realizing a fully customizable UI for a tool that is meant to be as compact as possible; I’m assuming the processor and any additional button would only add to size and cost of the flashlight. But just throwing the question out there; what is the future for a fully customizable flashlight UI, if any? Hoping someone with more knowledge can provide some insight!

Lux-RC’s optical programming seems to fit your bill? Every single setting can be manipulated via phone/computer screen then simply flashed to the flashlight to make the change. No button presses or mode groups required.

Depends on what counts as “customizable”.

If flashing firmware from a computer is allowed, there are already a bunch of fully-customizable flashlights. I made a UI toolkit and some example UIs which can be used on a variety of different hardware, and people can customize it to pretty much any UI they can imagine. If the UI can be described in the form of a flowchart, it’s probably possible. The examples include an Olight UI, a Zebralight UI, a Werner-style UI, Anduril, and a couple simplified forks of Anduril.

If customization is limited to config data and not allowed to modify the firmware, something like the FLEX Asgard might work, since it’s configurable over bluetooth. Or perhaps a Lux-RC, though its UI is very small and limited.

If customization isn’t allowed to involve a computer at all, like if it must be entirely built into the flashlight, something like the YLP Unicorn may be of interest. It has a couple base UIs and allows the user to configure what most button presses do. Or a H17F allows configuring each of several modes and options. Or Bistro is pretty configurable.

My recommendation would be to use the most flexible option, creating completely custom UIs and flashing firmware to something like a D4v2 with its optional flashing kit. But I recognize not everyone wants to customize things that extensively, so simpler options are good too.

Would it be possible to have such software on a computer able to communicate with the driver on the flashlight through a usb port? In the radio control world, speed controllers can be connected directly to a computer and many settings can be adjusted through a proprietary software. If a flashlight with a usb had this ability too, it’d be very easy to allow alterations to the UI.

It’s possible, but fitting a USB port and the extra internal parts is tricky, especially if the light is small and/or needs to be waterproof. It’d also require a lot of development effort to create new drivers, new firmware, and companion apps for each major computing platform.

You might be interested in the HexBright, if you can find one. It’s a USB-programmable flashlight which IIRC is compatible with Arduino software. It’s pretty old though, and appears to involve just as much programming as modern FSM-based lights.

This brings up the same question as before though… How exactly should the customization work? The more customizable the UI, the more complicated it will be to customize. Where is the ideal balance between “too limited” and “too complicated”? How “full” is “fully customizable”?

My solution errs on the side of being as customizable as possible, but also requires editing some text files instead of using a GUI. The user can do pretty much anything, and the code is relatively simple, but even simple code can be scary… and “pretty much anything” also includes the ability to shoot one’s self in the foot.

On a related note, this just popped up today…

Just speculating, I suppose it’s possible with a phone app and Bluetooth connectivity, which may require not one but 2 or 3 buttons on the flashlight body.


I’ve done the hardware: What did you mod today? - #8566 by Mike_C
However, I flash firmware I’ve coded from Atmel studio directly, I’m not interested in making an app like software for configuration options…. at least not yet…

That’s a pretty cool/crazy build, and the type of thing of which I was thinking. The idea wasn’t so much for infinite variability in the options, as what ToyKeeper points out, right now its only a difference between altering a text file vs. creating a GUI. I was thinking of simplicity. Some lights already have USB ports to charge. If that could be tapped into to allow alterations to the firmware without having to disassemble the flashlight, remove the driver, connect a bunch of little wires, and then re-solder and reassemble everything, then even with simply uploading an altered text file would make the whole process faster and easier.

But then, I guess the only people it would benefit would be those who are lazy and/or don’t like to solder. Unlike for radio controlled vehicles, speed and ease isn’t necessarily all that important here.

Well, there is the pogo pin solution used by a quite a few here, that eliminates the soldering part. For me it wasn’t good enough because developing firmware from scratch for a different type of microprocessor requires a lot of testing and re-flashing of firmware. Personally I don’t want to be holding anything while flashing, and constantly screwing of the head is annoying when in an intensive testing period.

There was a suggestion about using something flashes brightly and use the LED as a light sensor to receive data. I think someone here did some simple testing with that, but I don’t think anything has become of that yet.

So there is definitely interest here to speed things up. With the pogo pin solution I would say that quite a lot of people have moved away from soldering just to re-flash firmware.

I’ve done this here: My 6th Annual Scratch Made Light Contest Entry
And I’ve also modified a Q8 for remote control and configuration via bluetooth and android app.
Although I played a lot with these gimmicks when they were new I haven’t used them for a long time now. Once the light is running as desired I don’t need them anymore.

I had missed that one… Pretty cool!

Yeah, I only took it far enough to verify that it works… and then measure the effective data transfer rate. It ends up being very, very slow… so it would take several hours to flash firmware via optical transfer from a computer screen. And since it’s a unidirectional connection, it doesn’t really facilitate error correction.

So it’s possible, but it’d take hours per flash and has a high chance of failing each time.

It’s much more feasible to set config values this way, since that’s a lot less data. But then it’s nowhere near as flexible.

I see. I didn’t know that, thanks for the update.

People have been wanting to program their lights from a phone screen, like from a browser or by playing an animated GIF with the right blinky pattern. In theory, that could operate as fast as 60 FPS, but it would be extremely unreliable… and this is something where reliability matters quite a bit. So the effective frame rate ends up much slower.

Not sure if you’ve ever seen anyone update their Lux-RC light, but it’s only sending a small amount of data and it still takes a while. I think it only has like 12 or 16 bytes worth of configuration, and it appears to take about 18 seconds for the transfer, so … roughly a byte per second.

For a full 8 KiB ROM, it’d be over 2 hours if everything goes smoothly.

TBH I just want a working Muggle mode so the kids can use my lights