computing satellite states over several days (using several NAV files) #32
Conversation
…ssion before the beginning of the day for 24h IGS files.
… of NAV file to be able to compute the iono correction over several days
| @@ -100,17 +100,13 @@ def discover_or_download_auxiliary_files(observation_file_path=Path()): | |||
| rinex_3_obs_file = converters.anything_to_rinex_3(observation_file_path) | |||
| header = georinex.rinexheader(rinex_3_obs_file) | |||
| ephs = discover_or_download_ephemerides( | |||
| helpers.rinex_header_time_string_2_timestamp_ns(header["TIME OF FIRST OBS"]), | |||
| # remove 2*70 ms to the first obs epoch, to account for travel time (~70 ms) in the time of emission computation | |||
There was a problem hiding this comment.
Is it 2*70 to have some margin and also account for sat clock offset + receiver clock offset?
There was a problem hiding this comment.
It is not necessary to remove the receiver clock offset, as the RNX timestamp should be affected by that parameter.
I took 2*70 ms, as an additional margin. I guess a better justification would be to use the delay to a GEO satellite + maximum sat clock offset.
Max geo delay is around 36,000 km (for a satellite on the equator at lat = 0, and user at lat = 45 and lon = 80) divided by c = 120 ms
Max sat clock offset is 37 ms for satellite E11 in the file TLSE00FRA_R_20230010100_10S_01S_MO.rnx.
So let us consider a max delay of 200 ms (this includes a 43 ms or 27% margin)
…t for worst case scenario (GEO ranging, worst sat clock bias and margin)
|
Redundant with #53 |
This feature is required when using a IGS OBS file with first epoch at midnight. Since time_of_emission is time_of_reception - pseudorange, this first epoch is a few milliseconds before the end of the previous day.