Category: Hardware

Designing, building and testing amateur radio hardware.

NPR: Hamnet over 70cm

Some days ago, Guillaume F4HDK emailed me to introduce me his latest project, NPR (New Packet Radio). This is an open-source modem designed to carry IP traffic over the 70cm Amateur radio band, with data rates of up to 500kbps. The goal of this modem is to be used for the Hamnet Amateur radio IP network, to give access to end users where coverage on the 2.3GHz and 5GHz bands is poor due to the terrain.

Guillaume knew that I had worked on IP over 70cm with my CC1101 and Beaglebone black project, so he wanted to know what I though about NPR. After reading all the available documentation, I found NPR very interesting. Indeed, Guillaume has come up with clever ways of solving some of the difficulties I foresaw when planning out my experiments with the CC1101.

The most important aspect about NPR is that it is already a finished product that people can build as a kit and start using. My experiments with the CC1101 were a mixture of proof of concept and play around, and never progressed from that stage due to lack of interest in my local Amateur community. However, Guillaume has put a lot of time, thought and effort in developing NPR. Of course the project can evolve further, but it is usable in its present stage. In what follows, I do a detailed analysis of the technical aspects of NPR.

Continue reading NPR: Hamnet over 70cm

New dish for Es’hail 2 reception

I have replaced the dish I had for receiving Es’hail 2 by a new one. The former dish was a 95cm offset from diesl.es which was a few years old. I had previously used this dish for portable experiments, and it had been lying on an open balcony for many months until I finally installed it in my garden, so it wasn’t in very good shape.

Comparing with other stations in Spain, I received less transponder noise from the narrowband transponder of QO-100 than other stations. Doing some tests, I found out that the dish was off focus. I could get an improvement of 4dB or so by placing the LNB a bit farther from the dish. This was probably caused by a few hits that the dish got while using it portable. Rather than trying to fix this by modifying the arm (as the LNB couldn’t be held in this position), I decided to buy a new dish.

Continue reading New dish for Es’hail 2 reception

Recommendations for receiving Es’hail 2

A couple days ago, Janos Tolgyesi HG5APZ asked me by email about different hardware setups to receive the Amateur radio transponders on Es’hail 2, with an interest on inexpensive but effective solutions. He was quite happy with my detailed reply and convinced me to turn it into a blog post, so that other people can learn from it.

This post is intended for people that do not know much about Es’hail 2 but are interested in receiving it. If you’ve been investigating about the different setups that people are doing to receive it, then probably you’ll not learn anything new here. The post addresses questions such as “do I need a modified LNB” and similar.

Continue reading Recommendations for receiving Es’hail 2

Weird repair of the day: u-blox LEA-5S I2C interface

I have a DF9NP 10MHz GPSDO that is based on a u-blox LEA-5S GPS receiver. Essentially, the LEA-5S outputs an 800Hz signal that is used to discipline a 10MHz VCTCXO with a PLL. The LEA-5S doesn’t have persistent storage, so an I2C EEPROM is use to store the settings across reboots.

Lately it seemed that the reading of the settings from the EEPROM had failed. The u-blox was always booting with the default settings. This prevents the GPSDO from working, since the default for the timepulse signal is 1Hz instead of 800Hz. Here is the summary of my troubleshooting session and the weird repair that I did.

Continue reading Weird repair of the day: u-blox LEA-5S I2C interface

Flashing a Vaisala RS41 radiosonde

The Vaisala RS41 radiosonde is a weather radiosonde that is currently being launched in Madrid Barajas and other sounding sites in Spain, Europe and Australia. I have already spoken about how to decode it. One of the most interesting aspects of this model is that the RS41 contains a STM32F1 ARM Cortex-M3 microcontroller, a SiLabs FSK transmitter, and a uBlox GPS receiver, whereas the older RS92 contained custom ASICs to perform these functions. Thus, it is easy to reflash this radiosonde and write custom firmware for it, giving a lot of possibilities for experimentation.

In STARcon 2018, Julián Santamaría from AEMET (the Spanish meteorological office) gave me an RS41. While I have some long-term ideas about how to use it as a propagation sounder, I have just started playing with it. In this brief note, I explain how to flash the radiosonde with custom firmware.

Continue reading Flashing a Vaisala RS41 radiosonde

Interfacing the Hardrock-50 HF amplifier to the Hermes-Lite 2

Since several months ago, I’m operating my HF station “remotely” from another room in the house. The station consists of a Hermes-Lite 2.0 beta2, a Hardrock-50 HF amplifier, and an outdoor MFJ-993BRT antenna tuner. My plan is to operate all of this from a laptop with ethernet connection from anywhere in the house.

The Hermes-Lite poses no problem, since it is always controlled by ethernet only. However, I need to be able to operate the Hardrock amplifier remotely: I need to change the bands, which is usually done via buttons on its front panel, and to check the output power and SWR, if only to be sure that the antenna tuner has found a tuning solution. This is usually done by looking at the Hardrock front panel display or by looking at a Diamond SX20C power/SWR meter that I also have installed in the shack.

