Hardware – Page 3 – Daniel Estévez

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.

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.

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.

Calibrating the Hermes-Lite 2.0 beta2 in Linrad

Lately, I have been trying to make an amplitude and phase calibration of my Hermes-Lite 2 beta2 in order to use Linrad’s smart noise blanker. This is quite a task because Linrad doesn’t support the Hermes-Lite 2 directly. Today I’ve finally managed to do it. Here I describe all my setup and calibration results.

Testing a simple pulse generator for Linrad calibration

Lately, I’ve being talking with Juan Antonio EA4CYQ and Pedro EA4ADJ about performing Linrad calibration to enable the use of the smart noise blanker. They pointed me to the SIGP-1 by Alex HB9DRI, which is a 144MHz pulse generator with which I was already familiar, and a simpler pulse generator by Leif SM5BSZ which I hadn’t seen before.

Leif’s generator is very simple. It uses a 555 timer to generate a square wave, a 74AC74 flip-flop to divide the frequency of the square wave by 2 and obtain a precise 50% duty cycle, a 74AC04 inverter as a driver, and capacitive coupling to turn the edges of the square wave into RF pulses. Alex’s SIGP-1 is an improvement over Leif’s design. It generates the square wave in the same manner, but then it uses a helical bandpass filter for 144MHz with around 5MHz bandwidth to convert the square wave into 144MHz pulses, and a PGA-103+ MMIC RF amplifier and a BFR91 RF NPN transistor as a class A amplifier to increase the output level. The SIGP-1 has two main advantages over Leif design. The output is stronger, so the S/N of the pulses is higher, and the filtering helps prevent saturation in the receiver. However, Leif’s design uses only simple components and it’s adequate in many cases.

I have built and tested Leif’s generator and used it to calibrate my FUNcube Dongle Pro+ at 144MHz. I’ve also tried doing the calibration at other frequencies and it also works well, but the pulses are not very strong at 432MHz and above.

Improving phase noise performance of the DF9NP 27MHz PLL

In some of the latest posts, I’ve being talking about the phase noise performance of 10GHz receivers, and in particular, of 27MHz references for Ku-band LNBFs (1, 2, 3, 4). Indeed, this started when I checked the performance of my new 10MHz GPSDO and 27MHz PLL by DF9NP and I wasn’t too happy with the phase noise.

After working with Dieter DF9NP in investigating this problem and performing several tests, Dieter found that the problem was likely in the loop bandwidth of the 27MHz PLL. The loop filter bandwidth is 50kHz. He proposed the following component modifications to change the bandwidth to 300Hz.

Update 2018-10-21: Dieter tells me that this problem has been solved in the new units he is selling, so the performance of the new units should be good.

Modification of the PLL loop (new values in red) — Modification of the PLL loop filter (new values in red)

After I performed the modifications, I was quite surprised and happy with the results. As always, I’ve used the beacon of BADR-5 at 11966.2MHz to test the phase noise performance. Linrad’s AFC is in use. The result is below. As you can see, it is as good as the best references that I had tested before.

For comparison, this was the performance before the modification. The difference is huge. Many thanks to Dieter for his effort and to Luis EA5DOM, who also participated in the discussion and gave some good advice.

Using the CC1101 and Beaglebone black for IP traffic on 70cm

Lately, I have been experimenting with using a CC1101 chip together with a Beaglebone black single board ARM computer to transmit IP traffic over the 70cm Amateur band. There has been a similar project from OEVSV, but I’ve never seen this project reach a final form. Edouard F4EXB has some code that uses the Raspberry Pi instead. Presumably, this will suffer from problems when using the higher data rates supported by the CC1101, as his software is not real-time.

The goal of my project is to build an affordable 70cm IP transceiver with a power of a few Watts. This can be used in the Hamnet Amateur Radio IP network. The modulation should not use more than a couple of hundreds of kHz’s of spectrum, as it doesn’t seem very sensible to take up much more spectrum in the 70cm band. Although the usual maximum bandwidth in the 70cm band is 20kHz, the IARU R1 bandplan allows for wideband experiments around 434.000MHz. A data rate of 128kbps with MSK modulation seems about right, as it uses roughly 200kHz of spectrum. Further on-the-air tests will perhaps change these parameters a bit.

Adjusting TX gain in the FT-817ND

If you’ve been following my latests posts, you’ll know that during the last V-UHF contest I detected reduced output power on the 70cm band in my FT-817ND. The output power was only about 60% of the maximum 5W in SSB and CW, but in FM mode it reached 5W. This problem only happened on the 70cm band. On all the other bands, the radio reached 5W output power in every modes. After spending some time studying the service manual, I came to the conclusion that the problem was that TX gain in the UHF band was too low. This is a software calibration parameter, so, in the end, fixing this problem has been rather easy.

Replacing the fuse F1002 in the FT-817ND

On last Saturday’s V-UHF contest I observed reduced output power on the 70cm band in my FT-817ND. I spent the next day poking inside the radio with the oscilloscope trying to see where the problem was. While doing this, at some point I completely lost output power in all bands. I found that the problem was that F1002, an SMD fuse, had gone open. Here I describe said fuse and the replacement procedure, which I found much easier than I thought.

Building the OCXO/Si5351A kit from QRP Labs

Some posts ago, I spoke about the possibility of using the OCXO/Si5351A synth kit from QRP Labs as a low cost way of providing an external stable 27MHz reference to a satellite LNBF. I’ve received and built my kit some days ago, so here I will be looking at some aspects in the construction and performance of this kit.

Calibrating the S-meter in Linrad

In a previous post, I talked about the GALI-39 amplifier kit from Minikits. Here I will describe the procedure to calibrate the S-meter in Linrad (or another SDR) using this amplifier or any other amplifier with a known NF and an uncalibrated signal source. Leif Åsbrink has a youtube video where he speaks about the calibration of the S-meter in Linrad. However, he doesn’t use an amplifier, so I will be following a slightly different procedure.