Anduril 2 feature change suggestions

LED Flashlights – General Info
545

Moreover, I checked and fw3x-lume1 is not building in TK’s pristine rev 812 (ie, without my mod):

812/~toykeeper/flashlight-firmware/multi-channel/ToyKeeper/spaghetti-monster/anduril$ ../../../bin/build.sh 1634 anduril -DCFG_H=cfg-fw3x-lume1.h
avr-cpp -DCFG_H=cfg-fw3x-lume1.h -Wall -g -Os -mmcu=attiny1634 -C -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_fl
ashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/
 -o foo.cpp anduril.c
avr-gcc -DCFG_H=cfg-fw3x-lume1.h -Wall -g -Os -mmcu=attiny1634 -c -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_fl
ashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/
 -o anduril.o -c anduril.c
In file included from ../spaghetti-monster.h:29:0,
                 from anduril.c:77:
../fsm-ramping.h:103:15: error: unknown type name ‘PWM1_DATATYPE’
 PROGMEM const PWM1_DATATYPE pwm1_levels[] = { PWM1_LEVELS };
               ^
../fsm-ramping.h:106:15: error: unknown type name ‘PWM2_DATATYPE’
 PROGMEM const PWM2_DATATYPE pwm2_levels[] = { PWM2_LEVELS };
               ^
../fsm-misc.c: In function ‘blink_digit’:
../fsm-ramping.h:163:19: error: ‘RAMP_SIZE’ undeclared (first use in this function)
 #define MAX_LEVEL RAMP_SIZE
                   ^
../fsm-misc.h:18:35: note: in expansion of macro ‘MAX_LEVEL’
         #define BLINK_BRIGHTNESS (MAX_LEVEL/6)
                                   ^
../fsm-misc.c:46:19: note: in expansion of macro ‘BLINK_BRIGHTNESS’
         set_level(BLINK_BRIGHTNESS);
                   ^
../fsm-ramping.h:163:19: note: each undeclared identifier is reported only once for each function it appears in
 #define MAX_LEVEL RAMP_SIZE
                   ^
../fsm-misc.h:18:35: note: in expansion of macro ‘MAX_LEVEL’
         #define BLINK_BRIGHTNESS (MAX_LEVEL/6)
                                   ^
../fsm-misc.c:46:19: note: in expansion of macro ‘BLINK_BRIGHTNESS’
         set_level(BLINK_BRIGHTNESS);
                   ^
In file included from anduril.c:91:0:
load-save-config.h: At top level:
ramp-mode.h:31:26: error: ‘RAMP_SIZE’ undeclared here (not in a function)
 #define SIMPLE_UI_FLOOR (RAMP_SIZE*2/15)
                          ^
load-save-config.h:32:17: note: in expansion of macro ‘SIMPLE_UI_FLOOR’
                 SIMPLE_UI_FLOOR,
                 ^
In file included from ../spaghetti-monster.h:28:0,
                 from anduril.c:77:
../fsm-channels.h:36:9: warning: array ‘channels’ assumed to have one element
 Channel channels[];  // values are defined in the hwdef-*.c
         ^

I guess that’s because TK haven’t “ported it to the new API” or something. Tagging her in case she wants to comment. That was indeed the case, see my next post.

546

Just checked her raw commit logs and it seems that got fixed in rev.814:

814. By Selene ToyKeeper 17 hours ago

converted fw3x-lume1 to new API, I think
(needs testing on actual hardware, and ideally tweaking to improve performance)

So it seems she fixed it 2 revisions later and less than 1 day after I built my hexes… :slight_smile:

@Light_Veteran, is your light indeed a FW3X with the Lume1 driver? If yes, just say the word and I will try and build you an HEX with my 8C-Quick_Aux_Switch mod.

547

Ok I understand what happened. Don’t worry I’m in no hurry!:relieved:
Yes, is FW3A with lume1 and I have also an FW3X

548

Correct, is because Lume1 in the past was sell separately from FW3X with aux board so I grab one or two when was possible. So for my FW3A the correct firmware is FW3X-lume1

1 Thank
549

I will have it built, both for pristine rev 814 and for it plus my 8C-Quick_Aux_Switch mod. Please wait one.

1 Thank
550

As always thank for your time and kindness

1 Thank
551

It actually took almost 15mins :slight_smile: but here they are: https://durval.com/xfer-only/814+814-8C_quick_aux_switch.zip

Please let me know how it goes.

552

I set it now and the only thing do not work is aux channel in voltage reading.
Off—>3C = Voltage reading by main LEDs —>3C = Cycle from main LEDs to AUX for voltage reading.
So… OFF—>3C—>3C don’t work. Is not a problem for me but the correct way is to inform you

1 Thank
553

