Yeah, TK had added Aux LVP for RGB setups. And single-color Aux had LVP if you used the blinking mode, but not a constant mode. SammysHP and I both have patches in our Anduril2 branches to hopefully squash that going forward.
A PMIC would certainly do the trick as well. I actually have a serial of illuminated tailcap boards that use a PMIC for hardware-based LVP. It seems like illuminated tailcaps are mostly a thing of the past these days though.
Oh I know about your tailcap boards, that’s where I learned about those chips gchart! Thanks for sharing those boards.
Ok, where sits the bloddy accent? Is that on purpose?
(Sorry, I haven’t read the whole thread)
Old Version: Anduríl (on i )
New Version in simple UI: Andúril (on u )
My suggestion is: Anduril2 or Anduríl2
Without a space it is the easiest way to search online specific for the new version and no accent.
or without space and accent on i.
Well, TK didn’t make the name up so if she’s going to do it right, it needs the accent:
Sorry, I shouldn’t post stuff at 2am, when I am tierred and grumpy.
Is this the only grafik for Anduril2 direkt from ToyKeeper? No full one? Or do I search wrong. Everything I find seems dated.
I found a Products list but many lamps are not listed
Sofirn SP10 Pro, Wurkkos TS21 are the ones I know. Are there more?
No problem. Before his hiatus, Lux-Perpetua put together some nice diagrams: Anduril 2 UI diagrams (generic, Lumintop, Sofirn)
There’s also TK’s text-based manual that explains some things.
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
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).
The FWAA uses an Attiny85, you need a USBasp to program it.
thank you for the education
very helpful, thank you
soooo… daunting speed bumps
I lost a set of 18650s to an anduril-flashed BLF Q8. Sub-1v all of them.
I’ll probably swap the driver instead of flashing this one, and get fet+15+1
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?
I don’t know any option that would prevent you from setting the Simple UI floor to any level you want. Strange…
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.
i think lumens are more based on current than voltage…
wle
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.
Seems to me that it should only depend on the voltage of the cell when on, not necessarily on cell condition.