ANTEX Frequency parsing does not support all available values

[jbangelo]

The ANTEX record parsing does not properly handle all of the frequency bands available in current ANTEX files from IGS. I found this description the ANTEX format, and in the description of the START OF FREQUENCY section it lists several potential frequency bands that could be encoded but the current parsing doesn't handle all of these cases. The current implementation appears to label anything it doesn't expect as either Carrier::L1 or Carrier::E1. It also appears that all BeiDou frequency bands are given Galileo Carrier values.

This behavior means it's impossible to differentiate which is the "real" L1 calibration value and which are the mislabeled values. Here is a minimal program, the output shows that the list of frequencies for at least some antennas are ambiguous since there are multiple entries with the same carrier value. I'm also attaching the ANTEX file that I'm using locally, but any relatively recent file from IGS demonstrates this issue.

fn main() {
    let file_path = "/path/to/igs14.atx";

    let rnx = rinex::Rinex::from_file(&file_path).unwrap();
    if let rinex::record::Record::AntexRecord(atx) = rnx.record {
        for (antenna, frequencies) in atx.iter() {
            println!("Antenna {} {}", antenna.ant_type, antenna.sn);
            for freq in frequencies.iter() {
                println!("\tFrequency {:?}", freq.carrier);
            }
        }
    }
}

igs14.atx.zip

[gwbres]

@jbangelo,

Thank you so much for the great feedback !

in the description of the START OF FREQUENCY section it lists several potential frequency bands that could be encoded but the current parsing doesn't handle all of these cases

I'll try to provide an answer to this in August

[gwbres]

Hello @jbangelo,

So the classifcation is correct.

Basically you're saying that the "carrier" signal information, which we can relate to a frequency band, that is attached to each individual Frequency in a sorted ATX record, is regularly incorrect (bad parsing).

It solely relies on this method, which was developed for that ATX requirement specifically.
BTW this carrier.rs structure is our main object to represent frequency bands, with convenient methods mostly required in calculations.

It just looks like it's simply missing a few cases to identify (mostly E5b, LEX is covered by L6 in our library).
I just opened a preliminary pull-request : #104
can you try this gh-antex-103 branch, see if provides the correct answer?

thank you for your contribution

[jbangelo]

Hi @gwbres,

Sorry for the late response, and thank you for the fast turn around of that PR. It looks like it'll fix most of what I originally was reporting. I've submitted an additional set of changes in #128 to allow further differentiation of the different records in an ATX file. Hopefully those are helpful and acceptable to be included.

[jbangelo]

@gwbres if you would allow me to provide a somewhat larger suggestion. I think my original issue boils down to the fact that the records in an ATX file are describing a separate concept than the observation records used elsewhere in RINEX files. The ATX records are describing corrections for entire frequency bands instead of specific signals, so the re-use of the Carrier type to identify these records isn't quite right in my opinion. A separate Frequency type/enum would seem to be a better fit, and having helper functions convert between Carrier and Frequency types would probably help ease both of their uses.

I know this suggestion is much larger than what I identified in the original issue report, so please let me know if it's more appropriate to open a separate issue for this. Also let me know if this just isn't the kind of change the project would entertain. If this is something the project might consider I would be happy to prototype the sort of changes I have in mind for further review and refinement.

[gwbres]

@jbangelo,

Thank you for your contributions already, especially since ATX is kind of an exotic format and we don't have much info/applications as of today.

As far as i'm concerned I'm focused on fixing issues related to NAV computations, that will probably keep me busy for the next 2 or 3 weeks. If you want to see this topic progress quicker feel free to open pull requests, I'll be happy to merge them.

Currently we only have two tests for ATX files:

• test/parsing : which only makes sure the parser does not fail, for all the database
• and test/v1_trosar_25r4_leit_2020_09_23 which is finer but not very thorough as far as actual frequency content is concerned
• you can also submit the file that you proposed, we usually strip them to a few payload, so the file that we store does not exceed 1 or 2 MB

[gwbres]

Hello @jbangelo,

I'm actively working on gnss-rtk which will eventually benefit from the ATX rework, but not in a near future.

Let me know if this is blocking for you, maybe we can reschedule things to have it closed sooner

[jbangelo]

Hello @gwbres ,

I've been pulled away on other things at work recently and haven't been able to dedicated time to this. The previously accepted changes were enough to unblock what I was working on. Strictly speaking I don't require any further changes though I would like to revisit this in the near future and submit the changes I had in mind, I will try and find some time to make those changes soon and submit them for review so as not to block your eventual work 😅

[gwbres]

