Anduril ... 2?

[nick779]

@SammysHP

@nick779

I’ve always been curious… Why are their different options for exiting and entering simpleUI?

My guess is it’s because 10C will always enable Simple UI (or does nothing). So it’s pretty safe to enter. On the other hand 10H is more unlikely to enter to leave Simple UI. Also with the same combination you don’t know in which mode you are unless you try some modes like battcheck.

@nick779

I’ll need to rebase my brz branch and make the same modifications to the source code again to get my new lights the same as the old. (I struggle with GIT and BZR so if there is an easier way to do this, I’m all ears)

ToyKeeper once came up with an idea of allowing more customizations from config files. AFAIK it’s nothing more than an idea so far.

@nick779

Lastly, I modified the voltage rainbow to the old 4 color version (or so I thought) but it had never worked correctly. I believe I just removed the sections with colors I didn’t want, but it’s a bit unreliable at times. I’m not exactly sure why though as the code looked straight forward. Any tips or thoughts on this?

Look at this array definition in aux-leds.c: ~toykeeper/flashlight-firmware/anduril2 : contents of ToyKeeper/spaghetti-monster/anduril/aux-leds.c at revision 649

    static const uint8_t levels[] = {
    // voltage, color
          0, 0, // 0, R
         33, 1, // 1, R+G
         35, 2, // 2,   G
         37, 3, // 3,   G+B
         39, 4, // 4,     B
         41, 5, // 5, R + B
         44, 6, // 6, R+G+B  // skip; looks too similar to G+B
        255, 6, // 7, R+G+B
    };

Just add your thresholds and colors, for example:

    static const uint8_t levels[] = {
    // voltage, color
          0, 0, // 0, red: < 3.3 V
         33, 4, // 0, blue: 3.3 - 3.8 V
         38, 2, // 0, green: > 3.8 V
        255, 0, // 0, for internal purposes
    };

I’ll revisit this when I rebase and recompile this week, but this is what my code looked like when the purple top level didn’t work (Battcheck at 4.1v, multiple lights/targets): Anduril ... 2? - #833 by nick779 Upper section is my alteration.

 #if defined(USE_AUX_RGB_LEDS) && defined(TICK_DURING_STANDBY)
uint8_t voltage_to_rgb() {
 static const uint8_t levels[] = {
 // voltage, color
 0, 0, // 0, R
 34, 1, // 1, R+G
 36, 2, // 2, G
// 37, 3, // 3, G+B no Cyan
 38, 4, // 4, B
 40, 5, // 5, R + B
// 44, 6, // 6, R+G+B // skip; looks too similar to G+B
 255, 6, // 7, R+G+B
 };
// static const uint8_t levels[] = { //stock fancy
 // voltage, color
// 0, 0, // 0, R
// 33, 1, // 1, R+G
// 35, 2, // 2, G
// 37, 3, // 3, G+B
// 39, 4, // 4, B
// 41, 5, // 5, R + B
// 44, 6, // 6, R+G+B // skip; looks too similar to G+B
// 255, 6, // 7, R+G+B
 // };
 uint8_t volts = voltage;
 if (volts < 29) return 0;

 uint8_t i;
 for (i = 0; volts >= levels[i]; i += 2) {}
 uint8_t color_num = levels[(i - 2) + 1];
 return pgm_read_byte(rgb_led_colors + color_num);
}

[TIFisher]

I’m having a little difficulty figuring out the battery check voltage adjustment. Example: cell DMM’s at 3.85, but battery check flashes 4.0. How many clicks are necessary in config mode to get the check to reflect 3.9 (or 3.8)?

[SammysHP]

       1. Voltage correction factor.  This adjusts the battery 
          measurement sensor, allowing the user to add or subtract up to 
          0.30V in 0.05V steps.  Click N times to enter a value:

          1C: -0.30V
          2C: -0.25V
          3C: -0.20V
          4C: -0.15V
          5C: -0.10V
          6C: -0.05V
          7C: default, 0V
          8C: +0.05V
          9C: +0.10V
          10C: +0.15V
          11C: +0.20V
          12C: +0.25V
          13C: +0.30V

