Oshpark Projects

1808 posts / 0 new
Last post
Cereal_killer
Cereal_killer's picture
Offline
Last seen: 1 year 11 months ago
Joined: 07/22/2013 - 13:10
Posts: 4005
Location: Ohio

This is kinda what I was talking about, leaving the MCU on the top but making each of the 6 needed legs for programming have a via, then you could make a contraption like this and flash it without removing the driver.


(tivo’s pic)

edit It’s not like the via’s would have to go directly where each of the legs are, thats not even possible, some could possibly work but you would need to run traces around to real estate that was open on both sides using a bare driver to properly space the header pins like in the pic.

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 year 6 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town
DBCstm wrote:
Short 5/16” brass pillar for the contact, leave one spring at the switch end to maintain snug battery contact. This would make a small contact pad on the board, plenty of room for electronics, even shifted or skewed sideways a bit for the traces. With a solid pillar for contact, no chance of compressing the positive spring (nonexistent) to cause a short.

Centered on the contact pad, these work well

http://www.fasttech.com/p/1145100

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Cereal_killer wrote:
This is kinda what I was talking about, leaving the MCU on the top but making each of the 6 needed legs for programming have a via, then you could make a contraption like this and flash it without removing the driver. !http://i1222.photobucket.com/albums/dd498/tivo532/TZF082A_LED_Driver-AMC...! (tivo's pic) *edit* It's not like the via's would have to go directly where each of the legs are, thats not even possible, some could possibly work but you would need to run traces around to real estate that was open on both sides using a bare driver to properly space the header pins like in the pic.

...or just put the MCU on the battery side and use a normal SOIC clip. There's no reason the clip wouldn't fit, if the board was designed for the necessary clearance, and you didn't have some funky pill with the driver recessed or using a screw-down retainer. Normal pills where the driver mounts flush with the rear of the pill would be fine. Attach clip, program, screw pill back in.

This is only on the 17/20mm boards, the 15DD is a different animal. There's plenty of room for the MCU, a full-size spring mounted the correct way around would fit but just barely, with a smaller spring pad the same size as the big end of the spring. And if it were programmable with a clip without removing the driver, that would render the convenience of a threaded driver retainer moot, just solder it in and toss the retainer. You can still flash away till the cows come home without messing with unsoldering anything.

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

comfychair wrote:

Cereal_killer wrote:
This is kinda what I was talking about, leaving the MCU on the top but making each of the 6 needed legs for programming have a via, then you could make a contraption like this and flash it without removing the driver. (tivo’s pic) edit It’s not like the via’s would have to go directly where each of the legs are, thats not even possible, some could possibly work but you would need to run traces around to real estate that was open on both sides using a bare driver to properly space the header pins like in the pic.

…or just put the MCU on the battery side and use a normal SOIC clip. There’s no reason the clip wouldn’t fit, if the board was designed for the necessary clearance, and you didn’t have some funky pill with the driver recessed or using a screw-down retainer. Normal pills where the driver mounts flush with the rear of the pill would be fine. Attach clip, program, screw pill back in.

This is only on the 17/20mm boards, the 15DD is a different animal. There’s plenty of room for the MCU, a full-size spring mounted the correct way around would fit but just barely, with a smaller spring pad the same size as the big end of the spring. And if it were programmable with a clip without removing the driver, that would render the convenience of a threaded driver retainer moot, just solder it in and toss the retainer. You can still flash away till the cows come home without messing with unsoldering anything.


In many cases a clip won’t be able to get to the chip. A long stick with a 6-pin header on the end of it can reach down battery tubes and/or past retaining rings.

ICSP is often broken out on a header or pads. Why wouldn’t we do that here? It’s a pretty straightforward proposition and it eliminates squeezing entirely. I don’t see a downside really.

Maybe if we standardized on an ICSP header pinout we could drop the stars forever and just flash.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

DB Custom
DB Custom's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 01/13/2013 - 22:28
Posts: 20733
Location: Heart of Texas

And any light using the high amperage Tofty is a one spring set-up, spring on the driver. Never ran into a problem. Then again, I don’t go banging my lights around either.

Found a 3’ brass rod at Lowe’s, cut what I need. It’s really not much difference from the super stout cylindrical spring found on Qlites.

Making it fancy with vias for pins for flashing the MCU would probably drop a lot of modders right out of doing it. Me included. I flash the MCU, then build the driver, assemble and move on. Y’all have fun with that. Wink

