As noted in a previous entry of this blog where I discussed the "Raspberry Kiwi" SDR - another 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.
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.
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 more than two 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 and frequency stability issues discussed later on.
Getting immediately to one of the aspects of this receiver I'll discuss the two HF ports - and their implementation 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 wild variations of insertion loss.
The result of this is that the 30 MHz input is, for all practical purposes, unusable. 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 one puts a signal into the 50 MHz port, effectively making it 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!
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). 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 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 lower FM broadcast band rejection - more on that later.
The other 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.
- 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. Despite the gain reduction, the absolute receiver sensitivity was unchanged, implying that the system's noise floor is set either by the LNA itself (the LTC6400-14) or noise internal to the the A/D converter. If there's any beneficial effect at all I would expect it to occur during high signal conditions, in which case the "1.0" setting might make it slightly more susceptible to overload.
- "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 insensitivity 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. This has apparently been observed with other FlyDog units and it is suspected that a harmonic of a clock signal on the receive board may land close enough to the GPS frequency to effectively jam it - but this is only a guess.
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, 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 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) is the best option, 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 slowed 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 add 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 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:
The stability of the oscillator after the addition of the thermal mass and foam. Still not great,
but more likely to be usable.
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. 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.