Anduril ... 2?

344 posts / 0 new
Last post
Rayoui
Rayoui's picture
Offline
Last seen: 12 hours 44 min ago
Joined: 08/06/2019 - 00:38
Posts: 288
Location: Portland, OR

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.

SammysHP
SammysHP's picture
Offline
Last seen: 31 min 28 sec ago
Joined: 06/25/2019 - 14:35
Posts: 454
Location: Germany

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.

Man Without Shadow
Man Without Shadow's picture
Offline
Last seen: 47 min 22 sec ago
Joined: 02/20/2017 - 18:17
Posts: 458
Location: Wisconsin

name…

Eärendil?

Silmaril?

When I'm spending mony foolishly, I like to do it wi$ely...

I have all the flashlights I need, but not as many as I want...

 

0-8-15 User
Offline
Last seen: 1 day 7 hours ago
Joined: 11/25/2019 - 17:07
Posts: 54

ToyKeeper wrote:
What do people think about replacing manual memory with hybrid memory?
I’m all for it.
icpart
Offline
Last seen: 6 days 7 hours ago
Joined: 04/15/2019 - 01:13
Posts: 184
Location: Varna, Bulgaria

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 Sad

trakcon
trakcon's picture
Offline
Last seen: 3 hours 3 min ago
Joined: 01/23/2019 - 15:50
Posts: 345
icpart wrote:
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 Sad

Found this from way back on 8/1:

ToyKeeper wrote:

Code is in the anduril2 branch if anyone wants to try it: lp:~toykeeper/flashlight-firmware/anduril2
icpart
Offline
Last seen: 6 days 7 hours ago
Joined: 04/15/2019 - 01:13
Posts: 184
Location: Varna, Bulgaria

Thanks trakcon for link Thumbs Up

trakcon
trakcon's picture
Offline
Last seen: 3 hours 3 min ago
Joined: 01/23/2019 - 15:50
Posts: 345
icpart wrote:
Thanks trakcon for link Thumbs Up

You’re welcome!

how crazy is this
Offline
Last seen: 1 hour 56 min ago
Joined: 09/14/2011 - 13:24
Posts: 219
Location: Minneapolis

Thank you Toykeeper!

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!

SuzukiGS750EZ
Offline
Last seen: 4 days 19 hours ago
Joined: 09/07/2020 - 17:42
Posts: 28
Location: CT, USA

Is this in its final stage? I didn’t read through ALL the pages so I apologize if it’s been mentioned

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3

SammysHP wrote:
Something different … *H to enable, *H longer to disable, *C for configuration. … Requires some work to make other features consistent.

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.

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)
  • 10H: Configure hybrid memory timeout (menu)

But it might be nice to change it to this:

  • 10C: Manual mem (and save current brightness)
  • 10H (short): Automatic mem
  • 10H (long): Configure hybrid memory timeout (menu)

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3
SuzukiGS750EZ wrote:
Is this in its final stage?

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.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

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 cool) 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.

smile

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

Ok, now that I can dnld it, worth giv'n it a go? I gotta read up on it more - my head is spin'n... I got a E3/E3S board ready to go:  

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

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.

 

 

SammysHP
SammysHP's picture
Offline
Last seen: 31 min 28 sec ago
Joined: 06/25/2019 - 14:35
Posts: 454
Location: Germany

It blinks the model as well. This is a feature recently added to see which firmware is used on which flashlight by the manufacturers.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

Good idea! There's lots of blind copying goin on.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

I've been doing further testing (and minor modding) Anduril2 on the TK-35 light.

If I enabled START_AT_MEMORIZED_LEVEL, I ran out of code space again, so undef'ed USE_SUNSET_TIMER and that brought it down once again.

I also added a USE_2C_MAX_TURBO setting. What this setting does is always have the 2C go to max turbo, not max ceiling. But for Simple UI, works as it did before. 

Modded code snippet in ramp-mode.c below. 

