Emisar D4V2 Flash Kit Instructions (Official How To)

Took quite a bit of learning and time but it was more than worth it. Thanks Terry Oregon for this guide.

Finally got around to trying this. Used Win10 on the work laptop since I don’t have an android phone and don’t feel like installing Xcode or homebrew on the iMac.

Two verification fail errors using reading glasses and pushing halfway down. Then, using the Optivisor and pushing all the way down on the pogo pins: success. Yay.

Not sure if I did the factory reset properly. Held it down waiting for a flash, but it did a bunch of things and I just kept holding it down until a few seconds after it stopped doing anything different. I hadn’t changed it from defaults apart from aux settings. Those reset, so I guess it all did.

How to do thermal config? Tried the diagram and could get into config mode but failed at setting anything properly. Haven’t played with anything but Zebralights for a long time now. I use the FW3A more than my 3 Emisar D4, but in only the most basic way. The D4V2 has spent the last months in aux high blue mode on top of a clear plastic decoration. It is very pretty. I have the D4S, with cyan aux LEDs on the other side of the decoration. Even prettier. Before that, I mostly used the D4V2 in candle mode with an hour timer to go to sleep. Beautiful, but now I seem to have a large collection of LED candles vs just the one, so not so much need.

Now I see there’s a D4SV2, along with a FW21 I just ordered (bah, no 3000 or 4000K option). Lovely.

So, anyway, had to dig up the text manual for Anduril and now I get it. Wonderful, no more bug in a mode I never use, but since I waited so long I get … some other fixes. And satisfaction. I’ve been playing a lot with an Arduino Mega and the much nicer ESP32 (built in WiFi!) but command line is a bit more hardcore than the Arduino IDE. There is a GUI for avrdude but I haven’t played with it. I’d kinda like to flash my two D4 to Anduril but I’m not taking them apart to get to the chip.

The D4S has pads in a different arrangement I think. And I have no idea if it is D4 type or Anduril type interface. Probably will leave it alone unless I could buy a set of pogos (or a kit thereof) that fit it.

Anyway, thanks to all involved. Cool light, and had fun with the little bit of effort it took to reprogram it.

For anyone else, here’s the bit of instructions I need that wasn’t in this thread (or I didn’t see it):

Every config mode has the same interface. The menu has one or more
options the user can configure, and it will go through them in order.
For each menu item, the light will follow the same pattern:

- Blink one or more times, corresponding to the item number.

- Stutter or “buzz” quickly between two brightness levels for a few
seconds. This indicates that the user can click one or more times
to enter a number. It will keep buzzing until the user stops
clicking, so there is no need to hurry.

- Pause, and then go to the next option.

After the light has gone through all of the menu options, it should
return to whatever mode the light was in before entering the config

If the user doesn’t press a button during a menu item’s “buzz” phase,
that item remains unchanged from its previous value.

Maybe instead of using commands in Windows maybe something like AVRDUDESS could be used as it has an interface?

What do you think?

Just flashed attiny85 with Zflasher, works like a charm

Thank you for the guide was able to update the d4v2 an d1.

These are excellent instructions, Terry! Thank you for all the work you put into making them clear, detailed, well-illustrated, and easy to follow! As someone with an aptitude for and some experience with technical writing, and writing instructions in particular, I can appreciate good work.

I used your instructions to update the firmware on my D4V2 and I ran into only one difficulty, which was my mistake, but I want to share it in case anyone else has the same trouble.

First, though, I want to remind everyone of the importance of performing the factory reset after updating, or at least rechecking the thermometer calibration. My flashlight’s thermometer was calibrated correctly when I first checked it, and while I can’t remember, that was probably before the update. I did not perform a factory reset after the update, and I just found that it was reading 8° low! After the factory reset I just performed, the thermometer was correct to within a couple degrees. I then calibrated it a little more accurately.

Anyway, while first installing AVRDUDE, I installed it into the AVRDUDE directory I created, carelessly deleting the auto-created MHV AVR Tools subdirectory in the Setup dialog’s installation path (I changed the installation path to “c:\AVRDUDE” instead of “c:\AVRDUDE\MHV AVR Tools”). For some reason, this seemed to cause avrdude.exe not to be found. And I looked in the directory and it was indeed not there. It is, in fact, in the bin subdirectory, not in the main install directory, and the command window found and ran it when I installed the application into the MHV AVR Tools subdirectory that was auto-created. I finally figured that out during one of my reinstallation attempts and then it all ran correctly.

If you lose connection to the flashlight during the update and get an infinite loop of error messages, don’t panic. Just close and reopen the command windows and try again (maybe I only needed to reconnect the POGO pins and it would have automatically resumed flashing - I didn’t try it). That happened to me and the firmware flashed correctly on the second attempt.

Also, I want to mention for anyone using these instructions that the links to ToyKeeper’s Andúril hex files in these instructions will become outdated as TK releases new versions. I used the base, directory URL of the files (Index of /torches/fsm) and found a later version to download. The file name to look for is in the format “anduril.[YYYY-MM-DD].emisar-d4v2.hex”, and if you want the Nichia 219 version, look for “–219” after the flashlight model.

