EMI? Use The Proper Ferrites!

Transmitters and computers often don’t get along.  Cables going to computers, routers, ethernet switches, USB hubs (and anything else with wires) can pick up RF and disrupt operations.  This RF can be coming from your near-by antenna, from leaky coax, or from the transmitter itself.  Usually when this happens the easiest fix is to add ferrite chokes to the cables.  Sometimes it takes several chokes on a cable.  You will end up experimenting.

The ferrites you will find on eBay (etc.) are probably designed for VHF signal suppression. They will work after a fashion on the HF bands, but you will have better results if you use ferrites made from a material optimized for HF frequencies. Cores using “31” material from the “Fair-Rite” company are excellent performers. These come in all shapes and sizes, but the clamp-on core shown below has proven to be quite useful.

Ferrite

https://www.fair-rite.com/product/round-cable-snap-its-431164181/

Fair-Rite Products Corp
Part Number: 0431164181
31 ROUND CABLE CORE ASSEMBLY
Lower & Broadband Frequencies 1-300 MHz (31 material)

You can buy these from Mouser:
http://www.mouser.com/ProductDetail/Fair-Rite/0431164181/?qs=KmHvPbTOE4SbzMQqE/Okzw==

Here are some guidelines for ferrite core use:

  • Put the core as close as possible to the equipment.
  • If possible take two or three turns through the core. Up to a point, the suppression effect is proportional to turns² (turns-squared).
  • If possible, run power and ground together through the core.
  • Before buttoning things back up, secure the heavy core to protect the wires and connectors.  This advice is definitely appropriate for boat radio installations, but perhaps not necessary when in a stable environment.

 

Stabilizing the QDX

As has been mentioned before, the transmit frequency stability of the QRP Labs QDX transceiver isn’t quite good enough for some of the narrow-band modes.  It works fine for WSPR and FT8, but slower modes such as FST4W-300, -900, and -1800 require stability that the QDX’s internal TCXO just can’t provide.  Here is a plot of a FST4W-1800 transmission, showing the frequency drift as the QDX heats up during the long 30-minute transmit cycle:

FSTW4-1800 30m -v1.6.5 -5

In the plot above, the actual transmit frequency is about 10 MHz, but my measurement system has mixed it down to about 36 Hz in order to get higher measurement resolution.  Add 10.1402 MHz to frequency values shown on the plot.  We can see that the transmit frequency initially rises by about  +0.1 Hz, then eventually falls to -0.85 Hz.

FST4W-1800 has a FSK tone spacing of 0.089 Hz and does not track slow frequency drift, and so requires much better transmit stability than this.  And remember, this test was done in the 10 MHz (30-meter) ham band, the drift will be double that at 20 MHz, and half that at 5 MHz.

I spent some time looking at the causes and possible solutions for this drift.  First, I ruled out any software issues by measuring the output of the QDX internal 25 MHz TCXO.  Here’s a plot of the TXCO frequency vs ambient temperature, using a homebrew temperature chamber (the QDX was not transmitting during this test):

TCXO - QDX no case-idle 3

The top chart is frequency vs temperature, the middle one is frequency vs time, and the lower one is chamber temperature over time.  Again, here my measurement system is shifting the 25 MHz TCXO frequency down to 100 Hz in order to obtain higher resolution.  We can see that over a 6C to 60C temperature range the TCXO shifts over a range of 4.3 Hz.

We can also see the intriguing phenomenon of “retrace”, where the oscillator frequency exhibits a kind of thermal hysteresis.  All crystal oscillators exhibit this behavior to some extent, and this does limit the amount of correction that can be performed by measuring the temperature (one of the options contemplated for the QDX).

I attempted to slow the rate of frequency change by increasing the thermal mass of the TCXO (attaching a brass tab to the TCXO package), but the results were disappointing — the TCXO is too solidly attached to the circuit board and the heat transferred though the board from the QDX output transistors just couldn’t be escaped.

Setting aside any idea of a simple fix, I decided to bypass the TCXO entirely and provide an external clock.  There was room (barely) on the rear QDX faceplate for a SMA jack, and room inside for a small circuit board, do I designed and built a little reference clock multiplier:

schematic

