Oshpark Projects

No need to bash yourself. We’ve got that covered. :stuck_out_tongue:

Off-time cap doesn't interfere with reflashing, either electrically or mechanically (if you locate it in a spot that doesn't block the clip!).

20DD (same applies to 17DD):

Even possible to do on the tiny 15DD:

Also, no reason why the off-time cap couldn't be given its own dedicated pad & trace to locate it somewhere out of the way, since the board would have to be totally rearranged anyhow.

Question, would pads for a capacitor be warranted for applications such as this?
Like I did with the BLF22DD revision I did using Mattaus’s 20DD?

https://oshpark.com/shared_projects/fSQZEBEf

I agree that a “family” or some other sort of designation would be best for drivers which have the proposed feature. While we only have so many existing drivers and our naming system is only so well developed, I think that the real families will probably turn out to be based on what the driver does and how it does it. BLF17DD-through-BLF22DD all do the same thing using the same components for example. I think that a designation such as “BLFxxDD w/ BLFPH1 support” would clearly show that the driver was BLF17-based and supported whatever our initial pinheader standard might be. That might also be exactly what you were saying, heh. Either way, establishing a standard that can be used across more than one design would be great. It may be tricky or impossible, we’ll see.

On the subject of where to start, I think the opposite approach would be best. Starting with the smallest boards means we’ll have the least space to work with, thus making the layout trickier and more constrained. If a pinheader can be developed for those boards my hope is that the larger boards will have enough space to accommodate it as well.

I think it’s best to include the pads for an offtime cap whenever the design allows. I see no downside. That’s why I made sure to provide for that cap in both of my WIP drivers.

comfychair, your 18AWG is sexy.

What's the downside to using the clip? I had a nightmare of a time with my first one, a 3M, because it was total crap in stock form and even with a softer spring and the pins JB Welded in place so they'd stop pushing themselves up away from the chip's legs it only lasted a few months. The blue Pomona clip is not only cheaper, it needs none of the work the 3M did and is usable right out of the box, and has held up great. It's already lasted longer than the other one did and not yet showing any signs of getting flaky.

Moving the MCU instead of just adding header pin sockets solves two things at once: the issue of crowding on the topside (LED +/- can be spread out to opposite sides of the board, with the FET in the center and the gate/pulldown resistors below the FET), and of being able to reflash with the driver still in the pill.

I'm just trying to think up ways to solve as many problems as possible with the fewest number of drawbacks. I don't find using the programming clip to be a problem that needs solving. (and, constantly switching out the programmer's cable with the SOIC clip on it for the cable with the header pins on it is creating another drawback)

I agree with you CC even though I’m not up to reflashing yet what you’re suggesting makes sense. Some probably will still push for headers for their own reasons and that’s fine too but does crowd the board more. No reason why both directions can’t be pursued. The “family” thing is more organizational with the idea of having the names chosen accordingly and grouped accordingly.

I like the smaller dia Qlite spring as it’s longer than other 105C springs but still fits a 5mm pad. A reversed larger spring or a post are also options. The advantage of a post is not needing a spring mod.

Really, I should get my mind back on track here:

  1. I do not plan to do the work you suggested to the BLFxxDD boards, but I also do not plan on doing the work I advocated for them (creating a pinheader or similar)! So my suggestions and opinions are only to be taken at face value. Anyone who plans to do the work can consider what I've said, but that's about the extent of the impact I plan to have on this.
  2. Establishing a pinheader which is workable across multiple boards is *probably not practical*:
    A. it must be a small pitch, I suspect that connectors will not be available.
    B. I suspect that we just don't have enough space on these boards to standardize a header.
  • FWIW I haven't tried the Pomona, so I've only seen the bad side of clips in terms of how finicky or durable they are. Maybe this is something I should revisit, but I probably won't do it right away.
  • I often don't worry over a $4 tool or two, so having two USBasp boards, one with a pinheader dongle and one with a clip or test socket isn't really a problem from my perspective. I also use some screwdrivers with interchangeable tips; changing the tips isn't my favorite thing to do but I'm OK with it. If all your drivers going forward had the same header you wouldn't have to do much swapping. [OTOH sometimes I get really obsessed about trying to save a buck. I can't do anything about it other than attempt to stay self aware.]
  • The drawbacks I mentioned about the retaining ring are still there. They might not get solved with a pinheader-esq solution either though. It would have to be pretty tiny and pretty close to the middle.
  • I'm certainly not saying that increasing component spacing is a bad thing. If you can get that to happen while getting other good things to happen... good!
If only wishes were fishes and we had 8k of programming space this discussion might not be happening. I think that would be enough space for a bootloader and we could do programming with (I guess) 3 wires. The MLF packaged ATtiny85 might facilitate that, but that package brings on other issues.

So the AOD FET doesn’t work as a replacement for the 70N02? I should edit the op for this pronto. My apologies for missing this. Does this mean a new board with a different FET is needed?

The AOD FET does not work as a drop in replacement for the Vishay 70N02 with the R3 and R4 values currently used for the 70N02. A new board should not be needed, the current boards allow for all necessary components.

I am operating under the assumption that the AOD will function with different resistor values, but that could definitely be a wrong assumption. Regardless of whether the AOD works, I expect we’ll continue to use the BLF17DD for whatever setup does work.

Ok, I’ll edit the op to try and reflect this.

wight, can you (if you haven't already) check the datasheets and see if anything jumps out that might explain what's up with the two FETs?

http://75.65.123.78/pdf/AOD510.pdf

http://75.65.123.78/pdf/SUD70N02-03P-E3_72246.pdf

Comfy, I looked over them in detail earlier. I looked at things in general plus things I didn’t think of that Microa (and maybe others) brought up. Based on the very very little I know and the things other people brought up it AOD510 looked fine to me.

Right now I don’t need to order any other parts, and I don’t even normally order from Digikey (I use Mouser - they don’t seem to carry the AOD510 :frowning: ). So unfortunately I don’t think I’ll have a chance to play with AOD510 very soon.

And a general Oshpark question: am I missing something or do they really not have a 'shopping cart' to do more than one project per order/payment? What is this, 1996?

You noticed that too huh :frowning:

You’re not missing anything. The site is super basic. It annoys me a little bit because I think Laen has indicated in the past that the site would be upgraded but nothing ever seems to happen. There are several useful things missing, such as an order-history/re-order function.

Back on the FET thing… now that I think about it, the ATtiny13A datasheet shows it dropping quite a bit of voltage on the outputs. For the PWM pins it’s something in the range of 0.7-1.0v below VCC. If a protection diode is in place VCC is already lower than battery voltage, I forget how much. At least 0.2v lower I think. I posted combined graphs in post #844 showing that while the turn-on for AOD510 is much steeper (good), it also Crap. Nevermind, I was comparing it to the red line, the 70N03. I still see no problem with using the AOD510! Hopefully resistor value tweaks will help.

Well, way back when before we added the gate/pulldown resistors, one thing I found was that bypassing the diode made the FET behave correctly.

edit: this was with the Vishay 70N02, which has issues (on the 17DD/20DD boards only) without the resistors.

Is there a pot that could help find a usable R3 value?

Does that put a slightly higher voltage on the gate?

I assume so. But what keeps defying logic is that you can build a 17DD without the resistors, test it and find it does the crazy mode changing thing, strip all the parts off the PCB and stick them on a SRK-DD board, still without the resistors, and it works perfectly.