[retired] [WIP] 20mm single sided & 17mm double-sided ?-amp linear driver - surprisingly good!

After a little more tuning, here’s what we’ve got. I didn’t mean to leave BLF and the identifiers at the top upside down, I’ll correct that in the future.

As you can see I’ve:

  • Refreshed the via ring to be more attractive. Previously I rotated it slightly (on purpose) in order to help maintain separation on some things.
  • Moved the OTC, turns out I was doing an unnecessary component keepout on the ends of the ATtiny13A. The clip clears the area I’ve put the OTC into just fine and this position helps with the new via ring.
  • Switched to 0805 sense resistors. If you want to usea pair of 1206 there is enough space, but it may require some very minor surgery.
  • Added/extended large pads on both LED+ and LED- in addition to the large 1.2mm vias.
  • Vias and traces moved around and cleaned up.
  • Come to think of it, the purpose of that cleanup was to allow me to double the density of the vias (12 -> 24) of the vias in the GND ring. I need to go back and do that.

This still maintains the strict keepouts around the edge:

  • 1mm component keepout. No physical objects w/in 1mm of the edge.
  • 1mm bare-copper-which-is-not GND keepout. Only GND and covered traces are allowed w/in 1mm of the edge. No vias from a net other than GND and no bare copper from a net other than GND.

I’m thinking that the name needs to not be A17LDQX where the LD stands for linear driver and the QX stands for QX Micro Devices (QXMD, the IC manufacturer). Initially I thought that the QX7136 was unique to QXMD, but it turns out that 7136’s are also made by others such as MicrOne, whose products we’ve become familiar with around here in recent years. Here’s their MEL7136.

For now I’ve just changed the name to A17LDX where the suffix represents linear driver and an “x” for xtra powerful or xtreme or whatever thing the X normally represents in these situations.

v015:

v016:

Looking good! I see that you're going back to the LFPAK FET?

I might be losing my mind but I am pretty sure that early on I swapped out one or all of the 30N02 FETs on an M6 driver with 70N02s and it worked. Another trial with an M6 driver may be in order.

That looks awesome, Wight i think u need to open your own thread on your osh park driver list :)

A17LDGTO

I did some more work with the scope tonight. The pictures in post #18 are all of what’s happening on the gate. What’s not visible in those gate shots is that in some modes with a DTU30N02 this does result in the LED being turned off extremely briefly.

  • Of course in 255/255 we get smooth output at a constant current.
  • From 254/255 down to at at least 220/255 (but probably lower) we do get the sharp, brief, off as part of the waveform. Modes are producing a fraction of whatever the set current is. Bypassing the sense resistors like RMM does in his Mod Option 2 for the Supfire M6 will certainly affect all modes in that range. (I assume that it will cause the driver to behave like a DD driver, with those modes being fractions of DD current.)
  • At the bottom of the range we don’t see the sharp dip start to appear until maybe 45/255. In the 0/255 through 45/255 range bypassing the sense resistors appears to make no difference. If anything affects output it may be Vcc/Vdd on the QX7136 IC. I did not experiment with varying that.

Interesting stuff. Really this kind of quirk is more in line with what we might expect for an inexpensive linear CC controller when it’s being semi-abused like this. Nothing’s changed of course: I still expect that the actual performance should be just like one channel of an M6 driver. My shipment of LFPAK56 FETs should come in tomorrow (although I may not be able to do any testing tomorrow.)

  • SiR800DP behaves just like SMN3R0-30YLD and Vishay 70N02. Totally unworkable for dimming. Full blown 1-mode works fine. (1 regulated mode + unregulated turbo should also be fine although I did not test.)
  • SiS414DN - I forgot that this is an entirely different footprint. No wonder the “package limited” values are lower than LFPAK56, it’s not LFPAK56! It’s actually PowerPAK1212-8, a much smaller package. I may attempt to test with it, but it will not be convenient to test without new PCBs.
  • I haven’t tested any other FETs yet.

Foo! :frowning:

I'm going to be building some M6s this week and I'll try and swap a 70N02 and a few different ones in there to see if they work in that setup.

Thanks RMM. That would be very valuable!

I’ve been doing some thinking about why SiR800DP did not work. (Again, all the FETs I tried work fine in 255/255 mode. Current is regulated properly, the LED lights up, all good. It’s all lower modes where they struggle.)

If you take a look at the datasheets, nothing is spec’ed as having a markedly lower Qg than DTU30N02. It’s also possible that DTU30N02 comes in slightly below spec and the others are coming in slightly higher. At a glance it appears that “turn on delay time” is also either higher or spec’ed similarly on these other FETs I’ve tried.

What I’m hoping is that reducing PWM freq may fix something. That would be sweet…

Wight, I've only ever done phase correct 9.4 kHz into the 7136s. I wonder if there's something to that? I've never heard any noise at all come from the lights so there is nothing lost by switching to it.

#$@&%* YES!

I was less than thrilled when this thing didn’t work the way I expected with NXP PSMN3R0-30YLD or Vishay 70N02. My scant notes showed that I’d already switched to 9.4khz phase correct, so I dropped in a :8 prescaler to take things down to 1175hz. Since I had a Vishay 70N02 laying there on the bench, that’s what I tested with. It appears to be functioning fine. I haven’t scoped it yet, so no telling what the slow PWM is doing to my output waveform. Haven’t even measured current yet…

  • I scoped the output on the 70N02. Looks fine to me.
  • I installed NXP PSMN3R0-30YLD. No problem.