TK: Not sure if you want to use it, but if you do, you have my permission:

    // 2 clicks: go to/from highest level
    else if (event == EV_2clicks) {
        // simple UI: to/from ceiling
        // full UI: to/from ceiling if mem < ceiling,
        //          or to/from turbo if mem >= ceiling
        uint8_t turbo_level;
        
        // TE 2020-09-18: Add compile switch for Making 2C the max
        #ifdef USE_2C_MAX_TURBO
        turbo_level = MAX_LEVEL;
          #ifdef USE_SIMPLE_UI
            if (simple_ui_active)
                turbo_level = mode_max;
          #endif
        #else
        if ((memorized_level < mode_max)
            #ifdef USE_SIMPLE_UI
            || simple_ui_active
            #endif
           ) { turbo_level = mode_max; }
        else { turbo_level = MAX_LEVEL; }
        #endif

        if (actual_level < turbo_level) {
            // true turbo, not the mode-specific ceiling
            set_level_and_therm_target(turbo_level);
        }
        else {
            set_level_and_therm_target(memorized_level);
        }
        #ifdef USE_SUNSET_TIMER
        timer_orig_level = actual_level;
        #endif
        return MISCHIEF_MANAGED;
    }
I have not tested it yet - will do so tomorrow.
 
This is the section of the cfg file I've added:
//---------------------------------------------------------------------------------------------
// TE - changes:
//---------------------------------------------------------------------------------------------
#undef DEFAULT_THERM_CEIL
#define DEFAULT_THERM_CEIL 60 // from 45 -> 60
#define MAX_THERM_CEIL 90 // from 70 -> 90

#define USE_2C_MAX_TURBO

// TE 2020-09-18" Take away Beacon and Sunset Timer to get the code down under 8 KB!!
#undef USE_BEACON_MODE
#undef USE_SUNSET_TIMER

// For the TK-35, enable this!
#define START_AT_MEMORIZED_LEVEL

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3
Tom E wrote:

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?

If you can find the right place to put it, the -fwhole-program flag might help. That tells it to skip all the steps which enable linking multiple object files together, and instead assume the program consists of only one .c file. I’ve written FSM and Anduril in a weird way which makes that possible, and it saves a few hundred bytes on top of the other optimization settings.

This should get the Emisar D4 (v1) build down to about 7758 bytes in the default configuration. For blf-q8, I’m getting 8110 bytes.

Or maybe it’s due to some of the other flags. Here’s my build process:

> make
...
= emisar-d4 =
../../../bin/build.sh 85 anduril -DCONFIGFILE=cfg-emisar-d4.h
avr-gcc -DCONFIGFILE=cfg-emisar-d4.h -Wall -g -Os -mmcu=attiny85 -c -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=85 -I.. -I../.. -I../../.. -fshort-enums -o anduril.o -c anduril.c
avr-gcc -Wall -g -Os -mmcu=attiny85 -fgnu89-inline -o anduril.elf anduril.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex anduril.elf anduril.hex
Program:    7758 bytes (94.7% Full)
Data:        196 bytes (38.3% Full)

But yeah, it’s definitely getting closer and closer to the point where no more can be added without overflowing. On some build targets, I’ve already had to start removing things. (mostly just MF01-Mini and ROT66)

I’m considering a major change to how the menu system works, to reduce code size and to change the interface style. Instead of waiting through each option to time out before moving on to the next, it would let the user skip directly to the desired option. Basically, just hold the button until it blinks N times, to access option number N, then let go to trigger the numeric entry prompt. The downside, is that it would only allow changing one option per invocation… and would require people to re-learn part of the UI.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3
Tom E wrote:

Couple things…

  • 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.

Yes, in simple mode it’s meant to blink out once and then exit. People don’t like getting stuck in “disco modes” (*), so it makes sure exit on its own.

However, I’m not incredibly happy with how battcheck and version check work in one-time mode (where they blink out once and then exit). There’s a bug which can sometimes eat the next button press afterward, and it’s a very difficult bug to fix since it’s deep in the state-change mechanisms. Basically, state changes are instantaneous… but they need to be put in a queue for later handling. This timing discrepancy can cause some problems depending on how the program is written, and the fix is rather a pain to implement and would increase the program size significantly. So for now, it just eats a button press sometimes after version check ends.

Anyway, about the version numbers, it recently changed to a new format:

  • YYYYMMDDBBPP
    • YYYYMMDD: Year/month/day the program was compiled, or whatever version.h has in it.
    • BBPP: 4-digit brand / product model code, specified in cfg-*.h. A list of brands is in the MODELS file.

The model number serves a couple purposes. For one, it lets people know exactly which build and which configuration their light uses… even if the firmware was copied from another light. This has been happening a lot lately. It also makes it easy to detect when a company reuses code from another light, vs when they create new firmware customized for that specific model. Like, it’ll be easy to tell when Astrolux uses code built for an Emisar product, for example. Or when a D1 ships with a D4v2 tiny1634 driver instead of the older D1 tiny85 driver.

