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.
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.
Just got my sc31Pro. First Andruil flashlight. This is really nice work and I appreciate it! Makes what was (e.g. the SC31B) a good light into an EXCELLENT light! Bravo! Thought the driver you did for the silver convoy C8 was a very nice improvement over the drivers that were available in budget C8s of the day. This is so much better!
Those are really interesting ideas and I’ll have to try them sometime… but for now I might stick with the old menu UI. Most menus only have 1 item, and the longest one is only 3. However, the suggested design would probably reduce code size a bit, and would encourage moving menus from “C” to “H” shortcuts… so it might be a good option. It could also give the user a way to enter a zero in a menu, without sacrificing the ability to skip a setting.
The two-stage “H” actions are interesting too, for fitting 3 options into 2 button mappings… It could be used for the the manual/automatic/hybrid memory settings. I don’t see anywhere else it would be applicable though.
Before hybrid mem, it was:
10C: Manual mem (and save current brightness)
10H: Automatic mem
While adding hybrid mem, I changed it to:
10C: Toggle manual/automatic memory (and save current brightness when enabling manual mem)
Changing it to use short/long holds (with a blink at each stage) would increase the code size a bit and introduce a new UI style which is only used in one place, but it might be worth the cost.
It’s not really a formal process… I work on it sometimes when I can. Was hoping to have it finished and merged six weeks ago, but life has been weird.
I’ve also been a bit reluctant to merge early, since it’s a major change so it probably needs a lot of testing. Also because new ideas keep coming up and it’ll be a lot easier to add them now instead of later.
I tried building Anduril2, no changes, just defaults using cfg-blf-g8.h. It's saying overflowed text region by 110 bytes. Anyone else tried to build it?
I certainly could be doing something wrong.
TK - also wondering how you are adding features and not taking things away?
I'm using AtmelStudio 7 (of course - I do Windows ) which I've used successfully before to build Anduril.
110 bytes is darn close, so I'm thinking I'm close. I'll try taking away some functionalities.
Ooops, update: building with cfg-emisar-d4 worked!! 7934 bytes used in Program Memory!!! No AUX LED support did the trick, I'm sure.
So to test Anduril2 with switch LED support on a ATTiny85 FET+1, I decided to try it on a modded Nitenumen TK35 first. The TK35 has extra long LED wires so I can re-program easily. I disabled Beacon Mode (#undef USE_BEACON_MODE) to free up enough code space to fit in under 8 KB. So far it's working well, as documented anduril-manual.txt.
Yes, the Simple UI is simple...
Couple things though:
In Simple UI, the battery check works only once instead of running continuously. I didn't expect that but probably as designed
Thought I set the version # to "11", it's blinking a whole lot more than that. Not sure what it's doing.
) which I've used successfully before to build Anduril.
