Due to the variety of lights out there, it’s difficult to make a diagram that covers all situations. Some lights have no aux LEDs while others have single color aux, yet others have RGB aux. Some have one color / type of main LEDs, while others employ tint ramping. That doesn’t even cover all of the default configuration options (Turbo access sequence, etc).
Most of Sofirn’s lineup of Anduril lights have been converted to Anduril2. I think Hank (Emisar / Noctigon) as well. FireFlies, too. Sorry, it really is a lot to keep track of.
How do I connect my SP10 Pro programmer to a FWAA?
(can do soldered connections, I realize there are no flashing pads)
I would like to
get rid of the flashes in the ramp, and I would like
the new lower lows that are in the new TS10 hex file
I have reflashing working for SP10 Pro, TS10, and SC21 Pro. (all hex files and flashing hardware thanks to gchart)
all I need now is a new Hex file for FWAA, and to know where to connect the programmer wires to the FWAA. Would really appreciate a photo (I know there is one posted somewhere, but my google-fu is weak atm).
So I’ve noted a difference in the ability to configure ramp floor/ceiling levels in simple UI between my FWAA and my new FW1AA, despite the fact they both flash the same version (2020-09-27-0312). The FWAA is fully configurable, while the FW1AA will not configure Simple UI ramp floor below what I’m assuming is default 20/150, nor will it configure number of steps for stepped ramping. Advanced UI configures normally. Any ideas why the difference in behavior?
Is it possible for the MCU to read the battery voltage while the light is on? If so, to what precision?
I’m trying to think if it would be possible for the firmware to try and regulate output level on FET + 1 type lights by automatically increasing the level that is set based on battery voltage sag.
I.e. let’s say you’re on 10% PWM FET and that comes out to about 1000 lumens on a fully charged battery. Once the battery is half empty, maybe the output is only around 500 lumens, but could still easily do 2000 lumens at 100% PWM. Could we adjust in software to read the battery voltage and automatically boost the PWM duty cycle based on the voltage?
To be clear, I understand that there are limits to this, e.g. on full turbo, the output is going to sag no matter what, but it seems that it should be possible to have much more stable medium modes.
Ideally you’re right, there would a current-based feedback system that keeps the current drain at the cell constant, but I don’t think the MCU can measure current? I’m essentially using Voltage as a proxy here for current. I’m assuming there’s going to be some tuning around the specific light configuration.
The MCU could measure it across a current sense resistor, but that would require some circuit change and I’m guessing you were talking about a firmware change only.
It does measures Vin when ON, since a RGB button LED shows the battery level, you can see the LED changing color as you ramp up due to voltage sag.
I think I also mentionned this idea somewhere on the forum. Indeed it would probably require adjustment depending on the LED (s) used.
But I think we should push manufacturers to use regulated drivers instead.
In direct drive, current is highly dependent on the input voltage
Once i played with code to keep turbo “stable”. …
if ((actual_level > 130)&&(voltage < 38 )){ set_level(140);}
if ((actual_level > 130)&&(voltage < 36)){ set_level(150);}
So this could work. Part of the issue will be that fet+# drivers with lots of unregulated operation are on the way out, since 7135 is on the way out. The next issue will be space - a lot of those drivers are using ATTiny85s which are basically full with anduril
The other issue is battery variance. The FET levels vary quite a bit depending on the battery. 3.6V 50% FET on a brand new vapcell h10 is a lot different than on a nameless, 3 year old cell. Aging laptop salvage 18650 versus fresh Molicel? Etc.
This can work, but probably not so easy with Anduril. Basically what you want is current regulation with voltage sensing. For this you need a translation between voltage and current. This is the well known diagram with forward voltage, current and brightness. Often this might be approximated with a second degree polynomial. Not much magic so far. We also have to account for the temperature of the LED itself. Now put everything in a closed loop controller and there you have your constant output.
Why will it most likely not work with Anduril? Well…
AMC7135 are involved except level 150
We have PWM which will mess with the impedance of the system
Anduril has no regulation
What? No regulation? Correct. It just sets a reference output (PWM signal), without feedback. At low frequency it reduces or increases that level for thermal regulation. But the regulation of a set level is done by the rest of the driver. For this closed loop controller to work it has to run code at a higher frequency and become responsible for actual current regulation. Something that FSM, the framework of Anduril, is not designed for.
So this might possible, but means huge changes in the architecture. With such a closed loop controller we have much more capabilities. This is done in many other flashlights, but it’s not as portable. Also it will only work for a very specific LED and driver combination without changing the parameters.
The voltage sag depends on the current and the current depends on the voltage sag. Also the voltage measurement has 0.1 V noise, more or less. That in forward voltage is a very significant change in current.
