MTN Electronics: LEDs - Batteries - Lights - Chargers - Hosts - Drivers - Components - 1-Stop-US Source

MascaratumB, buy the stuff to flash your own. I’ve seen your mods I know you can do this easily.

It is especially easy with the way Richard solders on his chips because he leaves the legs raised up enough where the clip makes a good stable connection.

contactcr, I don’t know how to program and I am not familiar with those tools/programs that I’d need to use. I don’t doubt I’d be able to do it (eventually) but my lack of knowledge about many thing driver-related and programming related would make it a PITA for me and for those I would be constantly asking for help. Hence, my best solution so far is to get the drivers ready-to-use :zipper_mouth_face:

For example, I know that Lexel has drivers with those FW installed, but I need the spring part to be flat, without AMC chips, for a specific mod. MTN drivers meet the requirement of “flat back”, but no FW inside… I’ll solve it one way or another

Thanks for you words, though! :blush:

No programming required! TK has pre-compiled firmware “ready to go” on this page:

http://toykeeper.net/torches/fsm/

You pick a light that is most similar to yours (FET+1 for example) and you can also pick Q8 for example if it’s going in a big light or D4 if it’s going in a small hot rod so it will step down differently.

Takes only a few minutes. The hardest part is installing the USB driver because it’s not “plug and play” like other USB devices.

You are opening the gates of hell to me :person_facepalming: :smiley:
Well, now I will have to be searching for the tools for that… besides the drivers to be flashed :stuck_out_tongue:
I may be blaming it on you in some time, you know that, don’t you? :stuck_out_tongue:

I've discussed it with Richard in the past, about offering Narsil. He saw no volume for e-switch drivers - it's a small percentage of his business. As you can see in his flashlight and hosts, very little in e-switch's. It looks like he's got two e-switch hosts: the L6 and C8F.

He offers D4 V2 now. His concerns were UI simplicity and thermal regulation, this at least was back when I talked to him about it. D4 V2 is simpler than NarsilM or Anduril for sure.

Convoy, though is a great quality budget light, has been slow in supporting electronic switches - again, maybe it's simpler for a power switch, dunno. To me for years, and why I spent all that time&effort on my own to develop e-switch firmware, I find the e-switch based lights superior in several ways. Kind of like comparing analog to digital, or electronic ignitions to points - I see it as an evolution but there will always be preferences or sentiment for mechanical switch lights, some actually good reasons, like absolutely no parasitic drain and resulting risk of fully draining a cell.

Clip:
https://www.aliexpress.com/item/Programmer-Testing-Clip-SOP8-SOP-SOIC-8-SOIC8-DIP8-DIP-8-Pin-IC-Test-Clamp/32831113149.html

Wires:
https://www.aliexpress.com/item/40pcs-20cm-2-54mm-1p-1p-Pin-Female-to-Female-Color-Breadboard-Cable-Jump-Wire-Jumper/32836050778.html

Programmer:
https://www.aliexpress.com/item/1pcs-USBASP-USBISP-AVR-Programmer-USB-ISP-USB-ASP-ATMEGA8-ATMEGA128-Support-Win7-64K/32835212571.html

Using the above equipment I stripped and soldered the leads directly on to the pins because those plastic female connectors are too wide for that clip. If you use more expensive clip you can probably directly plug them in like this:

You can search Pomona 5250 if you want the fancy clip but it’s like $15+ and doesn’t work any better once it’s all wired up

Depending on your version of Windows we can help you find the right drivers too.

If you end up doing it and get all the stuff in feel free to message me i’ll help!

Completely get your point about the e-switch lights, and also Richard’s, on offering or not more e-switch firmware! I normally prefer a mechanical switch light, because I am able to mod it more easily (either the switches or the drivers).
Recently I managed to buy an old Nitecore D10, piston drive mechanism, ramping UI and had the though of modding it with a more advanced FW (Narsil at first, as I don’t have any light with it, or Anduril, but I’ll have the FW3A when it is released).
Asked CRX about some tips on the mod and started my quest for a specific driver, with e-switch FW (that will probably work in the Piston Drive system), and no chips on the back.
Currently, MTN and Lexel are the options, with incompatible “options” each one. So I gotta see what will work. D4 UI is nice, I would just like to try another UI option!

Thanks in advance!

Shall I thank :partying_face: you or blame you :money_mouth_face: already? :stuck_out_tongue:

Thank you very much for pointing these out for me!! I will take a look on them, and enter a new “not” budget zone of B L F :smiley:
I already pass nights modding and few sleep, now will be flashling :person_facepalming: :smiley:
Thanks, I may need some help when I get this! I’ll shoot a PM to you when it is time ! Gotta learn it first :wink: Thanks again!!! :beer: :beer: :beer:

It can be a little tricky though, since these builds were created for specific models and they might not work quite right in other hosts or on other drivers. There are often little details baked in which don’t translate well to other environments. For example, there is often a hardcoded “sane” level to help give the thermal algorithm some hints, and it’s calibrated for the heat-shedding capability of a specific host with specific emitters. Generally, each specific light’s response curves are hardcoded into its build, and the ramp shape won’t look right anywhere else.