You want to go down by 0.1 V, thus you need to click 4 or 5 times.

[roostre]

@TIFisher

I’m having a little difficulty figuring out the battery check voltage adjustment…

An Easy Method for Setting the Anduril 2 "Voltage Correction Factor":

1) There will be two (adjacent) "Voltage Correction Factor" settings that allow the "Battery Check" function to blink out "3.7" for a "Battery charged to 3.73 V".

2) Choose the one that can be selected with the least amount of clicks.

Additional information explaining the method: https://budgetlightforum.com/t/-/69798

[TIFisher]

@roostre

Additional information explaining the method: https://budgetlightforum.com/t/-/69798

Very detailed explanation, thank you. Maybe next time I have a question, I could try the ‘search’ function first(?), lol. Used your “slide rule” method and got it dialed in perfectly on my SP10 PRO. I applaud the effort you put into that post.
FWAA is next….

SammysHP wrote:
You want to go down by 0.1 V, thus you need to click 4 or 5 times.

Thank you for the table!

[nick779]

I successfully updated my builds with the latest pull from BZR and fixed the voltage AUX issue. Not sure what I had wrong before.

I did receive two lights today, the DM1.12 (K9.3 model #) and a two channel D4v2 (D4Sv2-Tintramp cfg). I need to update the DM1.12 with my AUX volt changes, but that should be easy. Hopefully there aren’t any issues with the new code revisions.

I haven’t dug too deep into the code differences between the two, but is there a way to set the turbo behavior on the D4 to use 100% of the current channel instead of 100% on both channels?

Lastly is there a way to backup the current hex on a light so I can flash it back if need be?

[SammysHP]

Except from setting the ceiling level to 130 (?) and disabling turbo, you have to redefine the ramp tables in the config file so that each channel goes up to 100%. Not sure which parameters where used for that light, but ToyKeeper usually adds it in a comment.

You can create a backup of the original flash content via “avrdude … -U flash:r:backup.hex:i”.

[nick779]

@SammysHP

Except from setting the ceiling level to 130 (?) and disabling turbo, you have to redefine the ramp tables in the config file so that each channel goes up to 100%. Not sure which parameters where used for that light, but ToyKeeper usually adds it in a comment. You can create a backup of the original flash content via “avrdude … -U flash:r:backup.hex:i”.

Appreciate that avrdude line, I definitely want a backup of the FW on the new lights.

I found level_calc.py, but I have no clue what parameters to use in that script to make the d4v2-2channel have 0-150 on each channel, aka 1 channel turbo.

This is the ramp from d4sv2-tintramp.

// has two channels of independent LEDs
#define USE_TINT_RAMPING
// how much to increase total brightness at middle tint
// (0 = 100% brightness, 64 = 200% brightness)
#define TINT_RAMPING_CORRECTION 0  // none, linear regulator doesn't need it
// main LEDs
//   output: unknown, 2000 lm?
//   FET: absent / unused?
// 2nd LEDs
//   output: unknown, 2000 lm?
#define RAMP_LENGTH 150
// abstract ramp (power is split between both sets of LEDs)
// 1-130: 0 to 100% power
// level_calc.py 5.01 1 130 7135 2 0.2 2000 --pwm dyn:64:16383:511
// 131 to 150: 101% to 200% power
// level_calc.py 6.44 1 150 7135 1 0.2 2000 --pwm dyn:74:16383:1022
#define PWM1_LEVELS 2,2,2,3,3,4,4,5,6,7,8,9,10,11,13,14,16,17,19,21,23,25,28,30,33,35,38,41,44,47,50,54,57,60,64,67,71,74,78,81,84,88,91,94,97,99,101,103,105,106,107,107,107,106,105,102,99,95,90,84,77,68,58,47,34,36,38,40,42,44,47,49,52,54,57,60,63,66,69,73,76,80,83,87,91,96,100,104,109,114,119,124,130,135,141,147,153,160,166,173,180,187,195,203,211,219,228,236,245,255,264,274,285,295,306,317,329,340,353,365,378,391,405,419,433,448,463,479,495,511,530,550,570,591,612,634,657,680,705,730,755,782,809,837,865,895,925,957,989,1022
#define PWM_TOPS 16383,13234,9781,13826,9593,13434,9973,12021,12900,13193,13150,12899,12508,12023,12666,11982,12181,11422,11393,11247,11018,10731,10826,10434,10365,9927,9767,9565,9332,9076,8806,8693,8395,8096,7928,7626,7439,7143,6948,6665,6393,6203,5946,5700,5465,5187,4926,4681,4451,4195,3957,3700,3463,3213,2983,2718,2476,2231,1986,1742,1501,1245,997,756,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511,511
#define DEFAULT_LEVEL 70
#define MAX_1x7135 150
#define HALFSPEED_LEVEL 10
#define QUARTERSPEED_LEVEL 2

Speaking of the K9.3, what is the last working build?

[nick779]

Well, I've been chugging away at figuring out the level_calc parameters and think I have it down, but I'm not 100% sure.

Syntax:
level_calc.py RAMPSHAPE CHANNELCOUNT HOWMANYLEVELS CHANNELTYPE LOWESTLEVEL LOWLUMEN HIGHLUMEN --pwm DYNSWITCH:DPWMSTEPS?:14BITPWMMAXVALUE:PWMTOPVALUE
DPWMSTEPS = (total steps / 2) - 1?
D4S Tintramp HWDEF:

#define PWM_CHANNELS 1 // 1 virtual channel (1 for main LEDs + 1 for 2nd LEDs)

#define PWM_BITS 14 // 0 to 16383 at variable Hz, not 0 to 255 at 16 kHz

#define PWM_TOP 511

// dynamic PWM with tint ramping

#define USE_DYN_PWM // dynamic frequency and speed

#define PWM_DATATYPE2 uint32_t // only needs 32-bit if ramp values go over 255
D4S Tintramp Syntax:

// 1-130: 0 to 100% power

// level_calc.py 5.01 1 130 7135 2 0.2 2000 --pwm dyn:64:16383:511

// 131 to 150: 101% to 200% power

// level_calc.py 6.44 1 150 7135 1 0.2 2000 --pwm dyn:74:16383:1022

I'm assuming that this is a good starting point, but I have no idea what to make the 2nd and 4th --pwm parameter. 511 sounds right for 100% power on 1 channel in the 4th parameter, but I'm stuck on the 2nd(64/PWMSTEPS?).

level_calc.py 5.01 1 150 7135 2 0.2 2000 --pwm dyn:74:16383:511

Although attempting to run that or any stock syntax fails with this error:

./level_calc.py 5.01 1 130 7135 2 0.2 2000 --pwm dyn:74:16383:511
Traceback (most recent call last):
File "./level_calc.py", line 294, in <module>
main(sys.argv[1:])
File "./level_calc.py", line 69, in main
if parts[4]:
IndexError: list index out of range

EDIT: It appears to have broken after revision 610, reverting back to the last file version allowed me to create the values. Based on the SP10 Pro level_calc.py, there was a 5th parameter added to the --pwm syntax that doesn't default when missing, causing the error. Credit to reddit user bunglesnacks for pointing me in the right direction.

EDIT2: Defaulting to tint toggle in ramping.c and setting a cfg of 0-150/0-100% pwm per channel gave the desired behavior with A2 turbo settings. No issues found so far.

Link to firmware: https://drive.google.com/drive/folders/1KJsUPAZ0DoBZgBxDW2NCnRlpZO0IED3V?usp=sharing

"tinttoggle-custom" hex is mine, the other is the stock firmware on my dual channel D4v2. Note: I also changed the model # to 137 (unused) to distinguish it from stock firmware and the tintramp target.

Last Edit:

DPWMSTEPS = (total steps / 2) - 1

(150 / 2) - 1 = 74

[zumlin]

I am not sure if this fixes your problem but there is an update to level_calc.py

[nick779]

@zumlin

I am not sure if this fixes your problem but there is an update to level_calc.py

It should based on the file diff. I guess TK is always lurking on this thread even if she doesn’t comment. (Or she already knew it was an issue)

@TK, do you know the last repository revision where the K9.3 build target worked?

[trakcon]

I have a KR1 with the 7.5A driver, but I want to limit it to 5.5A. I did this previously for Anduril 1 using level_calc.py, changing max_pwm, and plugging those updated numbers into the kr4-nofet cfg.

Now, I’m updating everything to Anduril 2 and dynamic pwm has confused things for me. I discovered that level_calc.py now assigns max_pwm=dpwn_min further down in the code, so I changed the last command line argument to —pwm dyn:78:16384:187. That significantly changes the PWM_TOP numbers, though. I looked in the kr4-219 cfg files to see how those were altered to limit power, and it appears that only the PWM1 & PWM2 numbers were changed; not PWM_TOP.

So, in my case, does anyone know if I should only replace the kr4-nofet PWM1 numbers with the max limited to 187, or should I also replace PWM_TOP with the limited data set?

Thanks much to anyone who has any input.

Mike

[elendur]

If I may, I without really knowing the answer to your think the 219 has fet enabled so I that may explain the TOP difference

Also, as long as you have 150 (or 151?) Values, I personally would try flashing it and see if the ramp behaves nicely.

Of course, I would still like some more insight into using level_calc correctly.

[g_damian]

@g_damian

Hi, I found a bug in the build for D11 B35AM (stock, I haven’t reflash it yet). If I recall correctly, there was similar thing discovered some time ago. I locked the flashlight, configured aux to blinking and white. After couple minutes it unlocked itself.

The same bug is present on DW4 boost driver.

[SammysHP]

@SammysHP

@m03da

Google custom search doesn’t work for me so apologies if this has been discussed before. I was thinking it would be useful to have a stepped/ smooth options on the tint ramp as well. That way two lights could be colour-matched much more easily, e.g. for photography.

It’s already on the list (and I started working on it a while ago, but never finished it).

I have finished my stepped tint ramping implementation. You can find the option in the misc configuration menu.

0 = smooth tint ramping with auto tint ramping on both edges
1 = only middle tint
2 = tint toggle
n = n steps, evenly spaced

https://github.com/SammysHP/flashlight-firmware/commits/stepped-tint-ramping

[Bob_McBob]

I’ve been using SammyHP’s stepped tint ramping on my dual channel 2700K/5700K 519A D4V2 since yesterday and I absolutely love it. With a smooth ramp I often find I’m mostly using the light at either end of the ramp or some undefined point in the middle that might be vaguely similar to what I actually want. With 7 steps I can get 2700K, 3000K, 3400K, 3800K, 4400K, 5000K, and 5600K, and it’s easy to select the CCT I want. This will be great for the LT1 as well.

[jon_slider]

Feature request:

Option for a user to Select to turn off Blinking during Ramping.

(Not requiring custom Hex Reflashing)

imo ALL Blinking features should be Optional.

[SammysHP]

Many “blinking features” give you feedback about the state of the light. Do you see batt-check, candle mode, bike flasher etc. as “blinking features” as well?

[jon_slider]

@SammysHP

batt-check, candle mode, bike flasher

All of those are Optional. I can turn them On or Off, whenever I want to. Same for Aux lights and Butto Lights, they are Optional, and the user can Select On, Off, Dim, Bright, or even flashing.

otoh, Blinkies while Ramping are Not Optional. They cannot be turned off.

That is why Im posting it as a Feature Request.
I would like the Option to turn OFF Blinkies while Ramping

Anduril is not consistent,
on my TS10 and SC21 Pro, there are NO Blinks while Ramping.

otoh, my FWAA and the SP10 Pro have Blinks while Ramping, that I do not want, but cannot turn off.

And to make matters worse, the SP10 Pro had No Blinks while Ramping, when it first came out, but now it does. Major Bummer!

[SammysHP]

@jon_slider

Anduril is not consistent

Anduril is (mostly) consistent – flashlight manufacturers are not. They can choose what features they want enabled.