After some work on the RTKLIB SSR support and retesting the SSRA00GAA* streams they are still not working - while it does work on many other streams. It receives and decodes the SSR from these streams but can not use it because the IODEs do not match the current GPS ephemeris IOD. This is not just for a short period when the IOD changes, and it is for all the GPS satellites. e.g. G01 SSR IODE is 84 and the current broadcast IODE is 85, G15 SSR IODE is 16 and the current broadcast IODE is 17, etc. It could just be a service issue, but might it be a software issue in Ginan.
Been working to have RTKLIB handle IOD changes as gracefully as possible, and wip maintains and the current and previous ephemeris and SSR but there is a time limit after which it has to be considered stale.
Noted the SSR spec. asks the producer to hold back a little to give the receiver time to have received and decoded the new ephemeris and is that configurable in Ginan and might that be a code path to check:
"However, it is recommended to delay the use of the latest broadcast message for a period of 60 seconds, measured from the time of complete reception of ephemeris and clock parameters, in order to accommodate rover applications to obtain the same set of broadcast orbital and clock parameters"
After some work on the RTKLIB SSR support and retesting the SSRA00GAA* streams they are still not working - while it does work on many other streams. It receives and decodes the SSR from these streams but can not use it because the IODEs do not match the current GPS ephemeris IOD. This is not just for a short period when the IOD changes, and it is for all the GPS satellites. e.g. G01 SSR IODE is 84 and the current broadcast IODE is 85, G15 SSR IODE is 16 and the current broadcast IODE is 17, etc. It could just be a service issue, but might it be a software issue in Ginan.
Been working to have RTKLIB handle IOD changes as gracefully as possible, and wip maintains and the current and previous ephemeris and SSR but there is a time limit after which it has to be considered stale.
Noted the SSR spec. asks the producer to hold back a little to give the receiver time to have received and decoded the new ephemeris and is that configurable in Ginan and might that be a code path to check:
"However, it is recommended to delay the use of the latest broadcast message for a period of 60 seconds, measured from the time of complete reception of ephemeris and clock parameters, in order to accommodate rover applications to obtain the same set of broadcast orbital and clock parameters"