The sales to the US market has resumed

Commercial Sellers' Spot
7594

I use a few pairs of disposable chopsticks…

**kinda have to bevel the inner part as to not shave down the button cover

7595

Same as my S21Evo then… At 75/2000 floor for moon it stops doing even that.

1 Thank
7596

If I had one, I could probably fix it. Or even if I had someone with a pre-flash-y d3aa / dw3aa who would be willing to test firmware changes.

… and on that note, could someone with preflash issues try this?

https://toykeeper.net/torches/fsm/anduril2/anduril.2025-05-07.hank-emisar-d3aa.hex

The D3AA / DW3AA driver has a nfet specifically to absorb any preflashes. It activates that for 12ms any time the light turns on or off. This eats any leftover energy in the circuit to ensure that energy won’t go to the LEDs.

If I remove the nfet code, there is definitely a bright preflash. But with the nfet code there, the preflash is gone. I tried increasing the time to 50ms, and it did the opposite of a preflash… after turning on at moon level, it would then turn off for a moment before turning back on. But if I reduce the nfet time to 4ms, that “turn off for a moment” seems to be gone, and I don’t get any preflash either.

So if that’s what people are seeing, then maybe this build will help. I think perhaps the preflash absorber was too strong, so this reduces that. It may seem backward, but give it a try and let me know how it goes.

4 Thanks
7597

It’s all good! Anyone that never misread anything may throw the first stone – certainly not me! :slight_smile:

1 Thank
7598

Weeeeeird… you sure we’re talking about the same thing? Here’s what happens with mine (and @jon_slider, and quite a few others), complete with video showing it happening: [NLD] TiCu D3AA w sw45k - #7 by dmenezes

What firmware version is on yours?

Right now, 20240421.

7599

Count me in! But unless we’re talking about different things, I’m pretty sure the only way to ‘fix’ it by firmware would be to set the minimum brightness level at or above the point where the preflash stops happening.

Oh my Dog! It does sound like you might have fixed it! Or if you didn’t – well, at least es ben trovato :slight_smile:

Will test it on mine as soon as I get some leisure, and post the results here.

1 Thank
7600

Yes, that video is why I think the preflash absorber may have been too strong. That flash was nowhere near bright enough, and the dark period afterward nowhere near short enough, to be the real preflash that the nfet is there to get rid of… so it looks to me like the preflash absorber was turned up too high.

No, which is why I’m hoping you’ll be willing to test it.

1 Thank
7601

I will! I’m staring down a deadline and have to finish some urgent stuff here, but the temptation is too great! Give me a couple of minutes for me to dig out my flash adaptor and start my development VM, will come back with the results shortly!

7602

And here it is: https://i.imgur.com/mURzhq5.mp4

As you can see, unfortunately the preflash is still there, and still bright and clear :frowning:

Anything else I can help you test?

PS: just did a 15C with your test hex still on the light, and it blinks 2025-04-29 and not 2025-05-07 as implied in the filename. Is that relevant?

7603

I can try
I noticed my preflash are with the aux not with the main LEDs

7604

No, it’s just how the build system generates version numbers. It uses the last release + number of commits since then + an optional 1 to indicate it was built in a dirty repo (with uncommitted changes). So for this, the version number would include “2025-04-29+0+1”.

I can’t really tell from the video, but how bright is that preflash? The earlier video looked like the preflash was about the same brightness as moon.

Also, is this any different than how it was before, or does it seem the same?

7605

Thanks for the explanation re version in the blink vs in the filename.

The preflash looks like the same as before, and it’s quite a bit brighter than the lowest moonlight – that’s why it’s a big problem for me: it effectively turns the lowest moonlight levels useless, at least in terms of maintaining dark eye adaptation.

7606

Okay, then there are two things to try:

You’ve tried 12ms (default) and 4ms (yesterday’s build). These new test builds are set to 48ms and zero (those parts of the code are removed).

Do you see any difference at all between these two builds? If not, then your nfet simply isn’t working and there’s nothing I can do to fix it.

However, if one of the 4 builds is better than the others, then maybe it just needs the timing adjusted.

On mine, the 4ms version looks best. My D3AA and DW3AA follow a similar pattern:

  • 0ms: Bright preflash.
  • 4ms: No preflash, and almost no post-dip.
  • 12ms: No preflash, visible post-dip.
  • 48ms: No preflash. much longer post-dip.

