Flashlight Firmware Repository

Hey there.

I’m using TK’s BLF-A6 firmware wherever I can so I can get familiar with at least one program. It worked great with Wight’s FET + 1 (using both channels). I fine-tuned it with Battcheck. Offtime didn’t need any tinkering as it was right on even though it doesn’t have a pull-down resistor. I found where it checks for memory, and set it to on. I gassed everything in the hidden mode, save for battcheck. I didn’t test parasitic drain after LVP shutdown.

Then I installed it on Wight’s 22mm 16X1735 single-channel driver. The only thing I had to change was to put battcheck on the first PWM channel and put values on the lower main levels as they were zeroes. It was reassuring that the battcheck firmware blinked out values within 1 of the FET + 1 driver from 4.2 down to 2.7 volts on the Fluke.

I have a couple questions:

I had a hell of a time with offtime medium presses on the 22mm 16X driver. I started at 470K on the pulldown resistor. I ended up using 910K, and medium presses were still too quick. So I loaded TKs Offtime_Cap firmware. A fast press gave me the expected 255, and medium presses gave me values of 156, 144, 148 and 140. The firmware was set to 190, so I changed it to 140, and everything is working. Given the values I got, was 140 the correct value to enter? Should I have entered a lower number to capture longer presses? How low can I go and still recognize the 156 press?

Next, I tested the LVP. Everything went fine, with the light throttling at 2.8 volts and going dark at ~2.75 volts. With the light dark (but still on), I put the Fluke on amps, and measured 270uA coming from the battery. That seems high, as the 13A’s datasheet shows the draw at 190uA when active, and 24uA when idle. Is there a way to get this 270uA down? Maybe the unused second PWM channel is doing something?

Thanks

I tried the medium press thing, including several different OTC values, and just can't get into it. If it's not on a momentary switch I don't want medium presses because I can't consistently do it without some sort of feedback. It's also a pain to get things consistent between different drivers and parts. I can see someone doing it for that "one light" they use a lot and become really accustomed to, but for lots of lights it's a huge pain in the butt. It's a cool idea, but just not one that in practice I really like. Of course, that's just my opinion, and everyone else is entitled to theirs.

~200uA is about par for the course if the attiny isn't sleeping, plus you've got the voltage divider draining a few uA no matter what, and probably the pulldown resistor putting a drain on things if the MCU isn't going to sleep.

That’s me and moon mode and/or a bazillion levels. Just give me 3-4 well-spaced levels—like mode2 in the A6 firmware.

I didn’t care about medium presses either until TK came out with on-board battcheck, which is accessed with a medium press. Battcheck is a really nice feature IMHO.

Edit:

I sure can see where setting up drivers for medium presses in a production environment would suck. Get the OTC/pull-down resistor (if applicable) close, flash offtime-cap, get the right number, program it in, flash battcheck, verify the numbers, modify the c file, compile the hex file, flash, test. Tedious to be sure, but what you end up with is a means to access hidden modes and useful features like battcheck, bike strobe, etc.

Do you suppose there is a need out there that I can fill?

Sorry, I don’t really do hardware. :slight_smile:
(and this was already answered above)

Yes.

I actually did this already in my “cypreus” firmware, only it uses the technique to pseudo-regulate moon mode instead of turbo… and it uses PFM instead of PWM. But the basic method is still roughly the same. Feel free to try it, modify it, etc.

I haven’t actually tested STAR much, only the derivatives I’ve made. It sounds like the MCU is getting useful voltage readings, but either the power supply or the firmware is doing something unexpected.

It was already mentioned, but for LVP tests I have to leave the amps cranked up to force CV mode instead of CC mode. I’ve never had any issues getting results this way, so I get the impression it’s more likely the firmware… especially since the batteries behaved strangely.

Also, it was brought to my attention today that I forgot to tag projects with LVP to make them easier to find. So, in the near future I’m hoping to go through each project and actually test the LVP so I can tag the ones where it works. It might take a little while though…

I also had the amps high enough to be in constant voltage. On my second try I used blf-a6 instead of STAR and ended up with the same result: LVP kicks in at 8v, but not 6v.

This is a strange one... Some backgrond first. The battcheck numbers look good but a little low, are you measuring voltage at the power supply or at the driver? Does the LVP ever kick in? Do different modes affect the LVP? Is this a zener mod? Is there a cap across the zener (Vcc to GND)?

Gotta run be back tonight.

It is a zener mod. The LVP never activates when it is running off the power supply. I have measured voltage both at the driver and the power supply. No cap on the zener.

What do you mean by kicks in at 8V but not at 6V?! That seems counter-intuitive.

Do I also understand that the LVP always kicks in on batteries, but never on the power supply?