For RMM, it’d probably be a pain for him to deal with. There’s a growing collection of build targets, and the code changes regularly, so there’s a lot of updating to do… and each driver would need a few different builds available for common types of hosts. RMM would probably need to maintain his own set of build targets to match his drivers. And it would only account for a small portion of sales, since people don’t buy a lot of e-switch drivers. It seems more common to reflash the driver which came with a light.

I try to make it reasonably easy to configure for arbitrary drivers and hosts, but it’s still not a trivial task.

Yea I try to pick a light of similar size/power and generally it’s good enough. (Q8 firmware on my C8F 21700’s has always worked fine)

TK brings up a good point on this. For example, every driver I build gets a uniquely voltage and temp calibrated, plus I got many driver configs supported, so it gets insane as far as possible combos. Also the MtnE driver designs are not the same as DEL's design. DEL's design is the basis for all NarsilM/Anduril lights - I mean all: Q8/Sofirn, Emisar, FireFlies, Astrolux, Lumintop, Mateminco, etc.

Will the MtnE drivers work with NarsilM/Anduril? Yes, I guess/suppose so when equipped with a ATTiny85 but I'd much prefer the design DEL came up with. One of the key features is the 4.7 ohm resistor directly off Batt+ before everything else: diode to the MCU. Also R1 and R2 should not be used, can be, but just adds to parasitic drain if present and not used.

Actually never thought or saw this listed before but we got 6 major light manufacturers using our designs now - pretty cool! But, big but, DEL doesn't get the credit he deserves.

On The Other Hand… I shove Anduril in lights without regard to their original hardcoded intention and just love how they work. :smiley:

Granted, you have to have an e-switch for Anduril, and it helps if you use like the D4 Anduril if you don’t have a lighted switch vs the Q8 Anduril if you do, but I use the programs with little regard to their intended target and simply love em, from the tiny Thorfire TK05 to my modded monster Q8 Ham’r.

Just sayin…

Of all people I wouldn’t expect the two of you to be steering people away from this. Tell us how to use a multimeter and where to modify the code to calibrate voltage. It will be within a few tenths regardless so either way it will be “safe” I think.

As far as ramp tables. I think this is something a google spreadsheet with some formulas could solve right? Lets make it and write a brief post on where to edit that piece of code.

These don’t seem like reasons to discourage savvy modders from attempting this. I’ve not done any of this and my lights work fine.

Not sure what you are asking... Think Anduril does voltage cal right in the UI, NarsilM doesn't - it should though. Temp cal is debatable whether you need it or not, based on how both version do temp regulation.

Ramp tables? What are asking for exactly? NarsilM has support built-in for a few ramp tables, so does Anduril. Right now, Anduril only supports "production" light configs while NarsilM supports custom drivers as well.

Basically, the driver types are: FET only, FET+1, FET+1+bank, and the tables may depend somewhat on the # of 7135's in the bank. In addition, there is 2 channel support for a buck driver. I think those are the primary variables, but there are others - what I/O pins are assigned to what, etc.

Not to my knowledge

Correct, I dont mean this. Both versions are acceptable as is.

Yes this

A little of this though it hasn’t been an issue thus far

I don’t see a “steering away” at all, just information to help achieve the best result…

All these replies and still no big announcement :weary:

Did that flicker problem ever get solved?

I’ve found a dab ofconductive lubricant after cleaning contact areas often helps.

So does checking and smoothing off the spring contact points, which often are chopped off with some kind of wire nipper leaving a sharp point that can make intermittent contact after it’s scraped a bit and given you a gouged battery with some ridges and hollows.

The tables can be generated by bin/level_calc.py in the repository. It typically requires some manual tweaking to get everything just right, but most of it is already scripted.

When people build their own versions for their own lights, it typically seems to work out pretty well. They can tweak everything to their liking, with all the options configured to taste. Making a generic version to sell on bare drivers for use in unknown hosts… is more tricky.

For example, take the relatively simple case of a FET+1 driver. We calculate a ramp for a light with one XP-L emitter at ~1500 lm. Then put that driver inside a host and run it. It’ll work well with a single XP-L emitter, but it’ll look weird when paired with something else. Give it a quad or something like an E07, and the ramp won’t look right. The FET portion will ramp up a lot faster than the 7135 portion. Or give it something lower-powered like a single XP-E2, and the ramp will look weird in the opposite way… the FET portion hardly even seems to go up at all:

That’s just one example, and a relatively simple one, but I hope the idea is clear. To get good results, the firmware needs to be configured and compiled for the specific hardware it’s used in.

Sorry, I , uh, may have jumped the gun in my excitement. My Bad.

TK, all that is well and good if you are OCD about everything being smooth and equal. If you don’t mind seeing the power level jump, it really doesn’t matter and can actually be a big kick watching it Roar! :smiley: