Emisar D4S review

Ah, but is this one a good candidate to flash? Will Anduril run the auxillary lights?

Yes, currently it’s the best one since you can flash it without a full disassembly.

And yes, aux LEDs work but they have different shortcuts to change the modes

TK must’ve upgraded Anduril since my last download.

I had the D4S fully disassembled in short order, flashing the MCU wouldn’t be a problem and I’ve thought about upgrading the FET as well but haven’t yet. I’m already set up to flash MMU boards so plugging in to the D4S driver shouldn’t be difficult either, just want to find out if the auxillary led’s are fully supported before I change anything. I keep messing up and going into Tactical momentary lockout as I’m used to 4 clicks doing lockout on Anduril . Ugh.

Edit: Now running Anduril-D4S. Wondering where to find a diagram on how to tune the auxillary LED’s, can’t seem to locate that… Thank you once again TK, awesome work and very much appreciated!

When I flashed Anduril it seemed simplest to remove the driver to do so. In the process I went ahead and tried to tone it down a bit and swapped the 18ga leads put in yesterday for smaller 20ga Teflon coated leads. This ended up with a whole 276 lumen drop, so not enough to even notice. Oh well. An attempt was made… lol

Yes, I got Anduril working first, then created RampingIOS V3 by removing and rearranging things until it matched Hank’s spec.

Same as the Q8: (Q8 and GT builds of Anduril, or anything with a lighted button)

  1. Go to lockout mode.
  2. To change aux LED behavior…
    • Click 3 times to change lockout mode aux LED settings.
    • Click 3 times and hold the last press to change “off” mode aux LED settings. Release when it gets to the setting you want.

The modes are: off, low, high, or blinking.

Compared to a Q8, the main firmware difference is that the aux LEDs won’t turn on unless the main LEDs are off.

Is it a MMU-style chip now? I haven’t taken the driver out of mine yet to look…

This isn’t as good as Lexel’s flashing adapter, but I found the D4S was pretty easy to reflash with a usbasp, a ribbon cable, and some solid-core wire:


what gauge wire are you putting in the flash holes?

Thanks!

I merely meant that I have wires set up for the board that flashes the MMU for a 10mm driver. So I have tinned wires set up on the USB ASP. They’re set up in a 4x2 arrangement though, not the 3x3 of the Emisar D4S, so it would still require some finagling for me to be able to flash it in the light, hence why I pulled the driver to flash it. Meant to also change the FET but did not, having some issues today not flashlight related…

Thank you for pointing me at that UI. I had already figured out the triple clicks to change levels in lockout but forgot about the “hold” for on-time use. prc8 it.

With Anduril. NarsilM doesn’t have those settings.

I’m not sure what gauge the wires are. I found it in a drawer long ago, and there is no label anywhere. I’m guessing 26 gauge. Maybe 24.

I should probably add it to the diagram somewhere, but there isn’t a good place to put it… and it’s only relevant to some of the supported hosts. So it remains sort of hidden.

Those guesses are good enough to keep my scavenging to a minimum…

assuming bare male jumper pins are too big?

Thanks!

Have you verified that these DuPont pins will fit in the programming holes of the D4S? Because all of my DuPont connector pins are too fat for the holes drilled in the D4S board, and I had to build a programming harness with some solderless bread board jumpers that did fit.

I was originally going to use some jumper pins, but I couldn’t find any in my parts bins. So I used some random wire I found instead.

Hopefully Lexel’s flashing connector will become pretty standard soon, but for now things are a bit more ad-hoc. I refer to the pinouts in flashlightwiki whenever I flash the D4S. This is fine for one-time or occasional flashing, but inconvenient during development. So I still do most of my development on a decapitated Emisar D4 with its brains hanging out. It works fine as long as I don’t need to do thermal testing or hardware-specific stuff.

Igor, bring me some fresh brains for my experiments! :confounded:

The command: avrdude -p t13 -c usbasp -u -e will erase the contents of the chip so that it can be re-written to. Finally, flash the driver with the new firmware: (change the star.hex part to whatever you named your .hex file) avrdude -p t13 -c usbasp -u -Uflash:w:star.hex:a -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m Be mindful of the value of the fuses; they may change from firmware to firmware. In the above example, the “low fuse” is 0×75 and the “high fuse” is 0xff. Generally all firmwares will state the proper fuse values in the .c file.

Are fuse considerations/command for flashing the D4S?

or just the "avrdude.exe -p attiny85 -c usbasp -Uflash:w:anduril.2018-08-22.EMISAR_D4S.hex:a" command as is?

thanks!

Don’t do that. It’s unnecessary and it risks bricking the MCU. Hoop should really remove that part of the tutorial.

Also, don’t use “-p t13” on a tiny85. It can also cause problems.

I recommend using bin/flash-85.sh, or copying the command in that script and replacing the filename.

Some firmwares specify fuses within, and sometimes what they specify isn’t correct. I’ve tried to include a flash.sh script inside any project with non-default settings, and otherwise it’s probably best to use one of the bin/flash*.sh scripts matching the MCU type.

I should probably go through the entire repository sometime to check that the comments at the top of each file are actually correct, because some of them aren’t. In some cases, it’s just copy/pasted from another project and was never updated.

In any case, there is no need to erase the ROM before writing new data. At best, it’s redundant. And at worst, a couple people reported that the chip wouldn’t respond any more afterward.

Thanks for the caution.

The problem for me is I’ve read all the flashing posts, and have yet to find a succinct step by step foolproof process for a particular light that didn’t also include general flashing info—that might be useful to someone who knows what they are doing—or what all the specific flags and commands mean. I know zero about this and just hope to find the simplest way to flash my DS4 (as it has easy access to the driver and anduril is so alluring).

Just ordered the ribbon cable and the usbisp and hope to try it soon!

Thank you!

Mine always performs the erase command before flashing and I’ve yet to brick an MCU, which probably means the next one I flash will jam up big time! I’ve only built a few hundred drivers though, so I’m still pretty new to all this.

Since the code formatting changed I don’t make any adjustments at all. I used to change power levels and such in the A6 firmware, but somewhere along the way the code started looking like an instruction manual for flying Alien spacecraft so I leave it strictly alone now.

This is about as short as possible, for someone who hasn’t done it before. I wouldn’t call it foolproof though:

  1. Get a usbasp device, a ribbon cable, and some solid-core wire or jumper pins which fit into the D4S flashing holes. Hardware links are available at the Link in my signature.
  2. Install avrdude.
  3. Download a pre-compiled .hex file for the D4S. Whatever is most recent here.
  4. Connect the usbasp to the D4S driver using the ribbon cable and pins, according to the pinouts listed in the wiki.
  5. Run “bin/flash-85.sh anduril.DATE.EMISAR_D4S.hex” or, in Windows, copy the command inside of flash-85.sh, replace the filename, and run it.

If avrdude reports success, you’re done! Pull the pins out and use the light.

For other lights, the instructions are similar except they involve a SOIC8 clip instead of jumper pins, and they often involve un-soldering things in order to make the driver accessible.

With Lexel’s flashing key, it replaces the jumper pins and eliminates the need to look up pinouts. Acquiring a key might be tricky, but it makes flashing very quick and easy.