Emisar D18 introduction

LED Flashlights – General Info 18650 Flashlights
441

+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.

442

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 :smiley: )

443

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? :stuck_out_tongue:

444

The D4S has pogo pins.

Are drivers hard to get out? (I don’t have any Emisar lights)

445

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. :open_mouth:

446

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.

447

I’m not a flashaholic. :open_mouth:

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.

448

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.

449

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?

450

No maybe about it, lightning mode at high output is definitely fun! :smiley: 26,000 lumens especially! lol

451

What Anduril light has 26k lumens? :open_mouth:

Or is it a Dale custom? :weary:

452

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.

453

Probably HAM’R.

454

M43 has calibration function 14fast click and hold. Temperature should be 25C.

455

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?

456

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?

457

Just checked out HAM’R…

458

LP, he’s saying the base setting should be 25C…I think. I found the M43 UI too confusing so I pulled it, stripped the driver, and piggybacked in an FET driver. I have Anduril in my M43 now too. And a Master/ 3 Slave configuration if I remember right. It gets really really REALLY hot in Turbo, way fast! 12 Samsung emitters will do that in this small of a light.

459

Thanks Matt, it was one of those wild hair moments. :smiley: (unfulfilled due to the lack of the extension tubes Sofirn quit on)

Anduril works fine in Ham’r because the drivers are separated from the heat source by a significant amount of aluminum. By filling the head of the light with the base of the finned addition there is a LOT of mass underneath the emitters. My M43 has the drivers virtually up against the bottom of a comparatively thin emitter shelf, as such it floods heat into the Master driver in a very quick manner and Anduril isn’t set up for this… too much too fast by a wide margin so the thermal issues arise in the driver. Again though, in the even more powerful Ham’r it’s simply not a problem.

460

lol… I found some behind the scenes footage from Dales HAM’R build!

Maybe this is a similar issue to what TA is experiencing trying to get Anduril to function on the MF01S?