Anduril ... 2?

Flashlight Modding and DIY Parts
1139

I’ve always been curious…. Why are their different options for exiting and entering simpleUI? I ALWAYS get it wrong on stock lights and repeatedly need to enter a 10C or 10H sequence. On the personal builds I made last year, I set enter and exit to 10C with a simple low brightness blink (Simple) or double blink (Advanced) to designate which UI the user was in. I suppose this may be trivial because getting to simple or advance is always a certain command in the original version.

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)

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?

1140

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.

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

Look at this array definition in aux-leds.c:

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/anduril2/view/649/ToyKeeper/spaghetti-monster/anduril/aux-leds.c#L55

    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
    };
1141

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);
}
1142

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)?

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

1144

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

1145

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

Thank you for the table!

1146

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?

1147

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

1148

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?

1149

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

1150

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

1151

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?

1152

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

1153

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.

1154

The same bug is present on DW4 boost driver.

1155

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

1156

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.

1157

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.

1158

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?