The make models command produces a list of all known model numbers. At the moment, this is what it says:

> make models
Model numbers:
0111	emisar-d4
0112	emisar-d4-219c
0113	emisar-d4v2
0114	emisar-d4v2-219
0115	emisar-d4v2-nofet
0121	emisar-d1
0122	emisar-d1s
0123	emisar-d1v2
0131	emisar-d4s
0132	emisar-d4s-219c
0133	emisar-d4sv2
0134	emisar-d4sv2-219
0141	emisar-d18
0211	noctigon-kr4
0212	noctigon-kr4-nofet
0213	noctigon-kr4-219
0251	noctigon-k1
0252	noctigon-k1-sbt90
0253	noctigon-k1-12v
0311	fw3a
0312	fw3a-219
0313	fw3a-nofet
0321	blf-gt
0322	blf-gt-mini
0411	ff-rot66
0412	ff-rot66-219
0413	ff-rot66g2
0421	ff-pl47
0422	ff-pl47-219
0423	ff-pl47g2
0441	ff-e01
0511	mateminco-mf01s
0521	mateminco-mf01-mini
0611	blf-q8
0612	sofirn-sp36
0621	blf-lantern
Duplicates:
Missing:

* As of a few days ago, there is actually a mode called “disco” mode. It flashes the RGB aux LEDs in random patterns at a high speed, and is an option for use during Off mode or Lockout mode.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3
Tom E wrote:

I also added a USE_2C_MAX_TURBO setting. What this setting does is always have the 2C go to max turbo, not max ceiling. But for Simple UI, works as it did before. 

Thanks, I added that as a compile-time option. By default it’s turned off, but can be enabled per build target or in config-default.h to affect all build targets.

Turning it on saves 4 bytes and reverts “Ramp 2C” back to how it behaved in Anduril 1.

There is also an “Off 2H” action to access momentary turbo (or momentary ceiling in simple mode). This has changed from the old behavior of “Off 2H” being a shortcut to “ceiling, then ramp down if held”.

Captain_Joe
Offline
Last seen: 5 days 10 hours ago
Joined: 09/10/2017 - 03:05
Posts: 28
Location: Deutschland

I really like the candle-mode, but most times it is too “nervous”- the flickering rate is high for me. Is ist possible to implement an adjustable “framerate”? So brightness & flickering could be matched to the situation. I would love the possibility : ) The lightning mode could also benefit from this Big Smile (okay, in this case only the pauses should be shortened/extended).

Will it be possible to update old drivers? I can’t relly get, what “it would break backward compatibility” means.

- Christian

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3

Captain_Joe wrote:
I really like the candle-mode, but most times it is too “nervous”- the flickering rate is high for me. Is ist possible to implement an adjustable “framerate”? So brightness & flickering could be matched to the situation. I would love the possibility : )

Will it be possible to update old drivers? I can’t relly get, what “it would break backward compatibility” means.

The intensity of candle mode can be configured at compile time by setting CANDLE_AMPLITUDE to a different value. The default is 25. It controls the difference between the dimmest and brightest parts of the animation. With lower values, it makes the individual steps easier to see, so it looks less smooth. With higher values, it’s more smooth but flickers too intensely like it’s a camp fire instead of a candle.

At some point, I’m hoping to increase the frame rate and/or make it use intermediate steps between the ~25 ramp levels it uses, to make it look more smooth without increasing the intensity. However, this is … tricky.

Old drivers can be updated, but it depends on the type of light. Some are easy, some require soldering to access the right parts, and some are glued so thoroughly they’re nearly impossible to open.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

ToyKeeper wrote:
Tom E wrote:

I also added a USE_2C_MAX_TURBO setting. What this setting does is always have the 2C go to max turbo, not max ceiling. But for Simple UI, works as it did before. 

Thanks, I added that as a compile-time option. By default it's turned off, but can be enabled per build target or in config-default.h to affect all build targets. Turning it on saves 4 bytes and reverts "Ramp 2C" back to how it behaved in Anduril 1. There is also an "Off 2H" action to access momentary turbo (or momentary ceiling in simple mode). This has changed from the old behavior of "Off 2H" being a shortcut to "ceiling, then ramp down if held".

Sounds good! TK - pm'ed you with a question. Need to re-sync locally from 559 to 561.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3
Tom E wrote:
Need to re-sync locally from 559 to 561.

