The LimeRFE is intended to work as an RF frontend for the LimeSDR family, although it can work coupled with any other SDR or conventional radio. As such, it has power amplifiers, filters and LNAs designed to cover the huge frequency range of these SDRs. It is designed to cover all the Amateur radio bands from HF up to 9cm, and a few cellular bands.
As anyone will know, designing broadband RF hardware is often quite difficult or expensive (Amateur radio amplifiers and LNAs are usually designed for a single band), so packing all this into a single unit is a considerable feat. The output power on most bands is around a couple watts, which is already enough for many experiments and applications. The block diagram of the LimeRFE can be seen below.
In this post I show a brief overview of the LimeRFE and demonstrate its HF transmission capabilities by showing a WSPR transmitter in the 10m band, using a LimeSDR as the transmitter.
The IARU R1interim meeting is being held in Vienna, Austria, on April 27 and 28. This post is an overview of the proposals that will be presented during this meeting, from the point of view of the usual topics that I treat in this blog.
The proposals can be found in the conference documents. There are a total of 64 documents for the meeting, so a review of all of them or an in-depth read would be a huge work. I have taken a brief look at all the papers and selected those that I think to be more interesting. For these, I do a brief summary and include my technical opinion about them. Hopefully this will be useful to some readers of this blog, and help them spot what documents could be more interesting to read in detail.
Many Amateur radio operators are familiar with the effects of the ionosphere at HF frequencies. However, the effects of the ionosphere are also noticeable at much higher frequencies. In particular, at L band, which is used by most satellite navigation systems. Thus, GNSS receivers can be used to measure ionospheric parameters. These measurements are usually distributed as TEC maps in IONEX files.
Here I describe some basic ionospheric physics, how a GNSS receiver can measure the ionosphere, and give some Python code to study TEC maps in IONEX files. Then I use TEC maps to study the CODAR ionospheric observations I did in December last year.
A few weeks ago I posted how I make wideband recordings of bandscope data with my Hermes-Lite 2. In that post, I sort of promised to do a small analysis of the waterfall I showed. After being busy with other things (PicSat’s launch among them), I’ve finally had time to write something up.
Over the last few days, I have been recording CODAR on 4463kHz to produce images of the ionosphere. I started on Friday 15th and the plan was to leave the recording running until Christmas Day, thus producing some kind of “CODAR advent” images. Unfortunately, there seems to be a problem when the receiver runs for several days that results in the sudden loss of the CODAR signal. This problem can be seen at the bottom of the image below. Thus, I have finished the recording on the morning of the 24th. The equipment and software used is the same that I detailed in a previous post.
CODAR is an HF radar used to measure surface ocean currents in coastal areas. Usually, it consists of a chirp which repeats every second. The chirp rate is usually on the order of 10kHz/s, and the signal is gated in small pulses so that the CODAR receiver can listen between pulses. The gating frequency can be on the order of 1kHz.
CODAR can be received by skywave many kilometers inland. Being a chirped signal, it is easy to extract the multipath information from the received signal. In this way, one can see the signal bouncing off the different layers of the ionosphere, and magnificent pictures showing the changes in the ionosphere (especially at dawn and dusk) can be obtained. For instance, see these images by Pieter Ibelings N4IP, or the image at the top of this post, which contains 48 hours worth of CODAR data.
Here I describe my approach to receiving CODAR. It uses GNU Radio for most of the signal processing, and Python with NumPy, SciPy and Matplotlib for plotting.
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.
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.
Last week I did an experiment where I transmitted WSPR on a fixed frequency for several days and studied the distribution of the frequency reports I got in the WSPR Database. This can be used to study the frequency accuracy of the reporters’ receivers.
I was surprised to find that the distribution of reports was skewed. It was more likely for the reference of a reporter to be low in frequency than to be high in frequency. The experiment was done in the 40m band. Now I have repeated the same experiment in the 20m band, obtaining similar results.
Meanwhile, I have used a variation of my usual Python script to plot waterfalls of the recording. Below you can see waterfalls for the 3 bands. They use the same scaling, with a dynamic range of 50dB, so it is easy to see how the noise floor changes per band. The carriers of the strongest broadcast AM stations are clipped. The resolution in these waterfalls is 187.5Hz or 15s per pixel.
I have also taken a high resolution waterfall around the WWV carrier at 10MHz. The resolution is 22.9mHz or 65.5s per pixel, and the frequency span is 19.95Hz.
Near the centre of this waterfall, two signal can be seen. The signal which is concentrated in frequency is leakage from my 10MHz GPSDO. The signal which is spread out in frequency is the carrier of WWV, probably mixed with BPM. I’m not sure about the identity of the signal below them, which is about 5Hz below 10MHz. I suspect that it is JN53DV.
This waterfall shows that the 500ppb TCXO of my Hermes-Lite 2.0beta2 is stable to a few tens of parts per billion, as I remarked in my WSPR study.
Last weekend, I recorded the full EAPSK63 contest in the 40m band with the goal of monitoring IMD levels. I made a 48kHz IQ recording spanning the full 24 contest hours (from 16:00 UTC on Saturday to 16:00 UTC on Sunday). This week I’ve been playing with making waterfall plots from the recording. These are very interesting, showing patterns in propagation and contest activity. Here I show some of the waterfalls I’ve obtained, together with the Python code used to compute them.