Avian’s Blog

Looking back at my last few posts I feel that I was going into increasingly theoretic guesswork about the impedance mismatches in my rtl-sdr measurement setup. Even though I still think it could perform better, I would like to share some actual antenna measurements I made with it. I've also now got my hands on a NanoVNA-H, one of the many variants of the popular low-cost vector network analyzer. It's interesting to compare the measurement results between the two instruments.

Yesterday I've measured the VSWR of a few compact LTE antennas. These antennas have an adhesive backing and are meant to be mounted into mobile devices that use the cellular network for connectivity. All of these antennas come with a coax cable tail that terminates with a female U.FL connector. This was a bit problematic since both my instruments terminate in a SMA connector. So to make a connection I've used a U.FL-to-U.FL "thru" on a RF demo kit PCB I got with my NanoVNA and another short U.FL-to-SMA patch cable.

I've calibrated both my rtl-sdr setup (vect-meas-mux in the following) and the NanoVNA with the short-open-load one port method. I've used the U.FL calibration standards on the same RF demo kit. This resulted in the calibrated measurement plane on the U.FL end of the U.FL-to-SMA patch cable. Hence the measurements include effects of the "thru" and the coax cable tail that was attached to each antenna.

The vect-meas-mux setup consisted of the ERASynth Micro, rtl-sdr, my custom multiplex board and the Transverters RF bridge as the directional element. It allows measurements up to 2000 MHz, with a gap around 1200 MHz, defined by the rtl-sdr's tuning range. It's the same setup as I described in the past blog posts in this series. The NanoVNA-H was bought from Nooelec and the particular version I have is no longer listed on their website. It shows firmware version 0.4.5-1 and allows measurements up to 1500 MHz. I transferred the S11 measurements from the NanoVNA to the computer using code based on this example notebook and then calculated VSWR from S11.

In the graphs below, the VSWR measured with vect-meas-mux (orange) and NanoVNA (blue) is compared to the VSWR given in the datasheet (black) of the respective antenna. I was mostly interested in how both instruments agree with each other and how well the results were repeatable. The datasheet curve is there as a reference. I wasn't expecting to get a good match. I took care to have a reasonably clean measurement environment: as much open space in all directions around the antenna as possible, antennas mounted on a non-conductive plastic holder, etc. However obviously that can't compare with a measurement in an anechoic chamber and random objects in the vicinity were affecting the results. I also didn't use a choke on the coax tail to prevent it from radiating.

I'm pretty happy with how these measurements turned out. The results from my own instrument match those from the NanoVNA quite well. The agreement with the datasheet is often reasonably good as well although, as I said before, that's probably due to my poorly improvised environment around the antenna.

After doing many measurements the main problem with the rtl-sdr method turned out to be its slowness. NanoVNA displays the result nearly instantaneously. On the other hand a 200-point sweep from 55 to 2000 MHz with vect-meas-mux takes around 7 minutes and 30 seconds. Most of this is due to hugely inefficient way I collect signal samples from the rtl-sdr: I run the rtl_sdr binary once for each of the 200 frequency points. This results in the setup and tear down time of the rtl_sdr binary dominating the total run time. I only need to dwell on each point for about 100 ms, which would mean a sweep time of about 20 seconds. I'll probably rewrite my code to use the rtl_tcp server to fetch the I/Q samples, which should reduce the overhead significantly.

In the future I would also like to be able to estimate the error intervals of the measurement, like I did with my scalar experiments. Because this was a vector measurement and I used calibration, the relatively poor directivity of my RF bridge affected the results much less than with scalar measurements. A bigger factor was probably the limited dynamic range of the rtl-sdr. scikit-rf has some support for estimating error intervals, but I still need to figure out how to integrate that with my code.

I'm also looking for extending the frequency range of my measurements, but that will require switching to a more expensive SDR. Perhaps something like the HackRF or an USRP.

This is another update on my project where I'm developing a system for vector signal measurements with the rtl-sdr. Back in August I was testing the performance of the time multiplex board I made. One of the more puzzling things I discovered then was that apparently the signal losses in the multiplexer varied a lot with frequency. I measured a dip in signal level of almost 10 dB at 1700 MHz. I expected a mostly frequency-flat characteristic due to attenuation on the PCB and in the MMIC switches.

My first suspicion was that I messed up the design of the grounded co-planar waveguides (GCPW) on the board. After some research however I found conflicting information on that. Some sources say that my design is correct and others say it's not. I also got the impression that even if the trace dimensions I used were slightly wrong, they shouldn't result in the signal losses I was seeing due to relatively short trace lengths.

I currently don't have any professional RF equipment at hand. My gain (i.e. S12) measurements were done by using ERASynth Micro as a signal source and rtl-sdr as the detector. I measured the losses in the circuit board by routing the signal through the board, sweeping the signal in frequency at a constant output power, and recording the received power at rtl-sdr using rtl-power-fftw. I used a measurement of a male-to-male SMA through as a reference in an attempt to subtract any variability of ERASynth's output power and rtl-sdr's sensitivity.

Since I suspected that the variability in the gain I measured might also be due to impedance mismatches I did some further measurements with ERASynth and rtl-sdr to better understand what is going on. These measurements were performed in the same way as my previous one. ERASynth Micro was set to -40 dBm output level and was swept in steps from 55 MHz to 2 GHz. On each step, the rtl-sdr was tuned to the same frequency and the baseband signal power was measured with rlt-power-fftw (RF gain was set to 15 dB).

The picture below shows the six signal paths I measured:

"thru" measurement was a single rigid male-to-male SMA adapter. "thru3" was a combination of 3 adapters (male-to-male, female-to-female, male-to-male). "gcpw" was a measurement of a single leg of the PCB trace on a spare board where I soldered a SMA connector in place of the switch IC.

During the measurements involving the assembled multiplex board the switches were powered up and configured to allow the signal to pass in the measured direction. Also worth mentioning is that for measurements involving both PCBs, two male-to-male adapters were also in the signal path (one on the ERASynth side, the other on the rtl-sdr side).

Following graph shows the results. In contrast to the graph above from August, this graph is not normalized in any way and shows raw values returned by rtl-power-fftw. The gap between 1100 MHz and 1250 MHz is the band to which rtl-sdr can't tune to. The results for the "ref in - det out" path had +10 dB added on this graph to make it comparable with other traces since this path goes through a 10 dB attenuator on the board.

These results show several interesting things. The first good news is that the two identical paths through both switches show nearly identical results ("ref in - dut out" and "dut in - det out" traces). This is reassuring. It's unlikely that my board isn't soldered well or that I damaged one of the switches.

The other interesting part is that all other traces differ a lot from each other. Even just adding two adapters changes things significantly ("thru" and "thru3" traces). This suggests that the variability I was seeing is due to some mismatch between the ERASynth and rtl-sdr and not the fault in my board.

It's also telling that the only path that involves an attenuator ("ref in - det out") shows the least variability and also seems to be lower or equal to all other traces. The attenuator provides isolation between the source and the load and reduces the impact of their impedance mismatches. It changes the situation from the mismatched load and source (where gain varies with frequency) to a mismatched load and mismatched source separately (where gain does not vary with frequency). Also, in contrast to the GCPW traces, I'm pretty sure I got the 50 Ω impedance of the attenuator correct.

The measured power in the un-attenuated paths at frequencies above 1 GHz varies for about 8 dB. This translates to a product of reflection coefficients of ERASynth and rtl-sdr of about 0.4 (-7 dB). I don't have any data for ERASynth. The datasheet for E4000 tuner in the rtl-sdr states a typical return loss of 15 dB for a 50 Ω system, but my rtl-sdr has some components in front of the tuner which might make it worse. I measured the return loss of my rtl-sdr at about 11 dB at 70 MHz, so 7.3 dB at 1 GHz combined with ERASynth doesn't sound too much off.

In summary, this all points to the rtl-sdr's poor 50 Ω matching to be the culprit. There are some ways I could make the frequency response flatter. The simplest solution would be adding another attenuator to the board in front of the DET OUT connector. I'm using the lowest RF gain setting on the rtl-sdr so there should be enough reserve in terms of signal level. I don't want to do anything more elaborate like a rtl-sdr specific matching network since I want this board to be usable with other small SDRs as well.

Anyway, I think I'll leave the multiplex hardware as it is for now. I still have some planned improvements on the clock recovery code. I've also found Henrik's blog and his wonderful posts about the homemade VNA. His project is orders of magnitude more advanced than mine, but some of the details he writes about are still very useful for me. Thanks to him I found out about the scikit-rf Python library which I will gladly use instead of my home brew calibration code. I also found his directional coupler design very interesting and I might eventually make a copy of it to replace the RF bridge I'm currently using.