Usually a “bzr pull” or “brz pull” should do the trick… if you downloaded it with a “bzr branch” originally and haven’t modified any of the files it tracks.

If modified, then you’d have to commit your changes and then “bzr merge” to get the things which changed. And if you changed the same parts I did, it’ll have merge conflicts. So usually I keep one copy to mirror what’s upstream, and another copy that I can work in.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 52 min ago
Joined: 08/19/2012 - 08:23
Posts: 13252
Location: LI NY

Hhmm, don't know the bazaar commands, after all, they are bazaar smile 

I just dnld. All I'm doing at this point is creating and modding cfg files. Also modded anduril.c to load the cfg file I want to use.

Been using git at work and recently just recently did branch and merges, but we use tortoise git as the git UI.

I'm not seeing much right now that I want to change - you've been adding most things I wanted, like voltage calibration.

I created a running list of possible future mods and this is what it looks like now:

  1. UI config to drop thermal regulation altogether
  2. For Off 3X clicks: BattCheck -> TempCheck -> Version# (like the old Narsil). Still think this would go well together in Anduril.
  3. UI config or compile switch for 2C from OFF to set max turbo instead of top of ramp

Beacon mode can be dropped now, and that I had as a custom mod before.

A bigger change would be to support 2 e-switches but that might have to be done as a different SM UI, think as you mentioned before. I got a couple 2 e-switch lights to mod but would need the driver support as well, though could wire up a modded driver.

 

stephenk
stephenk's picture
Offline
Last seen: 40 min 52 sec ago
Joined: 01/30/2016 - 05:09
Posts: 1405
Location: Australia

Some feedback another photographer, is that they didn’t realize that stepped ramping was available. Maybe the diagram needs to show two separate parallel bars, one for ramping and the other for stepped ramping, with the 3 click link?

NeoteriX
Offline
Last seen: 5 hours 21 min ago
Joined: 08/29/2020 - 11:14
Posts: 2
ToyKeeper wrote:
I’m considering a major change to how the menu system works, to reduce code size and to change the interface style. Instead of waiting through each option to time out before moving on to the next, it would let the user skip directly to the desired option. Basically, just hold the button until it blinks N times, to access option number N, then let go to trigger the numeric entry prompt. The downside, is that it would only allow changing one option per invocation… and would require people to re-learn part of the UI.

If my two cents are helpful, changing one option per invocation fits my personal workflow better. I usually need to figure out and think carefully about my intended setting and how many clicks it needs, such that I’m not thinking about the next setting anyway and will need to go back. E.g., calibrating the flashlight temp to room temp requires me to get the room temp, convert to C and get the # of clicks, letting the flashlight rest, quickly getting into temp config, and then rattling away the clicks. I’m in no mental state to quickly jump into what I want the temperature ceiling to be, or how many clicks above 30C that is.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 6 min ago
Joined: 01/12/2013 - 14:40
Posts: 10554
Location: (469219) 2016 HO3
stephenk wrote:
Some feedback another photographer, is that they didn’t realize that stepped ramping was available. Maybe the diagram needs to show two separate parallel bars…

Yeah, out of all the changes in Anduril 2, reworking the diagram has ended up taking the longest. It’s tricky to arrange so much info in visual form and still keep the layout clean.

dave1010
dave1010's picture
Offline
Last seen: 1 day 3 hours ago
Joined: 07/04/2017 - 02:38
Posts: 89
Location: Dorset, United Kingdom

I’m not surprised the documentation is taking time.

Along with things like simple mode, documentation is a huge part of having an accessible UI. If the docs are good then manufacturers will be happier that their lights are targeting all users instead of just experts. It also makes it easier for us to lend or recommend lights with Anduril to others.

The state diagram is great and my brain grocks it. I wonder if a more task-oriented diagram (similar to the text manual doc) would be more helpful to others.

I’m imagining this taking the form of a more tutorial style set of images or maybe even GIFs and a bit of HTML holding them together.

As with the text manual, this would allow someone to have a useful flashlight even if they didn’t get to the end.

This would take even more work than the existing docs though.

I don’t think Launchpad allows previewing HTML but if it did then that’d be perfect.

Have you considered a website or even a domain that redirects to the readme?

(Opinions from a random internet stranger. Feel free to ignore)

https://davestechreviews.wordpress.com/ / Email: <my BLF username>@gmail.com

Pages