Does a LNA (Low Noise Amplifier) improve my GNSS Position Accuracy

LNA vs. no LNA

Why?

Some time ago I was working on a project where the GNSS (Global Navigation Satellite System) receiver get positions less than perfect. As the timeline was tight, we left out the GNSS question of how to improve it. Fortunately, it turned out to be good enough! But still, why was the GNSS position so bad? And is the advice to add an LNA from the GNSS receiver manufacturer valid?

And I want to build an LNA, just because (maybe) I can. My first thought was to build it around a transistor, but seeing all these LNA chips available for GNSS, I will just focus on the effect of the LNA on the position.

GNSS Receiver Design

As a basis for this experiment, the existing design was used. All unnecessary components were removed, resulting in the following design:

Schematic of the Receiver

The GNSS receiver is powered by 5V USB. Two low noise linear voltage regulators were used to produce 3.3V from the 5V. 3.3V is the supply for the GNSS receiver and the LNA. The receiver has a USB2.0 interface which is routed to the USB-C connector.

PCB Layout 3D View

On the right side of the PCB U.FL connectors are mounted to calibrate (open, close, load and through) the VNA (Vector Network Analyser). To compare the effect of an LNA, two variants of the board are made, one with and one without an LNA between the antenna and the GNSS module.

For the comparison, 6 boards are ordered, 3 with and 3 without LNA:

PCB’s with and without LNA

Measurement Setup

The six receiver boards are mounted on a wooden baseplate. All the boards are connected via a USB hub to a raspberry pi zero, which is used to control the boards and log the evaluated positions (NMEA messages) to an SD card.

Receiver setup on Board

The GNSS receivers are then placed on the roof of our office to get an optimal view to the sky. And since the setup is not 100% waterproof, there has to be looked for a nights without rain.

Receivers on Roof Top

Data Acquisition

In order to generate the data required for this comparison, a shell script is used. The script writes all the received NMEA messages from all the receivers to the file system. (It’s started through an SSH session, so don’t forget to use nohup, otherwise the script will end when the ssh session is closed).

Measurements

The devices were operated continuously for one night and one day, resulting in the generation of approximately 700 megabytes of log files. Each GNSS receiver sends one position recorded per second. Once all the data has been collected, an analysis of the logged data is then conducted. It is my intention to enhance my proficiency in the Python programming language and to limit my use of the receiver manufacturer’s software to a reference only.

The sky map is plotted for all GNSS modules, assuring that all receivers are working correctly. The sky map shows the path of every GNSS satellite and its Carrier to Noise Ratio ( C/No) during its overpass, based on the NMEA data extracted from the log files. (see GNSSAntennas_AppNote chapter 7.1 Sky View for further details.)

Sky Map for receiver 4 (LNA)

Carrier-to-Noise Ratio (C/No)

To test if the LNA has an impact to the measures of carrier-to-noise ratio, the average of all C/No values is calculated for each GNSS board. As a result, the C/No measured by the boards equipped with an LNA is in average 1.6dB higher than compared to the boards without LNA. Low elevation satellites do not influence this average. But does a better SNR lead to a more precise position?

Carrier-to-Noise comparison

Absolute Position

To check the accuracy of the position evaluated by the GNSS module, the absolute position of each GNSS module must be known first. This can be done with the help of different topographic online portals and it was possible to reach an accuracy of about 30cm.

The receivers are next to each other, the position needs to be corrected by an offset.  To be sure, it’s done the right way, the position of the receivers is plotted on Google Maps.

Receiver Position on Roof Top

An examination of at the plot entitled «Distance to Absolute Position», no difference can be seen between the accuracy of the device with LNA and those without. A more detailed examination of the mean position reveals that receivers 2 and 4 are approximately 1 metre off in longitude compared to the other receivers. Following the implementation of several experimental modifications, it was demonstrated that this offset is attributable to the orientation of the receiver.

Distance to Absolute Position

This has nothing to do with the LNA, so I move on to see if the receiver’s 95% of time has improved.

95% of Time Distance to Mean Position

95% of time distance to mean of one receiver

Looking at the 95% of time to mean for LNA and non-LNA receivers, the following picture emerges:

95% of Time Position Error

It is an improvement of about 63mm, which may not seem like much, but an improvement is an improvement.

Summary

As illustrated in the plot entitled «95% of time Distance to mean Position», the modules equipped with a LNA perform better than those without, but the difference of about 57mm is marginal. Adding a LNA does improve the accuracy of the position estimated by the GNSS module, but the benefit is negligible as long as the signal is strong enough, so with the used setup, the LNA is not worth the added complexity. However, in the event that the antenna must be of a smaller size due to other constraints or if the transmission path between the antenna and the module becomes longer, an external LNA may become a necessity.

Technical traps on the way

Often the more interesting part is where the traps are. Here is a short list of the traps I have triggered.

GNSS receivers not responding to read command

To identify which receiver a log file belongs to,  the Pi Zero sends a read command to the receiver and get the receiver number which is set. This worked on the laptop with a receiver next to it. Trying to port this into the logging script on the Pi Zero. I can’t get it to work, the receiver always sends a not acknowledge message. After too many hours I ask a friend to help me. We looked at all the settings and together we had an insight. The receivers do not respond to the read command until the value is set. This means that they do not send a default value or anything, in this case they send a no ack.

Choose the right Coordinate System

I didn’t pay too much attention to the coordinate system, and the first pick with the ECEF looked good with the x, y and z coordinates. The basic geometric calculation for distance correction did not correlate with the plots. The z plane is not the same as my flattened small scale surface. For what it’s need to calculate about distances and so on, the geographic coordinate (longitude and latitude) is just perfect.

Power Bank switches off

I like to use a power bank so I can place my setup wherever I want. But the power bank I have switches off after 24 hours. To make it easier, I used a long cable to the mains.

Went down a Rabbit hole

I wanted to write a Python script to automatically generate a measurement report from a set of overnight log files. As I use Confluence, I thought this would make sense to generate it direct as a Confluence page. Yes, it makes sense and it is nice to see it working. But it was not done in an hour.

Time consuming Tasks

• Loading a log file into the manufacturer’s tool took over 6 hours.
• Reading all the log files with an existing GNSS Python library takes still an hour. Hopefully I can find time to commit my changes to make it 20x faster.