Should the orbit estimator expect time to never decrease?

[nhz2]

Can I assume the GPS time input into the orbit estimator will never(or at least very rarely) decrease from one control cycle to the next? This is important because it is hard to make the Kalman filter go backwards in an optimal way without storing some small buffer of past estimated states and covariances.

There are two simple methods I can think of to update the current GPS time.

1. if new GPS reading:
   current GPS time= GPS reading time
   else:
   current GPS time+= control cycle duration

2. if new GPS reading:
   current GPS time= GPS reading time
   cycles since reading= 0
   else:
   if cycles since reading>=(max control cycle error-1):
       current GPS time+= control cycle duration
   else:
       cycles since reading+=1

The first method could have current GPS time decrease, while the second method stalls the current GPS time for some number of control cycles if it doesn't get a new GPS reading. This makes a decreasing current GPS time much less likely, but it also adds more delay to the current GPS time vs real time. A more complicated method would be to somehow time stamp when the GPS data is sent using the teensy's real time clock(RTC) and then calculate the current GPS time using that time stamp, the current RTC value and the sent GPS time. This method might be more accurate but time stamping the GPS data seems overly complicated, and more accurate than we need.

For now I am going to assume method 2 is going to be used and not properly handle negative time steps in the GPS Kalman filter, but it shouldn't be too hard to add in more code later to more optimally handle negative steps.

[shihaocao]

I think I think it should be extremely rare for time to decrease from one control cycle to the next.