Awesome PocketSDR (snapshot positioning)

category: gnss

Table of contents

Introduction

At the high precision satellite positioning committee of the Institute of Positioning, Navigation and Timing of Japan (IPNTJ), Professor Tomoji Takasu of Tokyo University of Marine Science and Technology made a lecture entitled “An Open Source GNSS SDR: Development and Applications on Feb. 21st, 2022. The topics consisted of PocketSDR hardware, the L6 band satellite signal reception, the snapshot positioning, and the future plan of satellite receiver equipped with 14-element antennas array. Each of them are amazing contents that cannot be easily achieved. On the other hand, the source codes and the sample data have been disclosed and one can try them easily.

In this article, I tried snapshot positioning that I had never known before.

Snapshot positioning

Satellite positioning is achieved by simultaneous reception of radio waves from multiple satellites. The information that the receiver needs to calculate the coordinates are classified as:

information that requires signal observation (pseudo range), and
information that does not require signal observation but is decoded for position calculation (satellite position, satellite time, ionospheric delay correction, augmentation information, and so on).

Information that does not require signal observation is, for example, information transmitted in the order of 6 seconds or 12 minutes. Therefore, the receiver has to receive it without interruption during this period. However, this information does not necessarily have to be received by itself and can be obtained, for example, from cellular or internet channels.

Therefore, in principle, coordinates should be calculated by observing only the information that requires signal observation. This signal observation time may be short, and snapshot positioning is considered to be able to obtain coordinates even with a less than 100-millisecond observation, for example.

On page 13 of the Professor Takasu’s lecture material exemplifies the configuration of a snapshot intermittent receiver that receives only 20 milliseconds once a minute. It would operate on a single CR2032 button cell battery for over a year and it can record information to be calculated coordinates during this period on a single 32GB SD card. This power consumption includes the power consumption of the receiver module of MAX2769B, the power consumption of the microcomputer STM32L4 during operation and deep sleep, and the power consumption of SD card operation.

Snapshot GNSS receiver configuration (The figure is cited from page 13 of An Open Source GNSS SDR: Development and Applications)

So I tried this snapshot positioning using the sample data and Python code included in PocketSDR.

100-ms data file observed in the L1 band

The observation data used here is sample/L1_20211125_004000_12MHz_I.bin that is included in PocketSDR. The specifications of the data written in readme.txt file are as follows:

File Path   : L1_20211125_0040000_12MHz_I.bin
Date Time   : 2021-11-25 00:40:00 UTC
Duration    : 100 ms
Conf File   : pocket_L1L6.conf
Channel     : 1
F_LO        : 1572.420 MHz
F_ADC       : 12.000 MHz
Sampling    : I
F_IF        : 3.0 MHz
BW_IF       : 4.2 MHz

With this setting, PocketSDR takes 1 byte per sample and records data for 100 milliseconds at the rate of acquiring 12 megabytes per second. Therefore, the file size is 1.2 megabytes.

ls -l ../sample/L1_20211125_004000_12MHz_I.bin
-rw-r--r-- 1 sat staff 1200000  1 19 19:51 ../sample/L1_20211125_004000_12MHz_I.bin

If the sampling frequency is halved, the file size will be halved, and if the recording time is halved, the file size will also be halved.

To verify the GPS signal contained in this 100ms observation data, I used pocket_acq.py code in the python directory. I used a Macbook Air (Early 2015, Intel Core i7-5650U 2.2 GHz).

./pocket_acq.py -f 12 -fi 3 ../sample/L1_20211125_004000_12MHz_I.bin -prn 1-32

PocketSDR signal acquisition

Many GPS satellite signals have been observed. However, since the observation time is very short, we cannot track the signal of, for example, GPS PRN 5 satellite that has the strong signal.

./pocket_acq.py -f 12 -fi 3 ../sample/L1_20211125_004000_12MHz_I.bin -prn 5
TIME = 0.261 s

PocketSDR signal tracking with very short measurement

Snapshot coordinate calculation

We need navigation data in addition to the observation data for snapshot positioning. The navigation data is information that does not require signal observation, and is described satellite positions and satellite clock times. There are various ways to obtain this navigation data, but here I use the raw data obtained by the NovAtel OEM729 receiver in Hiroshima. We can download the 1-hour raw data from November 25, 2021 00:00:00 UTC (coordinated universal time) to 01:00:00 UTC, including this observation time.

curl https://phys.info.hiroshima-cu.ac.jp/gnss/oem7/202111/20211125a.gps -o 20211125a.gps

Next, we execute the RTKLIB application convbin to extract the navigation data 20211125a.nav and the observation data 20211125a.obs from this OEM729 receiver raw data.

convbin 20211125a.gps
input file  : 20211125a.gps (NovAtel OEM7)
->rinex obs : 20211125a.obs
->rinex nav : 20211125a.nav
->sbas log  : 20211125a.sbs

scanning: 2021/11/25 01:00:18 GREJCI
2021/11/24 23:59:30-11/25 01:00:29: O=3639 N=173 E=17

