hirokawa / cssrlib-data

Sample scripts and dataset for CSSRlib
Other
27 stars 8 forks source link

About ionospheric correction of clock bias #31

Open MayHarryWang opened 1 week ago

MayHarryWang commented 1 week ago

Dear Dr. hirokawa,

Thank you for providing this powerful tool for SSR-PPP learners.

However, I have one question about applying ionosphere-free bias correction to clock offsets in sisre analysis code. In general, the precise clock bias product should already be ionospheric-free. I wonder why the parameter of osbIF and osbIF_ are used again for both precise product and SSR correction?

Also, could you please provide reference about the equation of ionospheric-free satellite clock bias correction? I'm not sure why the code bias should be applied for satellite clock bias ionospheric correction.

Thank you very much! Best regards.

whu-dyf commented 6 days ago

I believe the reason for that is the clock reference used for precise products differs from the one used for SSR corrections. Therefore, it is necessary to convert them into a common reference frame before making the subsequent comparison. An example cited from (https://doi.org/10.1007/s10291-023-01410-y)

Additionally, one has to keep in mind that HAS clocks refer to the ionosphere-free combination of the LNAV signals (L1 C/A and L2P (Y), or C1C and C2P in RINEX3 convention) for GPS and I/NAV signals (E1/E5b, or C1C and C7Q in RINEX3 convention) for Galileo (European Union 2022), while the CODE final products refer to the ionosphere-free combination of C1W and C2W (in RINEX3 convention) signals for GPS and C1C and C5Q for Galileo (Villiger et al. 2019)

However, I find it is hard to look up clock reference of each satellite systems (GECJ) of all satellite-based PPP service (HAS, B2b, CLAS, and MADOCA). The official Interface Control Documents (ICDs) seems to not explicitly provide that information.

AndreHauschild commented 5 days ago

Yes, correctly! The different clock reference signals are the reason for applying the biases. The idea was to pick two reference signals and apply the corresponding biases from the SSR corrections and the IGS reference product, to make the clock offsets comparable.

It is not necessary for the user to know the clock reference signals, because they are supposed to apply the corresponding observable-specific bias (OSB) for each observation. If there is no bias for a signal, this measurement cannot be processed. It is the responsibility of the provider of the corrections to make sure that orbit, clock offset and bias corrections are consistent irrespective of which signals are processed on the user side. The use of OSBs therefore makes the processing on the user side much easier.

MayHarryWang commented 4 days ago

Dear Dr. hirokawa and Dr. AndreHauschild,

Thank you very much for your explanations! I think this is an available method to compare the clock bias.

However, is the GLONASS also possible to apply ionospheric free code bias correction to compare the clock bias in the same way? I'm asking this because I'm not sure the same method can be applied to FDMA signals.

Thank you very much! Best regards.

AndreHauschild commented 4 days ago

Dear MayHarryWang,

You are welcome! Your question on GLONASS is difficult to answer. In general, the answer is yes, because GLONASS is parametrized in exactly the same way in the SSR correction and therefore, at least formally, the method described above also applies. However, as you rightfully point out, the FDMA signals of GLONASS introduce a strong dependency of the biases on the user's equipment, which puts a limit on how well the biases can be eliminated with satellite-dependent bias corrections only.

MayHarryWang commented 3 days ago

Dear Dr. AndreHauschild,

Yes, this is why I'm questionable about the difference between precise product and SSR-corrected ephemeris of GLONASS. But, as you mentioned, I think it might still feasible to preview the assessment of SSR product.

Thank you very much for your work! It really helps me a lot! Best regards.

whu-dyf commented 2 days ago

Yes, correctly! The different clock reference signals are the reason for applying the biases. The idea was to pick two reference signals and apply the corresponding biases from the SSR corrections and the IGS reference product, to make the clock offsets comparable.

It is not necessary for the user to know the clock reference signals, because they are supposed to apply the corresponding observable-specific bias (OSB) for each observation. If there is no bias for a signal, this measurement cannot be processed. It is the responsibility of the provider of the corrections to make sure that orbit, clock offset and bias corrections are consistent irrespective of which signals are processed on the user side. The use of OSBs therefore makes the processing on the user side much easier.

I am still confused about applying the biases to make the clock offsets comparable. Take the GPS example in test_sisre_has.py, your code can be summarized as the following formula: image where the superscript denotes the source of bias and clock products. Parentheses indicate the original satellite clock reference observables. My question is: Why are (1) and (2) comparable after applying these biases? and what's the clock reference datum after applying? Why are the ionosphere-free combination bias of C1C-C2W used to make the clock offsets comparable? Is it chosen randomly?

Could you give me some guidance please? Thanks for your reply in advance!

AndreHauschild commented 2 days ago

It is assumed that the user processes the signals C1C and C2W, therefore the iono-free combination of the corresponding biases is applied to make the clock comparable for these signals. Again, the idea behind using OSBs is that you do not need to know (or assume) the clock reference signals of your product, because the biases are computed such that consistency is assured.

whu-dyf commented 2 days ago

It is assumed that the user processes the signals C1C and C2W, therefore the iono-free combination of the corresponding biases is applied to make the clock comparable for these signals. Again, the idea behind using OSBs is that you do not need to know (or assume) the clock reference signals of your product, because the biases are computed such that consistency is assured.

I understand that PPP positioning users do not need to know the clock reference signals after applying OSB products, but when doing clock comparison, from my point of view, the clock datum did not seem to be unified after applying the OSBs.

I'd appreciate if you could clarify the logic and reasoning behind it.

AndreHauschild commented 2 days ago

The reasoning behind it is that clocks and biases are inseparable. Imagine that the CODE and HAS clock and biases were free of any errors. Then the combined correction of clock offset and biases to the ionosphere-free observation equation would yield exactly the same values (*). If everything is done consistently in the generation of the products, this should also be the case if CODE and HAS use different clock reference signals. Hope that helps!

(*) ...but potentially a common offset for all satellites still exists, which will be absorbed in the receiver clock estimate.