With the Moon mode engaged through the Star 2 in STAR firmware, the MCU pin 5 is grounded, can’t flash it. So there would be limitations.

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

DBCstm wrote:
And any light using the high amperage Tofty is a one spring set-up, spring on the driver. Never ran into a problem. Then again, I don’t go banging my lights around either.

Found a 3’ brass rod at Lowe’s, cut what I need. It’s really not much difference from the super stout cylindrical spring found on Qlites.

Making it fancy with vias for pins for flashing the MCU would probably drop a lot of modders right out of doing it. Me included. I flash the MCU, then build the driver, assemble and move on. Y’all have fun with that. Wink

With the Moon mode engaged through the Star 2 in STAR firmware, the MCU pin 5 is grounded, can’t flash it. So there would be limitations.

It seems that you are misunderstanding the suggestion. It has no bearing on what you do – you’d just keep doing it! Neither changing the location of the chip (comfychair’s suggestion) nor adding contacts of some type to the board (Cereal-killer’s suggestion) would keep you from programming the chip and then installing it.

Cereal-killer’s suggestion, like comfychair’s suggestion, pertains specifically to programming the chip while in-circuit. Whether it’s the initial program or a change made later, the idea is to make it less trouble to program a chip that’s already on the board.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Or maybe I misunderstand you DBCstm. Are you simply saying that many people have no use for reprogramming a driver once it’s built? No matter how easy we make it?

If so I agree! I feel the same way about the “stars” as well though.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 1 year 11 months ago
Joined: 07/22/2013 - 13:10
Posts: 4005
Location: Ohio
DBCstm wrote:
With the Moon mode engaged through the Star 2 in STAR firmware, the MCU pin 5 is grounded, can’t flash it. So there would be limitations.

Or you could (dis)engauge moon mode in the programming, just sayin. I never solder stars, if I want something different from normal I change the FW and reflash, the only desoldering I have to do to reflash is the off-time cap, and using the header pin idea that wouldn’t be in the way anymore*

*but maybe you’d still have to remove it to flash? Not sure, it’s not technically grounding the pin, maybe you don’t (that is if you didn’t have to physically move it out of the way anymore, guess I’ll have to try flashing a 105 where the cap is on the back real quick and see if you can do it with the off-time cap still connected).

Just so you guys know I’m not trying to argue with anyone and I’m definitely not claiming anyone’s idea’s wrong or saying mine is better, just discussing different means to the same end…

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

DB Custom
DB Custom's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 01/13/2013 - 22:28
Posts: 20733
Location: Heart of Texas

I too was merely thinking out loud as it were. Neat that y’all are figuring a way around an existing problem. Who knows, if it were that easy maybe I’d have to adopt it and start doing things differently.

I find that quite a few lights I use have a retaining ring that accounts for the driver being grounded well. With this ring many of the new boards have too many components very close to the edge. How are y’all getting around that? I’ve been cutting a relief in the inner ring to keep it from contacting the components, thinning down the outer area where the ground contact is made.

Didn’t mean to come across as argumentative, I know that I do more often than not though. Sorry.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 year 6 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

Problem with it is, the Zilog only uses 4 pins for programming, the ATtiny will require 6…and that is if nothing is tied into the pins where the data is fed

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

The topside of the current-gen 17DD is awfully crowded on the top, seems like moving the MCU would solve several problems at once without creating any new ones. I think it's kinda unrealistic to discount a design change because the clip won't fit through a battery tube, removing the pill is rarely much of a big deal but unsoldering a driver from the pill just because the moonlight really needs to be a '3' instead of '4' gets old real quick.

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

DBCstm wrote:
I too was merely thinking out loud as it were. Neat that y’all are figuring a way around an existing problem. Who knows, if it were that easy maybe I’d have to adopt it and start doing things differently.

I find that quite a few lights I use have a retaining ring that accounts for the driver being grounded well. With this ring many of the new boards have too many components very close to the edge. How are y’all getting around that? I’ve been cutting a relief in the inner ring to keep it from contacting the components, thinning down the outer area where the ground contact is made.

Didn’t mean to come across as argumentative, I know that I do more often than not though. Sorry.

