What PWM values for each mode?
From the A6 C file…
// Mode group 1
#define NUM_MODES1 7
// PWM levels for the big circuit (FET or Nx7135)
#define MODESNx1 0,0,0,7,56,137,255
// PWM levels for the small circuit (1x7135)
#define MODES1x1 3,20,110,255,255,255,0
Yes, I know, that doesn’t add up. Makes no sense. According to the PWM levels in the C file, there should be only 4 modes with no 7135 for the small channel. BUT, that IS what I flashed the MCU with, and it IS set up that way, and both lights DO make low level light on 2 and 3. Yes, 1 is blank, as 2 and 3 should be with a 0 setting, but this is what both lights do.
I seem to remember reading in some threads that the fast PWM with a value of 0 is still on for a short time. Some people were using it to get some sort of moonlight mode from the FET. The first mode is set to phase correct PWM so it doesn’t have that problem.
Ah, but of course! The phase correct vs fast pwm settings would explain the difference. Thank you! Thought I was losing it (y’all don’t need to go there. 
)
Keeping it pertinent, I built a new driver for one of the X6’s, this time I was paying attention and used the A17DD-Hybrid with FET+1 architecture. Again, A6 firmware with ATTiny13A, Samsung 30Q fresh off the charger at 4.21V. 20Ga leads but this time I bypassed springs and used the through board bypass at the switch. 7135 chip is a 350mA version.
0.01A for 0.483 Lumens
0.03A for 9.177
0.14A for 69
0.47A for 223.215
1.36A for 534.405
3.10A for 1055.7
5.94A for 1783.65
30 sec yields 1669.8
This is still the XP-L V6 1D on 20mm SinkPAD, domed, and using the SIR404DP MOSFET. 1783 is pretty potent! 
Nice X6, for sure.
Is the 404 still OK as the voltage drops?
So far, I need to run a full cell killing timeline.
First, I got the new driver boards in. So, do I use the ATTiny25 with these and the Bistro firmware? Any special instruction before I build the first one?
Second, I just ran a kill test on the X6 with SIR404DP. One hour, I quit, Cell was still at 3.10V. All functions normal. Moon was stupid low…
15 min 3.81V 4.75A 1462.8 lumens
24 min 3.66V 3.55A 1255.8 lumens
38 min 3.45V 993.8 lumens
55 min 3.16V 1.2A 538.2 lumens
60 min. 3.10V…numbers as follows
0.0345 lumens
6.6585
54.722
174.225
228.755
320.505
455.4 lumens
With everything working as it should be, moon and all reverse hidden modes working fine, reverse press timing seemingly staying constant, I call it a win for the SIR404DP. One hour and I see why I don’t do this more often! 
I was just worried/curious about those gate specs for the 404 and if it would maybe fall off a cliff as the cell dropped. I think some of the FET candidates have had that issue, even the old 70N02 drops off pretty badly by around 3.5v. But it looks to be OK.
It was still drawing enough to keep the finned X6 head quite warm even up to an hour.
This one has a 45 second step down, so I’d click it back up every time it dropped. At first, about 12 minutes in, it was getting too hot to hold… took it outside where we have a stiff cool wind blowing and ran it til I could hold it. Then just kept clicking it back up til I was sick of it. lol Throughout, I’d run it down to moon, reverse through the modes, then back to Turbo. Stayed working fine all the way.
Right at 1000 lumens 38 minutes in, that’s pretty awesome! This was the Samsung 30Q, button top.
Held it the entire hour, clicked it back up immediately literally every time. Outside, blue sky, big sun… dang light was making a spot on the concrete you could see in full daylight even 30 minutes and more in!
Ok, I’m looking at the component list for this driver and seeing that Alex built one with the ATTiny13A to start with and bypassed the Zener Resistor (200 ohm) . What UI then was used?
And this makes me wonder WHY the 13 components instead of 7? I’ve built a LOT of these with zero issues, so what are we trying to fix if staying with the 13A and normal A6 firmware? If all this is to make it work with the lighted tail cap, leaving that out is far easier!
Even a factory ATTiny25 driver with Bistro runs my Quad Cu X5 with ease, making right at 3000 lumens on the little 14500. I had the tail cap down to a 0.14mA draw with 2 LED’s and a 12K resistor, but removed that this afternoon.
So I’m trying to figure out what firmware to flash, which MCU to use, and just why all the xtra components…. Has R5 been established? Is 1uF still good for the OTC? ATTiny25 and the latest Bistro? Got parts in hand, ready to go, need to know where before I start driving.
In theory, any firmware should work. I don’t think anyone has actually done it yet though, so I wouldn’t expect the best results without a few trial and error steps in the middle.
It doesn’t have to be bistro, but if you go with tiny25 there aren’t a lot of other compatible options yet.
I don’t even use bistro on lights I build for myself. It’s like those big cafeterias you go to when the whole extended family is together and you need dinner but nobody can agree on anything. It has enough variety that everyone can eat something, but none of it is as good as what you’d get at a more specialized restaurant.
What if one used a capacitor between the FET gate and ground? That would smooth out the signal to turn the FET on, which would reduce transient spikes and make the FET operate in linear mode at least some of the time, absorbing some of the energy that is going to the battery and the LED now. The LED and battery would heat up less and operate more efficiently with a more nearly constant current. It would not effect turbo mode.
In the BLF A6, for instance, LED heating in the higher PWM modes is quite significant because of the small head. I am not sure how much it would help the battery but it would certainly be better for it.
The FET needs to be switched hard and fast, doing otherwise is generally frowned upon. Generates massive heat. FETs are great when used as switches, pretty terrible if you try to use them as variable resistors. 'Smoothing out the gate signal' is the last thing you should try to do.
A gate resistor does what you're speculating about adding a capacitor (a capacitor won't have that effect), and it also slows the FET's switching time, leaving it in that not really on but not really off bad zone. If it can be made to work without a gate resistor the FET will have a much easier life.
Put a choke (inductor) inline with the LED to soften the square wave and cut the output on lower PWM timings way down. Leave the FET switching as-is. Problem is fitting a large enough inductor on the driver (and adding the choke requires a large flyback diode as well). This was already done on the 1st-gen BLF-SRK boards. Between 0.8 and 1.2uH, with a rating of 12-15A, works well. Higher uH gives greater reduction at small pulse widths. Inductors with those specs are rather large, fine for giant drivers, not fine for 17 or 20mm.
Or, forget all that nonsense and use a single 7135 controlled by a second PWM output for the low modes. Has anybody tried that yet? (/snark)
I think I read something about that a few months ago in some obscure GB thread
But for what it’s worth, I’ve done some experimenting recently and found it’s possible to get beautiful, PWM-free low modes from the FET by giving the gate a small charge from the pull-up resistor (about 150-250 cycles @ 4.8MHz on the attiny13a). It can then be left floating for a while.
The nice thing is that it makes a nice linear looking ramp, probably because the FET has exponential response to gate voltage. It will also go as low as you want it too, with the led barely visible in a dark room. The ugly part is that the charge time needed changes significantly with voltage and probably also from part to part and with temperature. So this will be difficult to use without some sort of feedback loop but I’ve not given up on it yet.
That’s the same thing I discovered, and I wasn’t able to do much about it in software. It seems led4power ran into the same issue, and used a separate power channel for the lowest modes. The FET is incredibly unstable at the low end.
Up front: Sorry if I miss anything folks - I don’t have a lot of time so I’ve skimmed the last 10+ posts.
I used the ATtiny13A for a couple of reasons: (a) because I’m rusty and I wanted something I knew I could program properly. (b) I also knew that it would be stable regardless of the hardware, so I’d be able to move through the modes properly and view them on my oscilloscope.
Having done those things, it looks to me as if this driver is ready to use with the more sensitive ATtiny25/45/85 MCUs. The extra components are present for a variety of reasons - one resistor is for the tailcap LEDs, one is for OTC pulldown, one is an FET gate pulldown resistor, and then I think the rest are there for regulating the voltage to the ATtiny25/45/85 (spike reduction). For more details look at #’s 301, 314, 326. I’m sure there are more details in there somewhere. (I’m under the weather today and my mind is elsewhere to boot. Sorry!!)
R5 hasn’t been established, but Sharpie made a suggestion a few posts ago. I left the OTC pad at 0805 with the intention of testing moving to 10uF w/ a pulldown. Sharpie suggested 100K. His suggestion was also to change R1/R2 out for 10x the resistance, which I find to be a very reasonable suggestion. (so approximately 191k / 47k) Rather than bypassing R3, 10ohm might be a good start. Sharpie seemed to think so too. I still haven’t ordered 0603 sized components, but once I do I’ll test that myself.
Looks like you and comfy may be onto something with that SiR404DP. Good work.
[quote=fixed it]
Unfortunately I think you’re exactly right. In order to avoid a large increase in component count it may be possible to use a current sense resistor and measure it with ATtiny25/45/85 using the 20x gain setting. The ATtiny13A doesn’t have this 20x gain setting and would be unsuitable. I assume that an RC circuit would be used to maintain the voltage on the gate pin.
lol
[quote=wight]
Yeah, I can build a UI I’ll be happy with within those restrictions but it won’t be something most people will like.
Would people bypassing springs and trying to find FETs with slightly lower resistance accept a current sense resistor? I really don’t know. Haven’t worked out the values needed either as it’s not something I can easily do in any case.
What I might try, as it’s a simple change, is to connect the LED negative to an ADC input and try keeping a stable LED Vf. I’m thinking I could self-calibrate it with the 7135.
As for voltage on the gate, that would be easiest indeed as you could use built-in PWM. Or you could do it with just a large enough resistor to ground, using the gate’s capacitance and the internal pull-up resistor of the MCU. Somewhat harder to program though. It can even be done with none of that by fully draining and recharging the gate every time a change is needed (what I did in my testing). It takes about 50 µs so it should not be noticeable.