Flashlight Firmware Repository

[Crux]

@LED Boatguy

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

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).

[LED_Boatguy]

@ToyKeeper

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.

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.

[Mitko]

ToyKeeper

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

Edit: The forum doesn’t seem to like raw code and is reformatting some of it incorrectly

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

[LED_Boatguy]

@Crux

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.</p

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.

[Crux]

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!

[Tom_E]

@RMM

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.

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.

[ToyKeeper]

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.

[LED_Boatguy]

@Crux

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<br>                   set_output(0,0);<br><span style="text-decoration: underline;"><em>add this</em></span>        ADCSRA &= ~(1&lt;\<7); //ADC off<br>                    // Power down as many components as possible<br>                    set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br>                    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!

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.

[ToyKeeper]

@LED Boatguy

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.

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

[LED_Boatguy]

@ToyKeeper

@LED Boatguy

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.

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

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!

[RMM]

@LED Boatguy

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.

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.

[LED_Boatguy]

@RMM

@LED Boatguy

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.

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…

[Crux]

You're welcome LED Boatguy! Glad to be of service. I don't think I'll ever part with my 87V either

I've just managed to get a 2cell driver down to 20uA in the LVP sleep mode.

10uA - ADC resistor divider, (664k total resistance) I need to do testing to verify this high resistance will be stable and noise immune.

3uA - 5V regulator,

2uA - ATtiny13A,

5uA OTC bleeder resistor (1Meg at 5V). I think driving the cap_pin low during sleep will save this 5uA.

Edit: Yep, this line saves the OTC bleeder resistor current in sleep mode, 5uA in my case.

PORTB &= ~(1 << CAP_PIN); // Set cap_pin Low

[dthoang]

@RMM

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.

I have a new angle on this. You know the difference between off-time memory and on-time memory right? What is called “medium press” here is really medium off-time. Measuring off-time is tricky and depends upon RC time constant that depends upon resistance, capacitance, and voltage. What if we compare short on-time and medium on-time instead?

1. From off, turn light on for < 1/4 second. Then off. Then on. This would count as short on-time.
2. From off, turn light on for between 1/4 second and 1/2 second. Then off. Then on. This would count as medium on-time.
3. From off, turn light on for > 1/2 second. Then off. Then on. This would count as long on-time.

This can be chained: on < 1/4 second, off, on < 1/4 second off, on would count as two short clicks.

The on-timing can be performed by the MCU accurately.

Any thoughts on this?

[ToyKeeper]

@dthoang

What if we compare short on-time and medium on-time instead?
…
This can be chained: on < 1/4 second, off, on < 1/4 second off, on would count as two short clicks.
…
Any thoughts on this?

That’s how the BLF A6 firmware enters config mode, and how some other drivers also access similar config modes or sometimes hidden modes. It’s necessary to do a bunch of short on-time taps in a row to get to the hidden modes, to reduce the chance of reaching the mode by accident.

This is also how some firmwares detect double-taps or triple-taps for other purposes, like going back instead of forward. I don’t really like doing that though, since I prefer to be able to advance forward quickly.

BTW, the memory decay trick is really useful for tracking short on-time taps. This allows it to work without writing extra data to eeprom.

[guardior]

While I’m waiting for the flasher to arrive from China I checked your repo for some code to use. After a while I found Luxdrv-0.30b and started to modify it. Very nice code for learning avr I must say, thanks DrJones. I ripped out everything I didn’t want and added a few minor tweaks. I’m not really sure about the license though? If DrJones is happy with it I stick to Public Domain, if not I’ll have to rip out some more code I guess. Not that much logic left anyway, it basically is hello world.

Here’s what I got so far: tacdrv.c - Pastebin.com

It’s only lo-mid-full-strobe so far, and easily tweaked in the code. Memory turned off by default and no run time modifications available. A few things I don’t really get, like how you tweak pwm, but perhaps DrJones already did that. I’m not really sure what driver this is meant for but I guess it should be 105c or similar.

[ToyKeeper]

@guardior

I found Luxdrv-0.30b and started to modify it. … I’m not really sure about the license though?

LuxDrv 0.30b says this for its public license: “License: Free for private and noncommercial use for members of BudgetLightForum.com and Taschenlampenforum.de”

By default, US copyright applies automatically and reserves all rights. Since LuxDrv only specifies private noncommercial use for a specific population, those are the only rights granted to us and we’re not legally allowed to do anything else with it.

So, modifying it and publishing changes is not legally allowed unless DrJones explicitly states otherwise. As far as I’m aware, he is the only person allowed to change it, publish it, sell lights with it, etc. The rest of us can only make personal private use of it. I had to ask him for permission before I could include a copy in the repository, and I do not have permission to include derivative works of it.

If I understand correctly, I think he takes licensing fairly seriously since he’s in the business of selling drivers and has commercial agreements with other vendors.

Just FYI, since you were unsure.

[chouster]

Hey driver experts!

I wonder if there’s a firmware or a driver that offers “soft transitions”. What I mean by that, is that the light will always perform a short ramp into a given mode. To really beeing able to notice this cool effect, such a light shouldn’t have many modes with a big enough gap between them. So when you turn it on, it will increase brightness to 100% or 100% of the mode it will turn on in. And when you turn it off, it will decrease brightness to 0%. And when you change modes it will perform a soft transition from one mode to another. Don’t know the time in that such a ramp should happen and if the ramp should be visually linear to make it look the coolest, but I think such a light would be awesome.

Are there lights that have such a feature?
Are there drivers or firmwares that do something like that?
If, not, is that kind of firmware even possible for 105C or BLF17DD?

Sorry, if those are some dumb questions to people that know that kind of stuff, but obviously I’m not that kind of guy…

Also, am I the only one that thinks these more or less soft transitions would be awesome?

Cheers

[Mike_C]

@chouster

Hey driver experts!Also, am I the only one that thinks these more or less soft transitions would be awesome?

No, but in my opinion it’s worthless if it’s not driver with an E-switch. With a standard tailcap switch the light has to be switched off for a brief moment to switch modes. That breaks the seamless transition to the next mode as it is. Having it smoothly ramp up or down after being entirely switched off would just feel tacky to me.

[chouster]

@Mike C

@chouster

Hey driver experts!Also, am I the only one that thinks these more or less soft transitions would be awesome?

No, but in my opinion it’s worthless if it’s not driver with an E-switch. With a standard tailcap switch the light has to be switched off for a brief moment to switch modes. That breaks the seamless transition to the next mode as it is. Having it smoothly ramp up or down after being entirely switched off would just feel tacky to me.

Yeah, I was actually thinking of an e-switch firmware without saying so, because I couldn’t even imagine that this kind of thing was also possible with a clicky light. I understand what you mean with a tacky feal, when the light is still emitting after having been switched off. But I think when it’s only half of a second and you already got used to it, than it might be a very nice effect.

How hard is it to get started with programming that kind of stuff to do things like such kind of a firmware for somebody who never programmed anything?