Toykeeper, thanks for the work you do in maintaining the flashlight firmware repository. I successfully flashed the AK-47 driver in a red XP-E2 Convoy S2+ I built as a bike light using the firmware you developed in this thread, and I also updated my BLF Q8 to Anduril.
Now down the rabbit hole of customizing firmware code, since apparently hardware mods aren’t enough 
It’s a deep rabbit hole.
Hi guys
I wanted to change the modes in my astrolux s41 (blf a6 firmware), but I can’t understand this speed pwm. Could anyone write to me how it should look corrrect in my modes? (Blue)
Green. Can I set the brightness of these modes there?
Fast is about 15 kHz, but doesn’t work well for moon and turbo and anything which needs to ever shut off the LED completely. Phase-correct behaves better, but is only ~8 kHz.
The numbers below, starting at 255 and counting down, are not the brightness. They are simply internal codes to represent each special mode. To change the brightness you’ll need to edit other parts of the code. Some of it can be changed with the BLINK_BRIGHTNESS setting, but turbo and strobe are hardcoded to full output and you’ll need to change the code directly.
I think I understand. So it’s ok.
Unfortunately, I have another problem. The medium press doesn’t work properly. It should be 0.5s to 1.5s, and I have about 3 to 6 seconds. The original firmware worked correctly.
this is a common problem
physically reducing the OTC from 1uF to 0.33uF should fix it
no clue where in the code the OTC voltage is interpreted and how to adjust it
Leviatan, look in the battcheck/ directory. A “README” there explains how to calibrate the voltage and OTC. It involves doing some measurements then editing a calibration header file (“tk-calibration.h”).
The OTC is pretty sensitive to slight differences in hardware, so it’s a good idea to calibrate each batch of drivers. Even just changing the supplier of a single component can throw it off.
Got it. Thank you again TK.
In INDEX: Extras>turbo timer should be blf-A6
Andúril’s Candle Mode on a reverse clicky light?
I really like Candle Mode from Andúril as used on my Q8. To better emulate a real candle, I’d like to put Candle Mode on a 3000K emitter light I built, but Anduril won’t work directly with that light due to it being a reverse clicky.
Can anyone tell me how difficult it would be to port Candle Mode into some firmware that would work on the hardware described below? It’s been a few years since my Arduino tinkering gave me a little bit of experience with C code, so I am by no means an expert. If this is a bit much as a first project, I’d like to know that now, not after my hair is all pulled out. :weary:
Realistically, I’d be happy to just get Candle Mode by itself if there are reasons (space on the driver?) the rest isn’t possible.
Any tips on references to read or paths to go down (or avoid), I’m all ears.
Hardware:
My ideal firmware for this light would have:
Thanks for the help!
I’d have to extract the candle routines from Anduril and see how large the code is once built. I’m curious though, so I might take a stab at that.
In the meantime, however, there is a firmware called CandleFlicker from a couple years ago that is solely a candle mode without any other niceties (including LVP). Even with just that basic set up, it compiles at 980 bytes (95.7% full).
Candle mode stuff relies on random numbers and lots of math, so it’s going to take up a bit of room.
Is it possible for Narsil to run the strobe modes at a lower level than 100%?
Updated.
It’s probably do-able, but not trivial. I’ve put all sorts of fancy modes into tiny13-based reverse clicky drivers, but they’re usually a lot simpler than how candle mode works. The main difficulty will be getting everything to fit. Also, instead of running via interrupt at 62.5 Hz, you’ll need to put it in its own timing loop with periodic exits to handle LVP and such.
The random number generator will also definitely need some changes to work on tiny13.
Not that I’m aware of. I mean, not without changing the code.
I have Qlite Rev.A 7135*8. I was thinking about cutting a trace to one of the 7135 and connecting it to the star (so other attiny13 pin), so effectively it will be 7135+7*7135 driver. Is there any firmware that can handle such modification? I’ve found JonnyC double PWM firmware, but it doesn’t have full 1*7135 mode. So I’m looking for something like BLF-A6 firmware without OTC.
Looking in the INDEX file, I see several projects which support dual PWM:
Some of these also support tiny13, no OTC, and clicky switches.
… and biscotti would be relatively easy to modify to support dual PWM, since it was based on bistro.
Thank you. All “STAR” firmwares do not have independent PWM channels.
I think Flintrock/bistro-hd is the one that I was looking for.
It’s worth mentioning that no OTC and no OTSM means no medium presses, so no reversing or hidden modes in a blf-a6 style UI. And if you’re already modifying a Qlite driver, it’s not hard to add an OTC. So you could probably run blf-a6 if you like.
On my clicky-switch lights, I mostly run the following UIs:
I haven’t done much with clicky UIs lately though, so all of those are at least a year old. Ever since I got some nice mod-friendly e-switch lights, I’ve hardly touched anything else.
gchart, thanks for the heads-up about CandleFlicker - I will be trying it out. I’m curious to see how it compares to TK’s version.
ToyKeeper and gchart, thanks for the info and explanation about what would be involved in getting CandleMode on an ATtiny13a. This is definitely not something I am ready to tackle. (Not that I wouldn’t be thrilled if someone more knowledgable than me did it… 
)
If CandleFlicker doesn’t cut it, I’ll have to use that as an excuse to get a driver compatible with an e-switch and build a new 3000K light with Andúril.
Oops, I had forgotten all about Werner’s candleflicker code.
I gave it a try on a dev host just now to see what it’s like, and glanced over the code. It looks like we came up with completely different methods which have very different-looking results:
I’m not sure Werner’s is running at the right speed on my dev host though. It seems really slow. Looks better if I triple its UPDATE_RATE value to 450. It also doesn’t try to model the thing candles do when disturbed by an air current, where it has diminishing bounces for a while before stabilizing again. But it does really well at the thing where a candle almost goes out once in a while before going back to normal brightness… or where a candle briefly gets extra-bright. And since it isn’t slaved to the WDT, it can update at a much higher frame rate.