As noted in a previous entry of this blog where I discussed the "Raspberry Kiwi" SDR - a (near) clone of the KiwiSDR - there is also the "FlyDog" receiver - yet another clone - that has made the rounds. As with the Raspberry Kiwi, it would seem that the sources of this hardware are starting to dry up, but it's still worth taking a look at it.
Note: There is now the "Web-888" which is functionally similar to the
RaspberySDR and the Flydog SDR, but reports indicate that unlike the
Flydog, it performs reasonably well over the intended frequency range.
Unlike the KiwiSDR, its support (e.g. software updates, interaction with the designer, accessibility to useful features like TDOA) is somewhat limited.
I had temporary loan of a FlyDog SDR to do an evaluation, comparing it with the KiwiSDR - and here are results of those tests - and other observations.
 |
| Figure 1: The Flydog SDR. On the left are the two "HF" ports and the port for the GPS antenna. Note the "bodge" wires going through the shielded area in the upper left. The dark squares in the center and to its right are the A/D converter and the FPGA. The piece of aluminum attached to the oscillator is visible below the A/D converter. Click on the image for a larger version. |
How is this different from the Raspberry Kiwi?
Because of its common lineage, the FlyDog SDR is very similar to the Raspberry Kiwi SDR - including the use of the same Linear Technologies 16 bit A/D converter - and unlike the Raspberry SDR that I reviewed before, it seems to report a serial number, albeit in a far different range (in the 8000s) than the "real" KiwiSDRs which seem to be numbered, perhaps, into the 4000s.
The most obvious difference between the FlyDog and the original KiwiSDR (and the Raspberry Kiwi) is the addition of of a second HF port - which means that there is one for "up to 30 MHz" and another that is used for "up to 50 MHz" - and therein lies a serious problem, discussed below.
Interestingly, the FlyDog SDR has some "bodge" wires connecting the EEPROM's leads to the bus - and, unfortunately, these wires, connected to the digital bus, appear to run right through the HF input section, under the shield! Interestingly, these wires might escape initial notice because they were handily covered with "inspection" stickers. (Yes, there were two stickers covering each other - which was suspicious in its own right!) To be fair, there's no obvious digital "noise" as a result of the unfortunate routing of these bodge wires.
Why does it exist?
One would be within reason to ask why the FlyDog exists in the first place - but this isn't quite clear. I'm guessing that part of this was the challenge/desire to offer a device for a the more common, less-expensive and arguably more capable Raspberry Pi (particularly the Pi 4) - but this is only a guess.
Another reason would have been to improve the performance of the receiver over the KiwiSDR by using a 16 bit A/D converter - running at a higher sampling rate - to both improve dynamic range and frequency coverage - this, offering usable performance up through the 6 meter amateur band.
Unfortunately, the Flydog does neither of these very well - the dynamic range problem being the same as the Raspberry Kiwi in the linked article compounded by the amplitude response variances, choice of amplifier device and frequency stability issues discussed later on.
Observations:
Getting immediately to one of the aspects of this receiver, I'll discuss the two HF ports. Their basic nature can be stated in two words: Badly implemented.
When I first saw the FlyDog online with its two HF ports, I wondered "I wonder how they selected between the two ports - with a small relay, PIN diodes, or some sort of analog MUX switch, via hardware?" - but the answer is neither: The two ports are simply "banged" together at a common point.
When I heard this, I was surprised - not because of its simplicity, but because it's such a terrible idea.
As a few moments with a circuit simulator would show you, simply paralleling two L/C networks that cover overlapping frequency ranges does not result in a combined network sharing the features/properties of the two, but a terrible, interacting mess with wildly varying impedances and the potential for huge variations of insertion loss.
The result of this is that the 30 MHz input is, for all practical purposes, unusable, and its existence seriously compromises the performance of the other (0-50 MHz) port. Additionally, if one checks the band-pass response of the receiver using a calibrated signal generator against the S-meter reading, you will soon realize that the resulting frequency response across the HF spectrum is anything but flat.
For example, one will see a "dip" in response (e.g. excess loss) around 10 MHz on the order of 20 dB if you put a signal into the 50 MHz port, effectively making it (more or less) unusable for the 30 meter amateur band and the 31 meter shortwave broadcast band. Again, there is nothing specifically wrong with the low-pass filter networks themselves - just the way that they were implemented: You can have only one such network connected to the receiver's preamplifier input at a time without some serious interaction!
Work-around:
Having established that, out-of-the-box, that the FlyDog has some serious issues when used as intended on HF, one might be wondering what can be done about it - and there are two things that may be done immediately:
- Do microsurgery and disconnect one of the HF input ports. If you have the skills to do so, the shield over the HF filter may be unsoldered/removed and the circuit reverse-engineered enough to determine which component(s) belong to the 30 MHz and 50 MHz signal paths - and then remove those component(s). If you wish to retain 6 meter capability, disconnect the 30 MHz port. Clearly, this isn't for everyone!
- Terminate the unused port. A less-effective - but likely workable alternative - would be to attach a 50 ohm load to the unused port. On-bench testing indicated that this seemed to work best when the 50 MHz port was used for signal input and the 30 MHz port was connected to a 50 ohm load: The frequency of the most offensive "null" at about 10 MHz shifted down by a bit more than 1 MHz into the 9 MHz range and reduced in depth, allowing still-usable response (down by only a few dB) at 10 MHz, and generally flattening response across the HF spectrum: Still not perfect, but likely to be adequate for most users. (In testing, the 30 MHz port was also shorted, but with poorer results than when terminated.)
In almost every case, the performance (e.g. sensitivity) was better on the 50 MHz port than the 30 MHz port, so I'm at a loss to find a "use case" where its use might be better - except for a situation where its lower performance was outweighed by its reduced FM broadcast band rejection.
This issue - which is shared with the RaspberryKiwi SDR - is that the low-pass filter (on the 50 MHz port) is insufficient to prevent the incursion of aliases of even moderately strong FM broadcast signals which appear across the HF spectrum as broad (hundreds of kHz wide) swaths of noise with a hint of distorted speech or music. This is easily solved with an FM broadcast band filter (NooElec and RTL-SDR blog sell suitable devices) - and it is likely to be a necessity.
Other differences:
- Lower gain on the FlyDog SDR: Another difference between the FlyDog and KiwiSDR is the RF preamplifier. On the KiwiSDR and Raspberry Kiwi, a 20 dB gain amplifier (the LTC6401-20) is used, but a 14 dB gain amplifier (LTC6400-14) is used instead - a gain reduction of about 6 dB, or one S-unit - and the effects of this are evident in the performance as described below. Was this intentional, a mistake, or was it because the 14 dB version was cheaper/more available?
- "X1.5/X1.0" jumper: There is, on the silkscreen, indication of a jumper that implies the changing of the gain from "1.5" to "1.0" when J1 is bridged. I didn't reverse-engineer the trace, but it appears to adjust the gain setting of the LNA of the A/D converter - and sure enough, when jumpered, the gain drops by about 4 dB - precisely what a "1.5x" factor would indicate.
- "Dith/NA" jumper: Also on the board is a jumper with this nomenclature marked J2 - and this (apparently) disables the A/D converter's built-in "dither" function - one designed to reduce spurious/quantization effects of low-level signals on the A/D converter, which defaults to "on" with the jumper removed as shipped. Although extensive testing wasn't done, there was no obvious difference with this jumper bridged or not - but then, I didn't expect there to be on a receiver where the noise limit is likely imposed by the LNA rather than the A/D converter itself.
- Deaf GPS receiver: I don't know if it's common to these units, but I found the Flydog being tested to be very insensitive to GPS signals as compared to other devices (including Kiwi and Raspberry SDRs) that I have around, requiring the addition of gain (about 15dB) to the signal path to get it to lock reliably.
Clock (in)stability:
The Flydog SDR uses a 125 MHz oscillator to clock the receiver (A/D converter) - but there is a problem reported by some users: It's a terrible oscillator - and it's bad enough that it is UNSUITABLE for almost any digital modes - particularly WSPR, FT-8, and FT-4 - to name but a few unless the unit is in still air and in an enclosure that is very temperature-stable.
 |
