-
In any case, how does one go about selecting a bead?
Okay, I think I've got a better handle on this, now (thanks again!). Also... on closer inspection, I notice that if I want a TH component in production, it appears my options are:- Laird 28L0138-10R-10 (45 Ω)
- Laird 28L0138-70R-10 (123 Ω)
- Laird 28C0236-0EW-10 605 Ω)
Seriously, that's it. I would have gone Murata, but they don't seem to make TH beads any more. So... what, if anything, do you know about Laird? 🙂
The Ohm-values in the list are impedance at 25 Hz... not quite 20 Hz, but as far as I can tell, the curves are fairly smooth (no surprise), so, while the impedance at 20 Hz will be a bit lower for all, the three parts can still be classified "low", "medium" and "high". The "high" is closest to the bead you mentioned, and IIUC, higher is better (given the DC resistance seems to be the same for all of them (10 mΩ), so I guess that one is "best"?
(The only other active manufacturer appears to be Abracon, but their data sheets are conspicuously lacking impedance graphs and current ratings, which is very not-trust-inspiring.)Thanks again! Get any code running yet?
No [...] are you in a hurry?
Please don't rush on my account! You've already been tremendously helpful, and I don't want to impose.
...but also, no (I don't have components yet, either). I was just wondering; more of a conversational gambit than anything. 🙂 -
Laird 28L0138-10R-10 (45 Ω)
The datasheets show 46Ω, 120Ω, and 580Ω impedances at 20 MHz, respectively; with resistance components of 38Ω, 95Ω, and 480Ω, respectively; and all with 0.010Ω = 10mΩ DC resistance.
Laird 28L0138-70R-10 (123 Ω)
Laird 28C0236-0EW-10 (605 Ω)
I'm not sure if the two first ones would have any effect in this circuit, considering we don't do ADC, and just want to add that little bit of additional filtering just in case it would otherwise interfere with our digital logic (pulse edge detection from tach inputs, specifically).
The last one seems eminently suitable for me, but the 0.65€ price in singles at Digikey makes me wonder if the additional "bracing" from a ferrite bead is worth that much. Remember, this was always about "extra" protection that to me costs 0.10€; and not a necessary component at all.
Most ATtiny85 circuits do not have a ferrite bead at all.
Thus: If the price does not matter to you, use the 28C0236-0EW-10. If the price matters even a little bit, I'd drop the ferrite bead and not worry about it; I would not use one if I had to pay 0.65€ (instead of 0.10€) for each one.So... what, if anything, do you know about Laird? 🙂
I don't have enough experience to have an opinion on Laird. It was recently acquired by DuPont. I do know that the datasheets for these date back to before the turn of the century – but even then, had frequency-impedance graphs generated using HP test gear and fixtures, making me like them quite a bit. At least back then, they were proud of their product, and not shy about showing how the figures they claimed were measured (making it easy for anyone to replicate the results). As to having been split and sold since then, I do not know what it has done to their manufacturing, but hopefully nothing has changed much for these radial ferrite beads.
Don't let my analytical communications style distract you from the fact that I, too, am only a hobbyist wrt. electronics; not an EE.Please don't rush on my account! You've already been tremendously helpful, and I don't want to impose.
...but also, no (I don't have components yet, either). I was just wondering; more of a conversational gambit than anything. 🙂
Good to hear!
The following is some musing on the firmware implementation, just in case someone at some point might find my current notes interesting.
I do intend to write and document the code so that even a non-programmer can gather a general understanding of how it works.
The reason I need to test both the interrupt and iteration-counting approaches is that when using interrupts, if we receive a tach edge just before the timing timer wraps, our timing count can be short by exactly one full timer period, or 256 units. I believe that by reading the timer count, then the overflow flag, and the timer count again, while interrupts are still disabled, we can determine the time reliably; but I haven't checked it in practice on ATtiny85 hardware yet. The actual timer value can be any size we need, as the low 8 bits are obtained from the timer, and the high bits are just the count of timer wraps, each wrap being an interrupt.
The iteration counting approach involves a fixed-duration inner loop body, that checks both fan tach input states, increments a counter, and loops until sufficient number of iterations have occurred. In this way, the iteration duration is the "clock" we compare the fan tach pulses against. The downside is that it has to be written in AVR assembly, to ensure each iteration takes a fixed, known duration. It is also a much more "old-school" way of timing things precisely; with some having a serious distaste against such "busy-waiting" schemes (mostly because they are bad on systems where you have more stuff to do).
In theory, both approaches work fine. The former is more complex in logic. The latter is simpler – just nested loops, no interrupts –, but the innermost measurement loop written in assembler would be a black box to most programmers.
In practice, there is bound to be jitter in the tach pulses and other practical stuff I don't know yet, because I haven't done this before. Thus, the correct RPM reading cannot be just the inverse interval between successive rising edges of the tach signal; we need some kind of averaging. And this is where the two approaches do differ. The interrupt approach always timestamps the same edge of the tach signal, obtaining the duration of the last tach cycle; whereas the iteration counting loop can do a time-limited measurement (count both the number of cycles and total duration of those cycles, for a limited duration).
The interrupt must be short, so that if the two tach pulses are in sync, the other is recognized soon enough that its timestamp is not too much later than was detected. Heck, since AVR has 32 8-bit general purpose registers, using GCC or Clang we could easily reserve some of these for the interrupts only, so that normal C code would not touch them, making the interrupts use only 2 bytes of stack per nesting level since no registers need to be saved, and reducing the interrupt latency.
A particularly interesting approach I want to try out is to use separate handlers that do the timestamp at minimal latency, and then enable the interrupts, so that the other interrupt can interrupt the current one; then the averaging calculation done in the interrupt does not cause a latency in the tach transition timestamping, only in the main code. Which, admittedly, in the interrupt-based code would be just twiddling its proverbial thumbs waiting for something to happen, anyway. I could do the timestamping bit in inline assembly (it's just a few lines), enable interrupts, and jump to C code that does the interruptable averaging and stall detection part.
In many ways, this reminds me of the time decades ago when I first learned 6502 assembly; happy times! Except now I have much better tools, and the AVR architecture with its many registers is much nicer than the stack-based 6502. Just my opinion, though! But ATTiny85 running at 20 MHz is more than an order of magnitude faster than the 1 MHz 6502 in C64 was... and for something like this, the very small amount of RAM we have on an ATTiny85 is not an issue: we don't have much state to keep track of, and call chains should be short (meaning we shouldn't need much stack either). -
The last one seems eminently suitable for me, but the 0.65€ price in singles at Digikey makes me wonder if the additional "bracing" from a ferrite bead is worth that much. Remember, this was always about "extra" protection that to me costs 0.10€; and not a necessary component at all.
Most ATtiny85 circuits do not have a ferrite bead at all.
Thus: If the price does not matter to you, use the 28C0236-0EW-10. If the price matters even a little bit, I'd drop the ferrite bead and not worry about it; I would not use one if I had to pay 0.65€ (instead of 0.10€) for each one.
If I was price-conscious, I'd probably be using SMD everywhere possible. 🙂 I'm not making thousands of these, maybe just a handful, so the difference between 10¢ and 65¢ isn't terribly relevant, and I'm inclined to lean toward paranoia. That said... I just don't any way to get a TH bead on this board due to the size constraints, and due to the trace routing, I can't see how I'd manage even an SMD bead... unless I used two of them (one for U1, one for R13/R23). One of my parent boards (the one using an ATX PSU, which I haven't designed yet) shouldn't have a problem with a couple big TH beads (one for this board, one for my other MCU that's handling the UI and higher-level logic), but the only option I see for the other parent board is to slap an SMD on the back of my otherwise single-sided boards. Oh, well.
I'm leaning toward a Murata BLM41PG102SN1 (35¢), though; similar impedance, lower DC resistance, and the larger size should actually be better for handling.The following is some musing on the firmware implementation [...]
I agree there is almost certainly going to be jitter. If I were writing this, I'd probably be looking at the interrupt approach first, and I'd probably approach the averaging problem using a ring buffer. Each tach pulse interrupt computes the (8-bit? 16-bit?) interval, shoves it into the current ring slot, increments said slot, and zeros a counter. (IIRC, you can't pass data to an interrupt handler, which means each fan needs a different handler in order to know what fan its handling. If you're writing in C++, this strikes me as a job for a template function. 🙂 Make "which fan" the template parameter and let the compiler generate the two handlers from a single block of code.) Meanwhile, a timer interrupt increments the counter for each fan. If that counter exceeds some threshold, that fan has faulted. That interrupt should run at lower priority, since the only thing that might happen if it's slow or skipped is it takes a little longer to detect a fault. Note also there is no averaging done in the interrupt handler. For that matter, the tach interrupt handler only needs to mask interrupts long enough to compute the interval. If you can reserve registers for those intervals, you could unmask interrupts even before the interval gets written to the ring buffer. Then the only thing you'd have to do during the interrupts-masked period is compute the interval, and I don't see any way the handler could possibly do less than that.
One caveat to keep in mind: the controller needs to start up in "startup" mode, in which it just sends 100% to the PWM until several tach pulses have been received. It also needs to revert to startup mode in case of a missed pulse. (For my case, I also want to somehow time how long we go without tach pulses in order to raise a fault if we go for, say 15-60s.)
This will also help with knowing when to start trying to correctly throttle the fan. Whenever the fan starts up, fill the ring buffer with MAX_VALUE. While in startup mode, check if the buffer still contains any MAX_VALUE values; if not, switch to normal-running mode. -
If I were writing this [...]
Okay, I had a crack at writing the code myself. 🙂 This is incomplete (and God only knows how many bugs it contains), as I don't know¹ how to do PWM or interrupts using only libavr, how to calculate the intervals between tach pulses, or how to handle potentiometer input. (Note: I'm assuming also that the interrupt should only trigger on one edge of the pulse. AFAIK the choice between rising and falling makes no difference.)
(¹ Not saying I can't figure it out eventually, but I wanted to get this "out there" as a starting point. Though I'm not going to be touching the speed control, since I don't know what the input values look like, or how you want to map them.)
I tried also to set this up so that the same code can be used with either speed control or health reporting. It expects at most one of ENABLE_SPEED or ENABLE_HEALTH to be defined via -D argument to the compiler, and will include or strip the relevant bits of code accordingly. You can also pass DISABLE_FAN1 to build firmware for only one fan (although this mostly only matters if ENABLE_HEALTH is defined). It also expects TARGET_RPM if ENABLE_SPEED is not defined.
Hopefully, the code is reasonably documented. You'll need to implement compute_interval (only used if ENABLE_SPEED is defined). Note that the minimum PWM is non-zero and intended to be "enough that the fans actually spin". There is no effort to support zero-RPM mode. The code would likely need refactoring to support that, in particular as I use 0 as a magic value for PWM to indicate a fan in startup mode (which means you might need to add a separate field for that to support zero-RPM). Also, the fan data structure is probably missing fields needed to compute the interval since last tach pulse.
There might be a better way (albeit likely requiring an extra byte of data/state) to handle the PWM that gets closer to the target speed. The way I've implemented it, it won't increase (or decrease) the speed unless it's too low (or high) by some margin, which means in theory you'll never quite nail the target speed, but also it shouldn't "bounce" the PWM between "slightly too fast" and "slightly too slow". I think a better (but more complicated) approach would be to track the direction of adjustment, let it overshoot, but then don't allow further changes until we've gone some distance "out of spec". (Also, I just realized I need a way to rate-limit the PWM changes, but it's too late tonight to figure that out.)
In theory, this should only need 32 bytes or less of global state, and the call stack should never get deeper than eight entries (including a guess at interrupts and whatever stack is beneath loop()).
The .c extension is a lie because the forum doesn't allow C++ extensions. fastio.h is a little (C++) library I wrote to wrap pin manipulation in a nice API, but in a way that should reduce to the same AST as writing direct port manipulation in C. Whether the compiler can or will combine instructions is another question, but the places where that would even be relevant (only in setup(), I think) aren't on the critical path. It was originally written for ATmega, but I think I made the necessary change so it will work (correctly) on ATtiny also. If not, it should be pretty obvious replace it with bare port manipulation. Don't let the C++ scare you into worrying this is going to generate enormous and/or inefficient code; almost everything that isn't straight C is constexpr and/or template goodness to allow writing "pretty" (and readable!) code that probably would have been preprocessor mess in C.
Permission is granted to use thee according to the terms of GPLv3. Let me know if that doesn't work for you. -
Okay, after the recent moaning and complaining about how THT components are going to cease to exist Any Day Now™, I had a go at reworking this as an SMD board.
WDYT?
It's... passable, I suppose, though I don't love how I had to run the 12V, or the short trace on the back that interrupts the ground plane. (Hopefully because it's just an elongated hole, and not a split, it shouldn't be too bad in terms of creating large ground loops?) It's also the same height as the old (all-THT) board, and only slightly less wide. Some of that is because I'm using larger components and (especially) larger traces, but I actually have a physical constraint as to how small I can make it... one of the assemblies that's going to use this has it sitting right next to an encased PSU, and the fan headers need to be far enough from T1 to clear that. (But it also can't be any taller because of the case it needs to fit inside.) The fan headers are just above the top of the PSU.
On the plus side, I did manage to shove a ferrite bead (BLM41PG102SN1) on here. Since that's the only schematic change (besides different part numbers, of course), I'm not re-uploading the schematic. C1 is as far as I can tell the same component (TDK's THT MLCC caps are literally SMD caps potted and with leads soldered on; the SMD component I penciled in is my best guess at what the THT version has inside the potting), the transistors are MMBF170s (so, exactly the SMD versions of the BS170s; they even use the same data sheet), and... well, resistors are resistors, although I am using 500 mW CRGH1206s. (Overkill for this case, but the idea is to only deal with one type of resistor, and I may want that rating elsewhere. Also, they're as close to equivalent to the LR1s as I could find.)
There continue to be no mounting holes; I just don't see any way I could add any. I do however have an idea for a plastic carrier the board would slide and clip into. (One of the things I've been working on is designing the enclosure for this and the parent board.) Due to vertical constraints, however, I'm probably going to be nasty and have the clips "attach" to the sides of the fan headers, rather than the top of the board.
I think I'm going to relabel this (and tweak the firmware) to switch the two fan identifiers, so that FAN1 has the shorter 12V trace. That's mostly cosmetic, though.
-
WDYT?
I like it. I'd even make the 12V snake a bit more, so you can get the mounting hole on the lower left corner.
For board side clips, consider making the board a mm or so narrower at that point, so the board will stay put.
Because the 12V supply voltage is relatively stable, and if you intend to use high-power fans (more than say five watts per fan) then you better solder additional 12V wires directly from the input pins to the fan power pins, I see no reason to worry about the 12V line snaking a bit.
In general, a 1mm wide, 100mm (4") long trace on 1oz copper PCB will carry 1A of current, get 7°C hotter than ambient, and drop about 0.05 volts.
At 2A, it will get 32°C hotter than ambient, and drop about 0.11 volts. So, I use the 1A per 1mm wide 100mm long trace as a basic guide myself.
The routing on mine is much more convoluted, because I wanted it narrow (15.2mm), maybe even mountable inside 20mm tube (20mm electrical PVC tubing, JM 20, is cheap and easily available here).
Again, I'm just a hobbyist like yourself, so if anyone with actual PCB design experience would care to comment this and mine too, we'd be grateful
-
I like it. I'd even make the 12V snake a bit more, so you can get the mounting hole on the lower left corner.
For board side clips, consider making the board a mm or so narrower at that point, so the board will stay put.
Hehe. I'm resisting making the board not-a-rectangle. Largely because it's a rectangle right now, i.e. not four line segments, which is a lot easier to edit.
Besides that the mounting holes I use at least are... quite large¹ (12.5mm including clearance), a hole there, in at least one of my applications, would be nigh inaccessible. (The encased PSU on the parent board would block it. I have checked, though, that the boards should go together without collisions, and the headers should be easily accessible.) So I'll probably stick with some sort of rails/clips system. I do intend to have 'tabs' on the clips that will either overhang the top of the board, or (as previously mentioned) the top of the fan headers, so the board won't be able to just slide out.
(¹ Meant for 6-32 screws, i.e. "standard PC motherboard screws", with plenty of space between the screw head and any components or traces. Yes, I could use smaller screws and less clearance, but that doesn't solve the accessibility problem. I also don't want structural holes too close to the edge of the board, for obvious reasons, and TBH that 12.5 mm "clearance" is as much a reminder not to put the holes too close to the edge.)Because the 12V supply voltage is relatively stable, and if you intend to use high-power fans (more than say five watts per fan) then you better solder additional 12V wires directly from the input pins to the fan power pins, I see no reason to worry about the 12V line snaking a bit.
In general, a 1mm wide, 100mm (4") long trace on 1oz copper PCB will carry 1A of current, get 7°C hotter than ambient, and drop about 0.05 volts.
At 2A, it will get 32°C hotter than ambient, and drop about 0.11 volts. So, I use the 1A per 1mm wide 100mm long trace as a basic guide myself.
Oy; five watts? Are you planning on server-grade / industrial fans? 🙂
I don't intend for this to ever see more than ~3.5 W TBP, and realistically, the highest fans-only draw I have intended is 1.56 W. (Single NF-A14. My other applications uses dual NF-A4x20's which are ~1.2 W combined.) The total net length of the 12V is about 65 mm, which includes the trace from FAN2 to R21 (that's the tach pull-up resistor across FAN2.2 and FAN2.3, just below FAN2), so the trace for the fans themselves is a little less than that... and that trace is 1.5mm, and half the current only has maybe 40mm to travel. Since I don't anticipate more than ~0.3 A, I think I'm probably fine in terms of capacity. 🙂
Sure, I'm using a 10 W PSU, but IIRC that's because I figure it's safer to have more capacity than I need, and the 5 W PSU is the same form factor and almost the same price. I believe my peak draw from that is ~3 W. My other application (the one using an ATX PSU) is higher, but... it's using an ATX PSU, which is going to be something like 300 W minimum and more likely 1200 W. (Which is severe overkill, but it's a PSU I have sitting around not being used for anything else. OTOH, it's a Rosewill, which is why it isn't being used, so I'm just as happy to not be asking too much of it.)
Anyway, thanks again!
p.s. Was my attempt at writing software of any help? I'm quite lost on how to do anything PWM-related, and what reading I've done so far hasn't helped, but hopefully the other logic is at least useful as a point of inspiration?
p.p.s. Let me know if you'd be interested in seeing this "in situ", either in my case mock-up or next to the parent board. -
Besides that the mounting holes I use at least are... quite large¹ (12.5mm including clearance), a hole there, in at least one of my applications, would be nigh inaccessible.
I have some nylon M2.5 stand-offs left from a Suleve M2.5NH2 kit I got for under 4€ from Banggood three years back, and they are nice. Pity the kit is no longer available. Brass ones are available here (but obviously more expensive), but one kinda-sorta needs to use nylon washers with them to keep from chewing the board (silkscreen and relatively thin 1oz copper) up.
My boards should be arriving within a week or so. Being cheap (poor), I used the EuroPacket shipping option, and according to tracking, they're in Europe already.Oy; five watts? Are you planning on server-grade / industrial fans? 🙂
Not myself, but Incognito might (specifically, Noctual IndustrialPPC fans).p.s. Was my attempt at writing software of any help? I'm quite lost on how to do anything PWM-related, and what reading I've done so far hasn't helped, but hopefully the other logic is at least useful as a point of inspiration?
With Timer1, ATtiny85 should have no issues generating the two PWM signals at around 25 kHz.
Other than testing whether to use interrupts or loop iteration counting for the tachometer inputs, there shouldn't be any sticky points at all.
I worry much more about properly commenting and documenting the code, really!
That part is the hardest to get right.p.p.s. Let me know if you'd be interested in seeing this "in situ", either in my case mock-up or next to the parent board.
Always! Theory is one thing, but practice rules. -
I have some nylon M2.5 stand-offs left from a Suleve M2.5NH2 kit I got for under 4€ from Banggood three years back, and they are nice. Pity the kit is no longer available. Brass ones are available here (but obviously more expensive), but one kinda-sorta needs to use nylon washers with them to keep from chewing the board (silkscreen and relatively thin 1oz copper) up.
...even castellated PTHs? Though I would have thought only the screw heads would be a problem; are you attaching these in a way that the standoffs are rotating against the PCB? Anyway, I generally avoid anything near my mounting holes unless they're castellated PTH tied to an earth plane. No copper, no silkscreen, just the FR4 and soldermask.Oy; five watts? Are you planning on server-grade / industrial fans? 🙂
Not myself, but Incognito might (specifically, Noctual IndustrialPPC fans).
Those are still only 5 W combined; TBP ~0.5 A. I'd think 1.5 mm × 1 oz traces would still be okay for that without needing to beef them up? (Mine are 1.5 mm. I'm not sure about yours, but comparing to the fan header PTHs, it looks like you must be using the same size, or very nearly so? BTW, what EDA do you use? I notice you have a lot of thermal spokes that don't go anywhere. I also noticed one of your fan headers' ground pin has wider spokes on both sides, but the other on only one side; was that intentional? Also, now that I'm looking more closely at it, I'm not sure it's a good idea to tie your negative to earth?)p.p.s. Let me know if you'd be interested in seeing this "in situ", either in my case mock-up or next to the parent board.
Always! Theory is one thing, but practice rules.
Here you go! I added an 8-dip model on top of the socket to make sure that wasn't going to be a problem, but I've actually got quite a bit of vertical clearance. Horizontally, now, the MCU/socket is almost touching the parent board (male) header, but that should line up with the end of the daughter board (female) header, so should be okay. The fan headers actually have a bit more clearance than I was expecting (probably because I didn't try to account for the extra offset of the male header), which is good. You can also see the 5V regulator setup (TO-92 and caps) on the parent board, which are plenty short of the header height and thus well clear of the MCU sticking out. And, of course, that great big PSU case is hard to miss, so you can see what I needed to dodge, and why a mounting hole in the bottom corner would be awkward to access.
I don't have the case mock-up on this machine, so I'll have to post that later.
-
I would have thought only the screw heads would be a problem
Yep, the screw heads. I just tend to have to assemble and reassemble the board a few times, so even a small burr or defect on the bottom side of a steel screw head will leave nasty marks. Mostly, I'm afraid that when tightened too hard, unscrewing will take some of the 1oz copper with the screw, unless you have a nylon washer between the screw head and the PCB.I'd think 1.5 mm × 1 oz traces would still be okay for that without needing to beef them up?
Yup. Mostly my power traces are 1.7mm wide; plus 0.6mm wide in a couple of places (only a few mm in total) around the ITS41 power switch IC, which is limited to 2A anyway.BTW, what EDA do you use?
EasyEDA, I'm still switching to KiCAD 7.I also noticed one of your fan headers' ground pin has wider spokes on both sides, but the other on only one side; was that intentional?
Nah, that was just a side effect of me ensuring I have a wide enough ground trace, by manually pulling a trace under the copper ground fill.
Remember, it is not sufficient for the +V side to have a wide enough trace; your return path needs the same.Also, now that I'm looking more closely at it, I'm not sure it's a good idea to tie your negative to earth?
There is no earth/ground aside from the zero reference potential ("negative"), in either of my boards. All voltages are ≥ 0V with respect to that. (Consider it the same as the black leads off your ATX power supply.)
On the 19V fan adapter, the host fan negative side must match the potential of the 19V negative side, or the adapter will not work, so they're connected together to make sure. Again, there is no protective ground or anything like that, just the common zero-reference potential. In this one, the plated rings around the mounting holes are not connected to ground.
The DC input on the dual fan controller is just a DC barrel connector, with two contacts only. (The third contact is only a switch connecting to ground whenever a barrel jack is inserted, it is not a separate conductor. There is also no shield or protective earth/ground or anything like that.)
I did leave the zero reference potential planes on both sides of the board close to the mounting holes. We can argue whether I should have pulled the copper, or made a non-connected ring of copper around the mounting hole, but as I specifically intended to use nylon M2.5 standoffs with this one (if the mounting holes are used at all), I left it like this. In fact, I will be experimenting with rigid PVC 20mm electrical tubing used hereabouts (JM 20, cheap!) to see if I can make a tube "enclosure" for these. -
I would have thought only the screw heads would be a problem
Yep, the screw heads.
Ah. You only mentioned standoffs in the previous comment; I got confused and wasn't thinking about the whole assembly (standoff, screw, any washers...). 🙂
You're making me wonder if I've been trashing every computer motherboard I've ever screwed down. 😉 ...but I guess those have better plating on their mounting holes?I also noticed one of your fan headers' ground pin has wider spokes on both sides, but the other on only one side; was that intentional?
Nah, that was just a side effect of me ensuring I have a wide enough ground trace, by manually pulling a trace under the copper ground fill.
Remember, it is not sufficient for the +V side to have a wide enough trace; your return path needs the same.
Of course! I assumed the fatter spokes were intentional; I was wondering if you meant to have two fat spokes from both holes. (Personally, I just use much wider spokes for cases like this, thus avoiding the need to augment them with traces, but a) that might be odd for the spokes-to-nowhere, and b) I don't know if EasyEDA lets you change spoke width per pad. KiCAD does. I've never used EasyEDA.)Also, now that I'm looking more closely at it, I'm not sure it's a good idea to tie your negative to earth?
There is no earth/ground aside from the zero reference potential ("negative"), in either of my boards.
[...]
I did leave the zero reference potential planes on both sides of the board close to the mounting holes. We can argue whether I should have pulled the copper, or made a non-connected ring of copper around the mounting hole, but as I specifically intended to use nylon M2.5 standoffs with this one (if the mounting holes are used at all), I left it like this.
Yes; that. Hmm, I guess you do have soldermask in theory preventing an electrical connection, but... if you're hoping other people might use this board (and I had the impression you are; good for you!), well, if it was my board, I would feel better if there was no copper under where the standoffs and screw heads are going to be to make an unwanted connection. It looks like you could probably keep the copper out at least to where you have silkscreen?
BTW, I notice you aren't following what seems to be a popular rule-of-thumb of having your pad radius be about twice the hole radius. Is that deliberate, or just "what EasyEDA does"? Do you have any feel for whether it makes a difference for soldering? (I have no knowledge here beyond cargo-culting, so I'd be interested in any wisdom you might have.) -
You're making me wonder if I've been trashing every computer motherboard I've ever screwed down. 😉 ...but I guess those have better plating on their mounting holes?
The ones I use have plated rings with strengthening through holes, intended for real grippy screws with bitey screw head underside.Of course! I assumed the fatter spokes were intentional; I was wondering if you meant to have two fat spokes from both holes. (Personally, I just use much wider spokes for cases like this, thus avoiding the need to augment them with traces, but a) that might be odd for the spokes-to-nowhere, and b) I don't know if EasyEDA lets you change spoke width per pad. KiCAD does. I've never used EasyEDA.)
The thing with EasyEDA is it has a nice way of publishing the designs easily at oshwlab.com.Yes; that. Hmm, I guess you do have soldermask in theory preventing an electrical connection, but... if you're hoping other people might use this board (and I had the impression you are; good for you!), well, if it was my board, I would feel better if there was no copper under where the standoffs and screw heads are going to be to make an unwanted connection. It looks like you could probably keep the copper out at least to where you have silkscreen?
Sure, good idea. Modified board top+bottom image attached.BTW, I notice you aren't following what seems to be a popular rule-of-thumb of having your pad radius be about twice the hole radius. Is that deliberate, or just "what EasyEDA does"?
Not deliberate; the pad radius is specified for each footprint, and they do vary. In the latest version (2023-08-10), I did "standardize" them a bit.Do you have any feel for whether it makes a difference for soldering?
I have no wisdom on this; others here do, if only they'd just tell us...
My own experience is that the separation between pads is more important. We do want a nice fillet, and if the annular ring is too small, the fillet will be tiny; but with 1.6mm PCBs, the solder will stick to the plating in the through hole, making good electrical connection anyway.
-
BTW, I notice you aren't following what seems to be a popular rule-of-thumb of having your pad radius be about twice the hole radius. Is that deliberate, or just "what EasyEDA does"?
Not deliberate; the pad radius is specified for each footprint, and they do vary. In the latest version (2023-08-10), I did "standardize" them a bit.Do you have any feel for whether it makes a difference for soldering?
I have no wisdom on this; others here do, if only they'd just tell us...
My own experience is that the separation between pads is more important. We do want a nice fillet, and if the annular ring is too small, the fillet will be tiny; but with 1.6mm PCBs, the solder will stick to the plating in the through hole, making good electrical connection anyway.
Yeah, it's the same in KiCAD, though I've noticed that footprints that ship with KiCAD tend to have rings 185-200% of the hole size. Actually, your point about fillets suggests that a constant ratio between ring size and lead size is probably sensible.
For what it's worth, KiCAD uses 2.03 mm × 1.73 mm pads (1.02 mm hole) for 47053-1000 (fan headers). A lot of KiCAD-provided THT footprints where the pads aren't crowded together use 2:1 (I found 0.8 mm, 0.9 mm, 1.2 m and 1.6 mm holes all using double that for pad size), though for some reason, TO packages tend to be slightly smaller (1.9 mm for 1.1 mm holes, 1.5 mm for 0.8 mm holes, 1.2 mm for 0.7 mm holes...).
Then there are Phoenix connectors that have 3.6 mm × 2 mm pads for 1.4 mm holes... go figure!
Interestingly, for generic KK-254 headers, KiCAD uses 2.2 mm × 1.74 mm pads for 1.2 mm holes. Apparently, 47053-1000 uses smaller leads than standard KK-254?