So 4S won’t work with AMCs on the driver and it needs a LDO? That explains why mine doesn’t work. Did I kill the 7135’s with the zener diode and a 4S battery setup?
Most likely the 7135’s are dead but I have been surprised before. I forgot to mention that it must be FET only for 4S.
Been nosing around for a good FET Driver… and almost lost my mind 
Been disappointed with the H1A Boost driverand its stepping, so now I’ve pulled the trigger on a half dozen 20mm boards to build and play around.
Shouldn’t be too bad at all and from what I have seen so far, should be pretty good for the 3V XHP50.2!
(Would kill for a decent dual 21700 host for an XHP70.2! lol)
I’m not sure if this is the best place to ask, but as most of recent driver designs seems to be based on TA I’ll try to find answer here.
On most recent FET + 7135 drivers regardless if it is triple or dual channel I see there is 3rd capacitor. You can spot it for example in FW3A or D4S drivers:
What it is used for?
We already have similar C1, but after 4.7Ohm resistor that i think help to prevent voltage spikes to MCU.
C3 seems to have some stabilizing role for LEDs. Is that correct?
I am not really sure what that is used for to be honest. Del suggested a bandaid for a sub-par layout for very high powered lights was a cap between LED V- and ground could help stabilize things but with a good enough base layout it proved unnecessary in my experience.
This one goes from V+ to ground though. It could serve a similar purpose but once again pretty sure it is only needed if the layout is sub-par.
I have not had any issues without it at currents up to 40A+ and beyond in my designs.
It could also help moon mode I suppose, although a cap in that position would have almost no effect on the LED output based on calculations I did some time ago when I considered using a cap to improve efficiency on PWM lights. It would need a much larger cap to make a noticeable difference in my calculations. Although at moon modes it is possible it could make a larger difference. But it would serve to raise moon mode, not lower it, so not sure why that would be desired.
I am not sure what it is used for to be honest.
DEL suggested C3 to minimize FET current spikes, which were frying 7135 chips on a 3S (or maybe 2S, can’t remember) driver Tom E was building.
On this thread you can read full story:
DEL’s OSH-Park driver boards
Opps, you are right, I was thinking of C4 which serves a similar purpose but was deemed unnecessary with a good PCB layout. C4 caused increased parasitic drain.
Yes, it is used to help contain the voltage spikes during transitions to keep the 7135’s alive. Also makes it easier for the other components not having to deal with the large spikes.
C3 is a worthwhile insurance option since it has virtually no drawbacks except the extra board space.
Thank you for explaining. Look like C3 is not mandatory for 1S, but it still can help with potential power spikes reaching 7135s while FET turning off.
Ahhh. Oh boy, been a while... Looks like your new designs (TA) with the resistor bank solved all those nasty 7135 problems I was having at the time. Think the light was my modded up 16X XHP50 2S3P light. Sorry, never got back to updating it to one of your new resistor bank drivers like I intended to do. Even got the driver (or 2) sitting there... :FACEPALM:
Yeah, the dual FET setup is much more roust and versatile. Better for general use drivers or drivers that will be pushed really hard.
I keep wanting to update the TA series with some of these designs but keep waiting for the next generation of firmware/ MCU’s. plus have not had any spare time. lol
You got my attention talking about the dual FET setup. I’m guessing this would be one regular FET like we have now in FET+1 design, but I don’t really see advantage of using second FET over 7135 while driving 3V led. So what is the idea behind dual FET drivers?
I first started the dual FET design back when I was working with the 6v/12v MT09R and the 7135’s would not handle it. Turned out to just plain be more reliable even in 3v applications as well.
The second FET is connected to a resistor bank, this limits the current and creates a “fake 7135” channel that is far more robust and flexible. It is basically just there for moon modes and to smooth out the ramp in the low modes where the main FET does not have very good resolution.
Although with modern MCU’s this might not even be necessary as they can have higher resolution control over the FET as I understand it (something like 1024 steps or more instead of 256).
Thank you for clarifying. Sorry for bothering you with my noobish questions. I have a plan to mod my D4S with custom FET+8+1, but now I’m thinking that it might not be the best solution.
Actually I have already designed and ordered sample PCB to test it.
Let me explain what are my concerns about such design. Of course those are mainly for 3V LEDs.
First of all I thought that constant current was the one of the 7135 most demanded features. Aren’t we shall observe tint shift while ramping with the FET?
Well I know it is possible to make constant current FET circuit, but I not sure it will fit small flashlight drivers.
Second doubt is that resistor limited FET is not that much different than 7135. However it might use much less space on board than bunch of 7135.
Are there any other benefits or drawbacks of using FETs?
No worries, the only stupid questions are those not asked.
To clarify, the FET + resistor is not a true constant current like the 7135. It will still dim as voltage drops, just much less so then a normal FET setup. Although with modern ramping firmwares I really do not find that maintaining constant current to be all that important IMHO. I simply ramp it up a little every few hours to get it back to the output I want. I will take the better tint and adjusting the ramp from time to time over the constant current personally.
The FET + resistors does take up less room, another reason I prefer the setup.
Far as drawbacks, slightly lower efficiency but not enough for most to notice without equipment to measure things.
The best setup would be a boost / buck driver with PWM ability but this is not something we have got working in a small enough package yet. Till then a dual FET setup is my preferred driver setup for most lights, particularly lights that suffer from tint shift.
An upgrade in MCU’s that would allow higher resolution control over the FET and more firmware options is all that would really improve the dual FET setup. Heck FET’s are fast enough that technically you could just use a single FET if the MCU and firmware was good enough and still get moon modes and silky smooth ramp.
Better MCU’s would alow allow for voltage compensation, something I have wanted for years. This would allow a “software constant current” using an FET to prevent dimming as voltage drops.
Got your point and I like the idea.
So basically you would like to some on diode voltage sensing. MCU could compensate brightness drop during time by increasing PWM.
Sounds easy enough to make it, but adding it on top of features that already we have thanks to TK’s Anduril might be challenge.
Driver still need to monitor temperature and take actions to reduce it. So you have a temperature that you aiming at, but also lumens that you would like to keep.
I also like the idea of single FET with ultra fast PWM. I’m not sure how far we could go here to still have good PWM level graduality to still see it as stepless ramping.
However hardware design shall be pretty simple. I think very basic schematic would be following:
Yeah, the basic idea for a software voltage compensation is pretty simple and with some tuning should work well. I have brought it up a few times over the years but it always comes back to the ATtiny just not having the power to handle the calculations needed easily. TK said it could be done at one point but would require some cleaver programming and would eat a lot of space. Basically waiting for a better MCU would be simpler.
The FET could be VERY fast if we played around with the model. I mean FET’s switching at 500khz+ is pretty common and right now we are only running at ~18khz and only 256 PWM steps.
There is still a lot of wiggle room to improve a single FET. If we could get 1024-2048+ PWM steps (at one point I thought that the attiny offered a higher resolution 10bit PWM on 1 of the channels but it never seemed to pan out) and then play with the khz frequency I think we could get a “stepless ramp” using a single FET and a good moon mode to boot. Worst case you could use a second channel from the MCU with an inline resistor to slow down the FET enough to give better control in the low modes as an alternative option. Still makes driver design a lot simpler and more compact.
I have had ideas for ways to take the next generation of drivers for some time, the issue is the MCU’s / firmware being the limiting factor right now. You could even build in a crude linear control for the low modes using the single FET as well if you wanted although that brings you back to tint shift issues but still an option for low modes.
Now that Andruil supports ATTiny1634 there’s a lot of free space, so some clever programmer could try implementing it.
BTW, is there a practical difference between using 2 FETs or one dual-channel FET?
Mostly the difference comes down to hardware, a single FET is more compact, simpler and easier naturally. The downside is that a single FET would require better firmware / MCU to control it.
Performance wise, there are trade offs but they will mostly be edge cases where they would matter. In most cases it will not be noticeable.
Attiny1634 has one 16bit timer so it look like we could get up to 65535 steps. Much higher PWM frequency shall not be a problem even for Attiny85, but we would be limited to 8bit duty cycle resolution.
Look like your dreams can make come true already.
Dual FET driver shall be still fine with Attiny85.
To run a single FET driver Attiny1634 is way to go.
Interesting, I knew that the newer MCU’s offered higher resolution PWM but the tiny85 I think has a 10bit yet it seems it was still limited to 256 steps in the firmware.
I am not a programmer so not sure if it is just a programming change that is needed or if that is some kind of limit.
Seems like using a higher resolution PWM would be best no matter what as at the least it would improve the transition between channels.