Assistance with SNAP decoding

[JonasBchrt]

I received a question via email, which I will comment on here. The question:

Hello,

I am looking for assistance with SNAP data generated a device that is no longer supported: the narrative clip 2. It captures SNAP data alongside images. I have the following information from the previous version of the device (narrative clip 1):
"The Narrative Camera uses the Cellguide ACLYS GPS Frontend. The .snap files are raw 1-bit I/Q GPS data, and have a size of 131,072 bytes, with a sampling frequency of 1024 Mhz (ref: Off-Board Positioning Using an Efficient GNSS SNAP Processing Algorithm and the help of the aclys_snap program on the Narrative indicates a default length of 512ms). As a result, the .snap file contains 524,288 I/Q samples."

The SNAP file generated is 64 KiB (instead of the 128 KiB from the previous device) so I am assuming that the length was reduced by half also to 256ms.

I am attempting to run 'backend.py' process_snapshots from here: https://github.com/SnapperGPS/snappergps-backend/blob/40e563873f36ddfe033aa5dca89f1c378e83453a/core/backend.py

I am loading the SNAP file like this:

snapshot = np.fromfile('20240220_215359_000.snap.bin', dtype = np.dtype('B'))

The error I am facing makes me think that the data is not in the correct format to be processed:

  File "/home/username/Downloads/snap/core/eph_util.py", line 3161, in acquisition_simplified
    x = (np.repeat(replicas_f, n_bins, axis=0) * signals).astype(np.csingle)
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
ValueError: operands could not be broadcast together with shapes (371,512,1,4092) (371,512,1,1024)

Do you have any suggestions on how I could confirm the sampling frequency and duration? Does your code support raw 1-bit I/Q GPS data? If not, is it possible to convert to a suitable format? Any and all help would be greatly appreciated.

Thank you,

[JonasBchrt]

This sounds like an interesting, but challenging task. While it should theoretically be possible to apply another snapshot processing toolchain to the data of concern, I believe it is challenging due to the limited amount of information available about the data and the hardware.
Some comments:

The first of piece of relevant information would be the data storage format. The way how SnapperGPS stores its raw data is described here:

Each snapshot is in a single binary .bin file with a name derived from the timestamp. One byte of the file holds the amplitude values of eight signal samples, i.e., the first byte holds the first eight samples. A zero bit represents a signal amplitude of +1 and a one bit a signal amplitude of -1. The order of the bits is 'little', i.e., reversed. For example, the byte 0b01100000 corresponds to the signal chunk [1 1 1 1 1 -1 -1 1].

It can be read from file with:

# How many bytes to read
bytes_per_snapshot = int(4092000.0 * 12e-3 / 8)
# Read binary raw data from file
signal_bytes = np.fromfile(filename, dtype='>u1',
                           count=bytes_per_snapshot)
# Get bits from bytes
# Start here if data is passed as byte array
signal = np.unpackbits(signal_bytes, axis=-1, count=None,
                       bitorder='little')
# Convert snapshots from {0,1} to {-1,+1}
signal = -2 * signal + 1

It is possible that your device stores the data in a different format. Maybe try big for the bit order, too.

Secondly, it is in general correct that SnapperGPS also works with raw 1-bit I/Q data. However, there are a few more signal parameters that can cause discrepancies:
Firstly, the sampling frequency. SnapperGPS samples at 4.092 MHz while your device samples at lower 1.024 MHz, a quarter. This may cause the error you mentioned. The problem there is that the code generates signal replicas with a length of 1 ms, which results in signals with 4092 bits, while the incoming signal seems to be 1024 bits.
Secondly, the signal length. SnapperGPS records 12 ms, while your device records much more data.
Both parameters (sampling frequency and signal length) are hardcoded in the function where the error occurs: acquisition_simplified.
You may want to use acqusition instead, which allows you to change these parameters.
Another point is the intermediate frequency (IF), which is a core parameter of the signal, too. I assume it to be the same (zero) for both devices, but can't say that for sure. You can increase the frequency (Doppler) search space to account for this (another parameter of the acquisition function).

For debugging, you can also inspect the raw output of the acquisition function looking for higher SNR values for some satellites.

Overall, not a trivial task!