Hello @jbangelo,
for your information, I've reached the point where my work (mainly post processed positioning) could benefit the rework of the ANTEX content and actual proper support.
I've initiated this work in atx-dev and will be working on this the next few weeks

[jbangelo]

Hi @gwbres , thanks a lot for the update! Unfortunately I've been inundated with other work and haven't been able to dedicate any time to this. Please let me know if you would need another reviewer or some other help, I should be able to at least contribute that if it would help.

[gwbres]

Hi @gwbres , thanks a lot for the update! Unfortunately I've been inundated with other work and haven't been able to dedicate any time to this. Please let me know if you would need another reviewer or some other help, I should be able to at least contribute that if it would help.

Oh no worries, just to let you know that this will be amongst the ongoing topics these days

[gwbres]

Hello @jbangelo,

I managed to improve things and my requirements are met.
I have two questions regarding the ATX format

• what are the usage of the phase patterns ? on my side, I only need the APC corrections
• for an RX antenna (not SV antenna), we sometimes get several entries (APC coordinates + phase patterns) for the same frequency. For example, if you look at Antenna TWIVSP6037L, we get specs for G01 and E01 which is the same frequency

[gwbres]

for an RX antenna (not SV antenna), we sometimes get several entries (APC coordinates + phase patterns) for the same frequency. For example, if you look at Antenna TWIVSP6037L, we get specs for G01 and E01 which is the same frequency

they have the exact same content

[jbangelo]

what are the usage of the phase patterns ? on my side, I only need the APC corrections

These are orientation specific adjustments to the APC mapped to the line of sight. An antenna's radiation pattern isn't uniform in all directions and for precise applications (or for bad antenna designs) you will have to take these variations into account. I think the existing data structure for these variations is perfectly acceptable.

for an RX antenna (not SV antenna), we sometimes get several entries (APC coordinates + phase patterns) for the same frequency. For example, if you look at Antenna TWIVSP6037L, we get specs for G01 and E01 which is the same frequency

Yes, this is not unexpected with the ANTEX format I believe. While you are right that the G01 and E01 frequency bands overlap and that the correction data matches for the two, some antenna manufacturers choose to provide these separate sections. I'm not entirely sure why but in my view it's helpful to remove ambiguity about which frequency bands are equivalent and which aren't. With separate sections the consumer of this data doesn't need to know that C01 and G01 are equivalent while C02 and G02 are not equivalent for example. Ideally I think a file parser would preserve these distinctions instead of trying to collapse them even if they technically can be.

[gwbres]

the consumer of this data doesn't need to know that C01 and G01 are equivalent while C02 and G02 are not equivalent for example.

that is a good point

Ideally I think a file parser would preserve these distinctions instead of trying to collapse them even if they technically can be.

That's how this crate behaves. All we need to match all possible scenarios, is to make sure the search methods (for example rinex.sv_antenna_apc()) use the carrier frequency. Thank you that was very helpful 👍

These are orientation specific adjustments to the APC mapped to the line of sight

Thank you once again. I just need to learn how to use it.

[gwbres]

Hello @jbangelo

happy holidays ! 🎄

I am about to merge the current developments, they will partially answer this topic.
I'm providing a method to easily locate an antenna (whether it be an RX or a TX antenna), either from its name or its serial number. The problem is, I'm getting inconsistent results because it seems the ATX specifications are not strictly followed.
That includes ATX v1.4 by IGS that is included in this topic.

The specification says the antenna name should be 20 character long

In practice, IGS uses 16 characters

Other files I found online, most likely less common than loading the IGS 1.4

Which means since I strictly followed the specs, I cannot match an antenna name easily.
I think I will crop to 16 so it works with IGS 1.4

[gwbres]

Hello,

I'll mark this issue as closed. The latest PR has substancially improved the support of ATX files. Mainly:

• we now have the ability to differentiate RX from TX antennas https://docs.rs/rinex/latest/rinex/antex/antenna/enum.AntennaSpecific.html
• we can now represent frequency dependent values correctly
  https://docs.rs/rinex/latest/rinex/struct.Rinex.html#method.antennas
• a new crate feature is introduced to make ATX features easily accessible.
  For example rx_antenna_apc_offset to retrieve APC of an RX antenna easily.
• we also have the Antenna Matcher object to easily locate an RX antenna we're interested in.
• also added a truncated IGS V1.4 ATX
• also introduced more ATX related tests

None the less, we do not support azimuth dependent frequency data at the moment. So this support is partial.
I have no idea how to use the frequency dependant data, my current use is the basic APC. So I did not develop high level features for these data fields either.

Note that RINEX-CLI does not take advantage of ATX files at the moment, but that will change soon as we're about to initiate PPP