Flashlight Firmware Repository

I have a Roche F6 with a real-time green/orange/red voltage indicator, and when I run it at the highest mode (25R cell) I’ve seen it sag by half a volt. A full charge can sag into the orange range within seconds on turbo, but it recovers soon after I turn the level down.

If you’re taking the cell out before measuring its voltage, it has probably already recovered quite a bit during the seconds it takes to get the cell out. And if it’s a high-amp cell, there isn’t a lot of capacity left at 3.6V. It will sag really easily at that level, much more than it would sag when full.

During normal use, I see the indicator flicker quickly from green to orange when it’s about half full, even with a lowpass filter on the ADC readings. I can actually tell the voltage pretty well by the relative time spent at each color, since at first it blinks orange only a little but it gradually gets more orange and less green. The results tend to be pretty noisy, so on the battcheck firmware it averages quite a few samples for each readout. I wonder if you might be seeing step-down too soon due to noise instead of actual sag.

Hmm very interesting. I guess I didn’t realize it would sag that much.

Just a quite question. How difficult would it be to change BLF-A6 to work with momentary switch?

It would require a complete rewrite. Clicky switch code is structured very differently than e-switch code, and has very different requirements and techniques to make things work.

However, I’m hoping to get some bigger MCUs soon and start on a combined clicky-switch / e-switch firmware based on blf-a6.c and Ferrero_Rocher/Ramping_UI_table.c .

Ooo now that sounds interesting.

this BLF A6 driver is it possible to copy or flash it to any attiny13 IC or to any nangj 105 driver like 8*7135 or the likes ???

Yes, but you’ll need an off-time capacitor, and it won’t work properly without the second PWM channel. You’ll need to move the modes to all be on the same channel if you want to put it on a Qlite or Nanjg (it is very simple to do)

What pilotdog68 said.

Yes, sort of. BLF-A6 expects to have an offtime capacitor (which nanjg drivers don’t have), and it also would need all its modes adjusted in order to work with only one power channel. You would also have to calibrate a bunch of hardcoded values for things like voltage and button timing and PWM levels, but I include calibration tools in the firmware repository.

If you can’t modify the driver hardware, you might want to look at other firmwares tagged with “ontime” or “mem decay”. Check the INDEX file to find these tags.

This discussion originally started in the X6R thread if you want to read or respond there: KronoReview: Eagle Eye X6R
TomE was helping a ton but maybe some other people can chime in so I don’t feel like I’m pestering him too much. :slight_smile:

The the X6R is a rechargeable clicky+eswitch light with the charging circuit separate but stacked on the driver, so a driver swap is possible. The tail clicky has to be ‘on’ to complete the circuit while charging.

I am going to use STAR dual-switch, but I would like the driver to know when the charger is connected and set PWM to 0 while charging, then turn the light back on when the charger is disconnected. I figured I could use the unused pin (#3?) for this. What can the I/O pins on a 13a measure? Can I just airwire that pin to the 5v power input? I assume the actual code for this would be very simple, but I dont know how to do it.

Interesting question. I don’t have a verified answer yet, but I expect it should be easy if you find the right part to connect a wire to. :slight_smile:

I hope it can be detected as a simple “open” or “closed” circuit like the e-switch, but I’m not sure if the charging circuit will have a part which behaves that way. And it’ll be a while before I have the hardware to poke at.

At the very least, I’ll have to make sure the light can be turned off via e-switch in order to allow charging to work correctly. Or ignore the charger entirely. I had otherwise been counting on the tail switch as a power on/off control.

So i’m trying to “add memory” to STAR momentary for my X6R. I looked at STAR dual-switch and STAR momentary side-by-side in diffchecker, and I found this at the end of the DS FW that was not in the momentary FW

I tried putting that in the same place in momentary and now the firmware literally just does nothing.

Any ideas as to what I should try next?

Are you trying to make it remember after power has been disconnected, or remember after the e-switch has turned the light to “off” mode?

In the former case, adding memory will involve making it read/write the mode in eeprom. Check the “store_mode_idx” and “read_mode_idx” functions in the base STAR code. Calling store_mode_idx is the only thing which will allow it to remember the mode across power disconnects.

In the latter case, it may be a little more complicated. There’s a lot happening in parallel through interrupts, and the UI logic there is a bit fragile. The main loop isn’t likely the right place to add e-switch memory.

I was speaking of the former. Thanks, very helpful

TK, is BLF A6 LVP configured around 19.1k and 4.7k resistors?

It is calibrated for the last driver sample from Manker. The resistor values alone don’t seem to be a reliable way to get the right LVP values. You’ll probably need to actually calibrate to your individual driver with battcheck.hex (and an adjustable power supply or some math).

If you use battcheck to get a reading at a low voltage (near 3.0V) and a high voltage (near 4.2V), I can send you the hardcoded voltage values to plug in to other firmwares. I made a script to calculate those, called battcheck.py, here. To use it, edit voltage-example.txt with your measurements (only two are needed, one high and one low), then run “battcheck.py voltage-example.txt”.

This is driving me crazy. All I did was edit the LVP, OTC, and TT values in blf-a6. I’ve set AVRStudio to optimize for size, but now when I go to flash it still says it is too big. My hex file is 2,922 bytes.

Maybe someone else can try to compile it to see if it comes out smaller? What size am I shooting for?

Here is my .C file

k, take small steps. First try it with no edit changes whatsoever. Your target size for code is 1024, data is ?? - I forget, maybe 64 or 128?? You should see that final code size somewhere. The file size of the .HEX file isn't directly meaningful. You could edit the .HEX and see where the last records end - little trickier though.

@work - don't have latest 6.2 version installed here, or time to dnld projects, etc.

Ok, it compiles to 1032 bytes both before and after my changes. Does version of AVR matter? I am using version 5.1

Ohhh - I started with 6.0 and am on 6.2 now. It could the issue. Might have made optimizing improvements in newer versions. Just 8 bytes over - close

Just in case you haven’t already done so, set your build type to “Release” rather than “Debug”. That produces smaller file sizes for me.