Thanks for the report, much appreciated!

I will have a look at it ASAP (probably tonight or tomorrow early morning, as I’m right now smack in the middle of one of these IRL situations… :expressionless: )

1 Thank
554

Just did a quick check with my TiTS10 which is running 812-8C_Quick_Aux_Switch and it works: 3C during voltage read blinking rotates between the aux LEDs (and all their possible aux colors on the TiTS10, given they’re RGB) and the main LEDs.

So that’s actually a bug, either in rev 814 or for the fw3x-lume1 (or both). I will investigate further and get back to you tonight or early tomorrow, please stand by.

1 Thank
555

Yes, I also try with TS10 and the only color available, work

556

And here it is: https://durval.com/xfer-only/toykeeper_-_flashlight-firmware_-_multi-channel_-_rev_812-8C_quick_aux_switch+fw3x-lume1_-_3C_during_3C_bug_fix_attempt.zip

@Light_Veteran please flash it and tell me how it goes.

PS: the bug was really hard to figure out (specially as I have no FW3X nor anything with a Lume1 driver, and no experience with either) but then I went through my recent unread-post backlog and found this: Anduril ... 2? - #1791 by wolfgirl42. Thank you very much @wolfgirl42!

1 Thank
557

ASAP, probably in the late afternoon… thank you

1 Thank
558

I only try so fast the aux. Nice! I’ll check all firmware today. As always thank you

1 Thank
560

Sooo… Any ideas on how to make sunset mode NOT dim the light as it counts down, but simply turn it off after the prescribed time frame?

Its a great idea, but the dimming is annoying, for my use case.

I tried editing this once, but the code in that section is.was a bit over my head… Would dearly love some guidance here if anyone is willing!

I do need code, not just compiled hex files. Need to be able to inset this into my setup, since I have highly modified the rest of my setup.

please note, I am in both rev657, pre multi channel as I recall, and rev725 is the latest multichannel I am compiling… So it would need to be compatible with those.

Unfortunatelly, all the current stuff in the docker thread is too confusing for me to even think about trying the latest code right now.

THANK YOU for any help!! :sunglasses: :heart:

561

Like you wrote I prefer the same so…
I notice the dimmer function is good when you go to sleep but if we need an immediately off after the timer is not possible
@ToyKeeper can you set the sunset mode without dimmer?
Or for example can you set the dimmer in the last 30 seconds of timer.
If I use the sunset for 30 minutes I don’t need to have less lumens during this time. As always thank you

562

In the latest version, this looks like where it calculates the dimmed_level and then sets the current level to that based on how much sunset time has passed:

        #ifdef USE_SUNSET_TIMER
        // reduce output if shutoff timer is active
        if (sunset_timer) {
            uint8_t dimmed_level = sunset_timer_orig_level * sunset_timer / sunset_timer_peak;
            uint8_t dimmed_level_next = sunset_timer_orig_level * (sunset_timer-1) / sunset_timer_peak;
            uint8_t dimmed_level_delta = dimmed_level - dimmed_level_next;
            dimmed_level -= dimmed_level_delta * (sunset_ticks/TICKS_PER_SECOND) / 60;
            if (dimmed_level < 1) dimmed_level = 1;

            #ifdef USE_SET_LEVEL_GRADUALLY
            set_level_gradually(dimmed_level);
            target_level = dimmed_level;
            #else
            set_level_and_therm_target(dimmed_level);
            #endif

So for a custom build, my guess is removing the lines which set a new level will do the trick.

563

Hmm thanks. I haven’t looked at thd latest code since I cant compile it yet.

Well, from what i remember, thats structured different than it is in my version(pre multi channel re-writes), because that is actually readable… or else my C reading has improved and I didn’t know it.

I think I see what to change there.
Of course I thought that in the earlier code too, and could never get the modification to compile.

I’ll compare this to what I have tonight, and see if I’m remembering wrong.

Stiil be great if someone else wants to change it and I can copy/paste though. :smiley: :wink:

564

I was actually looking into this a few days ago for my own use case. I use some E17A Azure lights in the morning to help me wake up, and I want to set a relatively long timer on them so they will power off by the time I’m awake, but I don’t want the output dropping below thermally sustainable.

One thing to note is that candle mode stays the same brightness, if the… candleyness (?) isn’t a problem. Although myself, I’d like a flat output for this as well. I’ll probably write a mod for it.

1 Thank
565

Is your version from after July 2020? It looks like this code has remained similar since then (line numbers may have changed though).

Even so I’m not sure what to do next :slight_smile: I can’t quite tell what’s responsible for turning the light “off” at the end of the timer — maybe it’s just when dimmed_level reaches 0? If so, the key would be to keep track of what the decreasing level, but not actually change the level until it reaches 0.