ka7oei

I noticed the DXE devices when they first appeared - and have wondered about them. I did notice that they didn't support POE (hence the claim of galvanic isolation) which means that they would be of little help when it comes to quieting the oft-noisy IP cameras that are becoming increasingly common, nor would they help in preventing the conduction and radiation of power supply noise from a POE-powered wireless link radios (e.g. for Internet or "Mesh" operation) - or from the power inserters/Ethernet switches that power these devices, which are often bad or worse than the device being powered in terms of RFI.

This makes me suspect that the DXE devices are simply back-to-back Ethernet transformers - with some care taken in the design to allow operation at Gig-E speeds.

For quieting Ethernet connections I have, for some time, just used the "flat" Ethernet cable (often called "Cat-6" or "Cat-7", regardless of whether they really are...) wrapped around large-ish ferrite toroids. It would seem that one can wrap this "flat" cable rather tightly without upsetting its geometry as it will still work fine at Gig-E speeds when "spliced" inline with a Gig-E circuit, provided that one uses a Gig-E rated double-female RJ-45 connector.

In testing, I've verified the following in a fixture that allowed the insertion of an Ethernet cable/device and inputted a signal on one side with a spectrum analyzer on the other side, terminating in 50 ohms:

Using 10-12 turns on the following cores (approx. 33mm O.D., 23mm I.D., except where noted):

- Mix 77: >=20dB across AM BCB and onto 160 meters (Fair Rite 5977003801)
- Mix 31: >=20dB from 160 meters through 30 meters (Larger core - Fair Rite 2631803802 - I haven't found a convenient source for the 33mm O.D. in this mix)
- Mix 43: >=20dB from 40 meters through 10 meters (Fair Rite 5943002701)

For a particularly troublesome situation, three cores with 10-12 turns each - two Mix 43 and one Mix 31(or Mix 77, which works almost as well at 40 meters ) in series, but each separated by about 1.5 inches (3-4cm) to prevent cross-coupling seemed to work well from 160-10 meters with well over 30dB isolation (>50dB measured at some frequencies) and about 20dB to 6 meters. I've used a similar scheme with a Mix 77 core to keep my 630 meter and 2200 meter transmissions from getting into devices.

Because these are simply common-mode chokes, they have no effect on (properly made) signals on the Ethernet cables themselves - and can be used to pass DC (as in POE).

For higher frequencies (VHF, UHF) it gets increasingly difficult to effectively quash radiation on cable, but more common split ferrites designed for the frequency range, placed as close to the offending device(s) as possible, are the best bet.

73,
Clint
KA7OEI

At the Northern Utah WebSDR, we have 14 "receivers" spread across three 8-channel Kiwis, leaving the first two (full-bandwidth waterfall) channels free for users. This gives us six channels with full waterfalls and four more with the "audio only" waterfalls.

Using the callsign "ka7oei-1" with the AI6VN "wsprdaemon" scripting, we have active 24/7 WSPR sessions on 2200, 630, 160, 80 (2 sessions), 60 (2 sessions), 40, 30, 20, 17, 15, 12 and 10 meters. At some point I'm reconsidering running only one session on 80 meters (dropping the deprecated frequency) and dropping at least one of the 60 meter channels. The processing for these "receivers" is done by an on-site machine (one of the on-site WebSDR servers - #3, actually) which is a box running Ubuntu. FWIW, it takes about 15-20 seconds for WSPRD running on this machine (quad core, 3 gig) to crunch and post the results from all receivers.

We were running WSPR on the Kiwis themselves for quite a while (fewer bands) but found the performance of the outboard processing to be better (many spots were being missed on the "busy" bands because of too little time available between cycles for the Kiwi to complete) and it negatively impacted the experience of the users - particularly if we tried to run more than 2 WSPR channels or so - causing the waterfall to slow considerably and make the Web-based UI seem "sluggish".

Bringing the "naked" GPIO pins from out of the box scares the crap out of me: I would, at least, put series 10k-100k resistors on those leads - both to suppress RF that might be conducted out or in from/to the BBG (which would easily quashed by a 1nF-100nF cap to ground on the "outside" side of the resistor) as well as to give the protection diodes on the BBG's GPIO a fighting chance to do their job should some sort of excess voltage find its way coming down the line by limiting the current.

If some sort of serial/parallel data was to be carried (that is, something that would be impeded by R/C filtering) then I would, at least, put some sort of sacrificial buffer circuit in between the bare GPIO and the outside world.

73,
Clint
KA7OEI