Right on! The poor little 7136 must not be able to count fast enough to keep up with the faster input PWM.

I’m quite excited about this little driver, glad to hear it’s making progress again. I’m getting tired of stacking 7135s and dealing with their tricky heatsinking requirements.
Something like this would be a perfect substitute from what I can tell, I take it only the large FET needs to be considered for heatskinking?

Cheers
Linus

I’m pretty thrilled myself (if you couldn’t tell ;)).

The FET definitely needs heatsinking once you go beyond a certain point. I just don’t build enough to know where to draw the line, so I’d say that anything which dissipates over 2W in the FET should involve heatsinking. Maybe a person could “get away” with much more, but why bother? At least throw in some kind of TIM cube like the ones from IOS.

With a set current of 10A your entire resistor bank should be dissipating 0.5W total. I don’t expect a need for heatsinking there. Depending on what you do and how you do it (ie bypassing the 7136 to turn the FET fully on for 10A while using a low set current, such as 3A) you’ll either destroy resistors or need to heatsink them. For most users that won’t be much of an issue I think - just don’t do a bypass and there’s no problem up to around 20A.

Right now the 17mm version has a trace for the bypass: note the trace that goes from Pin5 of the MCU down to the 7136 and then unbroken over to the Gate pin on the FET. Using this trace requires a customized version of the firmware which puts Pin5 into “high impedance” mode during normal operation and then pulls it “high” for bypass operation. I expect to either:

  • eliminate this trace (that sucks for the people that wanted to use it)
  • implement a solder jumper (these are tight quarters for a solder jumper… but I could eliminate some of the LED+ pad to make space)
  • implement a custom ATtiny13A footprint with solder mask completely covering the pad for Pin5. This would allow most folks to solder the IC in place with no connection to Pin5, allowing the use of normal firmwares normal firmwares with a prescaler or divider of 1:8. Users who wanted to use a bypass firmware could just scrape the pad before reflowing, no big deal.

I’m not really happy with any of these ideas at the moment…

I’m not sure which of the things I mentioned above is the problem. After reviewing the datasheets some more last night I’m leaning towards turn-on-delay-time as the culprit.

I’ve been using an older STAR_momentary firmware without dual-PWM support. That made the code less complex for me to work on when implementing a rough, testing-only, bypass mode (which I appear to have broken recently). I think it will be interesting to see how the driver responds to Dual-PWM. Dual-PWM should provide ~1.2kHz Phase Correct and ~2.4kHz Fast PWM. Frankly it may not do anything useful, probably it would just compress all the modes even higher into the PWM range. Not really a problem, just don’t use Fast PWM if it’s not useful.

I’ve been wanting to play with this in SRK/M6 size, but I pushed that to the back of my mind since the driver wasn’t working. Now that it operates, I took a couple of hours and laid something out.

  • 47mm
  • MCU on the bottom. I was inspired by Mike C’s - Mod: My SupFire M6 “BMF” edition (new beamshots in OP) and the way Mike C made the MCU available for flashing.
  • LDO optional. An LDO will work fine for all applications, but it costs slightly more than a diode. You can just solder on C1 and solder the diode between C1 and the empty C2 pads.
  • 1.3mm LED+ vias will take 18AWG wire from the careful modder, IIRC.
  • Extra pad on top for Pin 6 (extra PWM pin, temp sensor, or status LED)
  • Extra pad on top for Pin 3 (probably for a temp sensor or status LED)
  • OTC in case you are somehow making a clicky light…
  • I’m aware the MCU GND needs to be moved. This will not be a problem.

The optional LDO is present for e-switch MT-G2, MK-R, XHP50, XHP70, etc. With the current bottom it’s intended for 8x18350 (2s4p) or similar. I think it’s apparent that the bottom copper could be easily changed to be like Mike C’s layout.

Darn this looks really good, now I’m considering rebuilding my BTU Mtg2 around these drivers. They’d be a much neater solution, and I’d imagine less thermal issues since sinking 3 large components with handy pads on the bottom is much easier/more efficient than doing the same to 48 triple stacked 7135s.

Can you put the final nail in the coffin for me by confirming that actual voltage dropout is lower or at least equal to an equivalent 7135 based board? :stuck_out_tongue:

Cheers, and keep up the great work!
Linus

Thanks!

I only did a very small test, but Vdo seems to climb with set current for some reason. The Vdo from a bank of 7135s seemed to quickly eclipse that of the 7136-based driver as I increased the drive current (by adding 7135’s and increasing the sense resistance, respectively). I’m not sure why it worked that way. I think I wrote a very short post earlier in this thread about it.

I’m not sure about the “handy pads” you mentioned. The large pad is electrically connected to LED-, so it must be isolated from GND. If you just meant the large flat area on the top of the FET then carry on: I agree. One issue is that these FET’s are so slim that the QX7136 and ATtiny13A are both taller IIRC. Not the end of the world, there are various ways to deal with that.

Ah whoops. :frowning: I wasn’t paying attention and assumed the large pad underneath the fet was for ground/heatsink. Had thoughts of mounting those fets remotely and soldered directly to a copper insert or something in the driver cavity.
That makes it a little less ideal than I thought, I know from dealing with the 7135s that heat sinks making contact with just the top of the chip are next to useless in keeping the chip from going critical.

But again this is a massively bigger package so I’m keen to have a play around with this driver and see how it deals with the situation thermally.
Cheers