About PPP derived ellipsoidal heights and ZTD

[flex0902]

Dear Dr. hirokawa and Dr. AndreHauschild,

This python-based tool-kits is useful for learning PPP process.
I am trying to use the sample of test_pppigs.py to process IGS stations.
Typically, nav.elmaskar must be set to at least 35 degrees and nav.elmin must be set to 15 degrees to obtain better positioning results.
I used the station name "TWTF" at 2023-08-11 (doy223) and the nav.thresar = 2.0

FileName: ../data/doy223/TWTF00TWN_R_20232230000_01D_30S_MO.rnx
Start : 2023-08-11 00:00:00
End : 2023-08-11 23:59:30
Receiver: SEPT POLARX4TR
Antenna : ASH701945C_M SCIS

Available signals
BEIDOU C2I C7I D2I D7I L2I L7I S2I S7I
GALILEO C1C C5Q C7Q D1C D5Q D7Q L1C L5Q L7Q S1C S5Q S7Q
GPS C1C C1W C2L C2W C5Q D1C D2L D2W D5Q L1C L2L L2W L5Q S1C S1W S2L S2W S5Q
QZSS C1C C2L C5Q D1C D2L D5Q L1C L2L L5Q S1C S2L S5Q
GLONASS C1C C2C C2P C3Q D1C D2C D2P D3Q L1C L2C L2P L3Q S1C S2C S2P S3Q
SBAS C1C D1C L1C S1C

Selected signals
GPS C1C C2W L1C L2W S1C S2W
GALILEO C1C C5Q L1C L5Q S1C S5Q
BEIDOU C2I C7I L2I L7I S2I S7I
QZSS C1C C5Q L1C L5Q S1C S5Q

when the nav.elmaskar = np.deg2rad(35.0) and nav.elmin = np.deg2rad(15), the positioning results is like this

when the nav.elmaskar = np.deg2rad(30.0) and nav.elmin = np.deg2rad(15), the positioning results is like this

This happens quite often when I use other IGS stations.
In addition, I find the PPP derived ellipsoidal heights and ZTD show obvious negative correlation.
I think the ZTD will not have such variations in static observation and in one day.
I hope I explained my doubts enough.

1. Is it normal to set the nav.elmaskar to at least 35 degree for PPP at IGS station?
2. The ZTD estimations seems to be unstable and produce further impacts on ellipsoidal heights? and It should not be the problem caused by the used tropospheric model.
   How do I modify the parameters in program "pppssr.py"?

Best regards,
Flex

[AndreHauschild]

Dear Flex,

thank you very much for your interest in CSSRlib! Your issue is very well illustrated. I appreciate the effort and I think I can comment on your questions:

1. I believe that your processing with the low elevation threshold suffers from undetected cycle slips. Unfortunately, a sophisticated procedure for cycle-slip detection and removal has not yet been implemented in the software. At the moment, the algorithms relies on the cycle-slip flag reported by the receiver in the RINEX files, but this is typically not included in IGS data. It seems that for the first 4-5 hours, the processing works as expected even with the low elevation limit. Maybe you could try to identify the satellites causing the problems by comparing the processing PRNs between your two test cases and exclude them manually.

2. Yes, the correlation between ZTD and vertical position component is a known issue. Observations from satellites at low elevation angles help to de-correlate ZTD and up-component, but in your case undetected cycle slips corrupt the estimation results. Other than the manual approach described above, I do not see any other way of cleaning the data.

I hope this information helps a bit! Improving the cycle-slip detection algorithm is high up on the ToDo list, but finding time to actually do this is a bit difficult at the moment. Please stay tuned for future updates, which will eventually resolve this issue.

Kind regards, André