My brand new D4v2 Aux LEDs have started acting up. Specifically, only the red and green now work when set to low. Specifically I’ve noticed that when set to low, when I toggle to any of the shades that use the blue LEDs, the blue LEDs briefly come on (~2 seconds) and then turn off.
I compared the Aux LED behaviour side by side with my D4Sv2 which works flawlessly. The D4v2 is definitely wonky.
Interestingly when the Aux LEDs are set to high, all the colors still seem to work including the blue. Unfortunately I don’t use the high modes. The low mode is what I want.
Anyone have any thoughts, or should I just contact Hank for a replacement?
That’s strange. Mostly, strange that it turns on for a short time and then turns off. Do they stay on for the same length of time in both “off” mode and “lockout” mode? Does the low aux LED level turn on during the blinking mode’s animation?
The only thing I can think of which might cause that would be if, for some reason, the MCU is delivering a different amount of power when it’s awake than it does while asleep. If that was the reason though, it should turn off faster than 2 seconds. It should only stay awake for about 0.4s before going back to sleep.
ToyKeeper, thank you for taking the time to respond and for your suggestions.
I created a video that shows the conditions you asked about.
There does seem to be a difference in behaviour between off mode and lockout mode, with the blue LEDs seemingly working (better?) in lockout mode. Also, in this video the blue led went off much faster than other times I have seen it. The only difference I can think of is that the light had been powered on for a while, whereas when I noticed the blue led stay on for ~2 seconds the light had been off (tail cap loosened) for a few hours.
Let me know your thoughts, and if you have any ideas. If not, I’m guessing I’ll need to contact Hank for a replacement.
As a follow up, I set the aux LED to low-blue, and powered it off for ~24 hours.
When I powered it on they worked for a few minutes, then started flickering for several minutes, then stopped working completely again. So I’m guessing it’s totally physical. Maybe a bad resistor that stops working properly when it heats up (resistance drift?), or a bad solder joint of some kind?
I’ll contact Hank for a replacement. I’ve purchased 7 (or more) of his lights and never had a problem, but I guess there’s a first time for everything.
That’s still very strange though. I haven’t seen aux LEDs act like that before. I suppose it could be a physical issue of some sort, but it’s weird that it would be so intermittent.
Is there any chance you could try loosening and tightening the body tube, to see if it has any effect? Also maybe opening the bezel and gently prodding the blue aux LED wire?
If you have the firmware kit, it’d also be interesting to see if reflashing the firmware changes anything. I doubt it’s related to that, but it’s still something to check if you have the hardware to do so.
I agree, it does look like candle mode, but it’s regular mode. I reset by holding button and screwing the cap on, got the light show. Still have the problem.
I can only notice the flickering on low mode, at high power either I can’t notice it because it’s so bright or it isn’t flickering.
Maybe double-check the contacts on the back of the driver, both ends of the battery tube and the tailcap. Make sure they’re completely clean. One time I got flickering and the problem was a cat hair was between the battery tube and the driver contact. And that was enough to give a bad connection.
I took the head and tail cap off. Made sure the head, tail, and tube contacts were all completely clean. Re-tightened everything. No change.
I took a peek at the aux board, lifting it up slightly. The solder joints for the aux LEDs all seem good (open in new tab for full size).
The main LED ground wire was exposed very close to the solder overflow on the blue aux lead. Possibly it shorted to it?
I do have a programmer so I’ll try reflashing it, but I also doubt that will have any affect. One question though, should I use the latest compiled version from here dated Nov 20? Because the latest in your repo is from Jul 21 and I’m not sure what’s changed.
Hank offered to send me a replacement aux board if I was willing to try it. I may take him up on that.
I'd go wih the one dated Sept 28. It's the latest one I have installed and has the safety feature of ramping down if the button gets held on, i.e. if inadvertently pressed while in your pocket.
Not sure what has changed in the Nov 20 version which brings me to a giant want here on BLF. I sure wish there was a thread that was ONLY for discussing the firmware ONLY for the D4V2. It's about impossible to try and read two or three threads that might have info on what's included in what firmware. Yes I know there is info about the changes on TK's site but it sure would be nice to be able to subscribe to a thread here and get email updates whenever new F/W is released.
Oh, the trunk branch usually doesn’t have the latest code. Development for FSM-based programs like Anduril happens in the fsm branch, and then it eventually gets merged into trunk once in a while when it seems stable.
The 11-20 builds include a bunch of kernel-level changes. So far it’s all working great on the devices I’ve tested, but the changes are pretty large and deep so I don’t consider those versions totally safe yet. I’m hoping to get more test results on those.
Thinking about picking up one of these but in brass. I own the copper, and 2 versions of the FW3X series. Just discovered this light after buying the lumintop lights with GITD accessories.
I’m thinking XPL HI 5D, since I really like warm white /yellow with a hint of rose.
Thanks for the review.
I haven’t logged in to this site in 3 years!
Thanks for the clarification! I should’ve realized you had a development branch. :person_facepalming: For some reason I didn’t make the connection, probably because I anticipated more rapid promotion of the code and the dates threw me off.
I flashed it with the 11-20 build but the blue aux LED behavior is the same. Hank is going to send me a new aux board. In the meantime, I’ll put the 11-20 build through some use and DM any findings to you.
Apologies if I missed this, but is it possible to disable the e-switch backlight / LED without disabling the AUX LEDs? I noticed that the switch LED seems to follow the AUX LEDs when in lockout/off and the main LED when turned on, so I assume they are on separate channels on the driver. Also, is it possible to lower the brightness of moonlight? Even at minimum level, it’s much brighter than my other EDC.
Getting moon to go lower is particularly tricky though. You’d have to do one of the following things:
Run the MCU faster, to make the pulses shorter. This makes moon less bright but also increases power usage, so the runtime is only about a third as long.
Change the MCU to run in 10-bit PWM mode instead of 8-bit. This allows for more time between pulses, but also makes the PWM only 1/4th as fast so the pulses may be visible by eye.
Implement a hybrid PWM + DSM (delta sigma modulation) system, to change the PWM duty cycle every cycle. This allows hitting in-between brightnesses without slowing down the PWM speed, but it’s complicated to do.
I’m hoping to do that last one eventually, and the recent kernel-level changes should help quite a bit. But it’s not there yet.
As for turning off the button LEDs, that’s much easier. The details depend on what exactly you want to do with it though.
I want to try that one. I changed the TCCR1A register. Do I need to adjust something else to account for the fact that the top of the ramp is now 0x02FF instead of 0x00FF? Here’s my diff so far, against lp:~toykeeper/flashlight-firmware/fsm #457. (how do I do code blocks here?)
Yeah, sorry, it’s not that easy. I’ll have some code published soon with support for 10-bit PWM, but it’s not ready yet. It also hasn’t been tested on a D4 or a 7135-based driver at all, so it might do some weird things.
Normally PWM runs at 16 kHz, but it underclocks at the lowest levels to be more stable. It cuts to half speed and then quarter speed, so it’s only 4 kHz at moon mode. Then if it were to use 10-bit PWM instead of 8-bit, that’s another factor of 4, so only 1 kHz.
Simply turning off the dynamic underclocking is a much easier method, and can be done with a single compile-time flag.
