Awesome PocketSDR (snapshot positioning)
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.
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.
(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
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
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
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
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!
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.
- Galileo E6B signal reception with Pocket SDR, a open source software-defined radio 27th January 2023
- Failure in reflow soldering 19th January 2023
- Pocket SDR hardware production (part 3) 30th September 2022
- Pocket SDR hardware production (part 2) 14th September 2022
- Pocket SDR hardware production (part 1) 4th September 2022
- Awesome PocketSDR (order of hardware parts) 9th April 2022
- I want to use bladeRF with PocketSDR AP, part 2 16th March 2022
- I want to use bladeRF with PocketSDR AP 5th March 2022
- Awesome PocketSDR (reducing processing time with FFTW) 19th February 2022
- Awesome PocketSDR (L6 band signal decode) 19th January 2022
- Awesome PocketSDR (pocket_trk) 28th December 2021
- Awesome PocketSDR（pocket_acq） 4th December 2021