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