Flashlight Firmware Repository

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.

Thanks for testing that. Now I can add it to some of the firmwares by default. :slight_smile:

I just PM’d it to you. Should have known you’d be reading this. Hey: Don’t you have a job? Get to work! :wink:

I'm interested to see what you find. I found that I couldn't measure a statistically significant difference between the 4 mOhm and 2.4 mOhm FETs to the SIR; the repeatable difference was so minute that I couldn't measure it with any of the equipment that I have, which means that certainly it wasn't anywhere remotely close to a visible improvement.

I built up a Wight FET +1 board with the FET you sell and will use it to compare the same board with the same components, save for the FET, driving an XM-L2 and a 3 up XP-L mounted to an iceberg, er, my big ol heatsink. I’ll have to modify the firmware to remove the 7135 from the equation.

I gots ta know…