For as useful as computers are in the modern ham shack, they also tend to be a strong source of unwanted radio frequency interference. Common wisdom says applying a few ferrite beads to things like Ethernet cables will help, but does that really work?

It surely appears to, for the most part at least, according to experiments done by [Ham Radio DX]. With a particular interest in lowering the noise floor for operations in the 2-meter band, his test setup consisted of a NanoVNA and a simple chunk of wire standing in for the twisted-pair conductors inside an Ethernet cable. The NanoVNA was set to sweep across the entire HF band and up into the VHF; various styles of ferrite were then added to the conductor and the frequency response observed. Simply clamping a single ferrite on the wire helped a little, with marginal improvement seen by adding one or two more ferrites. A much more dramatic improvement was seen by looping the conductor back through the ferrite for an additional turn, with diminishing returns at higher frequencies as more turns were added. The best performance seemed to come from two ferrites with two turns each, which gave 17 dB of suppression across the tested bandwidth.

The question then becomes: How do the ferrites affect Ethernet performance? [Ham Radio DX] tested that too, and it looks like good news there. Using a 30-meter-long Cat 5 cable and testing file transfer speed with iPerf, he found no measurable effect on throughput no matter what ferrites he added to the cable. In fact, some ferrites actually seemed to boost the file transfer speed slightly.

Ferrite beads for RFI suppression are nothing new, of course, but it’s nice to see a real-world test that tells you both how and where to apply them. The fact that you won’t be borking your connection is nice to know, too. Then again, maybe it’s not your Ethernet that’s causing the problem, in which case maybe you’ll need a little help from a thunderstorm to track down the issue.

DEC’s LAN Bridge 100 was a major milestone in the history of Ethernet which made it a viable option for the ever-growing LANs of yesteryear and today. Its history is also the topic of a recent video by [The Serial Port], in which [Mark] covers the development history of this device. We previously covered the LANBridge 100 Ethernet bridge and what it meant as Ethernet saw itself forced to scale from a shared medium (ether) to a star topology featuring network bridges and switches.

Featured in the video is also an interview with [John Reed], a field service network technician who worked at DEC from 1980 to 1998. He demonstrates what the world was like with early Ethernet, with thicknet coax (10BASE5) requiring a rather enjoyable way to crimp on connectors. Even with the relatively sluggish 10 Mbit of thicknet Ethernet, adding an Ethernet store and forward bridge in between two of these networks required significant amounts of processing power due to the sheer number of packets, but the beefy Motorola 68k CPU was up to the task.

To prevent issues with loops in the network, the spanning tree algorithm was developed and implemented, forming the foundations of the modern-day Ethernet LANs, as demonstrated by the basic LAN Bridge 100 unit that [Mark] fires up and which works fine in a modern-day LAN after its start-up procedure. Even if today’s Ethernet bridges and switches got smarter and more powerful, it all started with that first LAN Bridge.