Yeah, I read it… and discarded it. I don’t know much about these things. If I need to add external components, then I might as well just add another 7135. That also works very well 
The fet has to have an electrically neutral thermal pad? is it a p-fet? how is the situation different than the usual fet drivers? Now we're going down I road I've been talking about for awhile, which I kind of like. The op-amp is just a current sense feedback to control a FET driver. there are some fets with built in current sense than are designed for this without the problem of sense resistance. As I recall those are maybe expensive and big though.
But then we also come back to software regulation. Maybe I should I get on that. OH yeah, I just remembered, regular fets don't operate half open. that's the difference, and why they don't dump much heat. PWM, not constant current, right, ok.
Ah OK, looked too fast at your link…that second C is not (much) part of the filter.
R6 here is to compensate for the bias current in R9. Not needed with the BOM opamps, anything from a jumper to 10 k will work.
I do not recall the exact numbers on LED ripple current here, but at 1/255 PWM it was below what I could measure on a scope and SPICE was saying something like 0.001 mA. Worse is actually at 127/255 PWM, 1.5 mA. Ripple tapers off symmetrically towards 1/255 and 254/255 PWM.
They PWM great, actually. You can get a mega low firefly with the QX7136 if you want, but of course it isn't true constant current since you are PWMing, but I'd say that it acts as a good quasi-CC controller. You still have the heat to deal with though---that's physics.
If you look at them on the scope the output when PWM is pretty bad, particularly at high frequencies. Basically the power tapers up very slowly on each pulse. This will lead to a large ripple effect in the light output and make the PWM appear much slower then it actually is. If you increase the PWM speed then the 7136 will never even turn all the way on before the pulse is done.
There was a thread a number of years ago showing the scope output of it and all the issues that went along with it.
Put simply since all it is doing is acting like an opamp with the external FET, we just went with an opamp.
The real issue is heat like you said. Which is why a 7135 with higher output and voltage limits would be ideal since they have a thermal pad and can get rid of that heat much better. Although they are bulky and we would still be limited in how many we can fit.
Moving forward we basically have 2 options for cheap, compact and big current drivers. Either move the FET somewhere it can get rid of the heat or use PWM.
I think we will end up with a combo of the above.
PWM is not as bad as we once thought, I am trying to figure out a way to do a proper test but can’t really figure out an easy way to vary the PWM duty in a controllable fashion without hacking together drivers like I have been.
If we can figure out a good PWM software regulation then this becomes a good option for the low Vf LED’s.
Every modified M6 I've ever built (including the Mega M6) has used QX7136 regulators. They work just fine.
If you want the best efficiency possible for low vF LEDs at lower output currents then go buck, not linear.
I never said they won’t work, just that they are a glorified opamp and a dedicated opamp itself works better.
I agree, buck is what we need but we still run into the issues of space and heat. Just not sure we can significantly improve on the mtnmax buck driver when it comes to current handling ability.
Plus bucks cost more then most people want to pay sadly.
I don't want to get in an argument over nothing, but you did in fact say that they would only work at 100%. I am not saying that the QX7136 is better than a dedicated opamp, but it is a heck of a lot easier to implement because you don't need external compensation or filtering.
A buck regulator would take more space, yes, but would also generate less heat than the linear would.
Either way, I wish you the best of luck on this project.
I have been rushed every time I get on the net the last few weeks so my posts have not been as clear as I like recently. I am sorry to all that have had to read my posts since then.
I should have been clearer, they can be PWM but the output signal is not good when you do this.
This driver was designed to not use PWM for the regulated output, which the 7136 can’t do without extra components, in which case it is simply a glorified opamp, just much larger and harder to control then it should be.
We really wanted to use the 7136 but we kept running into issues that negated any possible benefits over a plain old opamp.
If the 7136 just didn’t have that stupid ramp up “feature” it would have been usable.
There's no second C. That's post 5. Post 1 describes only one cap. It's exactly the same circuit used here other than the R6 (which is kind of built into the input impedance of the device you connect to anyway, unless it needs correcting as you say). The bias current was considered in that case and no compensation needed in that case though. Anyway, it's not like an RC filter is something I invented lol. It's kind of electronics 101. It is a very useful trick that maybe gets overlooked sometimes though.
Ripple tapers off toward 0 because voltage tapers off toward 0. I'm pretty sure fractional ripple is a maximum at zero unless yours is behaving more differently than mine than I'm realizing. I don't think it is though.
Ok so I should be a little more precise. In that case the bias current was a true current source for the most part (well.. probably, mostly), so couldn't be compensated anyway. This just meant the RC resistors had to be kept low enough so that charge discharge current was much bigger than bias current. That limits RC thouhg (or demands bigger caps) and places demands on optimizing the arrangement then. Otherwise you just go bigger on resistors and be done with it.
So it turned out that optimizing ripple (all the way to zero in fact) for the highest voltages needed is done by lowering the divider voltage down to that highest voltage needed. However that increases fractional ripple at the lowest PWM's. For the buck you only are really concerned about ripple much at high output anyway.
As for bucks, I definitely think there's room to improve these still, but bucks are just MUCH harder to design. I mean this is the kind of work people get paid actual salaries for. I'm not sure the texas buck is the end all of that either. It's a design built around a particular chip. That chip had some nice features but also some bad ones. For example their comparator flip flop is designed to make predictable output levels, but it adds ripple needlessly. Also it's a PFET and it's not synchrounous.
I really don't think hysteritic control is the whole story of ripple limitation on the Mountain buck. What I think matters more than the control algorithm is where the feedback is done. Many of the "hysteretic" bucks seem to feedback off the output voltage or current instead of the inductor current, the difference being the cap current that makes the output ripple smaller than the inductor ripple. If you feedback off the smaller ripple, you can't get as a tight of a response. The LMwhatever used in the TB sensed off the inductor current effectively (actually the on-time input current but since it used constant off time anyway, that's effectively the same as inductor current)
Part of why we liked that controller was it had a constant adjustable current controller on it. But I think using a small amplifier and bias circuit on the sense resistor, it's probably possible to take many simple controllers (either constant voltage or constant current) that may have other favorable features, like NFET operation, and convert them into adjustable current control too, and it's maybe not even THAT hard (as designing bucks goes). But there's always the chance these things go their own way, and you need scopes and prototypes, and real work. FETs and 7135s are relatively like just programming a switch.
Oh ya… TA, your contributions to the forum have been invaluable! You’ve not been here long but you have provided input on many things in all catigories. When you first joined and started posting your ideas, I just thought you were “blowing smoke”. However, you follow up on all of your statements and ideas to bring us educated information and helpful projects. The work you put in is to me impossible for being here less than a year. So, just want to say thank you!
Flintlock, your input into the firmware category has been amazing to watch as well! It would be nice to see some fet software regulation for lvf leds. Even a basic solution. 
I thought more about moving the FET to the LED star
first some guys said its affect the LED temperature negative
this is not true, when the FET is in DD it produces almost no heat, but the LED produces a lot
partially true, when its at the max power dissipation point, but the LED will produce a lot less heat and its Tj will be a lot lower than on DD
so the LED runs colder and more efficient in medium mode no matter where you place the FET
Why?
The LED cares only about the junction temperature, this is the temperature increase by the roughly 2K/W heat resistance between emitter and LED base
The FET heats up the body no matter where you place it
Lets start at a cold lighh resting at 20°C
Turn on the light at the max FET power loss level
The FET has 10mOhms resistance at 12A so 0,12W heat adding almost no temperature to the star
you have to place the FET somewhere with a really good heat transfer to body, the best spot is most likely the Star
so lets say the FET heats up the body within 2 minutes by 5K at max power loss
Then the LEDs junction temperature will increase by 5K, no matter where you place it
The temperature resistance from a 20mm star to body is mostly about 0.1K/W, so at 10W heat it adds only 1 K to the LEDs junction temperature
running the LED at low current will have a significant drop on junction temperature so the 1K does not matter much
Why placing it not on the driver has big advantages
Most Bistro and Narsil drivers have used the internal temperature sensor for detecting the flashlights temperature
But this is not true it detects the drivers temperature
The driver has always a pretty bad thermal resistance to the body, you can improove by potting it but not so much
so if the FET dissipates like 10W on the max. power loss spot it will heat up the driver a lot over the body temperature
So even if the body and LED has a very safe temperatue, the MCU is so hot it will step down
OTSM was as much about getting the hardware right as it was the firmware. The whole challenge with getting it on TA boards was finding a combination of the two that could work with only 47uF of capacitance, although yeah, the firmware features had a bunch to do with that.
Last night I was thinking about ways to heatsink the fet better. I had a thought but maybe it is not an improvement? What if the trace for the fet output/heat pad covered that side of the pcb just like the grounding ring usually does? Many lights use the battery side for ground contact, either to the batt tube or a retaining ring. We could put some thermal past around the back edge of the pcb where it makes contact with the body. Also, many lights now have anodized driver cavities, so with some thermal paste the fet output trace could be clamped directely to the hosts without silk screen in the way. Blf D80, some convoy lights, and many of the bigger names have lights with anodized driver cavities. This would not work for lights with pills. However, the lights that have pills could use a pcb version with the silk screen covering all the way to the edge. This along with an enlarged thermal trace should keep the fet cooler. But would it be enough? I also don’t know how well the fet output would be isolated from the host even with anodizing and thermal paste. It may be unsafe. Then silkscreen would need to be used in all lights and may not show much improvement? Any thoughts?
This was considered but the problem is that it is too risky to put into production. If the FET output trace was to come into contact with the pill or body at any point it would be a direct short across the battery and could cause your battery to explode. Simply not worth the risk when a small scratch is all it would take to create such a short.
This is why an FET with an electrically neutral thermal pad would be great, we could do exactly this.
Ya. I see…
How about pairing this driver with MOSLED MCPCB? 
If you really have problems with mosfet overheating, you can order aluminium based pcb for driver.