This simple circuit uses a PLL chip to multiply an external reference clock (either 5 or 10 MHz) up to the 25 MHz needed by the QDX.   I will dig into more circuit detail in a later post. This circuit is powered by the QDX internal 3.3V supply, and provides a 0/3.3V logic-level output which is connected to the QDX clock buffer input (after removing the TCXO coupling capacitor):

schem-mod

Here’s the little board layout:

PCB

PCB 2

And as installed in the QDX:

RefMult2

I picked up +3.3V and ground from some testpoints on the QDX board, and having no microscopic coax, I used a twisted pair of #30 Kynar-insulated wirewrap-wire to connect the clock signal to the QDX board (two different-color wires would have made more sense, but I was in a hurry).  The twisted pair just managed to squeeze through another testpoint through-hole, and was then soldered to the PCB:

RefMult3

The yellow oval shows where the TCXO coupling cap (C 54) used to be.

Using a Bodnar GPSDO as my 10 MHz reference I ran some tests.  The 25 MHz output from my PLL was reasonably clean, as was the resulting  signal from the QDX.  Here are some plots of the transmitter, in the 20-meter band:

2

This is a 200 KHz span, 100 Hz resolution bandwidth scan, showing a bit of broadband noise and a discrete spur at -100 KHz (there is another near +100 KHz, not visible in this plot). This noise potentially affects the receiver performance, but initial measurements lead me to believe that other QDX noise sources are dominant.  These measurements only show us the transmit signal, and to determine how much of this output noise is due to the PLL will require further testing. In any case, this noise will have no significant impact on the transmit performance.  We can see how the noise falls off dramatically as we approach the carrier frequency — this is the characteristic of PLL noise under the loop-bandwidth frequency.  Here is a close-in plot:

comparison QDX ext ref

This level of noise is definitely acceptable.

And here are plots showing the transmitted FST4W-120 signal, transmitting on 14.09715 MHz:

FST4W-120 a

As expected, the transmit frequency is rock-solid.  And here is the modulation in FST4W-1800 mode:

FST4W-1800 b

On-the-air tests of the modified QDX, transmitting FST4W-120 show essentially perfect performance.

About the external reference:

The reference multiplier input can come from any stable source of 5 or 10 MHz.  I tested using a GPSDO, since I distribute that reference to much of my test equipment, but a stand-alone OCXO, or even stable TCXO will serve the purpose.  Obviously, if you already have a stable 25 MHz clock available (the Bodnar GPSDOs can be configured to provide this) you don’t need a clock multiplier — just a connection to the QDX circuit board.  Be sure to provide appropriate coupling and some type of input transient protection!

The 25 MHz clock not only drives the radio portion of the QDX, it also runs the microcontroller.  Without this clock the QDX will not run, and any interruption will likely cause bad things to happen.  The external clock source is the first thing I connect, and the last thing I disconnect.

 

 

WSPR With the QDX and QUADRA

While testing the newest QDX “Beta 1_06_005″ firmware, I hooked it up to the small/cheap inovato QUADRA  linux box and ran some WSPR on 20 meters.  This is what I got after a few hours with 4 Watts into a dipole (I’m currently in California, a bit north of San Francisco):

WSPR 20 metersI’ve always wanted to visit Ellesmere and South Georgia Islands!

The QUADRA is a nice replacement for the virtually unobtainable Raspberry Pi 3:

quadra

 

A Simple Matter of Software (SMOS)

A SMOS.  That’s what we hardware engineers (and management, too) call it when something needs to be fixed and the hardware is already out the door.  Fortunately, in this case it was indeed a software fix.

I’m talking about the QDX and the difficulty it had generating very small frequency shifts, as first noted by my friend Glenn (N6GN). I described the problem and my measurement techniques in these posts: http://wb6cxc.com/?p=244, and http://wb6cxc.com/?p=275

I became fascinated by this issue, and while adding some pretty useful features to my Time Interval Counter, the QDX gave me a great way to improve my measurement technique.  In the process I re-connected with an old ham friend, and met some new ones who I really respect.

I also got to know the WSJTX mode FST4W, which uses much smaller/slower FSK than FT8 or WSPR.  For example, a single transmission of FST4W-1800 takes a half-hour with a symbol period (Baud) of 11.2 seconds, using a 0.089 Hz tone spacing.  This requires extreme accuracy and stability on the part of the transmitter and receiver.  The FST4W (and WSPR) modes are being used to measure atmospheric Doppler shifts, among other things.  Here’s a description: https://physics.princeton.edu/pulsar/k1jt/FST4_Quick_Start.pdf

Measuring FSK patterns is one thing, but analyzing the actual audio-to-RF frequency generation behavior called for a more deliberate approach.  So, I set up my PC to generate a slow audio-frequency sweep (using the NCH Tone Generator program), and sent that into the QDX USB port.  Actually, first I sent it to my Icom IC-7200 USB port and measured that output to make sure that my audio sweep (and measurement technique) were suitable.  Here’s a 1000 to 1010 Hz sweep, transmitted on 20 meters:

IC7200 20m sweep 1000-1010As before, my counter is digitally shifting the 14 MHz signal down into the audio range and counting that.  Here, we see a smooth and linear sweep with only a little noise.

I then tried the same sweep input with the QDX:

QDX 20m sweep 1000-1010

Here you can see the uneven and quite large steps, roughly 1.25 Hz each.  This would work (barely) with the 1.465 WSPR tone spacing, but was completely unusable with the smaller tone-spacing modes.  Here’s what FST4W-300 looked like (0.56 Hz tone spacing):

FSTW4-300 30m -1

As you can see, one tone is being entirely skipped over, and the spacing on the others is incorrect.  Not surprising given the sweep results.

I posted my measurements to the QRP Labs groups.io discussion (https://groups.io/g/QRPLabs/topic/qdx_fst4w_300_transmits_only/95257422 and elsewhere), as did Glenn and others, and Hans (QRP Labs owner and designer) dug right in to solving the problem.  He quickly homed in on the algorithm that calculated the fractional divider values for the Si5351 clock generator chip used in the QDX, and he generously traded email with me, describing his progress and solution.  It turns out it was a combination of limited floating point resolution and integer size.  Hans also figured out a way to improve the algorithm by separating the carrier frequency calculations from the audio-offset calculations.  The result was spectacular!  Here’s the 10 Hz sweep using the new  Beta 1_06_005 firmware:

QDXv6.1.5 20m sweep 1000-1010 correct

And here is the QDX transmitting FST4W-1800 (0.089 Hz tone spacing):

FSTW4-1800 30m -v1.6.5 -4

This is perfect.  The frequency-setting is now amazingly good.

And it was all just a Simple Matter Of Software!

But, there is still work to do if we want to use the QDX on the slower FST4W modes.  The QDX transmit frequency drifts as the radio heats up during a long transmit cycle.  This doesn’t really affect modes like FT8 or WSPR, but the small drift (about 1 Hz in fifteen minutes on 20 meters) will cause FST4W-300 and higher modes to fail.  Here is the thirty-minute long FST4W-1800 transmit sequence (remember this is a tone-spacing of 0.089 Hz):

FSTW4-1800 30m -v1.6.5 -5

Probably the only reasonable way to get the needed stability is by using an external 25 MHz reference, probably a GPSDO (GPS Disciplined Oscillator).  The QDX can be easily modified to accept an external reference, and I will be trying this fairly soon.

But all in all, this was a gratifying experience, and I salute Hans and QRP Labs for the speedy and spectacular work in solving a problem that most of the QDX users would never have even noticed.  I now have two more QDX’s on order: https://www.qrp-labs.com/qdx.html

 

Measuring FSK With a Mixing Reciprocal Counter

While evaluating the behavior of the QRP Labs QDX transceiver (my post here:  http://wb6cxc.com/?p=244 ), I put together an old-fashioned mixer / filter to let me make more accurate FSK frequency measurements.  I am using my Time Interval Counter, which counts the cycles of a 100 MHz (10 ns) internal timebase, and calculates the frequency of the input signal using simple math:

Frequency = 1 / Period

This works especially well for lower frequencies, where obtaining precise frequency results with a standard cycle-count counter requires extremely long measurement intervals.  The resolution of a reciprocal counter is a function of the timebase, in this case the 10ns timebase provides eight digits of precision with a one-second count interval (10ns / 1s = 1e-8)

Eight digits is good, but when measuring 10.140 MHz WSPR, with its symbol rate of 1.4648 Hz we need to do better.  With three samples per symbol (about the slowest we can sample it), we only have (10ns/ 0.5s), or about 7.5 digits.  This lets us measure a 10.140 MHz signal to about 1/2 Hz resolution.  This will show us the presence of the modulation, but not much more:

Counter direct div2M

Using an external mixer and VFO to shift the 10 MHz signal down to 100 Hz makes a huge difference in measurement resolution.  With our 1/2 second sample rate we still have 7.5 digits of resolution, but since we a re measuring a 100 Hz signal the resolution is now about 0.00005 Hz!

Setup

But I don’t need an external mixer and VFO — all that can be done digitally inside the gate-array I use on my frequency counter:

TIC-1-768x416

 

So I added those to the FPGA logic: Timing Path 1

 

This is the block diagram of the signal path in the counter.  The blue boxes are contained in the gate-array, and the grey boxes are discrete components on the circuit board.  Not shown are the uController, and a few other sections inside the gate-array.

There are four input stages, configurable for 50-Ohm or High-Z input (compatible with a 10X ‘scope probe), AC or DC coupled.  Each stage, the NCO, the 10 MHz TCXO, and a few other sources (not shown) feed a N-way selector that feeds four divider/timestamp blocks.  The switch also allows any of the input ports to feed a 10 MHz reference clock to the internal 100 MHz PLL.  This allows the counter to use an external OCXO or GPS-disciplined oscillator for increased precision.  In addition, the switch selects the mixer inputs.

The NCO is driven by the 100 MHz clock, and is 29-bits wide.  This provides a frequency resolution of 100 MHz / 2e29, or 0.186xxx Hz, and a maximum frequency of 50 MHz.  The 100 MHz clock means there will be a jitter of 10ns in the NCO frequency.

The NCO or an external signal drives the “clock” of a simple flip-flop mixer, and the external signal feeds the “D” input  This acts as a subtractor.  With perfect input signals there will only be a difference output, there will be no sum as you would see with an analog double-balanced mixer (or with a digital XOR gate).  But we don’t have perfect inputs, as these have been sampled and synchronized by the 100 MHz internal counter clock.  There is plenty of jitter on these mixer inputs, and the output can look like this:

TEK0002 TEK0003This isn’t a mixer difference frequency, it’s the result of jitter on (relatively) close frequencies.  Here the input is 10.14018 MHz and the NCO is running at 10.1387 MHz, giving a 1.483 KHz difference frequency.  But we can’t count that mess!

So I added a simple digital filter after the mixer.  This is a simple 8-bit up/down counter that limits at 0 and 255.  It’s essentially an integrator, counting up when the input is a “1″ and counting down when the input is “0″.  The output goes high when the count hits 255, and stays high until the count hits 0.  This results in a low-pass filter with a cutoff frequency of (100 MHz / 255) / 2, or 196 KHz.  Here’s that same noisy mixer output after it passes through the filter:

TEK0001

This cleaned-up signal is then fed to one of the divider/timestamp stages and the timestamps are read by the uController, converted to frequency,  and then sent over the counter serial port for logging or further processing.  This serial port can only handle report rates of about 50 per second, so the divider has to be set appropriately.  With a 1KHz mixer output the divider is set to 5 for a 50 Hz sample rate (or set to 100 for a 10 Hz rate.)

Here is a 10.140 MHz WSPR measurement, with the NCO set for a difference frequency of about 100 Hz.  The divider is set to 5, giving a sample rate of about 20 Hz:

wspr 2And here are some of the actual frequency measurements:

flist 2

Note that only about seven digits are actually meaningful, but that’s still quite useful.

And unless I decide to do more processing with the local uController, because of the slow serial port update rate this mixer down-conversion method is only useful for fairly low-speed FSK measurements.  Of course this is also useful when making other low-bandwidth measurements, such as clock drift.

And there’s still room left inside the FPGA!  What’s next???

 

DX with the QDX

DXThis morning I was chatting on 40 meters with a local JS8 operator , about 50 miles distant, and was monitoring PSKreporter to see where the little 3W signal from the QDX was showing up.

How about Australia!  I don’t know if this is technically “gray line” propagation, but I am impressed!

 

QDX Sensitivity Test

I still haven’t done a full evaluation of the QRP Labs QDX transceiver, but I did run a quick check of the receiver performance, comparing it to the Icom IC-7200 (which also has a native  USB interface for audio and CAT control):

ComparisonHere you see two instances of WSJTX, running FT8 on 20 meters.  My off-center-dipole was connected to a coax TEE, feeding both the QDX and the 7200.  No effort was made to match impedances, but since both radios are getting an identical signal that should be good enough for a comparison.  Obviously the transmitters were not activated during this test.

I let the programs run for fifteen minutes and then compared the logfiles.  The7200 logged 524 decodes, while the QDX logged  530.  The Signal/Noise ratio was generally the same, with the QDX showing one or two dB improvement on the stronger signals.  These small differences may be due to the AGC or the slightly narrower filters on the Icom rig.

This test was done if a fairly quiet location, with no nearby strong signals.

Conclusion:  So far, the QDX receiver is a good performer.

 

Building and Testing the QRP Labs QDX Digital Transceiver

I recently built the QRP Labs QDX transceiver,  which is a remarkable little radio, designed for FSK modes (FT8, JS8, WSPR, etc.)  on the 80-20 meter ham bands.QDX-2This rig has some very clever design inside.  Instead of the standard SSB modulator and demodulator, this uses a USB interface for audio and CAT rig control (emulating a Kenwood TS-440), and measures the audio input tone, using that measured audio frequency and the set “carrier” frequency to program the internal Si5351 clock chip.  This way it directly generates the transmit frequency — no sideband modulator / filter, no linear amplifier, just the synthesizer and an efficient Class-D 5W power amplifier.

On receive, the radio uses a “Tayloe” mixer, using the Si5351 to generate the necessary quadrature clocks.  The I and Q mixer outputs are digitized and processed in a software SSB demodulator.  This digital audio is sent out the USB interface, to a program such as WSJTX.

There’s much worth studying in this design and Hans Summers (the designer) has provided some excellent documentation:

https://www.qrp-labs.com/qdx.html

It took me about three hours to build this radio.  The kit comes with all the surface-mount components already loaded, so I only had to solder a handful of capacitors and wind some toroids.

QDX-1

There has been some discussion about the four power transistors — they do run a bit warm and people have burned them out trying for higher power (or due to bad SWR).  I ran the transmitter into a dummy load for about two minutes and measured the transistor temperatures.  This had stabilized at about 50 degrees C:

QDX 2 minutes TX

 

The signal transmitted by this radio is clean, with harmonics well under the FCC requirements (those close-in spurs may not actually be there.  The spectrum analyzer I was using has some spurious responses of its own):20m 1

After this I gave the radio a spin on 20 meters, using WSJTX running on a small, inexpensive linux box, the Inovato “QUADRA”.  This little computer is comparable to the Raspberry Pi-3, and only costs $30 (power supply and HDMI cable included).  I installed JS8CALL, WSJTX, and Direwolf using the command-line “sudo apt-get install [program name]“, and everything went without a hitch.  Running FT8 for a few minutes resulted in this:

QUADRA-WSJTX-QDX

FT8-20m

A friend had noted that the QDX wasn’t perfectly generating some of the smaller frequency shifts used in some FSK modes.  Hans has acknowledged the problem and is working on a firmware update, but I decided to look into this.  First I used my “Signalhound USB-SA44B” spectrum analyzer, in the modulation analysis mode.  FT8 looked good:

QDX FT8 mod 1

Note the frequency dither, as the QDX can’t decide on which frequency to send.  This should have absolutely no impact on performance.  8-FSK FT8 uses a tone-spacing of 6.25 Hz.

WSPR was next, and there are issues here.  The 4-FSK WSPR tone spacing is a narrower 1.456 Hz, and the QDX has difficulty generating these evenly-spaced tones.  Here is the analyzer modulation display for 30 meter WSPR:

4FSK Measurement

Notice how the tone frequency steps aren’t even.  Tone 1 should be halfway between tone 0 and tone 2 (and it isn’t).  I wasn’t able to measure exact tone frequencies with the modulation analyzer mode, so I put together a different test setup:

Setup

 

This technique mixes the output of the transmitter with a fixed-frequency signal generator, and the resulting difference frequency can be measured by a frequency counter.  I used a Time Interval Counter of my own design that does “reciprocal” counting where the period of the input signal is measured with 10ns resolution, resulting in fast and accurate measurement, especially for low frequency inputs.  These measurements are sent to a PC where they can be plotted and analyzed.

Modulation Measurement Setup

I had all the pieces lying around except for my low-pass filter, for which I put a simple R-C netwotk (470 Ohms series, 0.1uF shunt) and some SMA connectors on a bit of circuit board.  That Altoids tin contains a simple Si5351 clock generator, a tiny controller, and a not-particularly-stable crystal oscillator.

So here are some measurement results:

Meas Screen

This was done with the mixing generator set about 40 Hz lower than the QDX WSPR transmission.  The counter is pre-dividing the 40Hz difference frequency by four, resulting in a measurement rate of about 10Hz.  This gives about 14 or 15 samples per WSPR symbol.  Here we can see the same problem with the QDX frequency setting — this time it’s Tone 2 that is shifted.  The specifics of the shift or frequency error depends on the actual audio frequency coming in to the QDX (sent my WSJTX).  Here is the modulation with the WSPR transmit offset at 1404Hz (I believe that slow frequency shift is the QDX as it warms up, but I should test that using a better frequency reference):

Counter-QDX-1404

 

Note that the step error is at the low-frequency end.  Incrementing the audio frequencies by 1 Hz gives us this with the error at the upper frequency end:

Counter-QDX-1405

I saw the same error-vs-audio-frequency behavior as when using the spectrum analyzer modulation test.  As another check, I used my drift-buoy controller/synthesizer as a WSPR source (here, generating random WSPR -4FSK tones, and the measurements put into a spreadsheet in order to zero-reference the frequencies):

Counter-BuoyThe tone frequencies are correct.

The QDX  displays this WSPR frequency issue on both 30 and 20 meters,  and I assume on the other bands as well.  I have used the QDX to successfully transmit WSPR, so this amount of error isn’t necessarily critical, but I look forward to enhanced performance in the near future.

For what it’s worth, the Time Interval Counter (TIC) I am using (and designed) is able to directly measure the WSPR modulation at the 10.140… MHz carrier frequency, without using the fancy mixing / down-conversion arrangement:

Counter direct div2M

Here the TIC has pre-divided the 10.xxx MHz input frequency by 2,000,000 which gives us about five measurements per second, about the slowest rate that will reasonably measure 1.456 Hz symbol rate of WSPR.  With the 10 ns resolution of the TIC, this  results in frequency measurements with about 1/2 Hz resolution.  This is good enough to show the modulation, but not good enough to accurately measure it.

The down-conversion method, by directly mixing the 10.xxx MHz signal down to about 100Hz, provides a single-cycle frequency resolution of about 0.0001 Hz.  Since I am measuring four cycles, that gives 0.000025 Hz resolution, certainly enough to accurately measure WSPR deviation!

 

 

Version 2 Battery Charger and Boost Regulator

PCB-V2

After blowing up the transmitter power amplifier (1W) one too many times during test, I decided that it would be useful to put a current-limit circuit on my Charge/Boost board.  This board takes the power from two 1W solar panels, and uses that to charge the Li-ion battery in a controlled manner.  The battery powers the Drift Buoy and, through a switching boost converter provides 13V to the transmitter amplifier stage.

The Class-E transmitter amplifier is sensitive  to loading, and a badly-matched load can cause excessive power dissipation or over-voltage in the transistors.  In the process of trying to determine the safe limits for the amplifier I’ve managed to smoke a few transistors.

So the new regulator design now includes foldback current-limiting.  I’ve added more test points and several configuration options to this board (not all parts will be stuffed at the same time), allowing for easy experimentation.  The previous board had two layers, but this one uses four.  The additional cost is minimal and this allows for a much nicer layout.

The current-limit won’t protect the Class E amplifier under all circumstances, because the amplifier efficiency is due to the careful phasing of transistor voltage and current.  Different loads (resistive and reactive) will cause both amplitude and phase shifts of the voltage and current at the transistor so even with current-limiting there can be excessive transistor dissipation.  Current limiting will help but I also have a big bag of transistors.  And they’re cheap: about  17 cents each.

I should have test results in a couple of weeks.