Flashlight Firmware Repository

Thanks, that’s exactly what I was looking for. :+1:

You mean ones where you buy PCB and a bag of parts, then solder everything together?
There are a few…but scattered over many topics.
It would be interesting to make a reference at some point…but as of now it doesn’t exist, so please tell us what kind of driver are you looking for and we may be able to help.

I am looking for the design of a driver for an xhp70.2 led, I have to be able to power it indifferently with 2s 3s 4s battery packs, I need the design because the pcb must have a specific shape for the flashlight that I am building, I am a hobbyist with the passion to build things, I’m not electronic, but I can assemble a pcb, I’m building an underwater torch, if you can help me thank you

2s is something I may be able to help with. Zener modded Texas Avenger should do the trick. Please note that recently Texas Ace started to use resistors instead of 7135 because with powerful 2s lights they are much more reliable.

For more than 2s you need some other driver, most likely buck. I’m not sure if there’s anything open source available…

:smiley:

In this beautiful software there are one awful thing.
Every time, when i am going to check voltage, if i shutdown flashlight on high level, i get huge preflash during 3 short click. And because moonlight not remembered - even if i firstly switch on by hold on moonlight and off then - huge preflash would appear.

It would be essential, if software d’t turn immediatly on memory level after first click. Just moonlight for first 0.1-0.2 sec and only after - turn back to memorized level. So, if we do many clicks - as for voltage check, software would catch next click before turning power up to memorized level.

I use gentoo on my dev machine. I just got a notice that bzr will be removed from the package repo in 30 days because it requires Python 2. They recommend that I switch to breezy.

Seems to be a worthy change if possible. I usually don’t turn off from High, so maybe I don’t encounter it often, but I’ve encountered this (bright pre-flash) when doing the triple-click battery check.

I use breezy for months already, works great. The multi backend support (bazaar and git) is nice. Much better than fast-export. But for me it’s still just a bridge between bazaar and git. :wink:

Not sure of the solution would be more painful than the problem. I do agree it's annoying - happens to me all the time, but adding the delay to the basic click ON - I dunno...

Just a quick question: I assume all flashlights have slightly different coding? So I can't just adjust 1 code and upload it to several Anduril lights I own, for example: Noctigon D18, Lumintop FW3A etc.

Actually I have a second question, when I go to this overview: https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper

I'm trying to download but get errors each time.

Anduril has separate files for several more popular flashlights. They usually differ in the number of pwm outputs, auxes, button illumination, “maximum power” and temperature, or smaller “BLINK_AT_RAMP_MIDDLE” settings.
But if you are sure that the driver has the same structure and flashlights have the same functionality then one file should be enough.

TK seems to be trying to refresh the entire library. Check this thread.
At this link you will download (probably) the latest version (482). (Whole repository).

Long story short… bzr (bazaar) has become brz (breezy).

Longer version: Most of bzr’s development was funded by Canonical, and the company’s entire development process was built on bzr and Launchpad. Around 2010, the company changed priorities from a community-first approach to a profit-based approach. Lots of things changed over the years, and development for Launchpad and bzr was scaled back to just a few people. They also started adding support for Git, and some of the newer developers switched to GitHub instead of using the company’s own system. In 2017, after several failed attempts at profitable projects, the company laid off most of its developers. Soon after, some of the original bzr devs then continued to work on bzr in their own time, but renamed it to brz to signal a new direction… and they were much more free to do what they wanted with it. It was a labor of love again, not tied to a company. The original bzr is effectively dead, replaced by brz.

Yeah, prioritizing the path to battcheck would mean adding a delay at each normal activation… so it seems like spending $20 to save $5.

However, there are two ways to solve it… the user could build a customized verison with “B_TIMING_ON” set to “B_TIMEOUT_T” to make it wait until inputs are fully resolved before responding. Or if a “soft start” is ever added, that might reduce the pre-flash too.

I tried adding a soft start once though, and it added a lot of complication and potential for bugs, since it didn’t react well to being interrupted. But perhaps I could try again after doing some refactoring.

The code is structured to make the hardware details and UI details separate. If you change the UI, it generally should work on each supported device… and if you change the code for a supported device, it generally won’t affect the UI or any other devices.

For the most part, the code for each specific device is limited to only a hardware definition file (MCU pinouts, hardware features) and a UI config file (ramp shape, interface options). The rest is shared across all devices.

It’s very similar to how a regular computer works… there is an operating system and there are applications. But in this case, there’s a microkernel and a user interface… and they’re compiled into a single file to save space.

After making UI changes, it’s normally recommended to run “make”, which builds the firmware for every supported device. Then match up the .hex files with the devices you want to flash.

That should be resolved very soon. A bug popped up in Launchpad a couple days ago, I reported it yesterday, and a fix was committed today. So it should be in the next site update, and the updates happen frequently.

(edit: it’s fixed now)

Thank you for the story ToyKeeper. I’ll switch to brz then.

Hoping someone can help me. Pulling my hair out.

I’m trying to make a small change to the dragon low color output. I want it lower.

So I change it from this:

// THESE VALUES ARE USED FOR EASY LEVEL CHANGING INSTEAD OF USING THE RAMP
#define RAMP_SIZE 8
#define RAMP_7135 25,255,0,0,0,0,0,0
#define RAMP_FET 0,0,1,15,40,90,140,255

To this: (25 to 10 for first value)

// THESE VALUES ARE USED FOR EASY LEVEL CHANGING INSTEAD OF USING THE RAMP
#define RAMP_SIZE 8
#define RAMP_7135 10,255,0,0,0,0,0,0
#define RAMP_FET 0,0,1,15,40,90,140,255

It builds fine in atmel studio. It flashes to the attiny25 on the board no problem.

However, the brightness level does not change. I have tried flashing many times, no affect. What am I doing wrong or not doing correctly?

I’m not sure, but I recall hearing about some issues with the Dragon boards having a leaky 7135 chip which stays on even during the white modes. If you’ve got one of those, it might not be possible to lower it below a certain point.

To test it, try changing the first white mode to 0, and check if the color channel stays on.

It’s possible the white LEDs could be on at level 0 too, but that usually means it’s using fast PWM instead of phase-correct. Might be worth checking that too.

Thank you TK. I started all over from scratch in Atmel studio and it worked the first time. Must have been a glitch somewhere. :person_facepalming:

Can someone recommend an Anduril hex file for a D4V2 without the auxiliary lights?

I have a D4V2 that I’ve been swapping MCPCBs and I’m not reconnecting the aux light board. I assumed I could grab a hex file for another Anduril light without the aux lights but I’m not having any luck.

Any input would be greatly appreciated.

Honest question: what’s the harm with leaving the firmware as-is?

I snipped the leads and just wanted to make sure they weren’t powered. Maybe I’m being too OCD?