did you do next day shipping from china or something?!
@Tom Tom
@Tom E
Thanks for all the information. I’m quite interested in the topics especially since I understand how many mechanical things work but haven’t delved into electronics before. Simply learning how to do non-complex electrical work was enough for me so far. Lol as you may have predicted most of your responses left me looking like this:
Nevertheless, you also provided some great resources for my drivers 101 course which I’m excited to dig into! Thanks for the help!
Lol When I tell people I’m a member of a flashlight enthusiast forum the looks I get are priceless. Then I start by explaining the experts on here are actually consulted or contracted to design components or entire lights with input from the community and people are like wow a market that takes direct feedback from the consumer? Then when I tell them I’m learning about electronic components, circuit boards & drivers, they look at me like maybe it could make sense and then they laugh and say I have a fetish for flashlights. lol the world will never understand us but I find it fascinating how much I’m learning here.
Interesting.
If it has the non-PWM levels at 65 and 120, that would be the 2019-01-05 firmware… produced without even having much idea what the hardware would be. If you have the ability to do so, it might be worth updating the firmware at some point. I should have the code uploaded soon; was waiting to make sure it’s okay to publish first.
The versions are:
- 2019-01-05: No-PWM levels at 65 and 120. Turbo step-down 120. Super early version meant only for testing during hardware development. (and, apparently, for toobadorz)
- 2019-03-18a: No-PWM levels at 55 and 110. Turbo step-down 120. Testing only.
- 2019-03-18b: No-PWM levels at 50 and 100. Turbo step-down 110. Testing only.
- 2019-03-21: No-PWM levels at 50 and 100. Turbo step-down 125. Intended for production use.
I had a bit of difficulty flashing mine; the attiny85 wouldn’t respond. I’m guessing it may have accidentally had the lock bits set or something… so I removed it and put a fresh chip on to finish development. That shouldn’t be an issue for production lights though; probably just a typo when putting together an early sample unit.
Also, when taking the driver out to reflash, it’s important to be gentle with the switch wires. Unsolder the LED wires, push them through the MCPCB, lift the driver a little on the edge opposite the switch, then flip it upside-down by rotating it around the switch wires. This should make the MCU easy to access, without tugging on the short delicate wires still attached to the switch.
Hmmm. Toobadorz, can you tell us more about how you received your D18 so early? I placed an early pre-order and just received a shipping notice today. I hope Hank is using TK’s newest firmware from 3/21 in all the production models.
Thanks! I’m reminding Hank of using the latest firmware when shipping the next D18 to me.
That ’s because I live in Asia, and it took around 4 days to receive that light.
I hope the lights shipping now will have the production firmware and not some early test one.
That would be a first then! :weary:
I sent an email to Hank asking this question, will report back.
The fw can blink out the revision, right? So it should be a pretty straightforward thing to check the version the light came with.
Funny how history repeats itself as back when the M43 was released inferion was complaining about China not using the latest version in the production. There were only minor bugfixes though and not an absolute alpha sent into air. Hope it gets fixed soon by Hank if it a real issue.
I’m fairly sure you are referring to Narsil blinking out version. I don’t believe Anduril has that
The Emisar D18 Code link is broken here: https://intl-outdoor.com/emisar-d18-318650-14000lm-flashlight-p-939.html, but points to a .hex file with 2019-03-18 'b' in it's name.
Even for Narsil, there's so many changes along the way in v1.2 or v1.3, the blinking doesn't help too much. I should have bumped it more frequently, or added a 3rd digit. A hash code could be used but that's even more complicated.
I can’t remember, did anyone mention why Hank decided to use Anduril instead of his usual custom D4 firmware on this light?
Did he give in to what customers prefer?
Ramping IOS is an abbreviated Anduril that TK made for Hank, so it’s only logical that he step up to the full version in the top tier offering flashlight.
I would think TK convinced him. I believe he wanted to keep the UI as simple as possible, which makes sense for general sales, but these lights are getting pretty specialized to demanding (BLF?) users 
.
One of the greatest things about Anduril for me is the ability to set the ceiling ramp. It allows a reasonably safe/sane top level for normal use and a double click to Turbo for max output. This makes a hotrod a useful usable light without compromise. And of course, easily adjustable on the fly…
And similarly, not memorizing turbo!
With the downside of not being able to use turbo for momentary unless you set ceiling to turbo.
Does this have e.g. a pogo-pin interface on the back of the driver, so the manufacturer (or user, given sufficient skills, and a DIY cable) can re-flash without having to tear it apart, never mind desolder and replace an MCU that is locked by fuses ?
Otherwise I don’t see how this timeline is possible, considering how few days since TK sent her latest revision, and the need to build the first batch in time to get the first orders out.
In production the batch of MCUs is usually programmed, rapidly, on a dedicated expensive programmer, in house or contracted out, then soldered on together with the rest of the driver gubbins. Which has to be scheduled in to the manufacturing timeline.
Rarely are they put in blank, relying on individual in-situ programming at the last minute. As a bare minimum they would have a basic test-harness so the rest of the board could be checked out. Or just keep fingers crossed that great QC means they are all perfect, with no chance to detect systematic defects that might affect the whole batch.
Best way to do this would be to complete them with early firmware to check them, then re-flash in-situ just before they go out.
Cutting it fine. And adding cost, assuming that it was possible, and they were set up and trained to do so, and the new code had been received in good time, checked, entered into configuration control, and passed down the line.
Aside: firmware developers sometimes seem to expect to be able to continue refining their code up to and beyond hard deadlines by when manufacturing need it. Or think production should stop, whilst they continue wrestling with it. Some take a blase attitude and keep tweaking beyond then, even though that ship has sailed.
Manufacturers really don’t like that. As with other aspects of design, there comes a point where it has to be frozen, made and shipped.
Also a period of pre-production testing by other knowledgeable people may expose unexpected issues that a single developer working in isolation has missed, or which did not happen in their single development prototype.
That seems to be the job for early-adopters here.
Meanwhile Hank has beaten the MF01S to market by a good margin, and should do well. It should be a good torch.
Not gonna lie I was waiting for this wall of text to go off the rails, and it never did. Bravo 