Hi all, I thought this project might be of interest to those experimenting with SDR hardware and external interfaces to WSJT-X.
I have been developing ZynqRadio, a Windows C#/.NET 8 transceiver application for Zynq-7000 + AD936x SDR hardware. It interfaces with WSJT-X through the existing Hamlib NET rigctl and audio interfaces, while communicating directly with the SDR through libiio. SoapySDR is not used in either the control or sample path. The current implementation provides frequency control, CAT PTT, RX and TX DSP, 48 kHz Windows audio routing, direct IIO sample streaming, diagnostics, and simultaneous full-duplex RX/TX. The basic signal paths are: WSJT-X -> Hamlib/audio -> ZynqRadio -> libiio -> AD936x TX and simultaneously: AD936x RX -> libiio -> ZynqRadio DSP -> audio -> WSJT-X One of the more interesting problems during development was not the FT8 waveform generation itself, but maintaining the required sample transport rate during simultaneous transmit and receive. At 2.1 MS/s, using full complex I/Q streams in both directions caused the effective RX sample delivery rate to fall below the configured rate while transmitting. Diagnostic recordings showed that the generated FT8 TX waveform itself was correct, but the receive stream suffered enough timing compression to distort FT8 symbol timing and prevent reliable decoding. The solution I am currently using is an intentional 10 kHz RX LO offset combined with I-only RX transport. For this narrowband application, the wanted real-signal component is translated back to baseband in host DSP, while the unwanted image is rejected by the receive filtering. This reduces the RX transport bandwidth by approximately 50% and was sufficient to restore stable simultaneous RX/TX operation on the tested system. For end-to-end validation, I ran two WSJT-X instances. One generated the FT8 transmission, while the second acted as the receiver through the same SDR and ZynqRadio receive path. The second WSJT-X instance successfully decoded: CQ SV1EEX KM17 while RX and TX were active simultaneously. The bench validation was deliberately performed at very low RF drive, with no external power amplifier. The transmitter was configured with -30 dB hardware gain and 0.10 digital amplitude. I did not calibrate the absolute RF output level with a power meter, so I do not want to attach an unsupported dBm figure to the test. This was intended as a validation of the complete software, DSP, IIO and RF signal path using only enough local RF coupling for self-reception. It should not be interpreted as a demonstration of a complete high-power full-duplex RF front end. Appropriate isolation, attenuation, filtering and receiver protection would obviously be required when operating at significant transmit power. The project is now publicly available here: Source code, documentation and actual validation screenshots: https://github.com/z1000biker/ZynqRadio Current binary release: ZynqRadio v1.0.0 https://github.com/z1000biker/ZynqRadio/releases/tag/v1.0.0 A prebuilt Windows x64 package is provided with the release, so building from source is not necessary just to test the application. Current requirements / tested environment Windows 10 or 11 x64 .NET 8 WSJT-X 3.x Zynq-7000 + AD936x SDR accessible through libiio Windows libiio runtime Hamlib NET rigctl connection, normally 127.0.0.1:4532 48 kHz Windows audio path between WSJT-X and ZynqRadio The currently validated hardware is a Zynq-7010 + AD9364 Pluto-compatible board. The present full-duplex baseline uses: IIO sample rate: 2,100,000 S/s RX LO offset: 10,000 Hz RX transport: I-only RX buffer: 32,768 samples TX buffer: 131,072 samples TX Q polarity: +1 In my Windows test setup I used VB-CABLE for the receive audio path and Voicemeeter for the transmit audio path. These are simply convenient Windows audio-routing choices and are not inherent requirements of the SDR architecture. One current external dependency is the Windows libiio runtime, which is not bundled in the v1.0.0 ZIP and must be installed separately. I do not want to imply universal compatibility with every FPGA SDR or every IIO/AD936x image. At this point ZynqRadio should be considered a working engineering baseline for the tested Zynq/AD936x platform. I noticed the recent discussions on this list concerning external SDR bridges, including Pluto support, which encouraged me to post this implementation as another possible approach. I would be particularly interested in hearing from anyone working with Pluto/Pluto+, other Zynq/AD936x platforms, or with other FPGA-based SDR architectures such as Red Pitaya/StemLab, Hermes Lite or OpenHPSDR/ANAN. In particular, I would be interested in comparisons of how other implementations handle the WSJT-X interface, host/sample transport, and simultaneous RX/TX. Testing reports from other IIO-compatible Zynq/AD936x hardware would also be very welcome. 73, Nik, SV1EEX
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