We place 20211125a.nav, for example, in sample directory.

The recording duration of this observation data file is 100 milliseconds, but pocket_snap.py with the default setting processes the observation data for 20 milliseconds from the beginning.

./pocket_snap.py -f 12 -fi 3 -nav ../sample/20211125a.nav ../sample/L1_20211125_004000_12MHz_I.bin -ts 2021/11/25-00:40:00
2021/11/25 00:40:39.722    35.87xxxxxxx  138.38xxxxxxx     1xxx.xxx    5    8
TIME (s) = 14.863

Amazing! The coordinates can be estimated observing for only 20 milliseconds. The result showed in the RTKLIB position format. The number 5 after the coordinate means single positioning solution, and the number 8 after the solution indicates the number of satellites used for positioning. The observation time was automatically corrected about 40 seconds behind as we specified. Here, some of the coordinate values are hidden.

This coordinate estimation method requires us to provide an approximate time. In pocket_snap.py, the rough time should be automatically set from the observation file name, but here it seems that the code could not accept the file name time, so I explicitly specify -ts option to provides the approximate time. The argument consists of the year, month, day, hour, minute, and second in UTC, and are separated by one of the :/- symbols.

If you provide the rough coordinates, you would obtain the coordinates in a shorter time. Given the rough coordinates with an option -pos, the computational time was significantly reduced.

./pocket_snap.py -f 12 -fi 3 -nav ../sample/20211125a.nav ../sample/L1_20211125_004000_12MHz_I.bin -ts 2021/11/25-00:40:00 -pos 35.87,138.38,1000
2021/11/25 00:40:39.723    35.87xxxxxxx  138.38xxxxxxx     1xxx.xxx    5    8
TIME (s) = 0.650

If the time difference is within a few minutes from the time that seems to be correct, the coordinates can be estimated. This is the result of providing a time that is 1 minute and 40 seconds ahead of the time already estimated.

./pocket_snap.py -f 12 -fi 3 -nav ../sample/20211125a.nav ../sample/L1_20211125_004000_12MHz_I.bin -ts 2021/11/25-00:39:00 -pos 35.87,138.38,1000
2021/11/25 00:40:39.723    35.87xxxxxxx  138.38xxxxxxx     1xxx.xxx    5    8
TIME (s) = 0.557

In addition, we can specify an output file name with the -out option to record the coordinate in the RTKLIB format along with the header and specifications.

% SNAPSHOT POSITION by POCKET_SNAP.PY
% INPUT FILE    : ../sample/L1_20211125_004000_12MHz_I.bin
% SAMPLING TIME : 20.0 ms / SNAPSHOT
% SAMPLING FREQ : 12.000 MHz
%  UTC                    latitude(deg) longitude(deg)    height(m)    Q   ns
2021/11/25 00:40:39.723    35.87xxxxxxx  138.38xxxxxxx     1xxx.xxx    5    8

I tried to extend the observation time to 100 milliseconds with the -tint option, because the observation file contains a signal for 100 milliseconds.

./pocket_snap.py -f 12 -fi 3 -nav ../sample/20211125a.nav ../sample/L1_20211125_004000_12MHz_I.bin -ts 2021/11/25-00:40:00 -pos 35.87,138.38,1000 -tint 100 -out aaa.pos
TIME (s) = 3.236

It took longer to calculate, and the coordinate values changed a little. Since snapshot positioning analyzes the coordinate after recording, this calculation time is not a problem.

Until now, we use GPS satellite only to obtain coordinates, but PocketSDR is capable of processing multi-GNSS signals. Therefore, I specify the satellite systems of GPS satellites G, the Quasi-zenith satellites J, Galileo satellites E, and BeiDou C with the -sys option. Snapshot positioning is very convenient because we can add or remove the target satellite systems during analysis.

./pocket_snap.py -f 12 -fi 3 -nav ../sample/20211125a.nav ../sample/L1_20211125_004000_12MHz_I.bin -ts 2021/11/25-00:40:00 -pos 35.87,138.38,1000 -sys G,J,E,C
2021/11/25 00:40:39.725    35.87xxxxxxx  138.38xxxxxxx     1xxx.xxx    5   23
TIME (s) = 5.191

The time required for positioning has increased, but the number of satellites used has increased to 23.

Now I would like to try this snapshot positioning with my own received data!

Conclusion

I tried snapshot positioning with PocketSDR sample data and Python code. It was fun to be able to obtain the coordinates with signal observation for only 20 milliseconds and a small amount of external information.

The topic of L6 band signal reception was also interesting. Signal tracking is performed by finding the time at which the known bit pattern and the received bit pattern match more. The key idea of L6 band signal reception in this PocketSDR is to make use of the similarity of the correlation calculation and the convolution calculation, the Fourier transform property of converting the convolution operation into the product operation, and the fixed pattern of the preamble. I will try to further understand this document and the L6 band reception code.