rtksrv ssr update

[ourairquality]

Fwiw a follow up suggestion.

Leave it to the rtcm3 decoder to set the update flag, so that it can use this to also flag when the state is consistent and ready to be used in an update.

Search the previous ephemeris for an IODE consistent with the SSR data so that SSR updates can occur even if they still reference the prior ephemeris - when the ephemeris is updated with a new IODE before the SSR data.

[ourairquality]

Still seeing the available satellites collapse when the ephemeris is rolled over. Looking at the trace, if the SSR stream switches to the new ephemeris first then this logic blocks using it because there is no matching IODE and the last used SSR correction can fall outside the maximum allowable age which is currently 90 seconds.

Could either increase the allowable SSR age and use stale SSR corrections for a longer period to give the ephemeris more time to be updated, or tolerate a IODE mismatch as a fallback and accept applying the current SSR correction to an immediately prior IODE for a longer period.

[rtklibexplorer]

I've added a check of the previous ephemeris for IODE match in the SSR update. I believe this will fix the issue you are seeing, but if not, if you could either point me to a data stream which exhibits this issue or share some data, that would be helpful.

[ourairquality]

Thank you. It seems that SSR expects the receiver to update the ephemeris withing 60 seconds, the spec asks the SSR producer to hold back for 60 seconds after it receives new ephemeris to give the receiver this time. The stations that I was using for some testing were just much slower in forwarding ephemeris updates, these are Geoscience Australia streams and the ephemeris appears to arrive slowly and I can understand them not wanting to burden the streams with ephemeris data when most receivers would receive this from broadcasts. Looks like RTKLIB is doing the best it can, perhaps the max age could be made a runtime config option, but I can easily compile something locally.