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 
+1 to the above. I've been involved in embedded systems on and off for 40 years or so. But that's typical procedure over here. For the low volume runs over there, maybe, maybe not. Where I work now we adapt when we need to, and can't always have it all fully tested before getting to the chip/board vendor sourcing. it was always the intention at the time, but things happen...
I believe these don't have the exposed pogo-pins on the drivers. You would think they need a couple weeks, but all depends - they can assemble stuff pretty quick. It's a good thing and bad thing as we all know being on the end product side - maybe have 2nd/3rd assembly sources lined up in case the main supplier is busy, all depends. I do have trust in Hank though - he's a pretty detailed, quality mind set guy, from my dealings with him, and even in orders of qty 50-100 LED's, very little if any bad parts, and has his own tough QC. Going back to 2012, I probably ordered $1000's of stuff from him.
Aren’t Emisar flashlights designed without retaining ring(s) so far ?
I only bought a D4 but if drivers are generally glued on all models, I better hope that there is a pogo-pin alternative to the sofirn SF36 glued driver’s removing method :smiling_imp:
By djozz (my hero 
)
Wow haha! Looks like a makeshift hammer made from a crowbar and the SF36’s head.
Next step is to grip the handle of the hammer and swing it overhead, then smash the head down onto some concrete as hard as you can right? 
The D4S has pogo pins.
Are drivers hard to get out? (I don’t have any Emisar lights)
If the D4S has pogo pins, I wouldn’t be too surprised if the D18 also has pogo pins. :sunglasses:
Removing the driver from the D4 isn’t too hard, but isn’t easy either. I do the following procedure:
- Remove the bezel, lens and optic. Desolder and remove the star
- Insert something pointy into the driver wire hole with the pointy end pressing onto an empty flat area of the driver. Some people recommend toothpicks, but that didn’t work for me. I know use a metal probe similar to an awl. Seems to work fine without damaging the driver.
- Tap the back of your pointy thing with a hammer. This should be enough to break the glue and push the driver out the back of the light.
- Only tap the driver enough so it is loose. Hitting too hard might damage or break the switch wires.
- This is easier in the later production D4 which has screws holding the star down. The early D4 did not have screws and has a much narrower hole for the driver wires, making it harder to fit your probe down the hole.
Gasp! You poor soul you!!! Emisar makes fantastic lights! No flashaholic’s collection is complete without some. 
OK my bad then, blinking if it was available would not help much. I don’t know the output of the Mfg line but it’s hard for me to imagine that anything that’s alteady waiting for an order would be reflashed so I hope Hank will end the show with some good news.
I’m not a flashaholic.
Most of Hanks lights don’t appeal to me. I’m not a fan of throwers (plus I already have a couple) or TIR lights (except for headlamps).
This D18 however looks like it might be practical for my work.
That would seem to indicate that the firmware used is the last pre-production test code. However, I asked Hank if my just-shipped order uses the 2019-03-21 final production code, and he responded by saying “Yes, it’s with the latest firmware.” So, go figure. Not sure I’d be able to tell the difference anyway.
No, I never added anything like that. It’s not as simple as it might seem. Version numbers are complicated. For example, a program on my computer has version number “2.1.5+deb1+cvs20081104-13.2”. It’s not even a big program. That’s the version number for “eject”, and all it does is eject and retract the tray on optical drives.
Basically, to serve useful purposes, it’d have to be pretty long… like maybe one of the following:
- Checksum of the source code (plus a big reference table somewhere to look up what it means)
- Build date plus branch name and build target ID
- Branch name and revno (like 188.1.213) plus something to indicate which build it was
- Some sort of long and manually-updated version number which throws an error if not specified.
None of this is easy to communicate to a human by simply blinking a pixel on and off.
To be useful, the number would need enough detail to answer common questions. For example, is this the full-power build or the reduced-power 219C version? How old is it? Which repository version was this based on? Does it have bugfix X or feature Y? Is it part of the main repository or was it made from a different branch? Who built it? Does it match an actual repository version at all, or was it cowboyed without checking in the changes?
Tom tried to do a simple version number scheme with Narsil and NarsilM, and it worked okay at first when there was only one person making builds and only a couple of commercial lights using it… but it got messy pretty quickly when there were more people and more products involved. There are now a bunch of different versions all called “1.3”, but they’re all different and most don’t have the improvements Tom put in the official 1.3. People took earlier versions and bumped the number, which ended up being misleading in terms of how the code behaves.
So, long story short… no. I haven’t even tried to bake in a version number. It’s complicated, and I’m not sure it would even be a net gain.
Thanks. I’ve been meaning to ask Hank to fix that link, but I also need to merge the code into a public branch first. The revision history graph is a bit of a mess due to some recent refactoring and multiple concurrent projects, so I was hoping to clean things up a bit more before uploading.
This is the same on RampingIOS V3. The main things which are different are the blinky modes, and an easier-to-reach lockout mode.
Yeah, that’s unfortunate. Got any ideas how to work that into the UI without adding much complexity?
It could have two memorized levels instead of one… one for the ramps, and one for momentary. We can’t really do “hold to ramp” in momentary mode though. The simplest method I’ve thought of so far is to do 5 clicks in ramping mode to set the momentary level, then turn the light off, then 5 clicks to enter momentary. The symmetry works out to make it reasonably easy to remember. The upside is it would allow turbo in momentary without setting a ceiling to the maximum. The downside is that it’d require extra inputs and it’d be a bit less intuitive. And a more neutral aspect is that the momentary level would have its own separate memory, which could be desirable or not.
I don’t think this one uses glue. The driver screws into the shelf, similar to a BLF Q8.
However, I don’t think it’ll have pogo pads. And the LED wires are very short and thick so they can carry a lot of current, so the driver will almost certainly require unsoldering the LED wires to access the MCU.
I’m not sure. Maybe it was fun using lightning mode at 14,000 lm?
No maybe about it, lightning mode at high output is definitely fun! 26,000 lumens especially! lol
What Anduril light has 26k lumens?
Or is it a Dale custom? :weary:
I know it’s a complex solution but if one was really determined, a machine-readable blink-out would work.
I mean: do the same thing as optical programming but in reverse. Now it’s flashlight blinking out some binary code and a smartphone app receiving it.
M43 has calibration function 14fast click and hold. Temperature should be 25C.
Interesting. Thanks! That’s not in the manual. It only goes up to “12 Fast Clicks & Hold”.
Do you know of any other undocumented functions in the M43?
Sorry for asking a dumb question but what does “Temperature should be 25C” actually mean? Does that mean I need to make sure that ambient temperature around the (cold?) flashlight is 25°C before I click 14 times and hold?