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

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:

Just to be clear, Anduril is not yet available as an option from Mtn, correct? I’d like to try it in a mod, but wasn’t sure where to find a driver with that FW yet.

Simply look at the options on the website.

If you want a driver with Narsil or Anduril you typically need to buy one from Lexel.

Correct, it’s not an option there. Probably because it’s not that simple. Details about why were discussed a few comments ago.

Your best bet to find out what is available from mtn is to ask mtn…

Anybody try the Samsung LH351d 4000k 90cri LEDs from MTN?

How is the tint?

Yes, I ordered a bunch from MtnE. I like them, but can only speak for myself.

How do they compare to Nichia 219C?
Less green?