Latest Posts
RTTY and Lime SDR
This month Mike Richards G4WNC has more RTTY comparisons plus news on the LimeSDR. He begins with RTTY.
This month Mike Richards G4WNC has more RTTY comparisons plus news on the LimeSDR. He begins with RTTY.
Last month I spent some time making comparative tests between popular RTTY software. Those tests centred around the use of RF path simulation tools to synthesise a variety of common propagation conditions. The results were interesting and confirmed my suspicions that you must choose your decoder to match the conditions. Notably, MMTTY and others that use the MMTTY engine generally fare much better with flutter fading than FLDIGI. However, last month’s tests were focused on a single transmission with no QRM. So, this month I wanted to expand the tests to more realistically simulate the conditions found during a RTTY contest. The most obvious problem with contest operation is strong signals located very close to the wanted DX station. The aim, therefore, was to create a repeatable test file that could be applied to multiple decoders.
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 audio tones of these two interfering stations were spaced 250Hz either side of the wanted station. I’ve shown a spectrogram and waterfall display of one of the test signals in Fig. 1. For the sake of clarity, the wanted signal is shown in its strongest state where it is just 10dB below the QRM signals. For many of the comparisons, the test signal was significantly below the QRM stations. To make the QRM recordings I used RTTY software set to transmit and tuned 250Hz above the test frequency. 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. For the LF interferer, I repeated the process with the RTTY software tuned 250Hz below the wanted signal. These two recordings were then level-adjusted and combined into a single file, again using Audacity.
As with last month’s tests, the RTTY software was used with its default settings. 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. 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. Although it may be a bit convoluted, this process provided an easily repeatable measurement source.
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. As a result, I’ve only shown the results for the CCIR Flutter propagation and the Mid-Latitude Moderate propagation simulations. You can see these results in Figs. 2 and 3. This very clearly shows that FLDIGI handles close-in interfering signals a lot better than MMTTY. 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. The next interesting exercise will be to fine-tune the settings for each decoder to see if the performances can be improved. 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:
I’ve just updated the zip file to add the QRM recording I made with the two RTTY stations spaced ±250Hz from the test transmission. The only software missing from the zip file is the open-source Audacity audio recorder and editor and you can get that from here:
LimeSDR – Update and Warning
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. This resulted in the LimeSDR being perceived, by many, as a workable HF transceiver. When the boards started being delivered, there was a distinct air of disappointment among those that were looking forward to exploring its HF potential. 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. This severe HF attenuation was primarily due to the input matching circuitry that had been optimised for higher frequencies.
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. Lime have since tried to placate the disappointed early buyers by offering a refund and they have also published some modifications to improve the LF performance. The simplest of these was to remove a low value (8.2nH), parallel, inductor that was shunting low frequency signals to ground. While the modifications have significantly improved the HF performance, the sensitivity at LF remains very poor. However, there are further issues linked with the practicality of trying to receive weak HF signals with a wide IF bandwidth and an analogue first mixer.
Like all direct-conversion or low-IF SDR receivers, the first mixer performance is crucial because it can be exposed to strong out-of-band signals. That risk is even greater with the LimeSDR because you can, for example, set a 30MHz IF bandwidth (requires USB3 connection), thus exposing the mixer to the all the signals in the 0 to 30MHz range. In addition to the potential problems in the mixer, the LimeSDR uses 12-bit ADCs so the dynamic range is also limited. While it is still possible to use the LimeSDR as an HF transceiver, it will require some careful filtering to tame the performance. The important point to note here is that the LimeSDR is, and has always been, intended as a development board and not a ready-to-go radio transceiver. I think their advertising was poorly thought through, but they did offer refunds to early buyers once the problems had been identified. If you are considering purchasing a LimeSDR for HF, make sure you ask for a factory-modified version. The learning point here is to be wary of claims that seem to be too good to be true – they probably are!
Practical Lime
While it’s important to appreciate what the LimeSDR can’t do, it is still a very useful board, providing you work within its limitations. If you want to use it as an HF receiver, the best solution is to use an upconverter to shift the 0-30MHz range to a higher frequency. There are plenty of upconverters on the market such as the popular Spyverter or NooElec Ham-It-Up units, but my favourite is the design produced by Makis SV1AFN. This uses a 200MHz up-conversion oscillator and transposes the entire 0 to 55MHz band segment up to 200-255MHz. By 200MHz, the LimeSDR sensitivity has levelled-out, so you get the best overall performance. The upconverter also includes a 55MHz lowpass filter on the input and a 200MHz diplexer on the output. The theory here being that the wanted 200MHz to 255MHz signals pass from the mixer to the output, while the unwanted mixing products pass through the other leg of the diplexer and are dissipated in a 50Ω matching resistor. This, unusual, approach is intended to stop unwanted mixing products from being reflected back to the mixer and causing more mayhem. The upconverter also has a switchable RF preamplifier but you should use this sparingly. Full details of the SV1AFN up-converter can be found here:
When I received my LimeSDR, I decided it had to have a case and opted to build my own enclosure because the official cases were exorbitantly expensive (The official Lime aluminium case costs $300!). I found a suitable design on the Element-14 website and used the suggested extruded aluminium case (Farnell 248-1095) along with a small blower and heatsinks for the main chips, Figs. 4 and 5. The blower was a tiny unit from Farnell (101-2796) that was designed for 12V operation but runs almost silently at 5V and provides sufficient air movement to stabilise the LimeSDR chip temperatures.
Future Benefits
The real benefits of the LimeSDR architecture come to the fore when used for more demanding VHF/UHF signal processing and a prime example is DATV (Digital Amateur TeleVision). Until the release of the LimeSDR, DATV enthusiasts had to build their own hardware from scratch, which can be both expensive and requires a high level of specialist knowledge. A good example being the DATV Express units produced by BATC (British Amateur Television Club). The LimeSDR makes an ideal platform for DATV because it has a wide bandwidth transceiver along with an onboard FPGA that can handle the specialist processing. There is still a requirement for some specialist software skills but the availability of a flexible hardware platform is a big step forward. The LimeSDR makes it relatively easy to experiment with new designs and features, thus bringing all the benefits we’d expect to see from SDR hardware. Lime Microsystems also have an add-on board in the pipeline that will extend the frequency coverage up to the 10GHz amateur band using their LMS8001 companion board.
If you want to start small, the LimeSDR Mini uses the same Lime transceiver chip as the LimeSDR but employs a smaller FPGA (Field Programmable Gate Array) and covers 10MHz through to 3.5GHz with a single RF input and output. The price of this unit is $139 plus $10 international carriage, making a total of $149, equating to approximately £110, which is quite tempting. I’ve got one on order so expect to hear more later. There is also a big push for the LimeSDR Mini to be used in education and they recently launched a new Scratch library that enables programming of the LimeSDR Mini on a Raspberry Pi with Scratch 2 block programming language. You can find more on the LimeSDR Mini at:
www.crowdsupply.com/lime-micro/limesdr-mini
This article was featured in the July 2018 issue of Practical Wireless