I got returned a Anduril flashlight from a customer who reported that the light gets very regularely stuck in a sort of blinky endless circle
I tried hardware fixes but it seems that the firmware itself gets stuck somehow
The MCU gets stuck, while the light was at max ramping and get turned on again
the light needs to be disconnected from voltage to gets it out of the stuck behavior
I have it tested afterwards on a bench power supply trying to trigger the error
The light gets stuck the Indicator LED lights while the Output is off about 1 second
then a short blink of main LED and the Indicator LED gets out
First I thought its a 5V problem so I reinforced filter caps with no success
I have now the error reproduced on bench power supply
This is the 5V supply of MCU with oscilloscope
Indicator LED bahaves like this
The output of PWM 1 and PWM 2 are a short pulse packets
That’s an error in your config file. Stop setting the default to a mode you don’t want.
That was fixed in 2018. It happened sometimes when the switch signal was extremely noisy, and could generally be fixed by replacing the switch… but I modified the code to tolerate unusually bad switch hardware last year. Sounds like the firmware on that light is probably very old.
That’s intended behavior documented on page 1 of bothmanuals, and in the UI diagram. It has been that way since day 1.
Sometimes it takes new users a while to notice, but I’m a little worried that someone who builds products and sells services based on this code didn’t know about it.
please where do I find the config line does the default mode to low?
That was firmware from April 2019, its a buck driver
The light keeps blinking, even if I press the switch permanently it does an extra blink and goes on
my guess may be noise from the switching node
TK, I just noticed behavior in the 6/2 Anduril builds that I wasnt sure was intentional.
We have the two step lockout, however if you have the ramp minimum set to anything other than 1, the second stage becomes moonlight and the first stays the min ramp level.
Might it make sense for the lockout to maybe have some logic like “if MIN_RAMP_LEVEL > 1 ; LOCKOUT_STG1 = 1; LOCKOUT_STG2 = MIN_RAMP_LEVEL” or something similar?
Maybe even have a lockout config option for 6 clicks to toggle between single stage = min ramp and dual stage = 1/60lumen
Edit: does anyone know if Anduril has lvp with the aux leds?
Ah, okay. I wonder what’s causing it to go into a reboot loop, then. Something must be pretty noisy to set it off like that. Like, triggering interrupts faster than they can be handled, causing an overflow or something, until it goes into a reboot loop.
The first click is the current ramp floor, and the second click is the other ramp floor. Those can be whatever you set them to.
I’ve been pondering whether it should instead do first click = lowest ramp floor and second click = highest ramp floor, to ensure it goes in low-to-high order… but I’m not sure if it would be an improvement.
Only in the most recent version, on the D4V2. I didn’t add LVP in sleep mode until that project.
Older lights with aux LEDs won’t shut them off when the battery gets low… but the D4V2 does. It wakes up every 30 seconds or so to measure voltage while it’s “off”. I still need to fix some of how that behaves though… if the user presses the button during that narrow timing window, IIRC it doesn’t respond how it should. But at least it allows the voltage readout to update as the battery drains, and it keeps the battery from draining too far.
Just noticed this. This is a BLF Q8 running Anduril 02-06-2019 in “OFF”mode, aux off.
Looks like it’s powering the MCU down and up again?
My Q8, and D4S’s do this, my D4’s are steady @ 21yAmps
That’s odd. The speed looks way too slow, unless the DMM is sampling infrequently.
It should cycle between ~5 and ~30 uA about 8 times per second.
This happens on devices with the “sleep ticks” feature enabled, because it leaves the WDT enabled during sleep so it can wake up and change the aux LED state, like for the “blinking” mode. The exact cycling speed is defined by STANDBY_TICK_SPEED.
If there’s no aux LED though, or if you compile without TICK_DURING_STANDBY, the power use should be lower and steady, as you described on the D4.
It’s hard to say for sure. It would have been out by now, but people keep asking me to help them clone Emisar products, so I keep pushing back the release date. I’m not in the business of helping people undercut my clients.
Personally, I prefer the design and execution of Hank’s lights and Anduril is icing on the cake. I will always choose his lights compared to the clones. I would hazard a guess that a lot of other flashaholics would too.
Not sure if this is the correct thread to ask but… I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didn’t specify fuse values when flashing. Upon testing I noticed I couldn’t step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly? If it helps, I bought the C8 new from BG one year ago.
Sounds about right, the fuse settings. Had the same issue after flashing my BLF A6. The timing was way off. After reflashing it with the correct fuse values, it worked correctly again
Doesn’t flashing without specifying the fuse values leave them unchanged? Or are you saying I need new fuse values for the (presumably) newer firmware?
It probably needs different values for the OTC calibration. The CAP_SHORT / CAP_MED values might not match the hardware.
Specifically, it may be a good idea to use the blf-a6 branch of the code instead of trunk, because it’s what the light probably shipped with. The copy in trunk has had updates and the calibration is set back to a default which I think matches MtnElectronics’ drivers instead of Banggood’s drivers.
Looking at it now, the blf-a6 branch uses values of 245 and 180, while the trunk branch uses 190 and 94. So that may be what you’re running into.
Banggood’s drivers don’t really have the standby drain configured very well to begin with, and the lighted tailcap makes it worse. Here’s what I measured a few years ago. The blue line is ideal, and is what trunk uses by default. The red line is what Banggood’s drivers do. And when you add a lighted tailcap, it follows an even higher line.
I just wanted to post a suggestion for improvement.
When clicking 4 times to exit lockout, it would be nice the if the behavior were:
4-clicks, the light turns on to the last memorized mode
click, click, click, hold, the light turns on to moonlight and starts ramping up
5-clicks, the light turns on to ramp ceiling
click, click, click, click, hold, the light turns on to ramp ceiling and starts ramping down
etc.
Essentially, the fourth click should act as if the light were already out of lockout. This makes sense since if you’re taking the light out of lockout, the next thing you’re going to do is probably turn it on.
