Good point. When I had my D4v2 it had screws in the MCPCB.
My TO50R has screws as well and seems to have have good thermal path from the emitters because the heat can be felt around the entire head of the light very soon after turning it to high or turbo.
I have many D4 of various different models including 2 of the first generation model without screws.
The head heats up at about the same rate in all of them. The screws seem to make no difference at all.
If I recall correctly, the screws were added because people were moving the O-ring on the original D4, which made it so there was no pressure on the MCPCB… and then people were finding that their lights would overheat and damage the 219C emitters.
The screws hold down the MCPCB tight even if other parts are moved (or removed, like for a mule).
ToyKeeper, any thought to adding a Beacon Cfg 2 that you could set N for duration of light on while in beacon, not just the interval between on but the time in which it’s on for beacon? I prefer a shorter burst of light for beacon than default but could see where some would want it up to a couple seconds.
You recall well, some of the MCPCBs had poor contact with the shelf and had issues. With the screws the MCPCB loosing contacting the the shelf is solved, so then people could unscrew the bezel and change optics, use as mule, etc.
I got my D4V2 and I wrote a review of it here on BLF. The flashlight works well on the laptop 18650 cells. It can run on turbo, somehow, and the cells don’t get hot. I also conducted some runtime tests for a few modes.
My D4V2 and KR4 both flashed with latest version, in rainbow mode the KR4 changes faster than D4V2, how can I make them the same? Why is this? Different MCU?
The rainbow mode was originally 0.5s per frame, but people thought that was too fast so I changed it to 2s per frame. However, while finishing up the KR4 firmware, Hank asked me to change it back to the faster speed. Not sure why, but I’m guessing because it’s more eye-catching.
There’s a setting in the config file which can set the speed per config. Use one of these lines:
#define RGB_RAINBOW_SPEED 0x03 // 0.5s per color
#define RGB_RAINBOW_SPEED 0x07 // 1s per color
#define RGB_RAINBOW_SPEED 0x0f // 2s per color
Thanks TK. Is there a thread on how to compile my own hex? I don’t think I’ve seen one yet. I prefer the 2s frame.
Great, thanks!
There are a few, depending on which tools you want to use. If you’re using Windows, I’d suggest installing WSL (Windows Subsystem for Linux) with Debian or Ubuntu inside, and then following the README file in the firmware repository. Basically, run a few commands to install the tools and download the code, then go into the anduril directory and run “make”.
Some of the tutorial threads are also linked from the README file, but I’m not sure if it’s up to date with the latest info from BLF.
Been away from the forum for half a year, renovating a new house we bought. Back a day and already ordered a ti d4v2. Good to be back 
Thanks TK didn’t know you can do that, installed amtel studio and loaded up the repository but couldn’t get it to make anything. Will try with the WSL route.
I got and posted a full Atmel Studio version of Anduril - didn't take too long to port, for me that is. But now, it's my custom branch of the December version, so not current.
I would guess that the laptop cells don’t permit a high enough amp draw for the LED to reach max output (in both light and heat), which would allow it to maintain steady output without thermal stepdown. Your eyes may never know what they’re missing, though, since they tend to adjust. Just don’t buy another D4V2 and run a high-amp cell in it, side by side with the first one, or you might be spoiled…. for ten seconds or so. 
Someone should experiment to see if there’s a particular step we can select as our top output (at, say, 72 degrees ambient, handheld) which would prevent thermal stepdown.
The default was originally 500ms on, but that seemed too long so it was changed to 100ms.
There’s plenty of room to add more stuff in the attiny1634 versions, but on attiny85 the ROM is already full. So I’ve been avoiding adding much. However, the beacon time is relatively simple to change in the source code. Look for “beacon_mode_iter()” and change both instances of “100” to a different value.
Is there a way to turn the switch light off on the ti version?
You can disable it in the code and then reflash the firmware.
Thanks I might do that when mine arrives. Feels a bit to much.
It actually does step down on Turbo starting gradually at about 20 seconds, and severely at about 30 seconds. Even Level 6 steps down eventually. I think these cells must be delivering much more than 4.4A. It may not be good for them, but I have 9 of them, and they were free, and I rarely use the brightest modes, so I’m not worried about it. They don’t get hot, even after 5 minutes on Turbo or 20 minutes on Level 7, so I don’t think there is any danger of violent failure.
I knew I wasn’t going to get the full potential out of this light with these cells, and since I don’t need ultra-brightness from it (except to show off), I’m ok with that. It would be fun to see what a 15A cell could do, though.
Step 5 of Stepped Mode was the highest step that did not require thermal throttling at room temperature, but you’re probably talking about fine-tuning the ramping max using the 255 possible increments. I was also not holding the light for that test. Step 6, handheld, and with about a 50° thermal limit, did not step down. It got fairly hot, but not painfully so. Somewhere between those two steps, then, would be what you’d want if you want to keep the default 45° limit. This is all using the SST-20 4000k emitter, though.