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…
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
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?
- From off, turn light on for < 1/4 second. Then off. Then on. This would count as short on-time.
- 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.
- 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?
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.
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.
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.
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
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?
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.
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.
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
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)
The closest examples I’m aware of are:
- Ferrero_Rocher/Ramping_UI_Table.c uses a ramping interface, where you hold the button until it gets to the level you want and then let go. The transitions are mostly smooth, but it has only 64 (or 40) discrete levels instead of 255.
- STAR has an option to smoothly ramp when the turbo step-down hits, but this only happens at a fixed length of time and the ramp is designed to be slow so nobody will be able to see it while it’s happening.
- cypreus.c uses a quick ramp-up approach on moon mode, where it tries to soft-regulate the output based on battery voltage and pulse frequency.
None of these are quite what you were describing, but maybe they could give you a starting point to work from.
IIRC, the Nitecore SENS series always ramps to the level you asked it for, but it’s proprietary and uses an accelerometer instead of a button. It won’t ramp down to off, either, since it shuts off by breaking power.
A fool is the one talking BEFORE thinking. 
I’ve been using open source for more than a decade and out of all code I’ve ever found on the net 99.99% has been open source or Public Domain. What DrJones has written in the beginning of luxdrv-0.30b is something like Creative Commons. CC is very very rarely used for code and is not even considered to hold up in court in most civilised countries as you usually should sign a license agreement (yeah I know almost noone reads them :laughing: or NDA for closed source to apply. But as I said I’ll remove lines that DrJones consider as closed source.
Don't take what I said the wrong way. :) If you would like to use it why not ask?
As bugsy suggested, you’ll have to ask DrJones since no one else can speak for him and the license does not grant permission by default.
About explicitly open code, not all people who contributed code care about licenses so I’ve tried to fill in the blanks as best as I can. Here are some of the details:
- All original flavors of STAR: JonnyC basically granted permission to do anything anyone wants with it (see STAR/README.md). This has resulted in most of the open code being based on STAR.
- STAR derivatives: These are less clear since the parent license allows for open derivatives but does not require them to be open. I’ve done a lot of guessing based on the apparent intent of the authors, but would prefer if the licenses were more explicit.
- My firmwares are explicitly GPLv3 licensed, except for some which I haven’t put the license on yet (but that is the plan so feel free to treat them as if they’re already explicitly open). GPL is basically “do whatever you want, as long as you re-share the code and the rights with anyone who wants them”.
- alexvh/* : GPLv2 license
- Tamagotchi/* uses the GPL, but I’m not totally sure its authors understand what that means and I think it only works on modded nanjg drivers.
Some others are public domain, I think, but it could take a while to verify that.
My preference is to use GPL or GPL-style licenses, since it clearly answers the licensing question for both the original project and all its derivatives, and the answer is “yes, it’s open”.
So Star is Public Domain, I guess. Thing is, when I started learning I took luxdrv-030b because it’s so small, Star is quite big, and well commented by DrJones. It really is a good avr hello world. And should imho be put in the public domain. But I’ll take a look on Star too now as the code already is public domain.
Awesome, now it’s CC-BY-NC-SA. That’s a big improvement in terms of both permissions and clarity. Good things can come from asking.