Support for Advanced Navigation ANPP format

[joe-saronic]

Format defined here: https://docs.advancednavigation.com/boreas-d/ANPP/Advanced%20Navigation%20Packet.htm

This implementation only handles the raw satellite measurements, not the entire protocol.

Receiver selection is done in the same way as for SBF format: the opt field is searched for -RCVR{n}, where n must be an integer in the range [0-255] since ANPP theoretically supports that many antennae per unit.

Testing

Compared raw output from Boreas D-90 parsed with https://github.com/saronic-technologies/liban-rs/ (see saronic-technologies/liban-rs#18) to result of parsing with rust bindings to this library in https://github.com/kpwebb/rtklib-ffi/ (see joe-saronic/rtklib-ffi#1). Verified that obs fragments are handled correctly.

Inspected output of convbin from two receivers in a well-known dataset to ensure correct numbers of observations, constellations, etc. Main dataset can not be provided, but a small edited sample is available in the integration tests of the rust wrapper.

[joe-saronic]

Hi @rtklibexplorer. This is my first PR to RTKLIB. I'm curious if there is any procedure you have for reviewing/merging, and what standard of testing you expect for incoming PRs.

[joe-saronic]

@ourairquality I've addressed as much of your feedback as I could for the moment. Waiting for feedback from Advanced Navigation. In the meantime, I've continued testing this with the rtklib-ffi rust crate I'm augmenting.

[ourairquality]

Imported the patch into my branch and updated as to personal preference, the raw buffer access with bounds checking, avoiding the pointer arithmetic, the signals mapping guess, also noted a few other integration issues, and reworked a little. Are there anpp files that can be shared for testing?

[joe-saronic]

Are there anpp files that can be shared for testing?

I am sure I can find some non-proprietary stuff that I can share next week.

[ourairquality]

Here are some more issues to consider, a few integration matters, and some suggestions for adnav.c, there were some switch-break statements missing at least, and a few casts to help quieten compiler warnings. Untested, but will if some data can be shared.
anpp.patch

[joe-saronic]

@ourairquality I've absorbed 90% of your suggestions and fixed a couple of additional spots in the same spirit. Couple of exceptions:

• CMakeLists.txt has an alphabetical list, so no reason to put adnav.c at the end
• One of the modified files does not exist in my branch
• I can't bring myself to nest rtkboundscheck declaration and macro among the time and string utilities. Similar argument for putting the impl near fatalerr rather than some random string functions. I also happen to like the doc-comment I added.

I'm not going to be super insistent on any of these, just noting them for easier review. Definitely a big fan of everything else, still pending feedback from the manufacturer regarding the frequency bands.

[ourairquality]

CMakeLists.txt - might be best to avoid white space changes to files otherwise not changed.
app/consapp/convbin/msc/msc.vcxproj - needs adnav.c, was this the file missing in your repo, it seems to be in the main branch.
adnav.c qzss signal id 2 comment seems incorrect, the docs have this as L1 C.
adnav.c bds: even trimble receivers appear to report B1 B2 B2 as 2I 7I 6I, so probably little doubt on those.
decode_glo_eph: has a use of eph rather than geph.
src/src.pro: adds a trailing white space, to be avoided.
bound check primitive: that's fine, it was back-ported fom code that also addressed the unsafe string operations so that might be why it was there.
anpp ordering: personally look for it after unicore, the order added, but an exception seems fine where everything else is sorted.
anpp3.patch

[joe-saronic]

On a related note, a small CONTRIBUTING file or even section at the end of the README might be useful. There's a good amount of generally actionable stuff in our discussion of this PR.

[joe-saronic]

I have offloaded the task of finding a non-proprietary snippet to Advanced Navigation, since they are more likely to have something I can publish freely than I am.

[joe-saronic]

@ourairquality I've gotten a response back from Advanced Navigation regarding the frequency mapping. The mapping is not strictly 1-to-1, so I've attempted to choose the middle band for each available option. Please let me know if you prefer different options for any of these choices.

The table that was given to me is this:

