Laird 28L0138-10R-10 (45 Ω)
Laird 28L0138-70R-10 (123 Ω)
Laird 28C0236-0EW-10 (605 Ω)
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.
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).
Home
Help
Search
Login
Register