What the heck is going on?

Have you tried running battcheck with the batteries rather than the supply?

To me it seems there may be a bad connection that causes the LVP to see a low voltage, perhaps only during heavy load. (I'm grasping at straws here...)

I’m away for the weekend so I can’t do more tests right now, but yes.

I ran it off the power supply, and slowly decreased voltage from 6.5v down to 5.5v and let it run there for a couple minutes. LVP never kicked in.

I put in 2 batteries, at 4v each, and within seconds it started ramping.

Those OTC values look totally fine… it’s actually in the desired range, while the BLF A6 driver I have is unusually high. It sounds like 140 should work if that gives you the timing you want, but I’d probably go lower. The way I measure it is to half-press for about half a second, check the value, and use that for CAP_SHORT. Then I’ll half-press for about 1.5 to 2.0 seconds, check the value, and use that for CAP_MED. This gives me a reasonably wide window for medium presses so I can count “one one-thousand” in my head and let go and reliably get the medium press action.

The CAP_* #defines are the edge boundaries, not the center of the target. Any value above CAP_SHORT is a short press. Any value between CAP_SHORT and CAP_MED is a medium press. Anything below CAP_MED is a long press. So, if I understand correctly you might want to set CAP_SHORT to ~180 and CAP_MED to ~120 to increase the error margin. On a nanjg with OTC, I use 200 and 100. Your values of 140 to 156 fall right in the middle, which is a good thing.

As for post-LVP power usage, I’m not sure. I thought it would be lower than that since the code invokes power-down mode, but it sounds like RMM knows more about this and you should listen to him. :slight_smile:

Ok nice, interesting i might do that if i ever get around to start flashing my own attiny’s that is :slight_smile:

Yes 270uA does seem high, make sure you're testing it with your Fluke correctly. Connect ammeter to measure current. Set the Fluke to uA scale but place a jumper across the meter inputs (this shunts all the current around the meter), turn power supply ON and reduce voltage to the point where LVP kicks in. When the light goes out remove the jumper from the meter input (do this carefully so as not to open the circuit) and you will be reading "OFF state" current.

The ATtiny should be in 'power down' sleep and drawing only 1 or 2 uA, the ADC voltage divider however will still be drawing 103 uA. (2.75V / (22,000ohms+4,700ohms) = 103uA) If you're still reading 270uA look for another problem. Perhaps the ATtiny isn't sleeping.

For zener mods OFF state current can be 6,000uA! (assuming 6.2V battery, 5V zener and 200 ohm resistor).

Thanks TK. That was exactly what I was looking for. I’ve been building driver boards (from scratch until now) for over 10 years, but this flashing thing is relatively new to me. I’m getting the hang of it though.

I modified the USBasp to SOIC clip ribbon with a DIP switch, so I don’t have to unclip to test every modification.

The board/switch combo weighs all of 2.3 grams, and doesn’t add any length to the ribbon. I used this adapter board from Osh, and this DIP switch from Digikey. Sucker works like a champ.

I’ll finish it off by locking the ribbon in place with regular epoxy mixed with micro balloons (to make it thicker and lighter). That way the ribbon can’t flex at the solder joint.

ToyKeeper
:beer:
Just tested it( STAR-1mode), working as intedned- at 3.2v it start ramping down with every step it lower the ouput twice, and after 6 blinks it cutts of the emitter totaly at 2.8 v
G R E A T

Exacly what we needed

Can the TURBO option be removed? at 100% all time till it reaches 3.2v without step-down to about half power ?

That would be the best rifle mount STAR firmware awailable i think- most of my frieds here always want 1 mode- max

Indeed, every time i try compile C file it gives me either memory overflow or Error 0x000 000 or anything else …well, not everyone here understands C - and you have to learn it to maintain it
Like not everybody is an alpinist, miner, engineer or baker or whatever others are

Tnaks why we have Toykeeper and other coders! :bigsmile:

PS
On second thoughs the turbo might be needed if you forget your light on…yes, actualy its the best this way

Thanks again for your effords! Could be definately called the gun mount STAR firmware :slight_smile:

I can’t find this procedure documented anywhere, but I tried it with a 12ga jumper. Same thing—268uA with the jumper removed.

I don’t test LVP with my PS as I don’t believe it mimics a discharged battery well, e.g., the PS doesn’t rebound like a battery would after the light output drops, and I sometimes get erratic (crazy even) behavior from the driver. I use a sacrificial POS Trustfire 18650 that I keep around just for this purpose. I keep it at ~3.5V and use it to test my LVP settings.

I think I found the problem. Check in the source code to make sure the ADC is turned OFF before entering sleep mode. I added the following line to the TK_OTC derivative of BLF-A6 code, it looks like this:

// Turn off the light
set_output(0,0);
add this ADCSRA &= ~(1<<7); //ADC off
// Power down as many components as possible
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

Not sure what code you're using, so it may not look like this.

As far as the current measuring procedure, all we're doing is inserting the low current ammeter into the circuit without breaking the circuit. The series resistance of the low current ammeter is several ohms and won't allow high currents to pass without a large voltage drop. Also typical meters may break the circuit when switching between ranges. But you mentioned Fluke, which model do you have? It may allow you to switch between the mA/A range and the uA range without breaking the circuit, in which case you may not need the jumper, just switch between high and low ranges.

EDIT: read the forth post in this thread: http://www.microchip.com/forums/m525424.aspx

Hope this helps!

I hear you - I love the UI of an e-switch over this medium press UI. The e-switch click and hold options are easy, and easy to explain, easy for beginners to pick-up. I simply could not get the medium press working on a C_K driver, finally gave up on it. Worked out much better though on a wight driver, but still, it's somewhat awkward. Most beginners have trouble figuring out the 1/2 press thing anyway, even I struggle with it at times, depending on the switch. However with that said, the medium press thing for a power switch is truly innovative, and pretty ingenius of TK. I'm not gonna abandon it just yet - I do like it in my triple BLF X6. I think if you have a switch that's easy to do 1/2 clicks with, and you get the timing just right, it's pretty cool.

FWIW, I updated bin/level_calc.py to support dual PWM drivers, and to make it friendlier to being used in Windows… though I don’t actually have Windows so I haven’t tried that yet.

It accepts parameters either on the command line or as interactive questions. Here’s an example session where I asked it to estimate the PWM levels for the BLF EE A6 light. The FET channel ranges from about 15 lumens to 1300 lumens, on an average battery… while the 1x7135 channel goes from about 0.25 to 140 lumens. I asked it to give me seven evenly-spaced modes covering the entire range:

> ./level_calc.py
How many total levels do you want? (4) 7
Lowest visible PWM level, for moon mode: (6) 1
How bright is moon mode, in lumens? (0.25) 15
How bright is the highest level, in lumens? (1000) 1300
Use dual PWM? [y/n] (n) y
Second channel, lowest visible PWM level: (6) 4
Second channel, how bright is the lowest mode, in lumens? (0.25) 0.25
Second channel, how bright is maximum, in lumens? (140) 140
1: visually 0.63 (0.25 lm): 0.00/255, 4.00/255
2: visually 2.34 (12.88 lm): 0.00/255, 26.68/255
3: visually 4.06 (66.82 lm): 0.00/255, 123.57/255
4: visually 5.77 (192.29 lm): 8.37/255, 255.00/255
5: visually 7.49 (419.51 lm): 53.28/255, 255.00/255
6: visually 9.20 (778.67 lm): 124.28/255, 255.00/255
7: visually 10.91 (1300.00 lm): 255.00/255, 0.00/255
PWM1/FET  values: 0,0,0,8,53,124,255
PWM2/7135 values: 4,27,124,255,255,255,0
On a non-FET driver, the last mode should be 255 on both channels.
Press Enter to exit:

(the same calculations can be done minus the interactive prompts, by running “level_calc.py 7 1 15 1300 y 4 0.25 140”)

The results are fairly close to what I ended up with after manual tweaking with the help of a light box:

  • PWM1: 0,0,0,6,56,135,255
  • PWM2: 3,20,100,255,255,255,0

Moon mode here is a bit off because the real thing uses phase-correct PWM instead of fast PWM, so that’s expected. The other “off” values are because the tool uses a linear estimate but the actual hardware isn’t quite linear. And also because I think I manually changed the values a bit and probably had some measurement error. But overall, this at least gives a pretty good ballpark estimate to start from.

I hope this will help people who want to get visually-linear mode spacing, both on regular drivers and dual-channel drivers. Those dual-PWM drivers can be a little tricky.

That did it re: sleep mode parasitic draw. I added ADCSRA &= ~(1<<7); //ADC off (the rest of the stuff was already there) and the sleep draw went from ~270uA to 125.4uA.

Thank you.

I’m pretty sure I can switch from mA to uA without breaking the circuit. If I intentionally break the circuit, the light goes into moon mode (or just the lowest mode). If I switch from mA to Ua and back, the readings stay the same (save for some decimal points and accuracy). I gave up almost all of my good test stuff when I sold the business, but I kept a Fluke 87V True RMS DMM.

I’ll read that post you alluded to a little later. I warmed up solder paste, so I need to make a couple boards. I’m gonna do a FET shootout to see if that SIR800DP-T1-GE3CT FET is really any better than the ones that are half the price.