Hardly anything to apologize for. As for the component placement thing… do you have specific examples? I understand the basic problem, but it would help to know what you are running into specifically. As a point of reference, my 17mm QX5241 is supposed to have at 0.5mm+ clearance on both sides. That wouldn’t be enough for a retaining ring, I haven’t really gotten that far in my plans yet. I’ve been planning on just kludging something. On the other side of the story I specifically laid out the 22mm 17* board to have the retaining ring land on top of components.

WarHawk-AVG wrote:
Problem with it is, the Zilog only uses 4 pins for programming, the ATtiny will require 6…and that is if nothing is tied into the pins where the data is fed
I agree, that is an issue. I’m not sure how big an issue, but getting 6 connections into good spots (and in a row) doesn’t sound super-fun. I haven’t sat down and worked on it, but I think with some thought and maybe small concessions (arranging pins in a well considered pattern) that it may be doable.

comfychair wrote:

The topside of the current-gen 17DD is awfully crowded on the top, seems like moving the MCU would solve several problems at once without creating any new ones. I think it’s kinda unrealistic to discount a design change because the clip won’t fit through a battery tube, removing the pill is rarely much of a big deal but unsoldering a driver from the pill just because the moonlight really needs to be a ‘3’ instead of ‘4’ gets old real quick.

My personal goal was already to eliminate clips. Sticking the contacts for ICSP somewhere accessible for programming the driver while it’s installed is just a bonus from my personal perspective. I do understand that your priority is specifically to be able to program the chip.

I’m not discounting your idea only because a clip can’t be shoved down a battery tube or past a retaining ring. It’s still one consideration though.

EDIT:
sorry, I meant to mention this: Yes, I absolutely agree with the bit about removing a driver just to do a small tweak being lame. If that can be prevented it will be good for everyone.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Rufusbduck
Rufusbduck's picture
Offline
Last seen: 7 months 2 weeks ago
Joined: 04/04/2012 - 15:34
Posts: 10389
Location: Golden state

Quote:
Making it fancy with vias for pins for flashing the MCU would probably drop a lot of modders right out of doing it. Me included. I flash the MCU, then build the driver, assemble and move on. Y’all have fun with that.

Good points Dale. Designing a new driver doesn’t need to mean we delete one preferred by others though. If a new set is done with pin headers I recommend a new board “family” name placed in its own group to distinguish it from the current crop. It might be easier to start with a larger driver size to incorporate this detail and work down to the smaller ones. Another possibility, and you guys that to the programming can let me know in full detail why this won’t work, but how about a small board with nothing but the attiny pad layout with vias for pin headers. If the pins just clear the body of the IC with a locator pin at either end you would have a custom clip that would fit just about any of the nanjg boards.

Three Tanna leaves to give him life, nine to give him movement. But what if he eats the whole bag?

Scott

DB Custom
DB Custom's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 01/13/2013 - 22:28
Posts: 20733
Location: Heart of Texas

This idea has grown on me. Last night was rough, brain wasn’t working so well this morning. So I was in a resistant-to-change mode for some crazy reason. But after seeing this and wrapping my feeble noodle around it a bit, I’m liking the idea. As you said Comfy, being able to pull the pill and easily flash the MCU beats the heck out of de-soldering the driver from it’s grounds.

I haven’t re-flashed much before because it was difficult, this might change the whole game and make it easy to experiment with levels and modes and get a light tuned just so. And I have no idea why I was thinking it would pre-empt existing design. Anybody that doesn’t want it doesn’t have to buy in, geesh. lol

I should shut up. No need to second that, I already know. :~

Rufusbduck
Rufusbduck's picture
Offline
Last seen: 7 months 2 weeks ago
Joined: 04/04/2012 - 15:34
Posts: 10389
Location: Golden state

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

Three Tanna leaves to give him life, nine to give him movement. But what if he eats the whole bag?

Scott

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Cereal_killer wrote:
DBCstm wrote:
With the Moon mode engaged through the Star 2 in STAR firmware, the MCU pin 5 is grounded, can't flash it. So there would be limitations.
Or you could (dis)engauge moon mode in the programming, just sayin. I never solder stars, if I want something different from normal I change the FW and reflash, the only desoldering I have to do to reflash is the off-time cap, and using the header pin idea that wouldn't be in the way anymore* *but maybe you'd still have to remove it to flash? Not sure, it's not technically grounding the pin, maybe you don't (that is if you didn't have to physically move it out of the way anymore, guess I'll have to try flashing a 105 where the cap is on the back real quick and see if you can do it with the off-time cap still connected). Just so you guys know I'm not trying to argue with anyone and I'm definitely not claiming anyone's idea's wrong or saying mine is better, just discussing different means to the same end...

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):

