I think ramping is more universal. With steps, the next question is how many… then more debate and disagreement.
The problem with ramping is that you don’t know what brightness you are on, which means you then have less of an idea of expected runtime. For photographers you can’t get consistent results if you don’t know what the brightness is.
But then you do run into the age old debate of which brightness steps are best - though I like lights that have multiple options such as Biscotti. The second (from brightest) mode should in my opinion be the point at which the light can run continuously without getting excessively hot, so on a Convoy S2+ for example, that would be around 50%.
Toykeeper, is it possible to add “ramping speed” adjustment feature in Anduril2? I find standard speed too slow, and build my own, faster version (I change steps from 150 to 90), but maybe its possible to add such setting in firmware? at least 3-4 speed settings would be great.
I dont use stepped mode often, but this probably need speed adjustment feature too, especially when there is more than 3 steps.
Possible? Yes.
Happening in the Anduril 2 release? No.
Basically, the amount of work involved is rather large, and the demand for it has been very small so far… so I have no plans to do it any time soon.
The adjustments are tied to the internal hardware timer speed, which fires off at 62.5 Hz. That’s the fastest it can go, and it can only be adjusted in powers of 2… so it can’t be changed without dramatically slowing the timing of almost everything in the program. Fine-tuning it involves changing the ramp length, which then has effects on thermal regulation, and would also require recalculating the ramp shape and ramp parameters for each build target… so it’s not something which is feasible to do as a runtime config option.
The timing of ramp steps is a bit less tricky, but still not trivial to change… especially at runtime.
Thanks for clarification.
Can you point me to part in code which I can play with to change stepped ramp speed?
In Anduril2, it’s in ramp-mode.c where it handles EV_click1_hold. It currently waits HOLD_TIMEOUT timer ticks per ramp step.
Changing it may also require changing other places too, but I don’t recall where exactly. It all assumes the same duration per step, because the hold timeout is an intuitive way to do it. I didn’t define a separate duration value for stepped ramping.
Thanks. Will try shorter HOLD_TIMEOUT value. I am not that good at coding separate duration for stepped ramping.
I’d just like to comment here that, once the FET enters the mix, you don’t know any of this anyway. There’s still a lot of FET+1 Anduril out there, and once you’re past 350/380 mA, your current changes with a ton of different factors. Resistance of the total system (including battery resistance) and state of charge are the primary players along with the forward voltage of the emitters.
Question:
What do people think about replacing manual memory with hybrid memory?
This would basically be a cross between manual and automatic memory, depending on how long the light was off. If it’s off for a short time, it would use automatic memory. If it’s off for a long time, it would use the manual memory level instead. And the user would be able to configure how long this timeout is — anywhere from 0 minutes to 255 minutes.
So let’s say you configure it for a hybrid memory of 10 minutes… The first time the light is turned on each session (with 1 click), it would start at the manual memory level. Then the user could adjust the brightness and turn it on/off with automatic memory, as long as it’s never off for more than 10 minutes. But after putting the light away for a while, it would turn on next time at the manual memory level again.
It would resolve the issue of the user forgetting what level it was last used at, by making the light forget too. That way, it would be predictable without losing the ability to configure brightness for short-term use.
…
Additionally, if hybrid memory sounds like a good idea, what do you think would be the correct behavior when returning from lockout mode with “Lockout 4C -> Ramp”?
- Always use manual memory level, if enabled.
- Choose automatic or manual level based on timing, like in the “Off” mode.
…
If I add hybrid memory, it might not fit on all supported lights. On some models, it’ll be necessary to have only the older features, because there isn’t enough room. It would definitely fit on anything with a tiny1634 chip though… mostly just not on tiny85 lights which have aux LEDs and three power channels, like the MF01-Mini.
Mode memory is not something that single e-switch lights tend to excel at, though Anduril seems to manage it better than others as the ramping hold moves between brightness levels instead of a click.
I love the “hybrid memory” concept.
Using timing to determine what level it goes to seems to offer more of a choice for most users. In practice, unless the timeout for the memory is very long I think it wouldn’t matter much of the time anyway.
I think a congruent feature set supported across all lights using the same UI would be more advantageous than a hybrid memory mode that can be used only on select lights.
That said, I like the idea of it. I wouldn’t make use of it myself, I like my lights turning on at the same level every time. I don’t think it’d suit the simple UI since it’s one more thing for a user to keep track of unless it was a set default for every light, like 10 minutes, since adjusting the timeout would likely need to be done by unlocking full configuration.
If it does get added, the option to disable it on device would be nice, either via a separate button combo or have it so the timer could be set from 0-255 minutes where 0 minutes basically doesn’t allow the timer to run, if that’s a possibility.
IMO returning from a lockout state it’d make sense to revert to manual memory so there’s no confusion as to what level it’ll turn on to whenever you unlock the light.
Hybrid memory sounds appealing.
That’s a good way to do it. At 0 minutes, it’s full manual memory. Otherwise, it’s hybrid. And, of course, if manual memory isn’t enabled, it’d be fully automatic.
This should also make it smaller, and thus easier to include on more older lights.
Now pondering how to map the config options for it.
There are two variables…
- manual_memory: 0 for automatic, or 1-150 for a specific ramp level
- manual_memory_timer: 0 for fully manual, 1-255 for hybrid (up to 255 minutes of automatic memory before it goes back to manual memory level)
Before, the mapping was:
- Ramp 10C: Enable manual mem, and set it to the current ramp level
- Ramp 10H: Disable manual mem (set it to 0)
Now there’s another value to set, so I’m looking at a couple options…
- Ramp 10C:
- Enable: Enable manual (or hybrid) mem, and set it to the current ramp level.
- - or -
- Toggle: Set manual (or hybrid) mem to the current ramp level. If the ramp was already at the manual mem level, set it to 0 instead (go back to automatic mem).
- Ramp 10H:
- Blinks: Light blinks once per second while button is held. Release after N blinks to set the timer to N-1 minutes. So, 1 blink = 0 minutes (manual memory), 2 blinks = 1 minute (hybrid), 3 blinks = 2 minutes (hybrid), and so on.
- - or —
- Menu: Enter one or two values to configure the memory settings:
- Option 1: Click to set the timer value to N-1 minutes (0 to 254), or skip to leave it at the current value.
- Option 1 (alternate): Set the timer to N minutes, even if there was no click. Would always set a value, and be impossible to skip.
- Option 2 (maybe): Click to disable manual mem, or skip to leave it at the current value.
Not sure which would be better. The “Enable” and “Menu” options are the smallest in terms of ROM size, but I’m not sure if they’re the best for UI usability. A “Toggle” and “Blinks” combo works too, and avoids the need for a menu. Or there’s the option of “Toggle” plus a 1-step alternate menu.
The toggle/blinks would be easiest to set and would avoid a menu, but the menu would be consistent with Anduril’s other configuration options. This is likely something you will set once and forget about, so I think either option would be fine.
Imagine you would want to set the timeout to two hours = 120 minutes. With the 10H blink variant you would have to hold the button for two minutes (using a stopwatch to make counting easier). Pressing the button 120 times is quicker and maybe easier.
Hold+blink works for small numbers (like beacon frequency) but for everything else a menu seems to be better.
Overall I like your idea with a hybrid momentary mode. It’s similar to the autolock feature: after some time of inactivity assume that the user doesn’t know the state of the flashlight, so reset it to known defaults (or lock it).
Back to the UI: Something different not found in Anduril currently. *H to enable, *H longer to disable, *C for configuration. So to configure the timeout use 10C with a menu. 10H to enable it (with blink for feedback), holding it longer (e.g. 1s) to disable (blink again or double blink). Requires some work to make other features consistent.
Or: *C as on/off toggle with consistent feedback (e.g. 1 blink for on, 2 blinks for off). Result depends on the current state, so you can’t just *C to turn something on without checking the feedback and maybe doing it again. For configuration *H either with menu or with hold+blink.
The main problem is that there are too many features and only a single button. Grouping everything related to a specific feature seems more intuitive than one big menu, but there’s only “click” and “click+hold”. What about a hybrid approach? *C for most often used task (e.g. activation of a feature) and *H with blinking as the menu. Ramp config (changing number of steps) as an example: 7H and wait for the third blink (after 3s). Release button and press n times. This allows you to skip menu entries and saves you from waiting and counting blinks.
I’m all for it.
Where is code repository for Anduril 2? Some time ago I saw a link to it here in thread but now i can’t find it 
Found this from way back on 8/1: