Fried a MtnElec FET+1 driver?

I built my first triple earlier this week, an S2+ with the newer FET+1 driver from MtnE, flashed with Bistro. While building it, I went ahead and did a lighted tailcap, including a 750 ohm bleeder resistor.

It was working just fine until last night when I dropped it from waist-high onto my hardwood floor. It still lit up, but seemed to be stuck on a dim mode. I figured something happened with the bleeder, so I tore it apart this morning and everything was where is should be - there was no visible damage. So I then I…

  1. Reassembled it without any changes and tested. Result: still stuck on a low mode.
  2. Opened it back up and touched up the solder joints around the bleeder (the bleeder, the diode, and C1) just incase my tinkering messed up one of those. Result: still stuck on low mode.
  3. Opened it back up and removed the bleeder, everything back to the way it was when I got it from Richard. Result: still stuck on low mode.
  4. Concerned that perhaps I messed up the attiny25 somehow, I hooked it up to my usbasp and flashed the pre-compiled Bistro hex file. Result: nothing at all, no light. Then I realized that I accidentally downloaded the repository’s page that would display the hex file, not the hex file itself :person_facepalming:
  5. Flashed the actual pre-compiled Bistro hex file. Result: still absolutely no light.
  6. Downloaded and compiled Bistro from source code and then flashed it. Result: still no light.
  7. Concerned that maybe it wasn’t the driver, but an issue with the LEDs, I briefly tapped leads from a battery straight to the noctigon. There’s light… so it must be the driver.

Have I totally botched the driver? Is there anything else I should be trying? I don’t have any extra components sitting around (except what I could scavenge off of a spare nanjg105c), so swap-nostics might be out of the question (unless the diodes or capacitors are similar enough). Should I just toss this one and buy another driver?

I have trouble seeing the tiny components. Real good pictures help see things I cant, even under magnification.
I would also remelt the connections to components, see if that helps.

Others on here that understand the driver function in relation to the components may be able to narrow it down better.

Maybe the capacitor was damaged, it’s decay through the resistors is how the mcu recognizes button half presses. If D1 is damaged then no power to the mcu, no power-no gate voltage on the FET-no light. If the mcu is damaged then maybe dim or no light at all.

Have you tested it without the switch?

Thanks for the info, RBD. Started testing without a switch, or even the host after a while. Just soldered star to the driver with nothing in between. Hooked leads to a battery and carefully touched spring and grounding ring

Are D1 and C1 roughly the same components as a qlite? I could try swapping those. I’m guessing the MCU is fine, avrdude talks to it without any problems

Yes, the A6 driver sold by RMM at Mtnelectronics has better quality components but the original design was simply the nanjg 105C with the 7135’s replaced by a single FET. Later, a plus one 7135, a separate channel version was added to give more consistent moon mode control. If it turns out your driver is fried I highly reccomend it as a replacement.

The wires and braided spring options make it practically a drop in.

One last thing, the machining on these was sadly inconsistent with the threading for both the driver retaining ring and switch areas not always to the correct depth. In some cases the retaining rings don’t screw in far enough to tighten against the driver(threads not deep enough) and in others the switch seat was milled too deep (button cover preloads the switch opening the circuit) or too shallow( excess slop before button cover actually engages switch) so there are a few purely mechanical issues than can cause problems. It sounds like you understand the operation and can check these once aware of them. On my particular light tightening the bezel caused the mcpcb to rotate and cut the insulation in the wires so I eased the edges of the wire holes and mcpcb slots.

It sounds like the led is fried if it only lights up dimly.

I’ve tried hooking leads up straight to the LEDs, they’re good.

At this point, I’ve tried flashing the firmware several times, touching up the solder on C1 and the diode, removing and reseating C1, replacing C1 with the cap from a qlite, tons of poking around with a DMM, and have done each about 5 times. I’ve spent several hours on it, my time is expensive… just going to buy a new one. :frowning:

Thanks for the tips though guys. Ya’ll are what make this place great.

It’s a triple, so that it would be unlikely that all LEDs are dead.

I’d to some continuity checks first.

EDIT: Sorry, was writing my comment at the time you posted yours.

No problem, chouster. I appreciate you chiming in.

If nothing else, I’ve learned a bit more today about the anatomy of a driver.

I feel you, troubleshooting a driver for hours without finding the cause is a royal PITA. Been there…

Also did you try to go up in modes or backwards from the first to make sure it’s not just the 7135? Would be nice to know the exact layout of RMM’s new version.

What I like to do when troubleshooting 105C’s is to test continuity across all pins of the MCU, except the reset pin, there should be none. I had a 105C that refused to flash, even did weird stuff to my USB port… Had continuity across VCC and GND, turned out to be a shorted cap.

To check if D1 is faulty you could simply bypass it and check for function.

Sorry to dig up an old thread, but I’m having a similar problem with my C8 with a XHP50.2 in it and a RMM FET +1 driver.

gchart, did you ever find out what the culprit was? Mine was working great one minute, and then went into ultra low mode. I can cycle between modes, I can even change mode groups (using guppy3drv firmware). But the low is <1 lumen, and high is maybe 50 lumens.

Nope, unfortunately not. Flashing an incorrect file to the MCU was the final nail in the coffin - I don’t think there’s any going back outside of replacing the MCU.

Before I botched the MCU, though, I’m sure I probably broken something when I dropped it… broke a solder joint, cracked a component… something :weary:

Edit: as much as I like fixing things, there comes a point when it’s just not worth it anymore. After pouring over a $12 driver for over an hour, it just makes more sense to replace it than spin my wheels (I put a high price on my personal time)

Yea, if I had an easy way of diagnosing every component on the driver, I’d probably give it a shot. But about my only option is blindly replace a bunch of the parts with scavenged parts from other drivers, or spend $10 and save myself a ton of time.

Thanks for the update! :beer: