Texas Avenger "TA" Driver series - Triple channel + Bistro or Narsil + Clicky or E-switch - The Ultimate open source driver!

The ramp steps is important but more important is the PWM step size (which I think is what you are semi-talking about as well).

As we all know the hardest part of a smooth ramp is in the low modes where it is hard to make it look smooth. Having much smaller steps would vastly improve how smooth the ramp could be since each step would have a smaller effect on output.

With a 16bit PWM resolution I am betting we could get a single FET to handle a smooth ramp from moon mode with a little tweaking. The FET itself is capable of it, we just can’t send a small enough pulse to the FET right now to make it smooth at the moment.

Having 65k PWM steps vs 256 should give us ample resolution to smooth things out. It would just take some tweaks to TK’s ramp creation script to work with the new PWM scale I am guessing.

The end result would be the ability for simpler, smaller / more compact, more robust and better tint FET drivers all while having a smoother ramp that is easier to setup. Instead of having to double up on the PWM several steps in a row to give the illusion of smoothness, you could legitimately have a smooth ramp with each step actually higher then the last. Easier to get a smooth ramp as well since each particular step is less important.

Combined with the extra space the 1634 offers, you could use a ramp with 500 steps or more if wanted, although I tend to agree, ~300 should be a good number for most cases. On the very high output lights I have found that ~175-200 steps makes for a good smooth ramp, although I normally start with 200-250 and then manually delete a lot of the duplicate numbers in the low modes to smooth it out.

Yea, been a while since I looked at the tables - you are probably right there bout the dupe value entries - I seem to recall that. Would be interesting, just wish I had time to play with the 1634, and I'd probably start with TK's 1634 Anduril version.

As Texas_Ace wrote, the problem is PWM resolution.
We probably don’t need more than 150 steps, but we need very short duty cycle for moonlight/low modes

For example, while we have 8bit timer, resolution is 0-255. While having 5000 lumen light with PWM duty cycle set to 1 of 255 we will get ~19.53 (5000/256) lumen on lowest mode regardless frequency we use. Output (ramping) can be controlled with steps of 19 lumens, which is not great at low modes.
Of course with voltage dropping on battery each step will reduce its output as well.

10bit timer would be enough for 5000 lumen light (5000/1024 = ~4.9 lumen step), but with higher output lights, PWM resolution shall be increased.
Attiny85 can handle up to 64Mhz PWM frequency while MCU running on 8Mhz (guess this is not the best for battery life, but possible), so the limit is only 8bit timer.
With Attiny1634 we don’t have this limitation.

Actually new Emisar’s v2 models have Attiny1634 and FET on board (and vias for reprogramming), so someone could test this idea on those lights.

Your conclusion is wrong, you don’t need anywhere close to such low absolute PWM levels to get the FET reach Moonlight
the resolution is needed and the threshold depends on components used, another FET will result in more or less absolute PWM duty cycle needed
I have seen this on my scope before you see the nice PWM signal on an MCU output without load
then signal gets some slow voltage rise on very short timings
and the Output on the LED is also another story as after you charged the gate the FET needs also some time to get conductive

if you look on our AMC with 47Ohm gate resistor drivers you will see at PWM level of 1/255 no output or almost none

  • depending on how the voltages and temperature this drifts
    on 2/255 you get fairly low output

at 20kHz and 1/255 you look at 0.2us pulse with
problem here is the Gate resistance is about 50 Ohms at like 3.7V
now you need to charge up the gate charge is about 10nC of a regular full sized LFPAK56 MOSFET to get it conductive (this depends on the gate threshold voltage)

so we got
200ns time at 1/255
10nAs
50 Ohms gate resistance

Calculations:
Gate current is 3.7/50=75mA
the Attiny can only deliver about 25-30mA
0,030A*200ns=6nAs (in reality its probably less because gate resistance, other capacitance’s and so on)

Fact is a usual driver does not light up when the main FET is on 1/255 cycle
you would need increased resolution between 1 and 2/255 PWM cycle, this also depends much on the

an ideal Gate driver of switching drivers usually can push 2A or more to get very short switching delay and times

You are totally right Lexel. I’ve forgot we are not living in perfect world where everything is so simple. Thank you for your input. I would like to learn more of electronics, so I’ve done same research and it look there are much more factors than I thought. FET behavior will also change with temperature change. As I understood the best FET would be the one with smallest gate capacity, but I suspect this is just a part of story.
Anyway maybe there is a way to stabilize FET output with some constant PWM adjustment?

For moonlight the best option is using a small current FET which has less capacitance so its faster and a current limiting resistor in series

High power MOSFETs are relative slow

Can someone tell acceptable parameters ( Qg & RDSon) of 1 FET to drive from moonlight to turbo?

QG<30nC at 4.5V (the gate charge gets bigger with more voltage, but only a part is needed to get above the threshold and the FET conductive)
RDSON 1-4mOhm

https://www.mouser.de/datasheet/2/196/Infineon-BSC009NE2LS5-DS-v02_00-EN-540021.pdf

https://www.mouser.de/datasheet/2/427/sir800adp-1484143.pdf

this MOSFET has a relative high Gate threshold voltage
https://www.mouser.de/datasheet/2/916/PSMN2R4-30YLD-1320632.pdf

Yes, i know, but you said: “High power MOSFETs are relative slow ” Are they ok for moon?

if you get at least 12 bit resolution yes otherwise no
and with temperature drift they may get unreliable or too bright without current feedback

O.K. I got it

I’ve done some research and I think you should focus on the shortest raise time and fall time than Qg and RDSon. This probably telling you how fast you can switch FET with PWM.
Not sure how much turn on and turn off time matter.
Also lowest Vgs th better.
Power dissipation probably is also parameter you would take a look at.

Seams that FETs that Lexel already pointed are one of best we can have.

Again if you don’t have a real FET gate driver that can deliver like 1-2A with about 2-3Ohms driver resistance you will never see such short raise/fall times
the gate charge is the most limiting source when driving with the little current from an Attiny MCU

Higher RDSon MOSFETs with less max current capability have smaller chip area reducing the gate charge and speed up the switching
A MOSFET has always switching and conduction losses, at our low frequency of about 20kHz the conductive losses play the major role
If you want to increase the resolution you can reduce the Moonlight PWM frequency by factor 10 to about 2kHz still having a bit more than 10 bits resolution (but you need to implement that into a firmware)

you can create a Gate driver using two small SOT532 MOSFETs (crucial here is low RDSon and enough peak current, so they don’t get blown remember most big switching MOSFETs have like 1Ohm Gate resistance making the worst case 4A peak current while charging the gate)
one N channel on the MCU and one P-channel driving the MOSFET

Then you get very fast switching time as the gate and now you need to focus on more resolution of the PWM source

Then you have then significantly increased the current ringing problem and may need additional MCU voltage stabilization adding a 2. low pass filter (most new designs have 4.7Ohm plus 10uF behind it to eliminate the spikes that can reset the MCU)

Would it be better to use a small buck driver for the first couple hundred lumens and then switch over to pwm fet?

Designed my own FET+1 driver for D10 headlamp. Circuit identical to D4, only indicator led and cap on output to reduce moon a little. I’ll go for Si4866BDY. Found it for 12 cents :slight_smile:

It would be a very efficient way but also quite costly and complex….Really the efficiency difference wouldn’t be all that big so return of investment would be fairly low.
I’d love to see it though.

this FET has no advantages electrically over the other mainly used MOSFETs, it is only cheap
high input capacitance,
Gate charge,
relative high RDSon,
bad thermal conduction to PCB

I bought recently pretty good FETs for 1 Cent price bug I can sell them here cheap

So can this firmware be used on a driver that uses a click switch that cuts the power to the batteries, so a half-press will change the modes?

Yes, that is what bistro is designed for.

For an e-switch you need something like Narsil or Anduril.

Is there a schematic available that works with Bistro? I’m trying to figure out how it works, such as if a capacitor keeps a residual charge during a half press, etc. And how the MCU remembers the last mode after remaining off for a while.

Thanks!!!