Hello, yesterday I was putting together a FET+7135 driver from Mountain Electronics and after I got it all soldered together it would not light up. At all. I thought maybe there was an issue with the firmware, so reflashed it-even tried a fresh MCU and FET. (Attiny 25 MCU FWIW) Checking the the solder points with a magnifying glass turned up no issues. I then de-soldered everything and soldered the same components onto a different board and it works great.
Any advice on what to check? Where to check for continuity? I really would like to be able to use this board as I only have one in this size and it is for a particular light which uses this size of PCB. If a pinout or schematic is available, that could be helpful too, I think.
First check if there any power supply to MCU pins in first place. Also check if D1 which is reverse protection diode is in the right direction soldered. These are the first things which you must check after soldered all components. If you can post picture of soldered PCB we can made visual inspection of it.
Can you measure voltage between pins 4 and 8 of MCU with multimeter. Need to check is there present power supply voltage to MCU. What firmware you flashed to attiny13? From pcicture I see all must be OK with soldered components so the best will be to check voltages on it in some points of PCB. For circuit diagram just check TA driver thread here in the forum. Also to make reverse engineering of that little board is not difficult at all and drawn it schematic. Aslo check that great source here https://kandepet.com/deconstructing-a-flashlight/
Measuring the voltage between pins 4 and 8 only gave me around half a volt, obviously not enough to power it on. Comparing that to a different driver I know works, it gave me the same voltage as the battery (or PSU in my case).
Some more testing revealed that there was no connection between the diode pad and led+. I soldered I wire bridge between these two and it works now. Here is what I did:
I'm actually using the attiny25, and I flashed the bistro firmware. I flashed bistro to different driver the other day (same type, FET+7135) and it works great, but with this one the medium presses to back up the modes are very long, about 2 seconds or so. Not sure why this would be the case, since I flashed the same hex file to both MCUs and both boards are using the same components. I can't see how my diode mod could affect this and I'm using a ~1 uF cap for off-time. Should I change something in the firmware C code or should I do something else on the hardware side of things? Otherwise the driver seems to function normally now.
Could be your driver board and wiring have a difference in OCT timing from typical, I had a similar issue with clicky delays when I was trying to flash TK’s Crescendo onto a BLF-A6 Fet+7135 driver.
You’re right, I just finished flashing bistro again with changing the otc values on the calibration file to really high numbers and it’s now close to my other light. The first value I used 254 and the medium press is still a bit longe for my preference but it’s manageable. Also it does this thing where it quickly blinks off and back on from turbo to moon. Not sure why it’s doing this, can I fix this somehow?
Would an capacitor with a lower capacitance work better here? Maybe 500nF? I’m not sure I completely understand how these things work all the way, but it does seem like the capacitor is holding a charge for too long.
Could this be the case for the flash when changing modes sometimes? If I do a really fast tap it will sometimes skip to the next mode. See the above video for a demonstration of that. Or would it be possible to change this in the firmware yet?
I just changed the OTC to a 140nF cap, and with editing the ADC values in the tk-calibration.c to:
/********************** Offtime capacitor calibration ********************/
// Values are between 1 and 255, and can be measured with offtime-cap.c
// See battcheck/otc-readings.txt for reference values.
// These #defines are the edge boundaries, not the center of the target.
#ifdef OFFTIM3
// The OTC value 0.5s after being disconnected from power
// (anything higher than this is a "short press")
#define CAP_SHORT 254
// The OTC value 1.5s after being disconnected from power
// Between CAP_MED and CAP_SHORT is a "medium press"
#define CAP_MED 161
// Below CAP_MED is a long press
#else
// The OTC value 1.0s after being disconnected from power
// Anything higher than this is a short press, lower is a long press
#define CAP_SHORT 180
#endif
This gets me to an acceptable medium press, although still a bit longer than I like. I'm also still getting that annoying blink if I change modes quickly. Any help please?
The MtnE drivers, though good for their time, have been outdated for a few years now. Richard doesn't participate on the forum anymore. One of the important things a member DEL came up with is adding a 4.7 ohm resistor between batt+ and the diode. There should be resistor(s) on the FET gate as well - I don't see them on your pic above on post #4.
Again, the driver design is old and outdated from what we've done and learned since.
DEL isn't on the forum anymore but his design tweaks live on in countless # of driver designs that followed. DEL designed the buck driver in use on the BLF GT.
same here with recent MCUs I had to add 1Mohm over the OTC to deplete it faster and adjust the OTC values a bit
and TOM_E is right designs with OTSM are so much easier to use, no more OTC problems
Only downside OTSM does not work with buck/boost drivers big input capacitors and Flintrock is also MIA for quite some time from BLF
I thought I would continue on from this as firmware questions keep popping up. I can’t seem to fully understand how these drivers work and could use a little help here again. I’m using the 17mm single side MTN FET+7135 board with an Attiny 25. I flashed the Bistro firmware and it works well except when the battery is fully charged at 4.2 volts. Between 4.2 and 4.13ish volts it reverts back to the lowest setting when cycling up through the modes. It gets to about the 4th or 5th level then goes back to moon. If I use a slightly discharged battery, it functions normally. What could be causing this bizarre behaviour? I read somewhere that a low vF led might cause an issue but I have no idea if this could have any bearing on what is happening here. If it helps at all, the led I am using is a triple sst-20 from led4power.
Any help would be appreciated.
PS: I am also not able to flash the attiny when it is soldered onto the driver. Rather annoying.
I wish I knew. I just get a signature error mismatch warning when I try. Works fine when I remove the chip. And forget about flashing on those Nanjg 7135 boards. I’ve never been able to make those work either.
Ohh. The MtnE boards are somewhat non-standard compared to our BLF standard FET+1 drivers. Back in the day, Richard designed his own boards, I believe with help from his brother-n-law (maybe??) who is an Electrical Engineer. It's possible the driver PCB is not designed to be compatible with the USB dongles we use. This happened with drivers I was working on with Simon(?) at the time.
I'm forgetting some details here, but the point is a driver could be designed perfectly to operate, but unable to be flashed.
What the MtnE drivers lack is the 4.7 ohm resistor between Batt+ and the diode. This resistor, first added by DEL, stabilized the signals for the MCU. The MtnE drivers use a different method to achieve the same thing, but I believe the 4.7 ohm resistor is more effective.
The Nanji's could have a different problem, or could be the same issue. I've found Nanji's that would lock their MCU, another words make it un-writable. You need a special development tool to unlock them.
With the Attiny13 flashing is blocked when pin 5 is connected to ground, cutting the trace or desoldering and bending the pin up to break the connection are two resolutions, the driver seems to also work when pin 5 is floating. Might be the same for the 25.
Tom E’s right about the resistor for the issue with dropping to moonlight, it’s a known problem on the BLF A6 driver more details can be found here:
BLF A6 Turbo problem (post #12 has link to details of the fix, and post #22 references the Attiny 25 driver)
I also found the Nanjg driver to be locked, bought some 13As to swap them with but still haven’t got round to doing it.
Edit: - Tom E, just found a post that says you discovered the ‘pin 5 to ground’ issue on a Convoy driver and cut the trace to fix it
