Anduril ... 2?

I think you said that the aux code wasn’t totally done, but you may not have noticed this behaviour if you’re setting your aux to battery mode:

When turning off the flashlight, there’s always a short flash of aux, on high, to whatever aux-mode I’m set at.

So my aux are set to low purple. I turn on, and regardless of whether I’m in a bright mode or not, when I turn off, it will flash in high purple (always high) before showing the the battery level (in high or low, depending on the brightness when I clicked for off). The battery level is blue in my case, atm. After ~3 sec it goes back to low purple.

EDIT (more tests): setting the aux to battery check, then the “aux pre-flash at turn off” becomes red (weird, considering). If aux are set to green, the aux pre-flash is green, etc.

Also, a minor… weirdness: if aux are set to high, but I’m using a low brightness, at turn off, the battery indicator goes to low… then back to high.


Did it auto revert to simple UI???

That confused me a lot, because strobes, changing the aux, switching channels was all available, but the ramp and memory configs (on 7H and 10H) were disabled… apparently, turbo and tactial mode are also disabled. I guess this your personal simple UI config? :slight_smile: I like it, it makes sense, the only things that are “dangerous” (turbo) or that I would’t want someone to mess with (ramps and memory configs) are locked away, otherwise its full featured. (I guess I’d want turbo strobe and lightning mode should be locked away too).

There’s simavr, but it doesn’t support attiny1634 or attiny1616. The maintainer talks like those would be easy to add, but that’s yet another project.

There’s also simulide, which runs on top of simavr and simulates entire circuits. It looks pretty cool, but when I did a quick test trying to simulate a tiny85 with FW3A firmware, I couldn’t get it to show any sign that anything was happening. Probably just user error, but it seems it’ll take a while to figure out.

So I’m still debugging the old-fashioned way, by reading code and thinking about it… then testing theories on actual hardware, sometimes with a variety of creative debug clauses to show results.

Like, I thought maybe eeprom was getting corrupted. But I had it dump out the entire cfg struct before and after factory reset, and everything looked correct. So I guess I need to dump out some other parts of RAM to find the culprit.

Anyway, I haven’t yet found the reason why factory reset is causing thermal regulation to report overheating… or why it happens on KR4 but not D4v2. So far I’ve only found a lot of things which are not causing it.

Yeah, I do the same thing, I add event handlers to inspect the state of internal variables and stuff like that sometimes too. I wonder if a seven segment display would be a good thing to include on the devboard, could be driven with 2 pins with a register or some other trickery.

Is it because your battery voltage is sagging due to the load from the LEDs then recovering? Voltage is read at a higher frequency than it used to be (<1sec vs ~7sec IIRC). What happens if you turn the voltage aux entirely off

If you have an oscilloscope or logic analyzer, you could output serial data, even RS232-like, by modulating the light. Should also work with PWM when used together with a low-pass filter. Of course this doesn’t come for free and might change the behavior of the firmware depending on the extra delay.

The aux-preflash at turn off is the same color, wether brightness was high or super low. When aux is set yo voltage mode, preflash is red. When set to a color, pre-flash is purple. This happens in the boost driver multichannel driver that toykeeper publisher to her website a few days ago (17?)

I meant, what happens if you disable the post-off voltage display? battery check mode, 7H, second item, 0C.

Edit: I was able to reproduce it, I see what you mean. I might know why, need to check something.

Oh! I didn’t know it was an option. Ok, done. At turn off, it doesn’t show the voltage in high aux mode (it goes to low). However, the same aux-flash is present right before. Same behaviour. The color of the flash is the same as what aux are set at. Red flash if in battery aux.

@ToyKeeper Looks like it’s the line if (! go_to_standby) { pattern = 2; } in aux-leds.c here forcing aux to high, possibly due to the changes for the post-off voltage preventing sleep while the conditional there is being evaluated? because I don’t remember it doing this in the old branch on my version and my current light I have running stock fw doesn’t do it, so definitely a regression. I replaced that line with if (setting_rgb_mode_now) { pattern = 2; } which still has the same intended effect and is more flexible in terms of allowing other tasks to run without affecting aux, and fixed it for me.

Edit: @elendur here’s a build with the fix: 491.2 KB folder on MEGA

4 Thanks

Thanks a lot @wolfgirl42 … It works for me as well!

I’m finally have a build environment setup in Ubuntu and am trying to customize a hex file with my preferred settings. One thing I can’t seem to find is what is the default brightness at turn on for Anduril 2 on the regular firmware for Emisar D4v2. I want to turn on Hybrid memory at the default turn on level with a 5 minute timer. I see where to put in those settings, but don’t know what number to put in for the brightness. Coming up empty on my searches. If someone knows, I’d be very thankful.

Thanks, Bob.

DEFAULT_MANUAL_MEMORY for the level, and DEFAULT_MANUAL_MEMORY_TIMER for the timeout (in mins)

1 Thank

Yes, that’s the part I have figured out. But “DEFAULT_MANUAL_MEMORY” needs a number after that. That is the number I seek. What would be the default turn on brightness after a factory reset? There must be a number that corresponds to that brightness that I can put after that statement. Then I can put a 5 after “DEFAULT_MANUAL_MEMORY_TIMER” for 5 minutes.

DEFAULT_LEVEL, which is by default set to MAX_1x7135, which is set per-model. Ramp levels are from 1-150, so 50-75 is usually a good but safe default. Worst case you think it’s too high or low, just change it and build a new image.

2 Thanks

Thanks wolfgirl42. I’ll try 50 to start with and go from there. Assuming my hex actually builds, haven’t tried that yet :wink:

1 Thank

After playing around with this version, it seems to work perfect on my D4v2. Oddly enough, something isn’t right with thermal regulation if I flash it to my D4K. Both came from the factory with DM11-12v firmware.

The D4K will not get more than lukewarm and read 27c with tempcheck. I tried a factory reset and manual 45c limit.

I also get two different version check “styles”. The D4K flashes the primary emitters, the D4v2 uses the aux only on low.

2022.10.21_Andurilv2.noctigon-dm11-12v is what the D4k came with and at first glance, seems to work properly.

That version is a bit old, but I know on some lights with the current one there are some bugs around thermal regulation. I have a build of the latest version (with the bugfix I mention in the post) here if you wanted to see if that one is any different.

Wolfgirl42, for this particular D4V2 with 519a 2700k Domed the magic number was 65. Same exact readings on my TA Lumen Tube as factory default. Thanks for your help.

glad you found the step level info you needed…

how many lumens is that? :wink:

Both of my D4V2’s have 519a’s. The 2700k is 100 lumens, the 4500k is 110 Lumens. I also have one with the Deep Red SST-20’s, but that doesn’t register well in the lumen tube, so didn’t bother measuring it. But how that I’ve broken that ice, I’m sure I’ll be seeing what else I can customize.

Now that I know the step level, this caught my eye in the cfg-emisar-d4v2.h file:
#define MAX_1x7135 65

:man_facepalming:

good info
thanks :wink: