Locking the Icom IC-910H to an external 10 MHz (GPS) reference

In late 2009 my friend Bryan, W7CBM, came to me with a project that he had in mind:  "Can we lock my Icom IC-910H to my 'Z-box'?" - in other words, could the 10 MHz output from his Z-3801 GPS Disciplined Oscillator - known to be accurate to better than one part in 100 million - be used to lock his tri-band (2 meters, 70cm and 23cm) all-mode radio to frequency?

Figure 1:
The front panel of the modified Icom IC-910H.
Click on the image for a larger version.

During the initial discussion he'd brought with him an article where Rex, VK7MO, had done a similar thing (see the article on the VK3HZ site from the web archive - link) using an external box to provide a precise version of the radio's 30.2 MHz reference - but he wanted it to be contained entirely within the radio.  

In looking at the requirements and designing the circuit in my head, I decided that we could make it simpler, smaller and easier to use - and with these ideas in mind, I wrote down the specifications for a 30.2 MHz fundamental-mode crystal and he sent an order off to International Crystal.

About 2 months later - in early 2010 - we got back together in my ham shack, crystal in hand, and it was then that I decided that I'd better get around to designing the circuit, so I scribbled the vestiges of a schematic onto a piece of paper and built several circuits that would fit into the aluminum box that Bryan had milled out. At the end of about 3 hours we had a circuit that would faithfully lock the 30.2 MHz crystal oscillator to a 10 MHz external source.  This circuit was fairly small and consisting of two boards:  The amplifier/counter/PLL section wired on prototype board while the VCXO itself was constructed "dead bug" on to a piece of copper-clad PC board material as seen in Figure 3.

"Patience is a virtue - but this is ridiculous!"

And that was where it stopped.  In a case of "out of sight, out of mind" or "other fish to fry" - or any number of other excuses - the partly-completed lock unit stayed on a shelf in Bryan's ham shack for a decade, in plain sight.  When I'd go over to his shack, I'd see it as a reminder of a project yet to be completed, but it had become a fixture and was often overlooked.

Until recently.

As it happened, we both had more time available with the onset of winter and we carved out Wednesday evenings to get together to work on various projects and this, being the most senior and nearest completion, came to the top of the pile.  Over the course of a couple evenings we worked on the it, having to pause occasionally to get a part, modify some aspect the circuit's implementation, do some physical machine work, or because we ran out of time - but it is now complete!

How it works:

The schematic diagram is depicted in Figure 2, below.

Figure 2:
The schematic of the lock unit for the IC-910H.  This schematic is a reverse-engineered  version of the (now lost) originals and is likely to be mostly correct.
Click on the image for a larger version.

The VCXO:

The heart of the unit is Y201, a 30.2 MHz fundamental mode crystal in a Colpitts oscillator.  Using D201, a varactor diode (approx. 5-20pF) its frequency is made variable, the center of the electronic tuning range being adjusted by trimmer capacitor C201.  The output of the oscillator is buffered by emitter-follower Q202 to isolate the oscillator from the load.

The 30.2 MHz output goes two places:  To Q103, the 30.2 MHz amplifier, and also to a low-pass filter consisting of C208, L201 and C209 which is then output to the IC-901H's synthesizer.

The 10 MHz chain:

Figure 3:
The lock unit under test prior to installation in the case.
Unfortunately, this is the only picture that I got
of the oscillator portion.  The small PCB is the RF sense
circuit, built using SMD components by Bryan.
Click on the image for a larger version.

The 10 MHz input - which can come from a GPS Disciplined Oscillator (GPSDO), a 10 MHz oven-controlled oscillator (OCXO) or a Rubidium source - is input to and amplified by Q101 to a logic level and buffered by U1a, one section of a 74HC86 quad XOR gate.  

The output of U1a is also applied to a 74HC40103 which is wired as a divide-by-50 counter to yield a 200 kHz output - and this is applied to U2a, a 74HC7474 divide-by-two counter to yield a 100 kHz square wave.

The RF sense circuit:

A sample of the 10 MHz signal from U1a is also applied to the input of Q301, which amplifies it:  This RF gets rectified to DC by D301 and D302 and its presence turns on Q301 which pulls R303 to ground and turns off Q301 which is connected to U301 - a 5 volt regulator that is connected to the +5 volt lead of the original TCXO in the IC-910H:  In this way, the internal oscillator in the IC-910H is enabled when there is no 10 MHz signal, but disabled when it is connected.

Also connected to the emitter of Q301 is PNP power switch Q203 which, when R208 is pulled to ground when Q301 turns off, applies power to U201 - a 9 volt regulator - to power up the 30.2 MHz oscillator when the external 10 MHz source is applied, preventing both oscillators from being turned on at the same time.

The Harmonic mixer: 

A sample of the 30.2 MHz signal applied to Q103 is amplified and applied to U1b, another XOR gate buffer, which is then applied, along with the 10 MHz from U1a, into U1d - yet another XOR gate.  This gate acts as a harmonic mixer:  By virtue of the multiplying action of the XOR gate, the 3rd harmonic of the 10 MHz input mixes with the 30.2 MHz input and at the output of this gate is a small amount of the difference frequency - 200 kHz - which easily is filtered by L101 and C103 and amplified by Q102.

Figure 4:
The unit in place - final test.  SMA connectors are used for
10 MHz input and 30.2 MHz output and
feedthrough capacitors are used for the 13.8 volt DC
input and the switched 5 volts for the TCXO.
Click on the image for a larger version.

The use of a harmonic mixer is a very old technique and it has an advantage of simplicity over a more "conventional" digital divider network - albeit more "analog".

A more "conventional" way of doing this might be to divide both the 30.2 MHz and 10 MHz signals down to a common sub-multiple - say, 200 kHz - but to do so would require both a divide-by-50 (to take the 10 MHz down to 200 kHz) and a divide-by-151 (to take the 30.2 MHz down to 200 kHz).  This method works, but adds the a bit of hardware (an additional divider) and, more importantly, these divider steps and subsequent comparisons reduce the PLL loop gain.

By contrast, directly using the 3rd harmonic of the 10 MHz reference to mix with the 30.2 MHz, the 200 kHz difference (ultimately 100 kHz - see below) may be used directly - and loop gain preserved, potentially improving PLL performance and simplifying the design.

The comparison with the reference frequency:

The 200 kHz "difference" signal from the harmonic mixer, filter and amplifier is applied to the divide-by-to circuit U2d to yield to yield a 100 kHz square wave.  The 100 kHz square wave from the divided-down 10 MHz reference signal and that from the 100 kHz "difference" signal are applied to U1c, an XOR gate, which is used as a phase detector.  As the phases of the 100 kHz from the reference signal and that of the difference signal "slide" past each other, the voltage - smoothed by R107 and C107 - will vary from 0 to 5 volts.  If, as an example, C201 in the 30.2 MHz crystal oscillator is adjusted so that 2.5 volts applied to the "VCXO Tune" line, this will cause the crystal oscillator to lock to the reference when the two signals are 90 degrees apart, being steered back onto frequency if they start to drift apart.  

I chose to use an XOR gate as a phase detector over a conventional phase/frequency detector because other than the desired DC component, the lowest-frequency component from its output cannot be lower than the comparison frequency - 100 kHz, in this case, with the vast majority of the energy being 200 kHz and harmonics.  In comparison, many of the flip-flop phase/frequency detectors tend to output "occasional" pulses at very low frequency when at/near lock, which are nearly impossible to filter out.  There is a minor penalty, though:  An XOR gate phase detector requires use of 50% duty cycle square waves to work most efficiently, so each of its inputs is divided-by-two by a single 74HC74 dual flip-flop.

Figure 5:
Power connection to the original TCXO - L511 was removed.
Click on the image for a larger version.

Interfacing to the IC-910:

Switching the internal oscillator:

Bryan's IC-910 has the standard TCXO - X512 (the "CR-452") rather than the "High Stability" option (the "CR-293").  Either unit operates at 30.2 MHz, but there is a difference:  The standard TCXO operates from 5 volts while the high stability unit operates directly from the 13.8 volt supply.  Because the internal oscillator must be disabled when another source is applied, one will need to do one of two things, depending on how the radio is configured:

• Because this radio had the standard TCXO (CR-452 a.k.a. X512), inductor L511 (on the IC-910H's PLL board) was removed to make the power externally switchable and L510 and C501 (the "L510" on Figure 2, above) was connected to power X512.  It is this voltage that is switched by Q303 and regulated by U301 to provide switchable 5 volts.

• If the "High Stability" option ("CR-293") had been present (as described in the VK7MO case) we would have interrupted the 13.8 volt supply at C511/C512 (on the IC-910H PLL board) and switched it using Q303 directly rather than regulated to 5 volts by U301.  Comment:  It is unknown how much current the high stability oscillator consumes so a slight modification of the Q302 circuit might be required to do this.
  

Another difference between the way the two oscillators are interfaced appears to have something to do with the output level.  The standard TCXO outputs an RF signal of about 1.2 volts peak-to-peak while it can be seen from the IC-910H service manual that R515 is in series with the output of the high stability oscillator - presumably to reduce its level.

Injecting the locked 30.2 MHz signal:

Figure 6:
Connection of the 30.2 MHz to the PLL board showing
 the added D501 and L502.
Click on the image for a larger version.

Initially we simply connected the external 30.2 MHz in parallel with the output of the original TCXO, hoping that it would go "Hi-Z" when it was powered down - but that did not work:  When the original oscillator was powered down, its output was effectively shorted to ground, dropping the 30.2 MHz signal down to about 100 millivolts, so this signal was applied, instead, to the junction of variable resistor R570 and R572, using R570 to isolate it from the powered-down oscillator.  For this reason, diode D501 was implemented:  This diode - and L502 to provide a DC return - are connected directly at the junction of R570/R572:  When the external reference is activated, diode D501 is biased via R207, turning it on and connected the output of the 30.2 MHz VCXO to the IC-910H's PLL circuit.

If the external reference is not activated, Q203 - the VCXO power switch - is off and no voltage is applied to diode D501 via R207 and it remains "off", effectively isolating the original oscillator from the powered-down VCXO:  By placing the diode at the end of the coax, farthest from the external reference, there is minimal effect on the signal by that coax to the IC-910H's internal oscillator when the external reference is not being used.

Mechanical installation within the IC-910H:

Figure 7:
The back panel of the modified IC-910H.  The added BNC
connector is in the lower-left corner - the location of the
original ground screw, now relocated to the opposite corner.
Click on the image for a larger version.

Bryan had machined the box out of a chunk of aluminum back in 2010, sizing it to just fit (in all three dimensions) on the lid of the PLL unit.  As originally equipped, there are two brackets screwed down to the lid - apparently for the mounting of an optional voice synthesizer and DSP board - but these brackets were removed to make room.  Two SMA connectors were then mounted to the new box - one for the 10 MHz input and the other for the 30.2 MHz output, into the PLL board.  A pair of 1000pF feedthrough capacitors provide passage for the DC power into the box and the switched 5 volt output to the original TCXO on the PLL board.

Not shown (because I forgot to take the photo) is the connection to the switched 13.8 volt supply:  This was connected to the same point on the PLL board as depicted in the VK7MO document mentioned above - except, of course, that the trace did not need to be cut as would have been necessary to switch the power if the high-stability oscillator had been fitted.

The hole on the rear panel for the ground post was drilled out to permit mounting of a single-hole BNC connector with an already-fitted cable with attached SMA connector as can be seen in Figure 4.  This location for the BNC connector was slightly problematic as it somewhat blocked the screw to hold down the cover, but maneuvering of the connector, the use of tweezers and a small-diameter screwdriver permitted its installation.  In the opposite corner (the far-right in Figure 7) a new hole was drilled and tapped for the grounding post.

Spectral purity:

There was a small of concern that the spectral purity of the transceiver with the new reference oscillator would be worse than the original as I'd made no attempt to construct a very low noise oscillator (e.g. a lightly-loaded Butler or similar) so I compared the spectrum with both the internal oscillator and the "new", externally-locked oscillator on the various bands  - particularly on 23cm.

Figure 8:
Transmitter spectrum +/-500 kHz of a CW
carrier on 23cm as seen on an HP-8562A.
Click on the image for a larger version.

On 2 meters and 70cm, very weak (-70dBc) spurs at +/- 200 kHz - the main component of the output of the phase detector - were noted, barely above the broadband noise floor of the transmitter itself - but these were pretty much absent on 23cm as can be seen in Figure 8.  If these had been of concern, it would have been easy to further-improve the loop filter - which is currently a very simple R/C design as evidenced by Figure 2.  The fact that the plot in Figure 8 was made with the analyzer's resolution bandwidth set to 300 Hz should be an indication as to how low these 200 kHz components really are!

Another possible concern was closer-in phase noise:  Would various noise sources of the new circuits (VCXO phase noise, counter jitter, 1/F noise from regulators, loop noise, etc.) cause notable degradation?

Figure 9 gives a clue:  For this test, trace "A" is the original TCXO and trace "B" (the slightly fainter one corresponding with the peak on the right) was produced using the new, externally-locked reference.  As can be seen, the "close-in" phase noise performance of this radio isn't super great, anyway, but the two "noise humps" on either side of the carrier appear to be identical.

This trace also shows a slight difference in frequency, with the original TCXO (the peak on the left) being slightly low in frequency compared to the GPS-referenced, externally locked version - both showing identical amounts of phase noise indicating that the IC-910H is not degraded by this addition.

Figure 9:
A comparison of the close-in phase noise
using the original TCXO (left peak) and the
new, externally locked oscillator (right peak).
Click on the image for a larger version.

Conclusion:

Even thought it has been a long time in the making, this project is complete - and working as well as we hoped that it would.  I'm gratified that a mere decade ago, the circuit that I scribbled onto a piece of paper - and then built one evening works just as it was expected, with no significant modification!

* * *

 P.S.  Alas, if you wanted to order a crystal, yourself, International Crystal Mfg. is no more, but custom crystals are still available via Quartslab - link, and Krystaly - link - to name but two places.

NOTE:  "Quartslab" stopped doing business in 2021 and "Klove" appears to have acquired the business - link.

(You would have to check with your chosen manufacturer to see if they will make a 30.2 MHz fundamental crystal, though - either that or modify the oscillator to use a 3rd overtone crystal.)

Comment:  Since this article was originally published, devices like the Leo Bodnar GPS reference link have become available that can produce the 30.2 MHz reference required by this radio directly.  This device uses GPS-based timing to set an oscillator to the desired frequency that is programmable - typically with accuracy in the range of 10E-10 or so:  In other words, it can directly synthesize the 30.2 MHz frequency needed by the IC-910H.

If you wish to generate a 30.2 MHz from a stable 10 MHz source that you already have, the Bodnar device really won't help you.

* * *

This page stolen from ka7oei.blogspot.com.

[End]

 

Intruder at the top of the 20 meter amateur band?

It wasn't my intent to have this next post be about locating a source of a transmitter - but the temptation proved irresistible.

Over the past several days I'd been working on an addition to the Northern Utah WebSDR: A temperature-based frequency control of the local oscillators on some of the receive chains.  The receivers in question are based on the Si570 synthesizer and are prone to temperature-based frequency drift, and since they have internal reference oscillators, there is no way to externally lock them.

For this temperature-based stabilization to work, I have correlated the room temperature with the actual frequency, so I have been frequenting the bands/receivers with the aforementioned issues and making measurements - but I digress:  It was during this activity that I noticed this massive signal at the top of the 20 meter band, occasionally firing up and clobbering ongoing conversations by U.S. amateurs.

Figure 1:
  Waterfall display of the signal around 14.350 MHz.  Nearly invisible, on and in the left edge of this monster carrier, are ongoing QSOs underneath this strong signal.  No audio recording was made of this signal as its acoustic property was unremarkable:  It sounded pretty much like a DRM (Digital Radio Mondiale) signal - that is, white noise with selective fading.
Click on the image for a larger version.

What is it?

Upon seeing this, I had my suspicions based on articles that I'd read earlier - but I fired up the TDOA (Time Direction of Arrival) system on the KiwiSDR network, using five receivers within the zone of reception scattered across the continental U.S.  Multiple sessions of direction-finding over several days yielded similar results to this map:

Figure 2:
  TDOA results of the above transmission.  Note that long-distance HF direction finding has significant uncertainties, so the above location is likely accurate to only a few 10s of km at best.
Click on the image for a larger version.

This clinched it - it was likely shortwave-based high-frequency trading.

Who are they?

As you may (or may not) know, the so-called "High-Frequency" trading utilizes the very small differences in the prices of trading instruments (stocks, etc.) that occur over time.  The idea has nothing to do with "HF" like shortwave radio, but rather it is the notion that if one can buy or sell a tiny fraction of a second before someone else, differences in prices may be exploited.  One of the aspects of this type of trading is that conventional means of data transport (e.g. fiber optics) is too "slow":  Light travels at about 1/3 the speed of that of free space through a glass fiber and this means that compared to a radio wave on a "direct" path, data transmitted via fiber will arrive later - and this does not include delays due to the equipment in that data network.

What this means is that some entities are experimenting with the use of the HF bands for the most direct, point-to-point means of conveying this information possible - and it seems that some of this information is being transmitted on amateur bands, as the above indicates.

Not surprisingly, these entities are very secretive - but others have done a bit of digging in public, FCC databases.

Here are a few links:

• ARRL News article about "High Frequency Trading".
  
• QRZ thread about "High Frequency" trading.
• "Sniper in Mahwah and Friends" article about High Frequency Trading.
  

As noted in the QRZ thread, the Part 5 experimental license frequency includes the entirety of the 20 meter band, with no requirement for identification.

While many amateurs seem to be surprised about this, I was not:  There are several instances where Part 5 licenses have been issued (I can provide an example via email) - the applicant providing frequency ranges in their application that encroach on any number of other services - and been issued permission to operate there - but there's typically a caveat:  They are not to interfere with existing, licensed services.

It's this last point that's a bit tricky.  Anyone that has operated on HF knows that this is a dicey proposition as it's entirely possible that other users of a particular frequency may not be able to hear - or be heard by - the "offending" station.  As an example, if station "A" and "B" are in QSO - but the offending station can only hear - or be heard by - station "A", it cannot "know" to avoid transmitting while station "B" is transmitting.  It would seem that those who make the rules have overlooked this particular of aspect of HF propagation when it comes to utilizing HF "whitespaces" (e.g. seemingly-unused frequencies.)

"I've been getting QRM'ed - what can I do?"

The complete list frequencies on which these operations are currently unknown - and the fact that they are not assigned specific channels may make such information impossible to know other than by direct observation.  So far, the two frequencies of which I'm aware is that depicted above (around 14.350 MHz) and another around 4.4 MHz - but I have little doubt that there are others:  If you spot similar signals on other frequencies, please comment.

If you note similar interference issues, please contact your amateur radio representative.  In the U.S., you may contact the Volunteer Monitor program at the ARRL (see information here.)  Unfortunately, a quick search did not reveal any specific contact information regarding this program:  If you have such information, please let me know via a comment. 

* * *

Update:

"Luke" noticed this post and tweeted it, emailing me a few links:  Here's a bit of information others have dug up:

• Delmarva Broadband is authorized 14.35-14.99 MHz at 186 kW. Contact is a law office in DC. See https://apps.fcc.gov/els/GetAtt.htm
• … and M-Wave is authorized the 14-14.99 MHz at 16 kW. See https://apps.fcc.gov/els/GetAtt.htm
  

This page stolen from ka7oei.blogspot.com.

[End]

Interesting signals on the 20 meter band: Probable Radio Habana Cuba transmitter malfunction - not jamming

 I happened to be looking at the various receivers at the Northern Utah WebSDR - as I'm wont to do (since I maintain them!) and noticed a few strange-looking signals that hadn't been there before:

Figure 1: 
Obvious QRM (interference) in the 20 meter amateur band.  The signal repeated every 66 kHz or so, allowing its source - below the 20 meter band - to be easily divined. 
Click on the image for a larger version.

The first thing that I did was to check other receivers - both on-site and across the U.S. - to make sure that this wasn't some sort of local problem (overload, image, nearby source) and found it elsewhere - but the selective fading visible in the waterfall display made me quite sure that this was ionospherically propagated and not local.  The errant signal was practically nonexistant in the Eastern U.S. - but with the known skip distance of 20 meters, that might have meant that those receivers were closer to the source, geographically.

When tuned in using AM, there was a very obvious audio tone (approximately 363 Hz) associated with the signal with a vestige of distorted speech underneath and the RF signal itself wasn't stable frequency-wise.  The tell-tale sign that this was more likely a spurious signal of some sort was the fact that this seemed to appear at intervals - roughly 65-70 kHz - so I decided to "follow the money", tuning lower in frequency and finding stronger and stronger instances.

Figure 2:
YouTube clip with audio from the errant spurious signal.  This clip - from one of the instance of spurious signal "nearby" the original - clearly contains Spanish-language audio - a clue as to a possible source!

Adjacent to the 20 meter amateur band is the 22 meter Shortwave Broadcast Band, and there I found the culprit:  A Radio Habana Cuba signal with the same sort of tone on it, symmetrically flanked by the same sidebands.  Using the TDOA feature of the KiwiSDR network clinched the diagnosis:  I tuned to one of the lower-frequency components of this signals, ran the analysis and came up with the results, below:

Figure 3:
  Several TDOA runs on the WebSDR network yielded the same results:  The errant signal appeared to be coming from western Cuba.  The main signal was not actually on 13563 kHz:  It was slightly higher up the band (probably 13700 kHz) - I just picked this particular spurious component because it was one of the strongest ones and "in the clear" - not atop another signal. 
Click on the image for a larger version.

Clearly, the program material matched the location!

While writing this, the spurious signal suddenly disappeared at around 1503 UTC:  Perhaps someone noticed the problem and switched the errant transmitter off (or fixed something) - or maybe whatever it was that had been failing finally gave up the ghost?

Interesting!

Update:

The same problem was noted again on 18 November (during the 1500 UTC hour) with spurious signals appearing on the 22 and 19 meter shortwave broadcast bands with interference again appearing in the 20 meter amateur band.  Again, the KiwiSDR TDOA network showed the likely source of the signal to be Cuba.

Either the folks at Radio Habana Cuba are unaware of the problem, or don't care enough to fix it/curtail transmissions to avoid causing issues across the HF spectrum!

The most likely source of the interference is the transmitter on 13700 kHz as it is symmetrically flanked with spurious signals above and below, spaced about 68 kHz (variable).  There is clearly something wrong with the 11760 kHz transmitter as well based on its long-term issues of very poor audio quality.

This page stolen from ka7oei.blogspot.com

[End]

A high-current DC (and AC) noise filter for UPS or RV use

A friend of mine (Glen, WA7X) acquired a 16 kVA UPS (for free!) a year or so ago - a commercial system consisting of four hot-swappable 4 kVA modules:  With his current load, he only uses one of the four modules, the rest being available as spares or providing room to grow.  Using this as a battery back-up system for important devices in his house (computers, etc.) it's active all of the time as it is an "online" UPS - that is, the inverter pulls power from the battery bank, but the battery bank is always being charged.

Figure 1:
Whiteboard diagram of the dual AC mains filter for the
UPS - See text for details
Click on the image for a larger version.

AC-side filtering:

When he first installed the UPS, he discovered that being a commercial device, it was only a "Class A - commercial" device under FCC part 15 - and it trashed the 20 meter amateur band and caused interference on a few others.  This, however, was easy to remedy as he'd asked me for advice and built a larger version of UPS noise filters that we'd implemented together in the past:  See the article "Containing RF Noise from a Sine Wave UPS" - link.  

Being capable of many kVA, the filtering for this UPS had to be built from scratch rather than using (expensive!) commercially-available filter modules, but this was easily done using readily-available ferrite toroids and bypass capacitors.

Figure 1 shows the general diagram, crudely sketched on a white board in his shop after our consultation.  The inductors are 12-14 turns of 6 AWG on FT240-31 cores, each half (phase) being an equal number of turns for best common-mode suppression as depicted in Figure 2.  Because the UPS outputs 240 volts, the 50+ amp capability of unbundled 6 AWG wire is sufficient for the envisioned load on this UPS.

Figure 2:
The inside of the dual mains filter, built
into a standard NEMA box.  The capacitors
- mostly obscured - are connected to the
blocks with the ground side bonded to the
case.
Click on the image for a larger version.

The filter uses suitably-rated parallel 0.01uF and 4700pF capacitors:  Those across the AC leads (which could have been as large as 0.1uF or so) help force the RF energy to be common-mode across the bifilar choke while the capacitors to ground on the "outside" (non-UPS) side of the filter shunt the remaining RF - which is already at higher impedance due to the choke - to the common-point ground.  Shown in red on the drawing in Figure 1 are large 43 Mix slip-on beads on the "UPS" side of the filtering to better-suppress the high frequency (VHF) components:  Ideally, one would run both conductors through each bead for net zero flux on the core, but larger diameter devices were not available at the time of construction.

The filter pictured in figures 1 and 2 completely solved the RFI problem:  One has to get within a few inches of the UPS cabinet to hear magnetically-coupled RF energy with a portable shortwave radio.

DC-side filtering:

It wasn't a huge surprise, then, when he added more battery capacity external to the UPS - 120 volts DC - and the racket on 20 meters and other bands reappeared.  Because RF is RF, the filtering method for the DC leads is exactly the same as required for the AC leads:  Common-mode choking, bypass capacitance and single-point grounding techniques. 

Considering that the UPS is capable of up to 16 kVA, the DC filter needed to be able to handle more than 100 amps at the 120 volt (nominal - about 138 volts, actual) input.  Looking about, he found a pre-made set of 6 foot long, 2 AWG, very flexible "inverter cables" at Harbor Freight (cost:  $35) that were conveniently available - easily capable of handling about 100 amps - more than enough because he was not ever expecting to load the UPS to its capacity.

Because of the size of the wire, standard FT-240 (2.4 inch/61mm O.D.) cores aren't appropriate, so Glen obtained some "Monster" size toroids (Mix 31) from KF7P.com:  These cores are about 4" (102mm) in diameter and it was possible to wind 7 bifilar turns of the 2 AWG wire onto them, yielding about 170 uH - more than enough inductance to provide adequate choking on the HF bands.

Because they were on-hand, the same capacitors were used:  0.01uF and 4700pF capacitors in parallel:   With a DC system, much larger-value capacitors (e.g. 0.1-10uF) of appropriate voltage could have also been used if lower-frequency attenuation were required.  Like the AC choke, large slip-on ferrite beads (31 mix in this case) were slipped over each of the 2 AWG wires on the "UPS" side to help suppress the higher-frequency energy.  Because of the current involved, 200 amp screw terminal strips were procured - both to terminate the connections to the wire comprising the inductances, but also provide connections to the "outside" world.

Figure 3:
The completed DC noise filter.  The bifilar-wound choke on the "monster" 31-mix core is wound with 2 AWG welding/inverter cable:  The slip-on ferrites on the "UPS" side of the DC are clearly visible.
Mostly obscured are the bypass capacitors, connected to the screw-type terminals.
Click on the image for a larger version.

There are a few caveats to making a filter like this work:

• The "ground" lead must be as near zero length as possible.  This box was bolted directly to the box containing the AC input/output filter described above  (which, in turn, is bolted to the UPS cabinet) to establish a single point ground where the RFI on the AC in/out leads and the DC leads come together:  Connecting the two boxes with just a few inches of wire caused noticeable degradation in its performance!
  

• The cables connected to the UPS must be considered to be "dirty", carrying a lot of RFI, and must be kept as short as possible.  Additionally, one must keep other wires away from these "noisy" leads to prevent interference from being re-coupled into them!
  

• The external battery bank itself has its own fuse, at the battery bank:  Do not even think of connecting a high-current power source like this without some sort of short-circuit protection!

As with the AC filter, this one appears to be completely effective with no conducted noise being detected on the leads of the external battery connection.

Where might these techniques be applied?

The filters shown above are simply "scaled up" versions of those described previously on this blog (links below) to handle higher voltage and current.  A few instances where these techniques might be useful include:

• Adding higher battery capacity to an existing UPS.  You may own a UPS that will power your gear, but simply has too little battery capacity for the desired run time - and adding external battery capacity safely (e.g. fused, insulated) is one way to do this.  As in this case, adding more capacity caused radiation of RFI which had to be suppressed.
  

• Suppress noise from an existing UPS.  Many modern UPSs are likely to create RFI - and these pages show how that might be mitigated.
  

• Suppress noise from an RV power system.  Many RV (recreational vehicles) have power converters (AC to DC for charging batteries) and inverters (DC to AC for running mains-voltage devices) that are likely to generate RFI.  The techniques described on these pages show how it is practical to prevent the conduction/radiation of RFI on both AC and DC leads.

Thanks to Glen, WA7X, for supplying the pictures:  I just scribbled down diagrams and notes and gave him a few capacitors - he's the one that actually built the thing!

Related links:

Links to other articles about power supply noise reduction found at ka7oei.blogspot.com:

• Containing RF noise from a "pure" sine wave UPS.   Even when it is not operating your sine wave UPS may be producing a lot of HF radio interference!
  

• Completely containing switching power supply RFI - link.  Sometimes it can be difficult to quiet a switching power supply, so it may be necessary to put it in a box with strong filtering on all of the conductors that enter/leave.
  

• Minimizing VHF (and HF) RFI from electronic ballasts and fluorescent tubes - link.  Electronic light ballasts, like many switching power supplies, operate in the LF frequency range so "cleaning them up" at VLF/LF/MF frequencies can be a challenge.
  

• Quieting high current switching power supplies used in the shack - link.  This page describes techniques that can be used to reduce the amount of RF energy produced by switching power supplies that you may be using to power your radios.  Again, higher-inductance chokes may be required at VLF/LF/MF frequencies.
  

• Reducing switching supply racket - link.  This describes techniques that can be used to beef up the filtering for switching supplies in general.
  

• Quieting a 150 Watt Samlex Sine Wave inverter - link.  This talks about using familiar methods - if you've been reading the other links - to suppress RF noise on a Sine Wave inverter.
  

The large, ferrite toroids and beads used on this project were obtained from KF7P.com - link.

* * *

This page stolen from ka7oei.blogspot.com

[End]

Using the jt9 executable to receive FST4W signals

Note: 

Since originally posted, WSJT-X v2.3.0-rc2 was released, adding a feature to the "JT9" executable that simplifies this process (the "-F" parameter) as described below.  Note that most of this post was originally written soon after "rc1" had become available.

* * *

As a heavy user of K1JT's WSPR and operating on the 2200 and 630 meter bands, I have noted with interest the introduction of the "FST4W" mode in the recent (v2.3.0-rc1) wsjt-x release.  Operating using the same detection bandwidth as WSPR (when FST4W is operated in the 120 second mode) it offers a theoretical 1.4dB improvement in detection sensitivity.

Being involved with wsprdaemon (link to that project here ) - an open-source project that automates and optimizes reception of WSPR signals on all bands, particularly if multiple receivers/antennas are used - we have been watching this development with interest, particularly since FST4W has the likelihood of supplanting conventional WSPR operation, especially on the lowest amateur bands (2200, 630 and possibly 160 meters) where minimal of Doppler shift is expected.

Internally, WSJT-X  uses the subordinate wsprd program as the decoding (and encoding) engine.  As a stand-alone program, the wsprd executable code may be invoked with a command line to decode signals contained within a .wav file that was captured during the standard two minute interval - aligned with even UTC minutes - and produce a text file containing the decoded signals.

Why use the executable rather than the entire wsjt-x suite?  The fact is that the use of the wsjt-x suite does not lend itself easily to script-driven, bare-minimum, lightweight implementations where further processing of the decoded data (to remove duplicate decodes from multiple receivers, antennas and to use this same data for further analysis of signal/noise) is desired.

The "jt9" executable:

After a bit of digging about, it was "discovered" that FST4W - being an offshoot of the JT9 protocol - was handled not by the wsprd executable, but the jt9 executable.  Simply executing this program with no arguments will yield a list of command-line arguments which, on the face of it, made it appear that updating the wsprdaemon to include the decoding of FST4W signals would be a relatively simple matter.

Except that it didn't work.

Initial testing with strong, off-air FST4W signals that was known to be decodable (because farther-flung stations were able to decode the very same transmissions) yielded no results when the .wav file was applied to the jt9 program - but automatic execution over many hours yielded the occasional off-air decode.  Confused by this, I sought help on the WSJT-X groups.io forum.  Fortunately, Joe Taylor and several of the developers offered a clue:  The "-f" parameter of the jt9 executable, described minimally as "Receive Frequency Offset".

Apparently, the default center frequency of the jt9 executable - at least when in FST4W mode (and maybe others) is 1500 Hz - a fact implied when one gets the display of command-line arguments.  What is not so clear - and only alluded to in the available documentation - is that the apparent bandwidth of the decoding, at least in the 120 second mode, is on the order of 40 Hz (+/- 20 Hz).  Addendum:  This issue was fixed with the "-F" parameter - see below.

At a quick glance through the source code (file "jt9.f90"), this bandwidth setting appears to be hard-coded into a shared variable (apparently accessible by other programs in the WSJT-X suite) called "ntol" (likely a number referring to the "frequency tolerance" setting in the GUI) that is not available via the jt9 command line - at least, not without modification of the source code.  (The possibility of directly accessing these shared variables exists - but this would be platform-specific, a bit messy and somewhat dangerous!)

Unfortunately, this fixed +/-20Hz bandwidth does not appear to be compatible with the way that the FST4W mode has (already!) found use on 2200 and 630 meters where it is used along-side the WSPR mode in the 200 Hz subbands.

A hell of a kludge:

Update - kludge no longer needed:

As of version 2.3.0-rc2 it appears that a new parameter "-F" was added to allow something other than a +/-20Hz bandwidth (referred to as "tolerance") to be used, likely eliminating the need for multiple decodes, below.  A possible command-line for this would be:

jt9 -W -p 120 -f 1500 -F 200 <wav file to be processed> 

With the center frequency (-f) being the center of the passband (1500 Hz) and the "-F" parameter referred to as"tolerance" (e.g. detection bandwidth) being 200 Hz. 

Initial testing indicates that the -F parameter does what it's supposed to do and the kludge below is now longer required.

This fact implies that in order to use something other than the GUI version of the wsjt-x software, a work-around must be invoked.  The following is a bare-minimum example of how one might do this via the command line:

jt9 -W -p 120 -f 1420 <wav file to be processed> 

jt9 -W -p 120 -f 1460 <wav file to be processed>

jt9 -W -p 120 -f 1500 <wav file to be processed>

jt9 -W -p 120 -f 1540 <wav file to be processed>

jt9 -W -p 120 -f 1580 <wav file to be processed>

(One might include the -H, -L and -d parameters in actual practice.)

In other words, in order to cover the entire 200 Hz WSPR subband, the JT9 executable (v2.3.0-rc1) must be executed - processing the same .wav file - at least five times:  The results of the decoding will, in each case, be found in the file "decoded.txt".  If one wishes to implement an equivalent of the -w parameter of the wsprd executable (e.g. +/- 150 Hz "wideband" mode), you will need even more invocations than above.

The result from the above mess will be five different decoding results, each of which must be saved (e.g. renamed) between subsequent executions to prevent overwriting by the previous instance.  After this, the five results would be concatenated to yield a single file - but there is a catch:  It is likely - particularly if the signal is strong - that the same signal will be decoded more than once.  Apparently, the "+/- 20Hz" limit isn't the result of a "brick-wall" filter:  Signals beyond this frequency range may be decoded, but the reported S/N values will likely be reduced as distance of the received signal from the specified center frequency increases.  In short, this means that the results of the concatenated version of the "decoded" file(s) must be sorted and all but the single, "strongest" decode (e.g. best SNR) for each station must be discarded.

Comment:

It would appear that just five iterations to cover the 200 Hz bandwidth is not enough:  I received correspondence from a reader of this blog that observed that a frequency variation of less than 10 Hz from that defined by the "-f" parameter can affect the S/N reading by about 1 dB.  Make of that what you will!

* * * * * * * * *

If one wishes to integrate the FST4W decodes into the existing WSPR captures for processing, yet another step must be undertaken:  "Fixing" the formatting.  Not surprisingly, the output in the "decoded.txt" is not formatted the same as the results of the decoding from the wsprd executable meaning that one will need to do a few things, after the fact, to "fix" them - particularly if you wish to forward them to wsprnet.org, including:

• Supply the date.  The "decoded.txt" includes the time - but not the date.  Because date of the .wav file may not be the same as the system date (e.g. later processing of the .wav files - or the interval being processed occurred just before the new day) - one must use the actual date of the recording.  The obvious place to obtain this is from the name of the .wav file being processed.
  

• Frequency offset.  The information that one might send to wsprnet.org must include the carrier frequency of the received signal, but the output in the "decoded" file has only the audio frequency:  One must obtain the LO frequency of the receiver being used from "somewhere else" and calculate this on the fly.
  

• Supply missing information.  The "decoded.txt" file does not have all of the same information fields that one might supply when uploading WSPR spots, so this information must be added as necessary.
  

• Arrange the fields in the proper order.  Once the needed information is applied, one will probably want to use "awk" or similar to produce the same order as the wsprd data - assuming this wasn't already done in the process.
  

* * *

There are two outputs from the jt9 executable - one directly from the program itself to the standard console and that output to the file "decoded.txt" - and the latter is the most useful. 

Console output:

0416 -24  0.7 1515 `  KA7OEI DN40 17                                 
<DecodeFinished>   0   1

The fields are:  <time UTC> <SNR in dB> <DT?> <Audio frequency in Hz> <always "`"> <Callsign received> <Grid of received station> <Reported TX power in dBm>

From the "decoded.txt" file:

0416   0  -24   0.7   1515.   0   KA7OEI DN40 17                        FST4

 The fields are:  <time UTC> <unknown - possibly drift in Hz> <SNR in dB> <DT?> <Audio frequency in Hz> <unknown> <Callsign received> <Grid of received station> <Reported TX power in dBm> <Always "FST4">

* * *

There you have it:  The germ of what would be needed if one wishes to supplement the existing WSPR decodes with the newer FST4W mode using just the bare executables.  If one wishes to decode other than the 120 second FST4W mode, things get even more complicated!

Sample audio file:

An audio file containing both FST4W-120 and WSPR transmissions may be found HERE - right-click to download.  This file contains an FST4W-120 transmission by KA7OEI from about 116km distant and (at least) two WSPR transmissions.

* * * 

 

Note:  It appears that the "-F" parameter, above, modifies the default ntol setting as described above.

P.S.:  While it would be pretty trivial tweak the code to allow modification of the ntol variable via command line, this would complicate the ongoing maintenance of the wsprdaemon code.  We can only hope that the current authors see fit to include a means by which the entire wspr subband can be monitored with a single invocation of the jt9 executable.

 

This page stolen from ka7oei.blogspot.com

[End]

Revisiting the "Limited Attenuation High Pass" filter - again.

In several previous posts (See:  "A Limited Attenuation High Pass Filter" and "Revisiting the Limited Attenuation High Pass Filter" I described a "high pass" filter that offered low attenuation at high HF frequencies, but a controlled amount of attenuation at lower frequencies - this, to accommodate a fundamental fact about both HF propagation and direct-sampling Software Defined Radios (SDRs):  The two don't play nice with each other!

Note:

If you are using any direct-sampling Software Defined Radio to receive ALL of the HF spectrum simultaneously  - such as a KiwiSDR, Red Pitaya, RX-888, RX-666, TRX Duo to name but a few - you SHOULD read this page and understand why it is important to apply such filtering to maximize performance across HF.

In a typical receiver/antenna configuration, failure to reduce the lower HF frequencies with respect to the top of the HF spectrum (e.g. 10 meters) will result in comparatively poor performance.

As noted in the previous post(s), the problem is two-fold when it comes to broad-band SDRs that are intended to cover the entire HF spectrum all at once:

• HF noise power and signal level is (generally) inversely proportional to frequency.  At lower frequencies - say, 2-8 MHz - the noise power is far higher than it typically is at around 20-30 MHz.

• A direct-sampling SDR - or any receiver, for that matter - can tolerate only so much RF power on its front end.  Traditionally, this is a mitigated with the use of narrow-band RF band-pass filters, but this can't be done if one intends to be able to cover the amateur radio bands 160 through 10 meters (1.8-30 MHz).

With the aforementioned issues is yet another one:  Because the noise floor at 10 meters when it is "quiet" is so much lower than 80 meters (perhaps 40-50 dB during noisy nighttime conditions, 25 dB or so during quiet daytime conditions) there is an intrinsic disparity between the amount of sensitivity that is need to "hear everything" at the opposite ends of of the HF spectrum - but since a typical direct-sampling SDR is pretty much "flat", we end up with what might seem like a pair of intractible problems:

•  To accommodate the very strong signals and high noise levels at lower HF frequencies, the RF signal gain in front of the A/D converter must be carefully set to prevent overload.

• In order to "hear" the noise floor at 10 meters, the system gain must be set fairly high.

What these two factors, together, imply is that if we have enough gain to comfortably detect the noise floor at 10 meters, our receiver will be badly overloaded during strong-signal conditions on the lower bands.  Conversely, if we scale (e.g. attenuate) the input to accommodate the very large signal excursions, the receiver will simply be unable to detect signals at/near the "quiet" 10 meter noise floor.

Comments:

There will (hopefully) be the day that the upper HF propagation conditions improve greatly with the arrival of solar cycle 25 and at that time, strong signals will appear on the bands >=15 MHz.  When this happens, we will likely be faced with a problem similar to that which we are trying to solve here (e.g. very strong signals overloading the A/D converter).  At this time, the only recourse will likely be a means of using an external device to adjust the gain/attenuation in front of the receiver, probably using the existing I/O lines under receiver control.

Since the original posting of this blog entry I was made aware of an 1977 article on this very topic - you can read it HERE. (The article in question begins on page 3 of the PDF.)

A revised circuit:

Why talk about this issue a THIRD time?  I decided to make one that provided a better 50 ohm match across all frequencies than the previous versions.  This revised circuit may be seen in the figure below:

Figure 1:
Generic pre-emphasis network set for about 50 ohms.
Click on the image for a slightly larger version.

Some readers will recognize the topology of the circuit in Figure 1 as the classic pre-emphasis network found in the signal  path of FM video transmitters.  Whereas those circuits are typically designed for 75 ohms, this one is intended for a 50 ohm system - but careful observers will notice that 47 ohm resistors are used, instead:  For receive-only purposes, I have chosen the components in this article to be standard values at the expense of a slight increase in mismatch - but the VSWR of these circuits, when terminated at 50 ohms - is likely to be no more than about 1.1:1.

This circuit - compared with the previous versions - has the advantage that it presents a consistent source and load impedance across the frequency range, making it a bit more "friendly" in systems that may be impedance sensitive (e.g. following a band-pass filter, long coaxial cable runs, following/preceding conditionally-stable RF amplifiers.)  The obvious trade-off is that as compared to the previous version (which was based on a high-pass filter and some resistive bypassing) this circuit has definite limitations on how sharp and deep the "knee" may be at any given frequency as only a single inductor and capacitor are used.

By tweaking the values of R1, R4, C1 and L1 we can adjust both the amount of low-frequency attenuation and the frequency of the "knee" where the attenuation takes place - but for our purposes, we will be placing the center of that "knee" around 10 MHz to provide both the minimal loss at 30 MHz and adequate attenuation at and below 7 MHz.

Here are a few examples of values of R1, R4, C1 and L1 using standard-value components and approximate attenuation values at various frequencies:

R1 = 68 ohms  R4 = 39 ohms C1 = 390pF  L1 = 1uH DC attenuation:  7.3dB @ 2 MHz: 7.0dB  @4 MHz: 6dB @ 7 MHz: 4.6dB  @10 MHz: 3.4dB @ 14 MHz: 2.3dB  @28 MHz: 0.8dB	R1 = 120 ohms  R4 = 20 ohms C1 = 330pF  L1 = 0.82uH DC attenuation:  10.8dB @ 2 MHz: 9.8dB  @4 MHz: 8.1dB @ 7 MHz: 5.6dB  @10 MHz: 3.9dB @ 14 MHz: 2.5dB  @28 MHz: 0.8dB
R1 = 120 ohms  R4 = 20 ohms C1 = 270pF  L1 = 0.68uH DC attenuation:  10.8dB @ 2 MHz: 10.1dB  @4 MHz: 8.7dB @ 7 MHz: 6.5dB  @10 MHz: 4.8dB @ 14 MHz: 3.3dB  @28 MHz: 1.2dB	R1 = 100 ohms  R4 = 27 ohms C1 = 270pF  L1 = 0.68uH DC attenuation:  9.4dB @ 2 MHz: 8.9dB  @4 MHz: 8dB @ 7 MHz: 6.3dB  @10 MHz: 4.8dB @ 14 MHz: 3.6dB  @28 MHz:1.3dB

Figure 2:
Table showing some possible values for the circuit of Figure 1 and the example attenuation values.

 

In practice, several of these sections will likely need to be cascaded to achieve the desired amount of attenuation at the lower HF frequencies which brings up the question:  Could you not choose components to do this for a single section?  The answer is theoretically, yes - but the fact is that practical inductors - particularly the molded type - are quite lossy, departing from the intended attenuation curve, and achieving the predicted, higher amount of lower-frequency attenuation with a single stage can become problematic - so it's probably better to cascade several of these networks together, instead.

A practical example:

Figure 3:
The exterior of the four channel filter network.
Click on the image for a larger version

A practical example of such a network is one that is to be currently installed in the KFS (Half Moon Bay, CA) KiwiSDR/WSPRDaemon system.  There, four wideband antennas are available to feed the KiwiSDRs on site, so a box was constructed with four, identical pre-emphasis networks, each to feed its own receiver stack.

As is the case at the Northern Utah WebSDR, noise and signals at the lower end of the HF spectrum is often very much stronger than at the high end:  If amplification is added to allow the detection of the noise floor at 10 meters, there is the very high probability that the receiver will badly overload on HF signals from the lower end of the spectrum.

Each "channel" of the device depicted in Figure 3 is identical, consisting of two cascaded sections.  The first section is that from the upper-left quadrant of the table (R1=68 ohms, C1 = 390 pf) and the upper-right quadrant (R1=120 ohms, C1 = 330pF).  Rather than the use of molded chokes, the individual inductors were wound using 30 AWG wire on T25-2 toroids:  17 and 15 turns for the 1 uH and 0.82 uH inductors, respectively.

Figure 4:
The interior of the four-channel network.
The circuit is simple enough to be wired "Manhattan"
style on glass-epoxy PC board material between the
two center pins of the BNC connectors.
Click on the image for a larger version

As can be seen in Figure 4, the construction is very simple, requiring no circuit board at all when using standard, through-hole components.  The circuit was built into a die-cast aluminum box with the BNC connectors holding the piece of PCB material in place.

To secure the components - particularly the small, toroidal inductors - RTV sealant (white) was used to hold components in place and to prevent adjacent wires of C1/R1 and R2/R3 from coming into contact with each other.

This method of construction is very simple and effective, offering good performance into the VHF range when reasonable care is taken.  With the 20mm high dividers between the sections installed as shown, the channel-to-channel isolation exceeded 85dB (the limit of convenient measurement) at 30 MHz.

Figure 5, below, shows the typical response of the sections:

Figure 5:
The response of one of the sections as measured on a DG8SAQ VNA.
Click on the image for a larger version.

Because it can be a bit difficult to read, the values of attenuation and VSWR in the upper-left corner are reproduced below:

Frequency (MHz)	Insertion Loss (db)	VSWR
0.474	21.4	1.09
1.812	19.9	1.09
3.592	16.6	1.08
5.324	13.4	1.08
7.038	10.8	1.08
10.12	7.4	1.07
14.06	4.7	1.07
18.16	3.2	1.07
21.08	2.4	1.07
24.94	1.8	1.09
28.18	1.4	1.10
50.0	0.4	1.19

Figure 6:
Attenuation and VSWR of the network at amateur band frequencies.

 

Practical usage:

 

For large, broadband antennas and small, active E-field whip antennas, the tendency will be for a relatively "flat" frequency response - but with a small E-field whip antenna, the typical high-frequency roll-off can exacerbate the aforementioned low-HF band overload issue, making a filter network such as the above, even more indispensable.  While an attenuation value of about 17dB at 80 meters may seem to be rather extreme, unless your antenna system has severe low-frequency roll-off at the low end, the noise floor on 80 meters - even during a quiet winter day when the band is dead - should be at least several dB above the receiver's noise floor.

 For specifics relating to a wideband direct-sampling SDR like the KiwiSDR or Red Pitaya, refer to the earlier article linked above - "A Limited Attenuation High Pass Filter".

Set-up:

As mentioned above, a direct-sampling receiver like the KiwiSDR does not have enough sensitivity to "hear" the 10 meter quiet band noise floor at a very quiet receive site. In terms of overall system gain adjustment, a few comments are warranted:

• A good test is to see if, on 10 meters when it is "dead", you are hearing your local noise floor.  Note the S-meter with the antenna connected and disconnected - preferably, with the input to the receive system terminated with a 50 ohm load when disconnected.  If you do not see an increase in the S-meter reading and on the waterfall by 3-5 dB, the overall system gain is too low to allow the receiver to see the noise floor at your antenna system.
  

• If you do not see an increase in noise when the receiver is connected to an antenna, a bit of extra gain is recommended.  Given an ideal isotropic antenna at a very quiet receive site, it will probably take about 12 dB of gain to comfortably "see" the antenna's noise floor - assuming no other losses (coax, splitter, etc.)
  

• The preferred location of an amplifier is after the filter described above as it, too, will be protected against the very strong lower-frequency HF signals - even though a device like the above will increase the loss (and noise figure) by about 1.4dB at 10 meters.
  

• In cases where there are splitting losses (e.g. feeding multiple receivers) it may be beneficial to split the gain.  A modest-gain amplifier (10-14dB) might precede the splitters - the modest gain being enough to overcome splitting losses and to maintain system noise figure.
  

• In the case of a low noise level receive site, the splitting losses may put the 10 meter noise floor below the detection threshold of the receiver and, if necessary, another amplifier may be placed just after the filter described above to make up for it.
  

• It's worth noting that if you can detect a 3-5dB increase in noise floor with the antenna connected (versus disconnected) on every band, then even more gain will NOT further-improve system performance:  On the contrary, more gain than necessary will increase the probability of receiver overload - particularly on a direct-sampled SDR that has no AGC in its signal path like the KiwiSDR.  If one has more than 3-5dB of noise floor increase with the antenna connected on 10 meters when it is quiet, it's suggested that several dB of attenuation be added.  The preferred place to add this attenuation is in front of the amplifier to maximize its strong-signal handling - but only if one can still detect the noise floor on the antenna after doing so.  If one has a very high gain amplifier (say 20-25dB) and the gain is excessive, judicious addition of attenuation on both the input and output of the amplifier may be required.
  

• When an amplifier is to be considered for HF use, it should have clearly-defined ratings - one of the most important of these is the output power capability (often "P1dB" which is the output power at 1dB compression) which, for a modestly good amplifier capable of handling strong, off-air signals, should be in excess of +20dBm.  Second to this would be the 3rd order intercept point, which should be stated as being in excess of +30dBm - and the higher the better.  Both of these parameters are indicative of how well an amplifier might deal with multiple, strong signals that may be present at the antenna without adding significant distortion of its own.
  

• If you wish to pick your own frequency and impedance, the following will get you "close enough".  At the point where a single section of this circuit (as depicted in Figure 1) has an attenuation of about 4.1dB, the reactance of the "L1" and "C1" components will be equal to the desired characteristic impedance of the circuit - which will also be the same as "R2" and "R3".  Unfortunately, other parameters (e.g. the amount of attenuation at a specific frequency) are not predicted by this formula, although it's worth noting that both C1 and L1 will disappear at extremes in frequency and the circuit effectively turns into a resistive attenuator.  For example, C1 disappears (goes to infinity ohms) and L1 goes to zero ohms at DC while L1 disappears (equivalent resistance goes to infinity) and and C1 goes to zero at infinity MHz and one can pretend that these particular components no longer exist (e.g. either a short or open as appropriate).
  

Addendum:  Comments about the RX-888 (Mk2)

 

The RX-888 (Mk2) is a USB3-interfaced "signal acquisition device" - or an SDR front-end.  Unlike the aforementioned KiwiSDR, it has no signal processing capability at all - it's (more or less) just an A/D converter connected to a USB3 interface.  As such, it can operate at a sample rate of 130 MHz which means that it can acquire the entire HF+6 meter spectrum.  For various reasons (see the link below) it is usually better to operate an RX-888 at around 65 MHz, making it still-useful for inhaling the entire HF spectrum.

 

The RX-888 (Mk2) includes an attenuator (based on the PE4312) and a programmable-gain amplifier (using the AD8370) and this combination means that the noise figure PRIOR to the A/D converter will be on the order of 12 dB or so when the AD8370 is set for the "optimal" gain of about 20 dB:  See the link about signal dynamics of the RX-888 for a better explanation.  Unfortunately, the limiting factor - even with the AD8370 set for maximum gain - is the intrinsic noise of the A/D converter itself more than the components preceding it in the signal path.

 

In this case, I would make the following recommendation:

• As close to the antenna as practical, place a 10-12 dB gain, low-noise RF amplifier.  This amplifier will be the primary setting for the receive system noise figure and it should have excellent signal-handling properties.
• The "high pass filter" described above would be placed following the first amplifier.
• Following the filter, an additional 10-12 dB gain amplifier.  As the attenuation of the filter is relatively low at the frequencies where it really matters (e.g. >20 MHz) the noise figure of the receive system is preserved for these frequencies.  Placing the second amplifier downstream also reduces the total signal power that this amplifier will "see" from lower HF frequencies.  This amplifier should be chosen to have particularly handling of strong signals.
  

In the case of the RX-888, the PE4312 attenuator is likely not going to be required under any normal circumstances and should be set to "zero" and any attenuation that is needed would be set using the AD8370 amplifier.

Pages related to the RX-888:

• Improving the thermal management of the RX-888 (Mk2) - Link
• Measuring signal dynamics of the RX-888 (Mk2) - Link
  

 

This page stolen from ka7oei.blogspot.com

[End]

 

Comparing the "KiwiSDR" and the "RaspberrySDR" software-defined receivers

Updates:

• The RaspberrySDR schematic and a fork of the source code is now available - see the addendum near the end of this article for comments.
  

• Another variant - the so-called "FlyDog SDR" - has also appeared since this article was written.  Unfortunately, there is still work to do on this version - details at the end of this article. 
  

• KiwiSDR Version 2 now available:  The RaspberrySDR and its clones have largely disappeared, but Version 2 of the KiwiSDR - produced and supported by the creator of the original KiwiSDR - is available as of 2024 - see the kiwisdr.com web site for more details.
  

Any reader who has perused these blog pages will be aware that I have been using the KiwiSDR for some time now (I personally own four five of them and manage several more!) and have been happy with their performance, finding various ways to maximize their usefulness.  I was intrigued when a "similar" device appeared that might prove to be useful - the "RaspberrySDR".

Figure 1:
The exterior of the RaspberrySDR.
The case is well-built and compact, housing both the
SDR board and a Raspberry Pi 3+.
Click on the image for a larger version.

Background:

For those not familiar with the KiwiSDR, it is a Linux-based, stand-alone software-defined radio capable of receiving from (nearly) DC to at least 30 MHz using a variety of modes (SSB, AM, FM, Synchronous AM) and has several "extensions" that allow reception of several digital modes - including CW, RTTY, and WSPR - as well as provide a means of viewing FAX transmissions and SSTV.  It also includes a provision for TDOA (Time Difference of Arrival) determination of transmitter location in conjunction with other similarly-equipped receivers.

This receiver does not have a front panel, but rather it is entirely used via a web interface.  What this means is that it may be used remotely, by several people, simultaneously - each person getting their own, virtual receiver that they may independently tune.

Originally introduced as a Kickstarter project around 2016, the hardware has been augmented with continually-improved open-source software with the lions share of the work having been done by John Seamons.  Using a 14 bit A/D converter clocked at about 66.66 MHz, an FPGA (Field Programmable Gate Array) and a GPS front-end chip, most of the number-crunching is done before the data is handed off to a single-board computer - originally the BeagleBone Green, but now also BeagleBone AI (BBAI):  Both the KiwiSDR receiver board and the BeagleBone Green (BBG) have been sourced by Seeed Studios.

For a variety of reasons, the supply of KiwiSDRs has been a bit fickle - both due to the limited capacity by Seeed in response to demand of these devices and issues which have been impacted the supply of some critical parts.  Another possible issue may be that there is likely to be a bit of "fatigue" on the part of some of the key people related to the KiwiSDR:  Careful readers of blog entries from several years ago can see that a similar thing happened to me on a project on which I had previously worked - coincidentally, also an open-source SDR device.

Figure 2:
Inside the case showing the "RaspberrySDR" board.  The phyiscal layout is quite similar to that of the KiwiSDR.  The small heat sink is affixed atop the LTC2208 A/D converter and the fan is controlled by a simple transistor circuit on the acquisition board.  Unlike the KiwiSDR, only one row of headers (top) is used to connect to the host computer, and unlike the KiwiSDR, power is supplied via the host (Raspberry Pi) processor.   In noting the logo on the board, I can't help but wonder if its intent was that of parody, along the lines of the fair use doctrine?
Click on the image for a larger version.

 

The present day:

Because the KiwiSDR is based on open-source design of its hardware and software - ostensibly to encourage participation in enhancement of all aspects of its design - one may freely copy it within the constraints of the open-source license.  It is not surprising, then, that several derivative versions have recently appeared on the scene, more or less following the "open source" philosophy - a topic that will be discussed later.

Using the base code found on GitHub and the openly-published schematics as a starting point, the "RaspberrySDR" has appeared - using, as you may have surmised, the Raspberry Pi - specifically the Raspberry Pi B 3 (it is possible to upgrade to a Pi 4).  This single-board computer is of similar size as the BeagleBone Green and roughly similar capabilities - albeit a bit more powerful - and is certainly better-known than the other fruit, so it was a natural choice as the hardware interface between it and the receiver board is fairly trivial to adapt with a simple "conversion" board that adapted to the Pi's interface.

Also to be expected, a revised board (like those pictured above) specifically designed to interface with the Raspberry Pi has appeared from Chinese sellers, packaged with a Raspberry Pi, in a small, aluminum enclosure (with an external fan) for approximately $100 less than the KiwiSDR+Enclosure combination - and this revised version uses a higher-speed (125 MHz versus 66.66 MHz) and higher resolution (16 bits versus 14 bits) A/D converter so that its receive range is extended to a bit over 60 MHz, including the 6 meter amateur band - and there is the potential for improved receive performance in terms of dynamic range and distortion.

Comparison:

Having gotten my hands on one of these "RaspberrySDRs" - and already having available some KiwiSDRs for testing, I decided to put them side-by-side to compare the differences - specifically, to measure:

• Apparent noise floor and sensitivity
• Appearance of spurious signals
• Large signal handling capability
• Image response (Nyquist filtering)
  

Noise floor comparisons of the KiwiSDR using the BBAI and the RaspberrySDR using the Raspberry Pi3B+:

The KiwiSDR using the BeagleBone AI:

Figure 3 shows the noise floor of a KiwiSDR using the Beaglebone AI with no connected antenna.  As is typical of this device, there is a slight increase in the noise floor starting around 18 MHz:  The reason for this is unknown, but it is surmised that this is intentional - an artificial boost in "software" that is used to compensate somewhat for the Sin(x)/x roll-off intrinsic to any analog-to-digital sampling scheme as one approaches the Nyquist limit - which, given the 66.66 MHz sampling rate of the KiwiSDR, would be 33.333 MHz.

This assumption would appear to be supported by the fact that as one approaches the Nyquist frequency, the S-meter reading does not drop as one might expect, but remains fairly constant and appears to be close to +/- 1 dB from below 1 MHz to 30 MHz as shown in the data below.

Figure 3:
The noise floor of the KiwiSDR running on a BeagleBone AI (BBAI).
Note the slight rise around 18 MHz - the possible result of the data being "cooked" in the pipeline to offset Sin(x)/x losses near the Nyquist limit.
Click on the image for a larger version.

In numerical form, the measured noise floor of the KiwiSDR/BBAI combination using a 10 kHz AM bandwidth is:

• -117dBm @ 1 MHz
  
• -117dBm @ 5 MHz
• -116dBm @ 10 MHz
• -116dBm @ 15 MHz
• -114dBm @ 25 MHz
• -115dBm @ 30 MHz (29.9 MHz)

A broad 3dB peak is indicated in the noise floor:  We will attempt to determine if this peak is "real" in our later analysis.

The RaspberrySDR using the Raspberry Pi3+:

The RaspberrySDR has a 125 MHz sampling clock and a 16 bit A/D converter so the landscape looks a bit different as it can (theoretically) receive to 62.5 MHz, but is limited to 62.0 MHz in firmware.  Comparing the 0-30 MHz noise floor to that in Figure 2 (from the KiwiSDR) we can see some interesting differences in Figure 4:

Figure 4:
Noise floor of the RaspberrySDR running on a Raspberry Pi3+.  There is a similar rise in frequency - although it looks a bit different.
Click on the image for a larger version.

We can see a similar rise in the noise floor, but we get the impression that limiting our range to just 30 MHz hides its nature, so Figure 5 shows the noise floor over the full frequency range of 0-62 MHz:

Figure 5:
Noise floor of the same receiver as depicted in Figure 4, but showing the full 0-62 MHz frequency range.  Very evident is a rise in the noise floor centered at approximately 36 MHz.  This spectrum is unchanged if the SPI frequency is changed from the default 48 to 24 MHz.
Click on the image for a larger version.

In comparison, the noise floor of the RaspberrySDR+Raspberry Pi3+ as measured using AM with a 10 kHz bandwidth is as follows:

• -118dBm @ 1 MHz
  
• -118dBm @ 5 MHz
• -118dBm @ 10 MHz
• -116dBm @ 15 MHz
• -115dBm @ 25 MHz
• -112dBm @ 30 MHz
• -113dBm @ 40 MHz
• -116dBm @ 50 MHz
• -116dBm @ 60 MHz

The magnitude of the broad peak is more significant than on the KiwiSDR - being on the order of 6 dB rather than 3 dB.  Because the RaspberrySDR is based on the (open source) KiwiSDR, it is expected that a the RF processing will be similar - and this would appear to be borne out by the presence of the rise in the noise floor, centered around approximately 36 MHz.  It would seem likely that the adaptation to the higher sample rate hardware is not fully realized as the pre-emphasis in firmware - if it exists - is not properly implemented as is evidenced by the numbers.

Comparison of S-meter calibrations:

To provide and additional data point in our measurement, we'll check the S-meter calibration.  For our purposes we will use a frequency of 10 MHz and a level of -50dBm as our reference as that appears to be below the apparent amplitude peaking of either type of receiver.  Using a known-consistent signal source, the results are as follows:

Frequency	KiwiSDR with BeagleBone AI	RaspberrySDR with Raspberry Pi3+
1 MHz	-51dBm	-50dBm
5 MHz	-51dBm	-50dBm
10 MHz	-50dBm	-50dBm
15 MHz	-49dBm	-49dBm
20 MHz	-48dBm	-48dBm
25 MHz	-48dBm	-46dBm
30 MHz	-50dBm	-45dBm
50 MHz	---	-50dBm
60 MHz	---	-57dBm

The effects of what appears to be pre-emphasis can clearly be seen:  The effects of the Sin(x)/x roll-off on the A/D converter seems to have been more-or-less compensated on the KiwiSDR, but the attempt to do this seems to be misapplied on the RaspberrySDR.  Based on the apparent noise floor and the absolute response to the -50dBm signals, we can make an estimate of the absolute sensitivity of the KiwSDR and RaspberrySDR on the various bands with simple math.

Frequency	KiwiSDR Noise floor (dBm/Hz)	RaspberrySDR Noise floor (dBm/Hz)
1 MHz	-158dBm	-158dBm
5 MHz	-158dBm	-158dBm
10 MHz	-156dBm	-158dBm
15 MHz	-157dBm	-157dBm
25 MHz	-156dBm	-159dBm
30 MHz	-155dBm	-157dBm
50 MHz	---	-156dBm
60 MHz	---	-111dBm

The chart above compares the apparent noise floor of both receivers, compensating for the 10 kHz AM detection bandwidth (40dB) and the measured offset of the S-meter at each frequency.

 
It is worth noting that above about 20 MHz - and given zero line and antenna losses - neither receiver has sufficient sensitivity to detect the expected ITU noise floor given a unity gain antenna:  Approximately 10dB of additional low-noise gain is required at 30 MHz to "hear" the noise floor in that case and even more gain would be appropriate at 6 meters.

This very topic has been discussed at this blog in the past - see the blog post "Limited Attenuation High-Pass filter" - LINK and its follow-up article "Revisiting the Limited Attenuation High Pass Filter" - Link - and their related articles for a discussion. 

For information about the expected ITU noise floor under various "idealized" conditions, see the article:  Recommendation ITU-R p.372-8 link.

 *****************************

Overload signal level comparison:

Another test was done - the determination of the RF level at which the "OVL" message on the S-meter would show, indicating overload of the A/D converter.  This test was done for both units at 10 MHz - the same frequency for which the S-meter was calibrated - and in the "Admin" tab the unit was configured so that just one "OV" occurrence per 64k cycles would be detected.

KiwiSDR OV indication:

The KiwiSDR's "OV" indication just started to indicate at -14dBm.

RaspberrySDR OV indication:

The RaspberrySDR's "OV" indication just started to indicate at -9dBm.

The apparent difference between these is 5dB.

"Wait - shouldn't there be another 12dB of dynamic range with two more bits of A/D resolution?"

In theory, two additional bits of A/D conversion  should yield and additional 12 dB of dynamic range - but this is not readily apparent in the numbers given above (at 10 MHz, 142dB between the noise floor and the "OV" indication for the KiwiSDR and 149dB for the RaspberrySDR) - so what's the deal?

First off, all things being equal (e.g. the same reference voltage for the A/D converter) one would expect the additional range to occur at the bottom of the signal range rather than the top, but this difference can be a matter of scaling via careful adjustment of the amount of amplification preceding the A/D converter and how the code is written.

Ideally, one would carefully balance the signal path so that the intrinsic noise of the amplification preceding the A/D converter would be comparable to the signal level required to "tickle" an LSB (Least Significant Bit) or two with no signal applied:  A higher level than this risks "wasting" dynamic range on internal noise.  Judging by the "even-ness" of the noise across the spectrum, I suspect that the output of the input amplifier is enough to light up at least two LSBs of the A/D converter.  If the signal path were highly "gain starved", low-level spurious signals would likely appear when very low-level signals were applied:  The sort of distortion resulting from the A/D converter being too-lightly driven can be witnessed when using a receiver like the RTL-SDR in "direct" mode and just increasing the signal levels to the point where they start to appear and many spurious signals show up.

It's possible that the "extra" 5 dB at the high end of the signal range is real and that signal dynamics have been juggled a bit with some the extra 2 bits worth of range being present at the bottom end, but this would be difficult to divine without more thorough testing and without the availability of a schematic diagram.  My preference would been to have the unit be slightly "gain starved" so that the the LSBs of the A/D converter would be subject to the action of external amplification to provide maximum flexibility when it comes to managing the signal path.

Discussion:

Note:  The schematic of the RaspberrySDR has become available since this was posted - see the analysis at the bottom of this article.

Without the availability of a schematic diagram of the front end of the receiver there are several unknowns:

• The LTC2208 has a pin that indicates an overload condition.  It is presumed that in spite of other issues with the firmware (see below) that the "OV" indicator is working properly.

• The LTC2208 A/D converter has a low-level dither generator built into it:  It is unknown if this feature is active.
  

• Shorting the RF signal path  at the A/D converter to eliminate the contribution of the pre-converter amplification would be instructional to ascertain noise contribution from that device.
  

• Probing the input of the A/D converter at/near overload to divine the actual range of the receiver itself to determine if the full dynamic range of the 16 bits is properly utilized would be revealing.
  

• The LTC2208 has a programmable gain amplifier and full-scale input voltage may be selected as being either 1.5 or 2.25 volts:  The hardware configuration is unknown.
  

• At the time of writing this, I have not found in the code any modification of the FPGA image that takes advantage of the extra two bits of A/D resolution.  This does not mean that no modification has been done, but rather that I have not (yet?) discovered it.

Nyquist Image response:

Any receiver has an image response - and an SDR is no exception. In this case, signals above the Nyquist frequency (half the sampling rate) will appear to "wrap around" and show up in the desired frequency range.  Because it is impractical to build true a "brick wall" low-pass filter, there are always compromises when designing such a filter, including:

• Complexity:  How "fancy" should such a filter be in terms of component count?  More components can mean improved performance, but this implies a more difficult design, higher expense and more performance-related issues such as loss, ripple, sensitivity to source/load impedance, etc.
  

• Trade-off of frequency coverage:  It can be difficult to weigh the pros and cons of a filter in terms of its cut-off frequency.  For example, setting the cut-off near the Nyquist frequency will improve performance at the high end of the available range, but at the risk of poorer image rejection.  Conversely, setting it much lower than Nyquist may sacrifice desired coverage.  A case in point would be that for the KiwiSDR, with a Nyquist frequency of about 33.33 MHz, coverage to 30 MHz (the "top" of HF) is desirable, so a bit of compromise is warranted in terms of absolute image rejection.

How bad/good is it?

The image response of both the KiwiSDR and RaspberrySDR were measured and determined to be as follows: 

The KiwiSDR:

Generator frequency (% of Nyquist)	Nyquist image frequency on RX	KiwiSDR Nyquist image attenuation
37 MHz  (111%)	29.667 MHz	10dB
42 MHz  (126%)	24.66 MHz	20dB
47 MHz  (141%)	19.66 MHz	30dB
52 MHz  (156%)	14.66 MHz	39dB
59 MHz  (177%)	9.66 MHz	47dB
62 MHz  (186%)	4.66 MHz	55dB
66 MHz  (198%)	0.66 MHz	60dB
70 MHz  (210%)	-3.33 MHz	65dB

 The RaspberrySDR:

Generator frequency  (% of Nyquist)	Nyquist image frequency	RaspberrySDR Nyquist image attenuation
64 MHz  (102%)	61 MHz	9dB
75 MHz  (120%)	50 MHz	18dB
85 MHz  (136%)	40 MHz	27dB
95 MHz  (152%)	30 MHz	36dB
105 MHz  (168%)	20 MHz	46dB
115 MHz  (184%)	10 MHz	54dB
120 MHz  (192%)	5 MHz	58dB
124 MHz  (198%)	1 MHz	60dB
130 MHz  (208%)	-5 MHz	65dB

Doing a direct comparison between the two receivers one can see that based on the percentage of the frequency of the unwanted signal with relation to to the Nyquist frequency, the two receivers are pretty much identical in terms of image rejection, implying a very similar filter in each:  I suspect that the RaspberrySDR's Nyquist filter is pretty much that of the KiwiSDR, but with its frequency having been rescaled proportionally.

Because the Nyquist frequency of the RaspberrySDR is approximately twice that of the KiwiSDR, in terms of "dB per MHz" the attenuation of RasperrySDR's Nyquist filter performance will be noticeably worse.  For example, we know from the above information that for the U.S. FM broadcast band that the attenuation of the KiwiSDR's Nyquist filter will be at least 65dB - but we can see that for the RaspberrySDR that this attenuation will likely vary between about 30dB at the bottom end of the band (88 MHz) and 50dB at the top end (108MHz) meaning that it is likely that strong, local FM broadcast signals will cause some interference to the RaspberrySDR in the 37-17 MHz range implying that a simple blocking filter for this frequency range should have been built in   The work-around for this problem - should it arise - is pretty simple:  Install an FM broadcast band "blocking" filter such as those sold for the RTL-SDRs:  An example of such a filter may be found HERE.

Update:  Schematics for the RaspberrySDR are now available - see below.

Effects of receiver noise floor with a strong, off-frequency signal:

Any receiver is affected by other strong signals within its front-end passband - and with direct-sampling SDRs such as these, any signal appearing at the antenna port can and will have an effect elsewhere within the receiver's passband - primarly due to nonlinearity of the A/D converter and, to a lesser extent, the phase noise of the various oscillators - real and virtual.

For this test, a very strong signal from a 10 MHz OCXO (that of an HP Z-3801 GPS receiver - likely a variant of an HP 10811) was used as its output has respectably good phase noise performance.  Two tests were done - at -15dBm and another at -25dBm - each time measuring the change in the noise floor at different frequencies distant from 10 MHz.

With the 10 MHz signal set to -25dBm, NO change was observed in the noise floor at the frequencies listed below on either receiver - but there was a bit of increase in the noise floor with the application of the -15dBm signal - the magnitude of the increase of the noise floor is indicated in square brackets [] in the chart below:

Noise floor frequency	Noise floor of KiwiSDR [degradation]	Noise floor of RaspberrySDR [degradation]
11 MHz	-114dBm  [2dB]	-116dBm  [0dB]
15 MHz	-114dBm  [2dB]	-114dBm  [2dB]
25 MHz	-113dBm  [1dB]	-112dBm  [2dB]

Assuming that the 10 MHz signal source is "clean", the above information shows that the two receivers behaved quite similarly.  It also shows that if there are two additional bits of A/D resolution available in the signal pipeline on the RaspberrySDR, their effect is not readily apparent in the measurements above.

All is not well:  A few glaring bugs!

There are several "features" that are readily apparent in this version of RaspberrySDR firmware (Version 1.402) that cause a few operational problems:

• Inconsistent RF level calibration.  Occasionally, when powered up, the RF signal level calibration (S-meter, waterfall) will be way off requiring a setting of about -30dBm to yield correct S-meter calibration at 10 MHz rather than -19 - which is within a few dB of the setting of the KiwiSDR:  Simply rebooting the Raspberry SDR server will likely correct this.
  

• No obvious improvement in dynamic range or sensitivity due to the "extra" 2 bits of A/D resolution.  As discussed, one would expect to see clear evidence of improved performance due to the additional two bits of A/D converter resolution, but either this is masked by the low-level noise of the input amplifier, problems in the processing of the A/D data itself, or issues related to handling of high signal levels (see the next topic, below).  What difference there may be appears to be at the top end of the signal range rather than at the bottom.
  

• "Broken" S-meter at higher signal levels.  The S-meter seems to be incapable of reading properly above about -33dBm:  Signals higher than this will yield widely-varying numbers that have little to do with the actual signal level.
  

• "Motorboating" on strong, narrowband signals.  It has been observed that at about the same time that the S-meter starts to malfunction (above about -33dBm) one will hear odd noises on a strong signal (unmodulated carrier received in AM mode using a 10 kHz bandwidth) indicative of a malfunctioning bit of code somewhere - likely related to the broken S-meter.  The nature (sound) of this effect appears to change depending on the applied signal level.  It is not (yet) known to what extent this issue has a "global" effect:  That is, does a single, strong signal cause this effect on other/all signals within the receiver's 0-62 MHz passband?
  

• The "Firmware Update" function in the "Admin" screen doesn't work at all.  Make of that what you will.
  

 *****************

An interesting notion - Direct reception of the 2 meter amateur band:

In theory it should be possible to modify the RaspberrySDR to directly receive the amateur 2 meter band - and any other signals from above 125 MHz to at least 174 MHz.  Because the sample rate of the receiver's A/D converter is 125 MHz, one can undersample the 144-148 MHz 2 meter band, which would appear in the range of 19-23 MHz.  Because this is just above the sampling frequency, the "direction" of the frequency conversion (e.g. increasing frequency at the antenna will show as increasing on the display) will be correct which means that a standard transverter offset (e.g. a local oscillator frequency of 125 MHz) could be used.

To do this one would need to - at the very least - bypass the Nyquist low-pass filter, and with the noise floor likely to be much worse than the 158dBm/Hz seen at HF so significant low-noise amplification AND strong band-pass filtering (to quash spurious responses) would be required - probably something on the order of 25dB.

Based on the specifications of the LTC2208, undersampling should work into the hundreds of MHz, possibly covering other VHF and UHF amateur bands - but the need for appropriate amplification and filtering applies!

  *****************

The "elephant" in the room

It is immediately obvious - particularly from the board layout and screen shots - that the RaspberrySDR has heavily "borrowed" its design from the KiwiSDR and this is, to a large extent, entirely fair game since the KiwiSDR is a self-declared open-source hardware and software design.  Having said this, a few issues have been raised considering the RaspberrySDR:

• Is the RaspberrySDR being produced entirely in accordance with the KiwiSDR Open Source license?  Likely not.  For example, elements of the KiwiSDR "branding" appear all over the RaspberrySDR - from the derivative (parody?) logo on the board (see Figure 2) to the name "KiwiSDR" being present within the web interface itself.  The former may be an intentional, perhaps perceived as a slight - and the latter is rather hard to eliminate entirely - particularly if one wishes to maintain a branch of the code that echoes the continued development of the KiwiSDR - not to mention effort flowing in the other direction (e.g. improvements by others being incorporated into the KiwiSDR base).
  

• Another board with similar capabilities (16 bit A/D, 125 MSPS) has appeared - apparently similar to this RaspberrySDR board - but it interfaces with the BeagleBone:  I have not used one or seen one in person, nor do I know anything about hardware/software support.
  

• The RaspberrySDR source code itself seems to be somewhat obscured.  While there is a RaspberrySDR fork on Github (see note below), it is apparently not the very same code that is what is made available as a Raspberry Pi image only (as far as is known at the time of writing) from a link provided by the online seller.  In other words, I have not been able to find any sort of equivalent of a Github repo for the RaspberrySDR - a fact not exactly in keeping with the spirit of "open source". 
  

• Github user "FlyDog" has produce the fork mentioned above and his repo may be found HERE.  Now found HERE.  As mentioned above, I haven't been able to get this code to work with this board.   (See the end of this article for comments from users of actual "FlyDog" boards.)
  

• UPDATE (20200927):  Github user "howard0su" had produced a fork (found HERE) more likely to be relevant to the RaspberrySDR hardware.  Based on posts to the "raspsdr" list on groups.io, this appears to be a legitimate, open-source fork of the KiwiSDR code.  The owner of this fork has stated on that group that he is not involved with the production of the RaspberrySDR hardware.  As of the date of this update, I have not attempted to build from this source.
  

•  Update:  Schematics and source for the RaspberrySDR are now available - see below.  The schematic of the RaspberrySDR does not seem to be available at the time of this writing - again, not in the spirit of open source.  

• The primary author of the KiwiSDR code announced recently on the KiwiSDR message board that certain parts of the KiwiSDR's code - presumably elements not previously released under an open-source license - would be available only as binary "blobs" in the future.  The intent of this action - as it seems to be interpreted by many of the readers (including me)  - is, in addition to protect certain elements, is to increase the difficulty of replicating the software in the future - and some might argue that this goes against the spirit of "open source" that was embodied in the original Kickstarter definition of the KiwiSDR.  Whether this is true or not, the reader should not overlook the fact that the primary author has spent (and continues to spend) a lot of time, effort and money in the maintaining of the KiwiSDR software, hardware manufacture and certain elements of infrastructure about the KiwiSDR (Proxies, DDNS, TDOA to name three) and there is an understandable desire to "encourage" involvement (including buying "official" KiwiSDR boards, for example) that would go toward maintaining this.  The presumed argument is that follow-on versions based on the open source hardware and code - whether strictly adherent to the open-source licenses or not - are not compatible with his intent going forward.
  

Is it worth getting?

Is the RaspberrySDR a good deal?  It all depends on what you want to do with it.  At the moment, the ongoing support for it in terms of software development is a bit ambiguous as the "open source" nature of this fork seems to be a bit opaque, which is unfortunate.

For a general-purpose receiver that does not need the (useful!) facilities unique to the KiwiSDR network (proxy, TDOA, etc.) and for a receiver that includes the 6 meter band, this unit may fill a niche.

Again, the reader is cautioned that the "official" KiwiSDR brings to the amateur community several valuable features - including the TDOA - that require ongoing support which translates directly to people buying the "official" KiwiSDR boards, as I have clearly done.  (I personally own four KiwiSDRs, and have directly caused the purchase of at least two more.)

Final comments:

• For a general-purpose web-enabled remote receiver with decent performance, both the KiwiSDR and RaspberrySDR seem to be a good deal and the RaspberrySDR works reasonably well despite the bugs mentioned above.  The RaspberrySDR has the advantage that it also covers the 6 meter amateur band and has the potential of improved performance by virtue of its 16 bit (versus 14 bit) A/D converter.
  

• The KiwiSDR kit with the Beaglebone Green and case - even though it costs more (approximately US$100 more than the RaspberrySDR) - has the distinct advantage of ongoing support along with the other infrastructure features mentioned above.  Like any open-source project, there will come the day when such support will cease and it will be up to others to try to build on what is in the repository at that time.
  

• The current hardware of the KiwiSDR is starting to show its age for the reasons mentioned above and the existence of the RaspberrySDR shows that a relatively minor modification can potentially improve performance without a major rework of either hardware or software. 
  

• Note:  KiwiSDR Version 2 now available:  The RaspberrySDR and its clones have largely disappeared, but Version 2 of the KiwiSDR - produced and supported by the creator of the original KiwiSDR - is available as of 2024 - see the kiwisdr.com web site for more details.

• With the understanding that the time and resources of the primary author and frequent contributors to the KiwiSDR are limited in the ability to undertake such a change, I believe that it would be a mistake to overlook the potential (and "inspiration") of parallel work being done by others when it comes to keeping the KiwiSDR project up to date and relevant.

* * * *

Addendum - 20201002 - RaspberrySDR schematics and sources are now available:

An email from another amateur radio operator informed me that the schematic diagrams of the RaspberrySDR - and a reference to a Github repo of the source - were posted on the "RaspberrySDR" group on "groups.io" - the link to that posting is HERE.  (Membership in that group may be required to see it.)

A brief analysis of the diagram has revealed several things:

• GPS receiver:  The GPS receiver is identical - but that's not too surprising.  While the GPS receiver chip is not specified on the RaspberrySDR schematic, it has the same pin-out as that of the KiwiSDR, although a 66.666 MHz oscillator is shown rather than the 16.384 MHz oscillator on the KiwiSDR.
  

• Front end filter:  As I'd surmised, the low-pass (Nyquist) filter is of identical topology as that of the KiwiSDR with a note on the diagram stating "LPF change to 64M" - but the values are the same as those of the KiwiSDR.  Clearly, a change in the components was made, but the schematic was not updated.
  

• As with the KiwiSDR, the RF amplifier is shown as being an LTC6401-20.  This device has a fixed gain of 20dB (voltage gain of 10) and has a differential output:  The data sheet depicts it being used to drive an LTC2208 - the same A/D converter as is used on the Raspberry SDR.
  

• The A/D converter is shown as being an "LTC2208CUPPBF" - a 130 MHz, 16 bit A/D converter.  The diagram shows all 16 of the "A" bus being connected as well as the "DITH" (used for enabling internal dither generator), "MODE" (used to set the output data format), "PGA" (used to set the gain of the A/D converter to either 1.5 or 2.25 volts full-scale) and "RAND" (used to randomize the output data to minimize possible noise contribution) pins being connected to the FPGA - and like the KiwiSDR, the "OFA" pin is also used to detect over/underrange of the A/D converter.
  

• Maybe I missed it, but the circuit used to control the cooling fan does not appear to be on the schematic, nor did I find and obviously-named pin that might be used to control it:  Because the fan does not spin up unless the RaspberrySDR software service is running, it's clearly under software control - likely via a GPIO pin from the Raspberry Pi itself.

Discussion:

• When time permits, I will probe about to determine the state of the DITH, MODE, PGA and RAND pins on the A/D converter.
  

• Because the "PGA" pin may be controlled by the FPGA, it is possible that the A/D's input voltage range can be increased to 2.25 volts - a theoretical increase of about 3.5dB in signal input.
  

• If this pin is set to the "low" state, this would - all things being equal - increase the "OV" (overload) threshold from the -14dBm of the KiwiSDR to about -10dBm - very close to the "-9dBm" that was observed in the test, above.
  

• In other words, given the otherwise-identical circuitry, it is entirely possible that the increase in the "OV" threshold is entirely due to changing of the A/D converter's PGA setting.
  

• A back-of-the-envelope calculation shows that assuming a 1dB loss in the low-pass filtering, a -14dBm signal - that required to cause an "OV" indicator on the KiwiSDR, amplified by 20dB would yield about 1.12 volts peak-to-peak - a value that correlates well with a presumed 1.25 volt A/D maximum input voltage.
  

• Similarly, another calculation shows that - also assuming a 1 dB loss in the low-pass filtering - a -9 dBm signal - that required to cause an "OV" indication on the RaspberrySDR, amplified by 20dB would yield about 2.0 volts peak-to-peak - a value that also correlates pretty well if the "PGA" pin is set to configure the A/D converter for a 2.25 volt range.
  

• Because 2 extra A/D bits (theoretically) correspond to about 12 dB more usable range, that would, in theory, indicate about 8 dB more dynamic range for the RaspberrySDR over the KiwiSDR.  How well this hypothetical gain is distributed is certainly a topic for more detailed analysis.
  

• Because it is (presumably) under software control, I would like to see the settings of the DITH and PGA pins of the A/D converter being made available to the user in the configuration screen.  Because the amplitude of the dither is only on the order of 0.5dB (according to the data sheet) it is unlikely that its effect would be seen when a real-world antenna - and its noise - is connected to the receiver:  Anyway, it seems likely that the noise floor of the input amplifier may be the limiting factor.
  

• It's worth pointing out that, according to the data sheets, the SFDR (Spurious-Free Dynamic Range) and  S/(N+D) (Signal to Noise+distortion) specifications of the 14 bit LTC2248 in the KiwiSDR are typically specified as being 90dB and 74.2dB respectively at 30 MHz while the same spec for the 16 bit LTC2208 (in the RaspberrySDR) - assuming a PGA setting of 2.25 volts - are 94dB and 77.5dB:  Not quite the "theoretical" 12 dB afforded from two extra bits!  (The SFDR of the LTC2208 actually goes up to 100dB when the PGA is set for 1.5 volts.)
  

* * * * *

Large signal and noise analysis of the KiwiSDR:

Somewhat beyond the scope of this article, related directly to the KiwiSDR, is the article written by Adam, AB4OJ where the noise and large signal-handling characteristics of the KiwiSDR were examined in detail - the article found HERE.  In short, the conclusion of this article is that the receive performance of KiwiSDR hardware is shortchanged by nonlinearities in the amplifier preceding the A/D converter - something that should warrant further investigation.

Because the "clone" receivers described on this page are variants of the KiwiSDR, it is likely that their performance is equal to or worse than the KiwiSDR, depending on gain distribution.

* * * * *

Addendum 20210304 - The "FlyDog SDR":

Another variant of the RaspberrySDR has appeared for sale - a board marked "FlyDog SDR".  While I do not have one of these boards, I have spoken to several people who have obtained one and both have noted the following:

• The software is unreliable.  The KiwiSDR process appears to stop after several hours due to severe memory leaks.  Apparently, a "Docker" container is used (sort of like a virtual machine) and this may be the source of unreliability.  As of this date, it is considered to be unusable.  
  

• Comment:  It is possible to install the "RaspberrySDR" software image instead of the FlyDog, providing far better reliability.
  

• The issue with crashing was tracked down to additional software running (DigiSkimmer) that has a memory leak, taking the KiwiSDR software offline.
  

• Two antenna ports, poor execution.  The variants appearing recently sport to HF antenna ports - but all is not well:  Apparently, these two ports are not switched (e.g. A/B selection) but rather simply bridged together post low-pass filter.  In other words, it's likely that the mere presence of the additional filter hardware causes mismatch/ripple issues even if you don't connect a second antenna, causing lots of dips and nulls across the HF/VHF receive spectrum - and a particularly deep (20+ dB) right around 30 meters (10 MHz):  If you do connect two antennas at once, they will not "mix", but more likely combine in an unexpected manner.
  

• The suggestion is to bypass/remove the built-in low-pass filters on the FlyDog and implement any low-pass filters EXTERNALLY.  If this is done, the performance of the FlyDog is comparable to that of the KiwiSDR.
• This 10 meter "dip" can be somewhat mitigated by an antenna ONLY the "50 MHz" port and putting a 50 ohm load on the "30 MHz" port:  This moves the deep portion of the null closer to 9 MHz and reduced the attenuation at 10 MHz to "only" 3-6 dB.
  

• Extremely poor 125 MHz oscillator.   The A/D converter is clocked using a 125 MHz oscillator - and it is this oscillator that determines the stability of the receiver in terms of frequency and phase - and this likely makes it UNUSABLE for most digital modes.
• Unlike the KiwiSDR and the Raspberry Kiwi, the oscillator in the FlyDog SDR is extremely poor in terms of stability.  This instability is not necessarily in terms of phase noise, but rather something more akin to low-frequency jitter:  At 125 MHz, the frequency will shift several Hz, randomly, over the period of seconds - too fast for the GPS frequency correction to catch.
• This instability is bad enough that it makes the FlyDog SDR UNSUITABLE for use in decoding most modern HF digital modes - particularly those with slower symbol rates such as FT-8, FT-4, JT-65 and WSPR - and probably many more.
• It is expected that one could "simply" replace the oscillator with a more stable part - and a possible substitute is the TXC 7W-125.000MBB-T (Digi-Key P/N:  887-1192-1-ND):  This part has a reasonably low jitter specification - as opposed to many MEMs-based devices.  At the time of writing, this part has not been tried, so its suitability or "fitment" has not been verified.
• A work-around:  The stability issue appears to be a thermal one, the frequency of the oscillator being extremely sensitive (e.g. frequency shift of 1 ppm for just a degree or two of temperature change) and is such that even minor turbulence in still air is enough to cause the problems noted.  By epoxying a small piece of aluminum (I used a 10x13mm piece of 2mm thick metal - but as large as 10x20mm would work) to the TCXO - taking care NOT to cover any part of the FPGA - the short-term thermal stability is greatly improved due to the added mass.  It can further be improved by covering the piece of aluminum with a small piece of foam - again, taking care to NOT cover the FPGA or A/D.
  

In short:  Both owners of the "FlyDog" variant recommend AGAINST buying it in its current form as it has significant software and hardware issues "out of the box" compared to the RaspberrySDR or the KiwiSDR.

 

This page stolen from ka7oei.blogspot.com

[End]