I’m not sure what the right word is, but when it turns on at or near the correct level, then turns off for a bit before returning to the correct level, I’m calling that a post-dip. I’m not sure what causes it exactly, but I suspect the regulator chip may be overcompensating.

The theory is… the regulator tries to achieve a specific level of current. When the LED is running normally, this is pretty straightforward. But with the nfet enabled, it lets a large amount of current through no matter what, so the regulator keeps regulating down to try to fix it. Then the nfet shuts off and stops letting current through, and a small amount of residual power flows through the LEDs, and the regulator is still trying as hard as it can to reduce current… so the LEDs turn off. Then it takes the regulator a visible amount of time to correct itself.

So I’m also wondering if an even shorter nfet time might help. Like, instead of 4ms, maybe 1ms could be enough… and could reduce the post-dip.

When the regulator first turns on, it seems to start with some sort of default value, a “jump start” built in to the hardware. Then it regulates to whatever level was requested. So it makes a bright flash before it finds the correct level. The nfet is there to absorb the jump start and prevent the bright flash. However, if it absorbs too much, it messes with the regulator’s calibration and it takes a while to correct itself. So it needs to absorb the right amount. Too much one way or the other causes issues.

5 Thanks
7607

Do all D3AA/DW3AA’s use the same firmware, regardless of emitter?

7608

Sorry for the AWOL, domestic matters intervened.

Thanks for the explanations and additional test firmware , I will test them ASAP and let you know the results.

7609

AFAIK all D3AAs use the same firmware regardless of emitters. Can’t say about the DW3AAs as I never had one (and haven’t read much about them), but if I had to guess, I would say the same.

Different firmware in the same light usually happens because of different drivers, or when the manufacturer effs up something that need exceptional treatment (like the ts10-rgbaux vs ts10-rgbaux-lowfet firmware, where the latter was necessary to avoid burning the LEDs Wurkkos put in some TS10 batches/versions).

1 Thank
7610

And here they are:

In case the difference isn’t clear: with the 0ms version, I get the bright preflash as usual, but it’s of much shorter duration and the ‘dark interval’ between it and the moonlight is very very short (this is why the preflash doesn’t show well in the video, it’s so short that the camera can only manage to capture it as the single-frame “white shutter” we can see in the video).

With the 48ms version, we can clearly see the preflash and the ‘dark interval’ between it and the moonlight, as both are of much longer duration.

I think perhaps the 0ms preflash is brighter than the 48ms preflash, but I can’t be 100% sure as its level of brightness when compared to the 48ms is much less evident to me than the fact that they are both present.

Yes! I can clearly see the differences above. So, is there still hope for me and @jon_slider and everyone else affected by this?

Here, at least for my perception and use case, they all suck equally – they just suck in different ways.

Here the “post dip” (which I’ve called “dark interval” above) is clearly different between each version, and much in the same way you describe. BUT, that effing preflash is always clearly present :frowning:

TK, your level of knowledge about the electronics and workings of flashlight drivers is clearly way above my head :slight_smile: Seriously, your explanation kinda makes sense to my addled brain (after I read them thrice), but I suspect my true understanding about what you mean is more or less at the same level of my friend’s dogs when he tries to explain to them the specific differences between 4G and 5G cellular communications or the particular concepts behind Kant’s Critique of Pure Reason: he tells me they listen very attentively but are clearly not understanding a thing despite being perfectly happy to see pictures and video in his cell phone or tear Kant’s book to pieces :smiley:

If you’re willing to try, so am I !!! Just tell me what to do and I will do it report back. I’m willing to do everything to either have this fixed, or at least know for sure that no solution besides replacing the driver is possible.

Thanks again!

7611

Not every enthusiast likes rosy. Everything below -0.002 is too rosy for me. I will take domed 519a or B35AM instead.

11 Thanks
7612

Meanwhile, anything above -0.0050 is too yellow/green for me, especially below 4500K.

4 Thanks
7613

The metal switch on the Fireflies is pure class, it really would be a welcome addition to the Emisar, especially a D3AA because Fireflies don’t have a light that size.

Though the pics of the ‘black parts’ D3AA I saw (now disappeared) had a glossy black bezel exactly like that of FFL, we’re in danger of slipping into a dual evolution of the perfect light. The golden child of FFL and Hank :smiley:

4 Thanks