It turns out that Lime Micro had expected the board to be most useful for those developing cellular, WiFi, and other VHF/UHF applications, hence the lack of attention to the LF performance. This severe HF attenuation was primarily due to the input matching circuitry that had been optimised for higher frequencies. The HF performance of these initial units was very poor with a sensitivity drop of around 60dB at 10MHz with respect to the sensitivity at 100MHz. When the boards started being delivered, there was a distinct air of disappointment among those that were looking forward to exploring its HF potential. This resulted in the LimeSDR being perceived, by many, as a workable HF transceiver. The LimeSDR is an interesting SDR development board that has attracted plenty of attention, mainly due to its claim to be a dual-channel SDR transceiver with continuous coverage from 100kHz to 3.8GHz and a bandwidth of up to 61.44MHz! The publicity used at launch, and still on the Crowd Supply website, shows the LimeSDR compared to other well-established SDR receivers such as the HackRF One, Ettus B200 and RTL-SDR dongles.
#SDR RTTY DECODER ZIP FILE#
The only software missing from the zip file is the open-source Audacity audio recorder and editor and you can get that from here: I’ve just updated the zip file to add the QRM recording I made with the two RTTY stations spaced ☒50Hz from the test transmission. As per last month, I’ve made the tests easy for you to replicate by including all my test files and software in a zip file that’s available from my website at: The next interesting exercise will be to fine-tune the settings for each decoder to see if the performances can be improved. However, both decoders found the CCIR flutter tests particularly difficult and the best character error rate was close to 30%, which is a bit too high to be useful. This very clearly shows that FLDIGI handles close-in interfering signals a lot better than MMTTY. As a result, I’ve only shown the results for the CCIR Flutter propagation and the Mid-Latitude Moderate propagation simulations. Once I started experimenting with the respective levels of the wanted and QRM signals, it became very clear that 250Hz spaced QRM was a tough test. Although it may be a bit convoluted, this process provided an easily repeatable measurement source. To make the measurement, Audacity played the QRM and test signal tracks simultaneously through a Virtual Audio Cable to deliver the combined audio to the decoders. For each test session I used Audacity with track 1 loaded with the two-station QRM recording and track 2 loaded with the appropriate propagation distorted file. These two recordings were then level-adjusted and combined into a single file, again using Audacity.Īs with last month’s tests, the RTTY software was used with its default settings.
For the LF interferer, I repeated the process with the RTTY software tuned 250Hz below the wanted signal. I then used copy/paste to dump a long string of RYs into the transmit buffer and recorded the output using the Audacity audio editor. To make the QRM recordings I used RTTY software set to transmit and tuned 250Hz above the test frequency. For many of the comparisons, the test signal was significantly below the QRM stations. For the sake of clarity, the wanted signal is shown in its strongest state where it is just 10dB below the QRM signals. I’ve shown a spectrogram and waterfall display of one of the test signals in Fig. The audio tones of these two interfering stations were spaced 250Hz either side of the wanted station. I started with the same single signal test files as last month but created a second file that had a recording of two strong RTTY stations sending continuous RYs.
The aim, therefore, was to create a repeatable test file that could be applied to multiple decoders. The most obvious problem with contest operation is strong signals located very close to the wanted DX station. So, this month I wanted to expand the tests to more realistically simulate the conditions found during a RTTY contest. However, last month’s tests were focused on a single transmission with no QRM. Notably, MMTTY and others that use the MMTTY engine generally fare much better with flutter fading than FLDIGI. The results were interesting and confirmed my suspicions that you must choose your decoder to match the conditions. Those tests centred around the use of RF path simulation tools to synthesise a variety of common propagation conditions. Last month I spent some time making comparative tests between popular RTTY software.
#SDR RTTY DECODER PLUS#
This month Mike Richards G4WNC has more RTTY comparisons plus news on the LimeSDR.