Yes that’s the one you kinda recommended in your A17DD-SO8 / A20DD-SO8 / etc - thread. Seems like there has been a lot of discussion about the best performing FETs to use. Still haven’t read and more importanly understood all the info about FETs that was posted all over the forum. By the way, thanks, wight, for letting me see comfy’s scope images for the first time. 
I’ve been clicking through that thread once or twice and wondered what the lacking images would look like. Most of this stuff is over my head but it’s quite entertaining.
The SiR800DP is a beast---it can handle more current than most of the other FETs I've tried---the difference is much more than the datasheet would suggest. If you try and run 4x XHP70 from a single PSMN3R0 you will find that it quickly desolders itself; with a single SiR800DP it is fine without making any other changes--and that's with a 5V gate drive (much higher than we usually get with 1S setups). So yeah, you can run crazy stuff through an SiR800DP. It seems to even run cooler than the 0R9 NXP FET I have in the same situation.
The SiR800DP does suffer from dV/dt induced turn on when you're switching from 100% quickly to moonlight (that's the little light blip you see). As Tom E. noted, a small pulldown resistor solves that issue.
I use 0603 exclusively in my drivers as I want to utilize the space as much as I can. I also bend pins on the MCU, put the MCU where the spring usually is (for space and easy access to flash the light without full disassemble) and cut of the tabs of the 7135s to make them shorter (custom Eagle library part). One of my drivers where I’ve done this: Mod: My take on the convoy S series with side switch mod.
I did a design with 0402 sized components but they where to annoyingly small for me to work with, so I’m sticking with 0603.
Btw, nice to see you back, if only for a while.
Has anyone built this driver with a second stacked 7135? Adjusted the modes to use the pair of 7135’s for more modes of non-FET power? (more efficiency)
Not physically stacked that I am aware of but with more 7135's. The single 7135 was basically a method to achieve a regulated "Lo" that many complained was either "to the moon Hi" or a "subterranean Lo".
Wight and PilotDog68 both have drivers with more than one 7135
Yep, I’ve done it multiple times. I got tired of stacking though so that’s when I made the DoubleDown driver boards.
I dunno. With 4 or 5 nice well spaced modes, only 1 mode (32%-40%) uses PWM's on the FET typically. The lowest 3 including moon use the single 7135. One full 7135 mode does like 120-170 lumens roughly with a good NW or CW LED, good AR lens, so that's like 10% typically.
4-5 modes are my favorite settings. Adding another 7135 has no advantage that I can see for a 4-5 mode set.
Am I missing it, but is a FET+1 OSHPark driver available anywhere, from anybody in 20 mm size? Anyone have an interest in making one if it's not around?
I really miss this wight FET+1 driver in a 20 mm size...
In most of my lights I just want three modes, and I like the middle mode to be regulated at ~1 or 1.5amps. That’s why I like the extra 7135’s.
You can use the 20mm DoubleDown for that too. If you just populate the top side it’s FET+1 with some other stuff thrown in.
[/quote]
Oh thanks PD68! I just looked at my OSHPark order history - did order these boards back on Nov 7th(silly me 
).... I ordered 22's, 20's, and 17's. K, I know I need the 20's for a couple of projects, gotta get organized better..
your memory is getting almost as bad as Dale’s… 
I can totally relate to Dale. Wait, who's Dale? 
You should add a second diode, and put it right next to the second resistor… so that the labels will say “R2D2”.
Question:
One of these drivers, loaded with the BLF A6 firmware, acts like it has next mode memory. Anytime I cut power, it moves forward. Does not appears to be related to time spent off.
So, in moon mode, click off for 10 seconds. Turn on, it is in mode 2. Click it off for a few minutes, click on, mode 3.
etc………
Suggestions on what to change? I have a stack of these that work. This one I reflashed, and replaced the OTC.
Sounds like the OTC is not discharging or at least that’s what the attiny thinks. Is it the same OTC cap as the other (working) drivers?
Yep
You could try ToyKeeper’s offtime-cap.c to check what OTC values it’s seeing. It’s in the battcheck folder in her repository.
I have the same problem in one of my drivers. I think I need to run offtime-cap on his driver and adjust the settings in the firmware. Hopefully this solves the problem.
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/battcheck/
Usually that indicates a hardware problem, but the offtime-cap.hex firmware can at least help diagnose things.
I measure the OTC a few times at 0.5s, 1.0s, 1.5s, 2.0s, and 3.0s. This provides a good estimate of the discharge curve, and the values can be plugged into code to select whatever timing you like. Here’s a graph of three different drivers measured this way:
The blue line is close to ideal.
Of course, if you get 255 every time, the OTC isn’t working at all.
Yeah I think I might remove everything and rebuild the driver. Considering two different caps did the same thing, and reflashing did not help.
Or maybe just reflow the attiny.
I didn’t read all 286 posts… but perhaps this can be useful:
The stencil for Attiny:
actually, when I was starting with attiny85 I learned that the legs can very easily be bent downwards, it takes probably less than 1 minute
That means that the actual footprint for the attiny13/attiny85 can be smaller than official contact pads spread - if you bend the legs downward - the contact pads can almost all be under the MCU itself, not extending so wide around it.
That would save some space on the PCB