Hello, I wanted just to ask how to update brz branch? Because now every time I want to make new build I have to remove folder and download everything again .-.
Would it be possible to add a turbo level config setting ? As well as an UI config menu for it ?
If I havenât missed anything, currently to reduce the max current/output in firmware the ramp has to be recalculated or clipped. With no option for the user to adjust the max output in the UI.
Iâm thinking especially for my HDR constant current drivers, it is simpler to use one combination of components that gives the max current the hardware is capable, then decrease in software if needed (too much for the LED and/or lower/longer turbo desired), instead of adjusting the components (which requires remaking the ramp anyway). But the ramp calculation is not exactly straightforward with the dual sense and dynamic VREF (DAC), an option to set the max level would be much simpler.
That said I actually wanted that feature before knowing how to flash or make drivers because to me with multi emitter direct drive lights I find the turbo too powerful and too short and I would have liked a turbo setting in the UI.
So a turbo level, but not at compile time? What's the range? up to 255 or higher? 255 clicks? 3 digit entry? Does the max ramp have to be configurable as well? Guess you could count click down from 255 if you are still using 8 bit values?
I mean a .cfg option ( is that âcompile timeâ ? ) and UI option, just like the ceiling and floor settings.
Ramp level would be much simpler than PWM level, just look up the ramp table and find the closest ramp level for the desired current, example in my 6A buck driver ramp right now 5A is ramp level 145 and 4A is level 140, 6 or 11 clicks.
Some of what you said is a little over my head, but I think the latest builds of Anduril 2 can sort of already do that. Thereâs a âturbo styleâ configuration option now. Per the anduril 2 manual:
- No turbo, only ceiling
- Anduril 1 style. Ramp -> 2C goes to full power.
- Anduril 2 style. Ramp -> 2C goes to ceiling, or goes to full power if user ramped up to ceiling first.
This value also affects momentary turbo in Ramp and Off modes.
So that that allows you to do is completely disable turbo and only have ramp ceiling, which is a value you can adjust so itâs basically the same as what youâre asking, if Iâm reading correctly.
Not at all since there is no turbo functionality anymore.
I see. Can you elaborate on what you mean by âturbo functionalityâ? What functionality would be lost if you disabled turbo and set your ramp ceiling to the level you want, for example?
Sounds good, except that a permanent reduction of the highest level via ramp config reduces the number and thus the resolution of the remaining available levels compared to an updated ramp table. I think this will be more useful when the ramp table is calculated during runtime.
It doesnât affect momentary turbo, only how 2C is interpreted.
Yes - cfg option is compile time, vs UI configuration setting (runtime).
All depends. The entire ramping table is configurable at compile time, including min, max, turbo, etc. To me it never made much sense cutting the ramping table's top off by setting top of ramp to a ramp table index. For example, you gen a ramping table of 150 positions, but set top of ramp to 120, turbo to 150. So the positions of 121 to 149 are never used - doesn't make sense. Would be better to gen the ramp table to the output levels of the full ramp - 150 positions from start of ramp level to top of ramp level, then turbo just become an output level - that's all. You've maximized the range then. I only used 150 because I wanted full ramping done in 2.4 secs, 150 x 16 msecs = 2.4 secs, where 16 msecs is the timer interrupt frequency. If you cut the ramping by 20%, then you reduce the ramping time to 1.92 secs - ok if you want that, but not what was intended.
The ramping table is created by a Python script that is very flexible. You are supposed to set params matching approx. lumens to levels - it works very well, written by Tk of course.
That line is actually part of the direct quote from the Anduril 2 manual on Toykeeperâs website. I also just confirmed with my D4V2 and lumen tube that it does also govern momentary turbo.
True but at the top of the ramp itâs not a lot of levels that are lost for a relatively larger output reduction, in my example itâs 10 levels for â33% output.
Ah yes I donât always know the right terms 
Well you can generate a table with more levels to get the the 2.4s ramp no ?
The python script is a great tool but it would need to be updated to support 2 ranges in one line for the dual sense resistors, and for the VREF switching. That said Gchart made a calculator in a spreadsheet.
Ceiling/turbo differentiation is lost.
Indeed! This feels more like a bug and regression because before ToyKeeper has introduced the runtime option, off+2H / on+3H was always 150/150. Now off+2H is MAX_LEVEL except turbo was disabled and on+3H depends an the configuration and current level - it does the same as on+2C, just temporarily.
Positions 121 to 149 are used though, when the light ramps down from turbo for thermal regulation. In Loneoceanâs buck driver that is being used in the recent FireFlies lights, level 149 is the highest (6A) regulated level and 150 is turbo. When these lights ramp down from turbo for thermal regulation, they immediately jump from turbo level to the max regulated level. This means you only get a few seconds of full output and then an immediate cut to 6A.
I preferred the old way too. In the original Anduril 2, 2C from off/on gives you top of ramp and 2H from off/3H from on would always give you full turbo. This was a great system because you always had immediate access to top of ramp as well as full turbo. I like the option to switch turbo style because I know people have different preferences on how they want 2C to operate, but I wish 2H/3H had been left as-is.
I disagree. You can still get the exact functionality you described by configuring the turbo style as always level 150. What TK did was ADD the option to cap brightness at the ramp ceiling.
That eliminates the possibility of having 2C go to top of ramp and 2H/3H go to full turbo, which was the original behavior when Anduril 2 first became available.
I was unclear. The behavior youâre describing is also still an option. There are more details in the Anduril 2 manual on TKâs website if you search âturbo styleâ. There are three options:
Full turbo via 2H from off, 2C from on, or 3H from on.
Full turbo via 2H from off, 3H from on, or 2C from top of ramp, but 2C from off or 2C from on (except at top of ramp) goes to top of ramp. This is the original Anduril 2 behavior youâre describing.
Ramp ceiling via 2H from off, 2C from on, or 3H from on.
Thanks. I was unclear if this was the case because in the manual it does specifically state that the turbo style also affects momentary turbo.
In the current implementation it works differently. 2H from off goes to ceiling in mode 0 and to MAX_LEVEL in mode 1 and 2.
But from on it is different:
- Mode 0: ceiling
- Mode 1: MAX_LEVEL
- Mode 2: If current level == ceiling to MAX_LEVEL, otherwise to ceiling (same behavior as 2C)
Hmm, itâs odd that in mode 2, 2H from off would go to MAX_LEVEL but 3H from on goes to ceiling when 2C is already a shortcut to ceiling.
Iâm not sure if this is the right place to suggest improvements, but I have a couple of features Iâd like added if possible:
- Please allow lower moonlight modes in the tint-ramp firmware even if it means losing resolution (i.e. just having one set of LEDs on).
- When doing a 4H to exit lockout mode, it would be really nice if it could start ramping up like when you do a 1H from off.