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?
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.
Got version 6.2 installed - no other changes - it now compiles to 1000 bytes
Good News! I think in the beginning, someone posted having probs with 6.0, so most people stuck with the older 5.x tools, but I quickly found the problem and fixed it - some compiler directive, or mnemonic that luxdrv had in it, I think.
Thinking of implementing a lock-out like this in my e-switch firmware for the 25/45/85. This is from a review on the Sunwayman C15A:
Lock out:
The flashlight should be more than seven seconds off, press 1 click and maintain a second click (short flashing) the flashlight will be locked. To unlock, do the same.
Not sure if it's the best way, but I got a couple of side switch lights that don't have lock-out threaded connections, so something like this might just work. Richard's SupFire M2-Z is one example. Dunno bout that 7 second delay though - seems odd.
FWIW, the way I did locking on Ferrero_Rocher/Baton.c is:
- Start with the light off.
- Hold the button for 3 seconds. Light will enter moon mode, then turn off. This indicates that it is locked.
- To unlock later, hold the button again for 3+ seconds. Light will then enter last-used mode.
I haven’t used it much on a real light though… simply copied the UI from the popular Baton series.
That's another way, just that if the button was stuck on, it would go to last mode? I really dunno what is better. I think the quick click to hold might not be so easily reproduced in a pocket or bag. I know my F6 had gone on in my pocket sometimes when I forget to lock it out.
You know that F6 is simply an awesome light! I got the Convoy (2nd version) and drilled a hole in an indent next to the switch and mounted a light pipe (tube) in there now. Works really well - on the nightstand it's a clear low green glow - bout perfect. Didn't know the light is the exact match/copy of the Sunwayman C15A (https://budgetlightforum.com/t/-/18681), just the C15A is a small tube for an AA/14500 cell. The C15A's switch looks better. Actually I might buy one from ILLUMN if I can get a good deal - they've been great before. He's got them marked down to $33 now (illumn.com/sunwayman-c15a), hoping the F6 driver will fit, and swap the LED. I have a T5-5D3 LED in my F6 and it's just a perfect milky white, at least to these ol eyes. I want to add a 2nd light pipe towards the rear, in another indent - it would be closer to the color LED's and should be even brighter. This light works so well with a SANYO GA cell - not as quickly burning hot as with a higher amp cell.
I’d love to see a picture of that, sounds very cool.
I'll have to take some pics of it...
Edit: Post #236 here: https://budgetlightforum.com/t/-/26078 has the pics.
Thanks Tom. Really neat looking that is. 
Toykeeper,
I only just how had a chance to look over your BLFA6 UI. That is really great. It adds a whole new dimension to the open source pool for sure. I can hardly wait to start playing around with it.
Thanks again.
Hi, just wanted to mention that the code repo now has some attiny25 tools and firmwares. It’s only a small amount so far, but it’s a start.
TK, I was still puzzled by the much lower than advertised PWM frequencies we see (and hear) on the BLF A6 and re-flashed Nanjg drivers.
I get 13 kHz - 14 kHz, as opposed to the expected 18.75 kHz.
The delay_loop_2 function that is supposed to take 4 CPU cycles is also way off, as you probably noticed.
I stumbled across this document:
There is also this in 17.3 of the data sheet:
It seems the specified 10% clock accuracy is only valid if using the default 9.6 MHz internal oscillator (and at 25 C and at 3 Vcc).
Maybe I am just late to the party, otherwise I hope this bit of info is helpful.
A fix, without getting into the user calibration procedure, would be to manually write the 4.8 MHz calibration data (it is there, just not used) to the calibration register.
Personally I decided to run at 9.6/8, phase-correct PWM only (2.352 KHz). Any higher and the PWM signal turns ugly on an oscilloscope. Probably not a good option if you want to avoid noise with a high-current driver. Also slightly higher MCU power consumption.
PS. Your s7.c firmware got me started in this. Thank you 
!
Hi TK,
Thanks for this thread and the work. I was wondering if you might include Tido’s work in the repository (or maybe it’s there and I missed it), the BLF-VLD:
Jim
I didn’t have that in the repo, but it’s included now.
I’m not sure how I missed that one. It looks like it’s pretty decent, has some interesting tricks, and is free under the GPL.