And for your modded D4V2…… IIRC, that is the same combination of emitters you used in the modded FireFlies E07 I bought from you.
A very nice combination too I might add!!!
A configuration file is a list of "key=value" properties. The value of a property can be expressed using the value of another property by putting its name inside brackets "{" "}". For example:
In this example the property recipe.c.o.pattern will be set to /tools/g++_arm_none_eabi/bin/arm-none-eabi-gcc that is the composition of the two properties compiler.path and compiler.c.cmd.
Automatic property override for specific OS
We can specify an OS-specific value for a property. For example the following file:
will set the property tools.bossac.cmd to the value bossac on Linux and Mac OS and bossac.exe on Windows.
Global Predefined properties
The Arduino IDE sets the following properties that can be used globally in all configurations files:
{runtime.platform.path} - the absolute path of the platform folder (i.e. the folder containing boards.txt)
{runtime.hardware.path} - the absolute path of the hardware folder (i.e. the folder containing the current platform folder)
{runtime.ide.path} - the absolute path of the Arduino IDE folder
{runtime.ide.version} - the version number of the Arduino IDE as a number (this uses two digits per version
number component, and removes the points and leading zeroes, so Arduino IDE 1.8.3
becomes 01.08.03 which becomes runtime.ide.version=10803).
{ide_version} - Compatibility alias for {runtime.ide.version}
{runtime.os} - the running OS ("linux", "windows", "macosx")
I’ve seen your post with a modded D4V2. Thanks for sharing your experience. Could you describe the beam profile(spill/throw) after reflowing the leds, how is it compared to SST20?
Bad switch has been proposed already before MM bug has been discovered. Highly unlikeky both owners would not have noticed this before and discovered it while performing the same action.
But the two lights are not interchangeable firmware wise to my knowledge, the D4V2 has an t1634 MCU while the FW3A has a t85. The new firmware that showed the muggle glitch doesn’t work on the FW3A. So unless much more than the firmware was changed on the Lumintop light it’s virtually impossible it has the same problem. And obviously the glitch is resolved anyway, so …
I was thinking about a second bug due to the nature of this problem seen in three Anduril flashlights. Paranoia maybe. Or wishful thinking - flashing a bugfree firmware ist quite sexy compared to having a f/l with a hardware problem.
I’ve got 15 lights running Anduril and have built multiples for a couple of my friends. This new Emisar with the t1634 MCU was the first bug I’ve seen and it’s been dealt with.
No glitches, even, running a t85 Master with 4 Slaves in a 17 emitter 23,000 lumen build.
You also may have to take into account the influence of the front glass lens. I have 2 D4S’s, one came with a coated lens, the other with a clear one. The AR shifts the tint of the SST-20 distinctly to green. So there positively is a “front glass lottery” here. I confirmed with Hank that may happen and ordered a clear D4S lens with my D4V2.
I just placed an order for a new D4V2 on July 25th and am waiting (impatiently ) for it to ship. I’m guessing it’s safe to assume any new units shipped after July 19th will already have the updated firmware (with fixed muggle issue) or should I just go ahead and pick up a reflash kit?