| Figure 2: Stability of the "stock" oscillator in the Flydog at 125 MHz in "still" air, on the workbench. The amount of drift - which is proportional to the receive frequency - makes it marginally usable for digital modes and is too fast/extreme to be GPS-corrected. Click on the image for a larger version. |
Figure 2, above, is an audio plot from a receiver (a Yaesu FT-817) loosely coupled and tuned to the 125 MHz oscillator on the Flydog's receive board: Due to the loose coupling (electrical and acoustic), other signals/noises are present in the plot that are not actually from the Flydog. The horizontal scale near the top has 10 Hz minor divisions and the red has marks along the left side of the waterfall represent 10 seconds.
From this plot we can see over the course of about half a minute the Flydog's main receiver clock moved well over 50 Hz, representing 5 Hz at 12.5 MHz or 1 Hz at 2.5 MHz. With this type of instability, it is probably unusable for WSPR on any band above 160 meters much of the time - and it is likely only marginally usable on that band as WSPR can tolerate only a slight amount of drift, and that's only if its change occurs in about the same time frame as the 2 minute WSPR cycle. The drift depicted above would cause a change of 1 Hz or more on bands 20 meters and above within the period of just a few WSPR - or FT8 - symbols, rendering it uncopiable.
"The Flydog has GPS frequency correction - won't this work?"
Unfortunately not - this drift is way too fast for that to possibly work as the GPS frequency correction works over periods of seconds.
What to do?
While replacing the 125 MHz clock oscillator with another device (I would suggest a crystal-based oscillator rather than a MEMs-based unit owing to the former's lower jitter) or apply a stabilized, external source (e.g. a Leo Bodnar GPS-stablized signal source) are the best options, one can do a few things "on the cheap" to tame it down a bit.
While on the workbench, I determined that this instability appeared to be (pretty much) entirely temperature-related, so two strategies could be employed:
- Increase the thermal mass of the oscillator. With more mass, the frequency drift would be slowed - and if we can slow it down enough, large, fast swings might be damped enough to allow the GPS frequency correction to compensate. With a slow enough drift, the WSPR or FT-8 decoders may even be able to cope without GPS correction.
- Thermally isolate the oscillator. Because it's soldered to the board, this is slightly difficult so our goal would be to thermally isolate the mass attached to the oscillator.
To test this idea I added thermal mass: I epoxied a small (12x15mm) piece of 1.5mm thick aluminum to the top of the oscillator itself. The dimensions were chosen to overlap the top of the oscillator while not covering the nearby voltage regulator, FPGA or A/D converter and the thickness happens to be that of a scrap piece of aluminum out of which I cut the piece: Slightly thicker would be even better - as would it being copper.
The epoxy that I used was "JB Weld" - a metal-filled epoxy with reasonable thermal conductivity, but "normal" clear epoxy would probably have been fine: Cyanoacrylate ("CA" or "Super" glue) is NOT recommended as it is neither a good void filler or thermal conductor.
Comment: If one wishes to remove a glued-on piece of metal from the oscillator during experimentation, do not attempt to remove it physically as this would likely tear it from and damaging the circuit board, but slowly heat it with a soldering iron: The adhesive should give way long before the solder melts.
The "thermal isolation" part was easy: A small piece of foam was cut to cover the piece of aluminum - taking care to avoid covering either the FPGA or the A/D converter, but because it doesn't produce much heat - and is soldered to the board itself - the piece of foam also covered the voltage regulator.
The result of these two actions may be seen in the plot below:
 |
| Figure 3: The stability of the oscillator after the addition of the thermal mass and foam. Still not great, but more likely to be usable. (The signal around 680-700 Hz is the one of interest.) Click on the image for a larger version. |
I have read that the Flydog SDR is no longer being manufactured - but a quick check of various sites will show it (or a clone) still being available as of the date of the original posting of this article - but its presence is fading. The Flydog is easily identified by the presence of three SMA connectors (30 MHz, 50 MHz and GPS) while the more-usable Raspberry Kiwi SDR has just two and is a black case with a fan.
Unless you absolutely must have 6 meter coverage on your Kiwi-type device (doing so effectively would be an article by itself) I would suggest seeking out and obtaining a Raspberry Kiwi - but if you don't care about 6 meters, the original KiwiSDR is definitely the way to go for the many reasons mentioned near the end of the aforementioned article.