http://75.65.123.78/driverhacks/Dsc07909.jpg

Even possible to do on the tiny 15DD:

http://75.65.123.78/driverhacks/Dsc07907.jpg

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

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.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 year 6 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

comfychair wrote:

Cereal_killer wrote:
DBCstm wrote:
With the Moon mode engaged through the Star 2 in STAR firmware, the MCU pin 5 is grounded, can’t flash it. So there would be limitations.
Or you could (dis)engauge moon mode in the programming, just sayin. I never solder stars, if I want something different from normal I change the FW and reflash, the only desoldering I have to do to reflash is the off-time cap, and using the header pin idea that wouldn’t be in the way anymore* *but maybe you’d still have to remove it to flash? Not sure, it’s not technically grounding the pin, maybe you don’t (that is if you didn’t have to physically move it out of the way anymore, guess I’ll have to try flashing a 105 where the cap is on the back real quick and see if you can do it with the off-time cap still connected). Just so you guys know I’m not trying to argue with anyone and I’m definitely not claiming anyone’s idea’s wrong or saying mine is better, just discussing different means to the same end…

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):

http://75.65.123.78/driverhacks/Dsc07909.jpg

Even possible to do on the tiny 15DD:

http://75.65.123.78/driverhacks/Dsc07907.jpg

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
wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Rufusbduck wrote:
Good points Dale. Designing a new driver doesn’t need to mean we delete one preferred by others though. If a new set is done with pin headers I recommend a new board “family” name placed in its own group to distinguish it from the current crop. It might be easier to start with a larger driver size to incorporate this detail and work down to the smaller ones. Another possibility, and you guys that to the programming can let me know in full detail why this won’t work, but how about a small board with nothing but the attiny pad layout with vias for pin headers. If the pins just clear the body of the IC with a locator pin at either end you would have a custom clip that would fit just about any of the nanjg boards.
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.

WarHawk-AVG wrote:
comfychair wrote:

Cereal_killer wrote:
DBCstm wrote:
With the Moon mode engaged through the Star 2 in STAR firmware, the MCU pin 5 is grounded, can’t flash it. So there would be limitations.
Or you could (dis)engauge moon mode in the programming, just sayin. I never solder stars, if I want something different from normal I change the FW and reflash, the only desoldering I have to do to reflash is the off-time cap, and using the header pin idea that wouldn’t be in the way anymore* *but maybe you’d still have to remove it to flash? Not sure, it’s not technically grounding the pin, maybe you don’t (that is if you didn’t have to physically move it out of the way anymore, guess I’ll have to try flashing a 105 where the cap is on the back real quick and see if you can do it with the off-time cap still connected). Just so you guys know I’m not trying to argue with anyone and I’m definitely not claiming anyone’s idea’s wrong or saying mine is better, just discussing different means to the same end…

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:

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 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 wrote:

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):

comfychair, your 18AWG is sexy.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

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)

Rufusbduck
Rufusbduck's picture
Offline
Last seen: 7 months 2 weeks ago
Joined: 04/04/2012 - 15:34
Posts: 10389
Location: Golden state

Quote:
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.

Three Tanna leaves to give him life, nine to give him movement. But what if he eats the whole bag?

Scott

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

comfychair wrote:

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)

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Rufusbduck
Rufusbduck's picture
Offline
Last seen: 7 months 2 weeks ago
Joined: 04/04/2012 - 15:34
Posts: 10389
Location: Golden state

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?

Three Tanna leaves to give him life, nine to give him movement. But what if he eats the whole bag?

Scott

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Rufusbduck
Rufusbduck's picture
Offline
Last seen: 7 months 2 weeks ago
Joined: 04/04/2012 - 15:34
Posts: 10389
Location: Golden state

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

Three Tanna leaves to give him life, nine to give him movement. But what if he eats the whole bag?

Scott

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

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

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

comfychair wrote:

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 Sad ). So unfortunately I don’t think I’ll have a chance to play with AOD510 very soon.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

comfychair
comfychair's picture
Offline
Last seen: 5 years 7 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

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?

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 year 6 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

You noticed that too huh Sad

wight
Offline
Last seen: 1 year 8 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

comfychair wrote:

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’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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Pages