Flashlight Firmware Repository

Flashlight Modding and DIY Parts
85

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!

86

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.

87

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.

88

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.

89

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

90

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:

91

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.

92

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ā€¦

93

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

94

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?

95

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.

96

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. :slight_smile: 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. :slight_smile: Iā€™m not really sure what driver this is meant for but I guess it should be 105c or similar.

97

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.

98

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

99

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.

100

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?

101

Impossible to answer, everyone is different, but what I can say is that the kind of programming used here is probably amongst the easiest. Itā€™s pretty straight forward.

Before I got into this stuff I had done a little C programming many years ago, so I canā€™t give you the perspective of a total beginner. I already knew what variables, integers, arrays, definitions and all that stuff was. It was so long ago that I canā€™t remember how long it took me to get my head around it. When my interest in programming flashlights started I just had to brush up on the actual programming syntax. Then I started analyzing the Star firmware and started making changes to it, checking the datasheets to understand exactly what every line of code did, and then finally writing my own.

Edit: I should point out that reading the datasheets for the MCU is not necessary for ramping and general flashlight behavior modifying. You only need to start looking at datasheets if youā€™re going to start using different pins for everything or other major changes to the way the MCU is does things.

102

So luxdrv-0.30b is basically closed source, even though the code is published in the open?! Do there exist any Public Domain driver? Star? Or possibly open source? Anyway, If DrJones is not happy with me borrowing a few lines of code from luxdrv-0.30b and release it as PD I will happily remove those lines he/she thinks are closed source.

103

Not hard but there are two parts to it.

Part 1, Flashing: The easiest. Mainly a hardware thing and pushing a button.

Part 2, Coding: A little more difficult BUT actually written in layman's ENGLISH. The key is understanding how to read code, and by NO means am I an expert. All code starts with (in layman's terms) "Definitions" that are always at the top of the code. Below that you will see "Actions or Commands", of with words like "if" "and" "or" "while" etc. and values (numbers) that set parameters.

If you start out by reading the simplest of code (ask TK to point you in that direction) and then start seeing the differences with the more advanced code (all while knowing in advance what the actual code does) then you will start to pick it up. The hardest part of it all - READING. Very far from the sports page but just as interesting once you get the hang of it :) I have been too busy with too many other project to devote the time to read and learn but if you have a desire to do it is worth it.

The hardest time is the first time. After that it is easy (no matter what it is) LOL

104

That question should be posed to Dr.Jones. None of us can answer that and you should NOT assume what his position is either way. If the Doc is opposed and you do not ask that just shows disrespect AND if he is not opposed you just shorted yourself and others.

I also own a graphic design and sign business. Copyright is what we have to protect us BUT there are many things that as long as we are asked we do not care. We tend to get upset when someone takes something we worked hard to produce without asking and makes a million or is worth a million and in turn makes it worthless.

Here is another phrase (I have lots of them).....It is the fool that does not ask. And just FYI if it wasn't for asking TK we would not have the fantastic A6 code or even Wight's +1 7135 driver (which I do not have further info about yet)