BLF17DD Info Thread - Reference

Thanks Richard.

I can see this quickly getting over my head.....

Using the method you described, are you suggesting that all four XHP70's could be powered by a single DPAK-2 FET?

So the flow for the PWM signal would be;

Attiny pwm---->PFET gate, PFET drain----->NFET gate.


Can you point me in the direction of an appropriate PFET for this application?

Hmmm - I'm having difficulty understanding how I'd wire this up.

Am I on the right track here? (I realize it's not the Zener schematic)

Yep. That works. You can use a very small PFET, just use one that has sufficient voltage ratings. You may also need a pull up resistor to keep it off, but you'll have to figure that out in use.

Is there a reason I can't use the LFPAK56 or DPAK-2 in lieu of the PFET in that diagram?

Or even a 7135 ?

Thanks.

Do you understand the difference between a P channel and N channel FET?

I tried reading up on them, but I'll just accept a "no", & move on to locating a suitable P channel.

All I know is that the FET doing the main switching is rather loaded with a lot of current, so the AtTiny is having dramas moving the switch(NFET), so we are using an intermittent switch (PFET) to lend a hand.

I know that's probably the least technical description, & will make someone who knows what they are talking about cringe.... ;)

-- edit --

I now understand enough to see why the N channel would not work.... from a Positive feed.

Will this one do the trick?

Transistor Polarity: P Channel
Continuous Drain Current Id: 11A
Drain Source Voltage Vds: 200V
On Resistance Rds(on): 500mohm
Rds(on) Test Voltage Vgs: -10V
Threshold Voltage Vgs Typ: -4V
Power Dissipation Pd: 125W
Package: TO-220
Pulse Current Idm: 44A

Full Datasheet.

I'd get one with a much lower voltage rating (you'll get better overall specification for your application). I'd look at an SOT-23 package. That 44nC gate charge is really high and you don't need a huge TO-220 package.

Thanks for pointing me in the right direction.

I've got some of these on the way.

Those ought to work well.

I’ve been hitting a wall. I’m putting together an Triple XP-L for woodfiend, and I have a problem. When I put it together (assemble the light, with driver soldered to the pill) the light loses its ability to change modes. I didn’t notice until I went to do measurements on it, and I’m wondering if it’s not the driver but the LED’s(but I can’t fathom why).

I’m using BLF17DD’s (I’m on the second one, I assumed the first one was bad, but the second is doing the same thing). When I tested it on my PSU before soldering the driver everything worked. Soldered the driver in place, still working. Assemble the light, mode switches 1 time only then not any more. I can program the guppydrv and set mode groups and it will start at whatever the modes first level is, but won’t change.

Do I just need to bite the bullet and start replacing LED’s?

Have you tried longer and shorter switching off and on? Maybe you have a problem with the off time memory capacitor?

It is bizarre that it will go into programming mode but not change modes. What BLF17DD revision are you using? V1.0?

Yes I have. I had the same concerns about the OTC, but considered it unlikely when a second driver with all new components exhibited the same issue once assembled into the light. Not saying it’s completely ruled out, but I’m doubtful at this point that it’s the culprit.

They’re actually MTN17DD’s, I remembered wrong. Version 1.11, you’re special batch of boards with the masked + pad. Using the guppydrv firmware you flashed for me.

This is the 8th or 9th I’ve assembled, and only 1 other had any issues after assembly(I think that one got overheated).

Can you try it with a half-full or weaker battery? The voltage may be boosting too high for the MCU which causes it to glitch. I've seen this happen on really heavy loads with full high-drain cells on some drivers.

That is definitely weird. I wonder if it uses on-time (exclusively) to determine whether to enter programming mode, and off-time (exclusively) for changing modes. That way, an issue with the OTC draining too fast could result in the symptoms described.

Maybe the OTC got shorted so it can’t hold a charge?

OK, so a weaker cell doesn’t appear to make a difference. But now it won’t go into programming mode. Grrrrr. I know for sure that the lead wires are not shorting out, and the jumpers are on for parallel operation. The driver isn’t bottoming out in the pill, and it was the best reflow job I’ve done yet.

D o e s n ’ t m a k e s e n s e.

I try to always test in phases, sounds like you did the same thing, I'm just not clear - what was the last configuration that the driver worked properly in switching modes? I know you said soldered the driver in and it worked, but was the LED's all soldered in place? Is it a removable pill assembly? I pretty much always test with a real cell on the pill assembly, then after installing the pill, test with a cell again. The PS is great for doing a first trial at low power, but after that, I'll still test with a cell.

I find it really helpful to have a couple alligator clips which lead to wire with exposed ends, so I can clip one to the ground ring and one to the spring and then hold the wires onto a battery for testing. Or hold them onto the battery and tap the clip against the body to test after putting the pill in. Or a variety of other methods, testing at each step like Tom E suggested. It really helps with determining what failed.

I’ve had some which fail after putting the reflector in, which is fixed by putting kapton tape on the back of the reflector. Yesterday I had one where the front half of the light worked but it failed after attaching the back. It turns out that one was a bad switch.