nRF9160: GNSS factory almanac generation

[JordanYates]

Is it possible for users to regenerate the nRF9160 GNSS factory almanac data from public sources?

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/cellular/gnss/src/factory_almanac.h

There is a public script to convert a binary file to the header, but no mention of the source of the binary file.

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/cellular/gnss/scripts/factory_almanac_to_string.py

[Didrik Rokhaug]

Hi,

At least in theory, you can just read it from the satellites. You might also be able an A-GPS response to get it.

However, I don't know how we get it when we generate that header file.

I'll check with the modem team and see if I can get some more details.

Best regards,

Didrik

[JordanYates]

Without knowing the format of the factory almanac data it doesn't really seem possible to construct it from the satellites themselves.

The current factory almanac string looks to 2058 byte hex string, so 1029 bytes. This doesn't neatly map to the size of the almanac (15000 bits, 18750 bytes), so there are still a lot of questions there.

Ideally the format would be documented, so public almanacs like this could be constructed. The current almanac hasn't been updated for 3 months, which is obviously not ideal.

[Didrik Rokhaug]

I didn't get any more information about how the file is generated, other than it being done from "publicly available GNSS almanac data".

However, we do plan to start updating it once a month, with the first of these regular updates hopefully being in a couple of weeks.

[JordanYates]

Being generated from "publicly available GNSS almanac data" is irrelevant if the final binary format is proprietary. If nRF cloud is the only reasonable source for data that can be provided to "%XFILEWRITE" I would expect that to be documented along with the command.

[mackz]

Is there any update on this? Is the binary format still proprietary?