Could you please check the inner edges of the battery tube? The edges in mine are razor-sharp and damaged the shrink wrap of my batteries. I did not have this issue in an earlier D18 I bought several months ago.
Lux, this new D18 is the same as all my others in terms of build quality.
The edges inside are crisp, but not overly so. I gently load the cells so they donât get chafed in any way, but no excessive caution is required.
^ Sounds like the inner tube edges are not chamfered enough, or more than likely skippedâŚ
If you donât mind losing a little ano on that edge, its pretty easy to do yourself with a deburring tool
Frostcream, the point of threading without battery is to see if itâs the cut threads are screwed up, or just the added tension screwing you up (:
D4V3 21700 big brother 4x W2 could be fun?
For this, a LEDiL solution I think worthy to consider:
https://www.ledil.com/product-card/?product=C13483_ANNA-40-7-S
https://www.ledil.com/product-card/?product=C13484_ANNA-40-7-M
Suitable as both K6.1 or K4.3
Optics diameter is around 40mm, but only ~11mm tall.
Iâm holding out for tint ramping
Hank, take a look at this post
Itâs ugly :confounded:
D4S 21700 would be better, not only in appearance.
^ my thoughts too. The d4 is A perfect size for what it is meant for. Small EDC that fits well in the pocket. The KR4 21700 would Get my businessâŚ
It looks nice, would look a bit better with more cooling fins on the head, like at least 1-2 if not 3.
I just wish there was an upgraded D4s with lighted switch. Precious metals, sure, doesnât matter. I know now that I have a d4 (brass) with a lighted switch I wouldnât buy an aluminum version with a regular switch. It pains me that the D4sV2 switch is so nice (functionally) but isnât lighted. Itâs just a nice extra. Emisar does have the nicest side switches of all my lights though.
Is there any problem changing lens on D4V2 Ti? I want to buy extra lens but not confident about changing it by myself.
I just want a TiCu KR1âŚâŚâŚ
Hank sent me a message about the K9.3 lockout bug, so I investigated and fixed it. Weirdest bug Iâve seen in Anduril so far. Still not sure what exactly causes it, but it acts like a compiler bug or something. If I simply add some extra no-op instructions in the affected code path, the issue goes away.
Itâs weird because it only affects the K9.3, even though the lockout and aux LED code is exactly the same on a bunch of other lights. Also weird because it goes directly from lockout to âoffâ, and there is no code path which does that any more. So that would suggest itâs rebooting, but it doesnât do the boot-up blink. Also weird because only lockout is affected; the same configuration works in the regular âoffâ mode.
A steady color works fine in the low or high modes, and every pattern (including blinking) works fine in disco / rainbow / voltage modes, but a single color blinking fails:
1 Color |
Disco |
Rainbow |
Voltage |
|
---|---|---|---|---|
Off |
pass |
pass |
pass |
pass |
Low |
pass |
pass |
pass |
pass |
High |
pass |
pass |
pass |
pass |
Blinking |
fail |
pass |
pass |
pass |
But that âfailâ becomes a âpassâ if it has a few more bytes of padding, if it takes a few clock cycles longer to run.
Updated builds:
I doubt itâs a compiler bug, since those are very rare in practice. I probably did something wrong⌠but I havenât been able to figure out what. So I hope to give it a more proper fix if I can confirm whatâs causing it. Would be helpful to build it pre-fix on other platforms, to check if the compiler version is relevant. The buggy version was built with gcc-avr 1:5.4.0+Atmel3.6.1-2 from Debian.
Also, code for the K9.3 is now available in the anduril2 branch.
Hank sent me a message about the K9.3 lockout bug, so I investigated and fixed it. Weirdest bug Iâve seen in Anduril so far. Still not sure what exactly causes it, but it acts like a compiler bug or something. If I simply add some extra no-op instructions in the affected code path, the issue goes away.
Itâs weird because it only affects the K9.3, even though the lockout and aux LED code is exactly the same on a bunch of other lights. Also weird because it goes directly from lockout to âoffâ, and there is no code path which does that any more. So that would suggest itâs rebooting, but it doesnât do the boot-up blink. Also weird because only lockout is affected; the same configuration works in the regular âoffâ mode.
A steady color works fine in the low or high modes, and every pattern (including blinking) works fine in disco / rainbow / voltage modes, but a single color blinking fails:
1 Color
Disco
Rainbow
Voltage
Off
pass
pass
pass
pass
Low
pass
pass
pass
pass
High
pass
pass
pass
pass
Blinking
fail
pass
pass
pass
But that âfailâ becomes a âpassâ if it has a few more bytes of padding, if it takes a few clock cycles longer to run.
Updated builds:
I doubt itâs a compiler bug, since those are very rare in practice. I probably did something wrong⌠but I havenât been able to figure out what. So I hope to give it a more proper fix if I can confirm whatâs causing it. Would be helpful to build it pre-fix on other platforms, to check if the compiler version is relevant. The buggy version was built with gcc-avr 1:5.4.0+Atmel3.6.1-2 from Debian.
Also, code for the K9.3 is now available in the anduril2 branch.
Glad to see you back ToyKeeper, i think we did not see you around for a while, thank you for fix!
Hank sent me a message about the K9.3 lockout bug, so I investigated and fixed it. Weirdest bug Iâve seen in Anduril so far. Still not sure what exactly causes it, but it acts like a compiler bug or something. If I simply add some extra no-op instructions in the affected code path, the issue goes away.
Itâs weird because it only affects the K9.3, even though the lockout and aux LED code is exactly the same on a bunch of other lights. Also weird because it goes directly from lockout to âoffâ, and there is no code path which does that any more. So that would suggest itâs rebooting, but it doesnât do the boot-up blink. Also weird because only lockout is affected; the same configuration works in the regular âoffâ mode.
A steady color works fine in the low or high modes, and every pattern (including blinking) works fine in disco / rainbow / voltage modes, but a single color blinking fails:
1 Color
Disco
Rainbow
Voltage
Off
pass
pass
pass
pass
Low
pass
pass
pass
pass
High
pass
pass
pass
pass
Blinking
fail
pass
pass
pass
But that âfailâ becomes a âpassâ if it has a few more bytes of padding, if it takes a few clock cycles longer to run.
Updated builds:
I doubt itâs a compiler bug, since those are very rare in practice. I probably did something wrong⌠but I havenât been able to figure out what. So I hope to give it a more proper fix if I can confirm whatâs causing it. Would be helpful to build it pre-fix on other platforms, to check if the compiler version is relevant. The buggy version was built with gcc-avr 1:5.4.0+Atmel3.6.1-2 from Debian.
Also, code for the K9.3 is now available in the anduril2 branch.
Good to see you!
Is there any way to safely (non-destructively) dismantle the USB charging circuit if I wanted to reach the positive terminal of the battery tube, i.e. the opposite side of what you see on the picture? Call me a cleaning maniac but I frequently clean contact parts like springs, brass buttons, tube ends etc. with alcohol to have the lowest possible contact resistance between battery and circuitry. Fiddling with a cotton swab in the tube's obscurity is maybe not the best solution. ;-)
hank, are the D4V2 (black and grey) out of stock?
Will they be available again anytime soon?
Thanks!
hank, are the D4V2 (black and grey) out of stock?
Will they be available again anytime soon?Thanks!
This! + xp-l hi 5D and 219c 4000k
Received my copper KR1 today, its great. i know this is probably too heavy for some, but i am 100% ok with it. i was worried that i picked the sst40 emitter, but i have been messing with it the last 3 hours of darkness and its a great all around edc beam in the KR1 - 5000k, very nice spill, throws very well (i feel better then the claimed 29KCD), and takes well over 2 minutes to heat up on turbo. i donât know if the extended turbo is the heavy copper body, the emitter, or both but its great. heres some pics for those who care. finish is beautifully done. Also, shipping was incredible. got it to CT, USA in 15 DAYS! my quickest shipment from China in the last year. I didnât pay extra for fast shipping.
Thanks Hank!