Nice. I check with Hank pogo if I can do the same
Yes
Hankās flasher is a USBASP, afaik it canāt do UDPI flashing.
Ah okā¦ I have to try with gchart pogo
Just another idea, how about you enter strobe mode first, then use 5C to activate momentary mode? Then you can hand the flashlight to anyone and they can hold down the button for strobe without any chance of changing any settings.
I am going to try it!
Does it only leave the strobe? Or also normal light.
They preferred the non-Anduril models, because they could turn on, turn off and set the strobe mode.
The adults ones to have the strobe I had to put them in advanced UI but as getting into that mode was a 3H so trying it they end up in another mode
I spent the night route resetting the flashlights, in the end I wore anduril and they ended the summer with flashlights from the Chinese bazaar, I did not count it before because of health problems.
I would like to prepare them for the next trip, we are about 10 between brothers, sons and nephews.
We had a great time in the bush at night!
I think a Basic UI mode, just ramp and strobe would be ideal, now in Basic UI there is voltage control and other things that have no use, they are things for advanced UI.
In basic UI 3C is to check battery I would set the strobe mode.
Just an input of what happened personally.
Thank you.
Moved from the interesting discussion in the Wurkkos TS26 thread
Just have to say I love this exploratory discussion! Even if various ideas are impractical or wonāt with, itās great to see them discussed from everyone.
Now that I pre-emptively excused the interjection of my novice thoughtsā¦ feel free to be as brief as possible, I donāt mind homework
Why only in the medium-high part of the ramp? I assume because weāre talking about voltage-based sag from high current draws?
What causes the sag at medium-low ramp levels? Am I wrong to think at output/current levels, voltage drops less and thus the measurable battery voltage would be more correlated with the drop in output, and thus correctable by a LUT?
Thermal regulation as output regulation a pretty wild idea. It works on high output levels because the thermal target is reached quickly, then Anduril utilizes their PID controller to try and match the target (much better than manufacturers I might add which have nasty underdamped swings in output).
I would love to see someone try this on a fork as so many lights have the same steady-state output for the highest several modes. The temperature targets could just be defined by deltas beneath the current max temperature threshold.
As for medium-low modes, there is some period of time ramping up before thermal steady state, so it doesnāt seem like it would really work? It depends on many factors, some from the flashlight (starting temperature, surface area, thermal mass, and other heat dissipation factors, emitter efficiency, etc) to environment (temperature, airflow, humidity, thermal mass of environment, etc). But many scenarios and targets it will just never reach the thermal target. It would be odd for the output level depend on environmental factors, but I suppose itās not that much worse than the output depending on the battery level.
I suppose for non-low levels that are likely to hit a steady state, it could start at a pre-defined level and then transition to thermal-based regulation.
The bottom half of the ramp is regulatedā¦ so it doesnāt need any fancy tricks to keep the output steady. The ā+1ā part of the FET+1 driver is a regulator.
The top of the ramp is direct-drive, so it couldnāt regulate even if it triedā¦ because it canāt go over 100% duty cycle.
That leaves only the range from the middle to the topā¦ and neither edge of that range can really benefit from fancy tricks. Itās mostly just the middle of that range where thereās some wiggle room.
ā¦ and at those levels, it already does some tricks. It gradually increases the duty cycle as output sags, to maintain a steady temperature. And this temperature regulation has the side effect of keeping brightness reasonably close to the same level too.
Dāoh, I even quoted the āFET+1ā part. What about fully direct FET drivers without the regulator?
That is awesome that Anduril already has that logic. Looking back at reviews where I saw sagging on medium outputs, it was on lights running old versions of anduril (IF25A, TS21) which I assume didnāt have this logic right when they were reviewed. Newer lights / firmwares do look like are much flatter, though no one really tests lower modes.
For anyone curious about tweaking the logic or thermal regulation damping it looks like it is here.
Thinking more about different thermal ceilings per output level as output regulation to avoid the same steady-state output level makes it more and more nonsensical. Switching between modes wouldnāt have immediate user feedback. And if you want a lower mode you can always just lower output levels until you see a visual change. It was an interesting thought experiment, and it also it it doesnāt look too intimidating to add that logic as the TH_CEIL looks nicely encapsulated to adc.c.
I donāt think there are any of those in Andurilās supported hardware. I used some in like 2014, but FET-only lights seem to be uncommon lately.
I even implemented variable pulse frequency modulation for moon mode on a FET-only light, in an attempt to make moon keep a stable brightness at different battery voltagesā¦ but even with pretty extreme adjustments, it still sagged quite a lot.
Something similar could probably be done at non-moon levels, but there arenāt any supported lights with that type of driver so there hasnāt been any reason to try.
Wurkkos TS25 and TS11 are the only current ones IIRC.
I recently acquired a BLF GT, and Iām trying to flash anduril to it.
Unfortunately, itās failing to flash the fuses. Am I missing something? Do I need to flash the fuses before flashing the firmware?
Shouldnāt be any need to change the fuses, messing with them is the easiest way to accidentally brick an MCU.
Gotcha. I was using the bin/flash.sh
script included in toykeepers repo, which references the bin/flash-tiny85-fuses.sh
script. Iāll comment that line and try again.
Stumbled across some felt like unintended behavior with 2C turbo in any style. When there is any stepdown (e.g. from thermal or voltage), 2C tries to go back up to turbo instead of returning to the last level. If you are already at a thermal/voltage limit, it happens rather quickly after initiating turbo, since thermal/voltage control is at ~2 Hz. Ran into it when testing a change to turbo style where 2C would go between 3 states (ramp ā ceil ā turbo).
I was surprised by this but had not seen any discussion on it? To most people it may just be perceived as 2C being unresponsive when in turbo as the brightness change may not perceivable. But it seems for sure that people wouldāve run into this, though you can certainly still use 1C to turn off.
Itās intentional, to kick you back up to turbo if you want to do that.
The only issue with it is when re-turboing results in instant stepdown then 2C intending to get out of turbo may then re-turbo again, but Iām not sure if thereās an easy solution everyone will be happy with there, maybe to always go back down if thereās another 2C within the same timeout as the ramp direction reversing?
Does turning the light off keep it from memorizing the stepped-down level? Then you could go back to memory by turning off, and turning it back on.
Is there any āhow to get started with hardware design for andurilā guide/info around? I have a light Iād love to replace both leds and controller for, and that definitely needs customized PCBs for both, so might as well make it andurilā¦
Not really. I think most requirements are:
- Supported microcontroller: ATtiny1616, ATtiny1634 or ATtiny85 (from most to least recommended), models from the same series with more capabilities usually can be supported as well. The DD series is still experimental.
- 1 to N channels with PWM control. Directly modulating the output or using the PWM signal as a low-pass filtered voltage is possible. In some advanced configurations it is also possible to switch between multiple sense resistors for better resolution.
- Exactly one button.
- Optional aux LEDs, either one or three channels.
- Voltage doesnāt matter, Anduril can handle most configurations (NiMH range, 1S, 2S, 3S, ā¦), just make sure to provide a usable voltage for voltage measurement (e.g. from a voltage divider because the old ATtiny cannot measure voltages higher than their reference voltage).
- To use thermal regulation, make sure the MCU is close enough to the heat source. External sensors arenāt supported yet.
Thanks, thatās a good start. I saw most modern lights using Tiny1616, so I guess that is the current go-to chip.
Iāll have a single channel, yet to decide if I want to make the light buck or linear - guess I can just low pass filter the PWM as a control voltage for the control loop.
Will be 2S LiIon, and 2 LEDs in series. Glad to hear Anduril abstracts well for multiple voltages. Lamp head is small, so the tiny will be coupled well to emitter temp either way. I didnāt even know those MCUs had internal sensors, fancy. Less components is better.