Ad. Nav.	Rinex
GPS
L1 C/A	1C
L1 C	1S, 1L
L1 P	1P
L1 M	1M
L2 C	2S, 2L
L2 P	2P
L2 M	2M
L5	5I, 5Q
GLONASS
G1 C/A	1C
G1 P	1P
G2 C/A	2C
G2 P	2P
G3	3I, 3Q, 3X
Galileo
E1 OS	1C, 1B
E1 PRS	1A
E6 CS	6B
E6 PRS	6A
E5 a	5I, 5Q, 5X
E5 b	7I, 7Q, 7X
E5 a+b	8I, 8Q, 8X
BeiDou
B1	2I, 2Q, 2X
B2	7I, 7Q, 7X
B3	6I, 6Q, 6X
SBAS
L1 C/A	1C
L5	5I, 5Q, 5X
QZSS
L1 C/A	1C
L1 C	1S, 1L, 1X
L1 SAIF	1Z
L2 C	2S, 2L, 2X
LEX	6L, 6X
L5	5I, 5Q, 5X, 5D, 5P, 5Z
NavIC
L5	5A, 5B, 5C, 5X

[ourairquality]

Could you ask them to clarify the bands for the common but missing GPS rinex 1W 2W 1X 2X and 5X. At a guess L1 C should also include 1X, 1P should also include 1W, 2P should also include 2W, L2 C should also include 2X, L5 should also include 5X.

For Galileo: E1OS also 1X.

For QZSS: L6 LEX also 6S. For L5 do they expect us to distinguish between the satellite block and have a separate mapping for 5IQX vs 5DPZ, it looks like satellites send either L5 of L5S but not both so that might work?

Receiver options will need to be added for the mappings for each of these. It does not seem credible to pick just one signal. The defaults should be based on the common usage, e.g. for BDS even Trimble report 2I 7I 6I so use that etc, I gave you the common usage, just use those for the defaults.

It appears they have a converter for rinex 'Tools > Log Converter', but I see no configuration options for the signal mapping, and could you ask them to document the signal selection configuration for their own tool to make that clear for us too:
https://docs.advancednavigation.com/gnss-Compass/Monitoring/InsManagerToolsMenu.htm#Log_Converter

[joe-saronic]

Sorry this is taking so long. I am still actively prodding for feedback.

[joe-saronic]

I have an update from Advanced Navigation:

Hey Joseph,

I’m back with an update and clarification. The previous table I
provided had mappings that aren’t “translated” per our Firmware Team.
Below I’ve provided an updated table that the Firmware Team has provided
my that maps the RINEX Code to our Statuses as of today.

For the question about receiver dependent bands, the mapping in the
table below is not receiver dependent as this is a mapping to our ANPP
structure that is shared across all of our devices. Any band capability
differences between our X20P receivers and MX5 receivers can be found
from the data sheet to see which bands those receivers will receive.

No luck on digging up GNSS obs and Nav Data yet.

RINEX	ANPP60 Signal
1C	GAL_E1os
1B	GAL_E1os
7I	GAL_E5b
7Q	GAL_E5b
5I	GAL_E5a
5Q	GAL_E5a
6B	GAL_E6cs
6A	GAL_E6prs
1C	GPS_L1CA
2L	GPS_L2C
2S	GPS_L2C
5I	GPS_L5
5Q	GPS_L5
1C	GLO_G1CA
2C	GLO_G2CA
1P	GLO_G1P
2P	GLO_G2P
2I	BEI_B1I
7I	BEI_B2I
6I	BEI_B3I
1P	BEI_B1C
5P	BEI_B2A
1C	GPS_L1CA
5I	GPS_L5
5Q	GPS_L5
5X	GPS_L5
1C	GPS_L1CA
1S	GPS_L1C
2S	GPS_L2C
2L	GPS_L2C
5I	GPS_L5
5Q	GPS_L5
5A	IRN_L5

@ourairquality Please let me know if you have any concerns with this mapping. Otherwise I will be implementing it shortly in the PR and rebasing on main.