I have taken advantage of the holidays to finish making all of this controllable by ethernet. Here I describe my solution.

Continue reading Interfacing the Hardrock-50 HF amplifier to the Hermes-Lite 2

Building a feedline HF choke

My current HF antenna is a long wire (around 15 or 20m) connected to an MFJ-993BRT outdoor automatic antenna tuner. The tuner is fed with around 25m of M&P Airborne 10 coaxial cable which runs into the shack. When I installed this antenna, I suffered from high RF currents on the outside of the coax shield when transmitting. These currents go into the shack trying to find a path to earth, since this kind of antenna needs good grounding. Also, while receiving, the coax carried lots of interference into the antenna, especially in the lower bands.

I tried to mitigate this problem by installing a ground rod besides the tuner. This is 2m a copper tube with 50cm buried in the ground. The top of the tube is connected to the tuner ground with a short cable. After installing the ground rod, approximately half of the RF current flowed into the ground rod and the remaining half kept flowing into the shack via the coax shield.

To measure RF current, I have been using a clamp on meter. My design is similar to the design by Ian GM3SEK, but I measure voltage across the output capacitor with a multimeter instead of using a resistor and ammeter coil.

Now I have built and installed a feedline choke following the design of the mid-bands choke by GM3SEK. I use 4 turns of M&P Airborne 5 coax through 3 Fair Rite 2643167851 material 43 cores, wound as an 85mm coil. The finished choke can be seen below.

HF feedline choke

I have measured the performance of the choke using my Hermes-Lite2 beta2 in VNA mode, as I already did with my mains choke. The results are shown below.

The performance seen in these graphs matches the performance measured by GM3SEK in his document. The choke has a resistance of over 1000 ohms on most of the Amateur HF bands, and up to 5000 ohms in the middle bands.

I have installed the choke directly on the input of the tuner. The RF current flowing on the outside of the coax shield has now decreased to around 2% in several cases and 10% in the worst case. The interference received in the lower bands has also decreased noticeably.

Published
Categorised as Hardware Tagged

Quick fixes for some bugs in LimeSDR drivers

These days I have been experimenting with my LimeSDR board. This is an SDR board based on the LMS7002M transceiver chip. The drivers for the LimeSDR are called LimeSuite. This bundle contains a SoapySDR driver called SoapyLMS7, which makes the LimeSDR accessible through SoapySDR and also in GNU Radio through gr-osmosdr; some lower level drivers for the LMS7002M chip; and a GUI called LimeSuiteGUI that allows one to play with all the settings and parameters of the LMS7002M by hand.

In my tests I have come across a couple of driver-related bugs which I find quite annoying. This is not surprising, as the LMS7002M is a very complex piece of hardware and the LimeSDR drivers must control a huge number of settings and parameters and provide different interfaces to access the SDR hardware. I have reported them in the GitHub issues page of LimeSuite, but there are many other bugs open and LimeSuite is still seeing heavy development, so it doesn’t look likely that they will be fixed very soon.

To overcome this bugs, I have done some workarounds. Rather than trying to find the root cause of the problem, these disable the part of the software that is not working as it should. These workarounds are in the dirtyfixes branch of my LimeSuite fork.

The first bug I found was related to the baseband filter. This filter has a selectable bandwidth. Some bandwidths didn’t work properly, because the passband was far from flat or the cut-off frequency was way off. Moreover, just changing the bandwidth slightly sometimes produced a very different filter shape. I have been tweeting some pictures showing this effect (see also my replies to this tweet). I’ve found that the reason for this is that the parameters to tune the filter are usually cached by the drivers in order to save computations, but this cache system doesn’t work properly. My workaround is to disable the cache and always compute the filter parameters.

The second bug is related to DC spur hardware removal. We are used to the fact that many IQ SDR hardware have a (sometimes huge) DC spur in the centre of the passband, due to several hardware imperfections. This is also the case for the LimeSDR, but the LMS7002M has a hardware system (called RX DC correction) which is quite effective at removing the DC spur. I noted that DC spur removal was much better in LimeSuiteGUI than in GNU Radio or SoapySDR based applications. You can see the difference here. At first, I thought that this was an issue with the IQ calibration. However, it turns out that the RX DC correction was always being disabled by the SoapyLMS7 driver, even though it was supposed to be enabled by default. The reason for this is that a lower-level function from the LMS7002M seems to lie and says that the RX DC correction is disabled, even though it is not. I have bypassed this lower-level function in my workaround. You can see the effects of RX DC correction here.

Update: The second bug has just been fixed. It seems that the DC_BY_RXTSP bit that controls the RX DC correction was being overwritten somewhere else in the TX setup code because of a typo. I have reverted the workaround in my “dirtyfixes” branch and merged the proper fix. This branch still contains the workaround for the lowpass filter calibration.