Today marks a milestone in being able to access a standalone remote receiver at the W0QL station. A KiwiSDR arrived. It consists of a I/Q receiver board attached to a Beaglebone Green micro controller.
For more information see the link http://www.kiwisdr.com/ks/using_Kiwi.html
KiwiSDR is a receiver capable of tuning from 10 kHz to 30MHz accessed exclusively over it’s Ethernet connection which in this case will be the Internet.
Within 5 minutes of arriving it was up and running—truly plug-n-play. Software was pre-loaded and all needed hardware and peripherals were included in the kit ( $300 ). The KiwiSDR was decoding WSPR stations with the builtin wspr extension and displaying them on an iPad over the Internet. It is also sending spots to wsprnet.org.
Two projects are targeted for this radio so it’s possible a second one will have to be added for the second project. The first project is a dedicated wspr receiver capable of receiving and spotting several bands at once. This will provide information 24 hours a day about what bands are open at this particular location and instant in time. The other project is to have a second receiver to pick up FT8 signals. This would provide a “pseudo” SO2R receiver for use in single operator, two radio mode. Today is just the start of the projects.
Oops. Silly person. The KiwiSDR can have up to 8 users at a time completely independent from each other. Two KiwiSDR’s are not needed. One Kiwi can serve the purposes of different users. For example wspr can be on 7 bands simultaneously and an eighth receiver slice can be on FT8. Or mix and match as one wishes. The limit is CPU processing power.
Day 2 discovery: Catch 22. Can’t decode FT4 perhaps due to latency. WSPR and FT8 are ok but FT4 transmissions appear to be delayed too much by the Internet. FT4 transmissions are only 4.48 seconds compared to 12.64 seconds for FT8. A few milliseconds latency is a larger percentage of the shorter transmissions.
Meanwhile a SDRPlay RSPdx receiver has also been installed. There is a fundamental difference between the two receivers and that is where the FT4 transmission is decode by WSJT-X. RSPdx does it locally and KiwiSDR does it at the client site.
.The Kiwi processes the I/Q signals at the receiver site using the Beaglebone microcontroller. A client computer dials into the Beaglebone over the Internet to obtain the processed I/Q signals (audio SSB). WSJT-X runs on the client computer and decodes the audio ssb FT4 transmissions. The RSPdx does it differently. It sends the I/Q signals over a USB cable to an external cpu on site, typically a Windows pc. The pc processes the I/Q signals and sends them internally to the WSJT-X application running on the same pc. Next the WSJT-X display screen with decoded FT4 information is transported over the Internet using Remote Desktop where latency is not an issue. There is an issue for Remote Desktop, though, and that is Internet bandwidth. It uses a lot and running more than one Desktop on one Internet connection does not work well with the service at the remote base site.
One possible solution for KiwiSDR would be to delay the time clock on the client pc by the same delay as the latency. How would this be accomplished? Another solution is better Internet service.