For anyone interested, here is my review of the Emisar D4V2: Emisar D4V2 Review Supplement (the pickier details) (Emisar D4V2 Review Supplement (the pickier details))

Thanks, I updated my instructions to include Toykeeper's list of latest files.

I guess “anduril.2020-04-13.emisar-d4v2-nofet.hex” is the latest FW for D4V2, right? Is the new thermal management code contained? What means “nofet”?

I think my FW contains a minor bug with voltage measurement. Also, I’d like to have shorter beacon pulses. But: I have 0-8-15-users PID code and want to keep this functionality. Can I have everything, please :smiley: .

No, it’s not the latest firmware. “nofet” means that it will use only the 7135 and you will get very limited output. The latest version is anduril.2020-03-18.emisar-d4v2.hex.

It has new code for thermal regulation. But it’s not the code from 0-8-15-user because it had some major bugs, so ToyKeeper wrote something based on his code. The problems you noticed with voltage measurement are a result of the bugs in 0-8-15-user’s code.

Ok, thanks a lot. I’ll flash it with that version.

Edit: Works, excellent :+1:

Is there a no 7135 version?

Does anyone know what the anduril.2020-07-08.emisar-d4v2.5 firmware is for?

I tried flashing it to my D4V2 Ti thinking it was the right one and my flashlight aux lights would go through the rainbow then shut off. After being frustrated for a while thinking I bricked my light, I finally tried the next older version anduril.2020-03-18.emisar-d4v2 and that worked.

Emisar D4v2.5 -> Emisar D4v2 with Noctigon KR4 driver
Taken from TK’s map

Ok that makes sense. Thanks!

It wasn’t buggy. 0-8-15 User put a lot of work into it and it seemed to function well. He had some really good ideas, and some of those ideas are being used now. I don’t recall seeing any significant issues with voltage measurement in it.

The issues were more qualitative. It used techniques which were expensive, awkward, and incompatible with some things I’m hoping to do in the future. A big part of the interrupt rewrite effort was to reduce the number of clock cycles spent in critical code paths, to eliminate timing-related issues and allow software-based PWM to work. However, the 0815 code significantly increased the time spent in interrupt handlers… which works against some future goals. It also did some computationally-odd things like using decimal math instead of binary (powers of 10 instead of powers of 2), and introduced several other little things I wanted to fix. So I started trying to patch it and ended up rewriting it completely.

I think his version probably had somewhat better thermal response on the devices it was designed for. However, it needed more adjustment to work on other devices, and wasn’t a big enough improvement to justify the cost. It was a little better on some devices, a little worse on others.

While working on it, I did a lot of testing on the underlying measurement techniques… and I found that the attiny chips have a ridiculous amount of noise in their sensor readings when the main LEDs are on. In theory, the sensors can be oversampled to reduce noise and increase the effective resolution… and when the main LEDs are off, oversampling actually works (on some drivers). But in practice, I soon came to understand why he used 2560X oversampling for a relatively small increase in resolution, even though 64X should have been more than enough… it was because of a crazy amount of noise in the signal.

And that was on good drivers. On not-so-good drivers, there was still too much noise for it to function correctly.

So I dropped the extra resolution and tried prioritizing noise reduction instead. And most of the issues I’ve seen over the past few years… just disappeared. Even on the noisiest, lowest-quality drivers I tested, the noise issues seem to be gone.

The end result is far from perfect, but it’s a solid enough improvement over older versions that I finally merged it into trunk.

TL;DR: 0-8-15 User did good work, and I want to recognize his contributions. Things would probably still be broken without his help.

I guess that could have been a lot shorter… Basically, there were no major bugs in 0-8-15’s code; I’m just a picky bastard and kind of a terrible maintainer. So if anyone’s going to complain, they should complain about me instead of the awesome people who reached out to help. :slight_smile:

Yeah, sorry about the “major” bugs. But there were noticeable issues like delayed measurements. Btw, haven’t heard from 0-8-15-user since he finished his code…

TK, Sammy, the problem was (for me) an apparently wrong voltage reading after the light was switched off. Basically, it showed the blue aux for a couple of seconds even on low voltage. Wasn’t really a problem, but I updated to enojoy the new aux mode for voltage indication.

I’m very happy about the 0-8-15-inspired thermal management/regulation code! :+1:

Interesting. Usually when it’s off, it does the opposite… it’ll show low voltage for a few seconds after shutoff, then recover to a more accurate reading. That happens due to the measurement happening about half a second earlier while the battery is still under load, and then it waits a few seconds after shutoff before checking again.

Measuring high then adjusting down is odd.

So I ordered the brass D4v2 with the E21A and wanted to flash it to the latest version. Do I go with the Nichia or non-Nichia hex file?

Also, I noticed that if I were to set the moonlight mode to 1 click (lowest), when I would turn it on, it fades on. Pretty neat! BUT, when I step up in brightness and then back down to moonlight, the emitters no longer shine. It would take a couple seconds before it fades back on but sometimes it’s just not lit and I’d have to turn it off and back on again. Is this normal?

Is there a way to tell what version of Anduril is installed?