RTK-capable GNSS receivers will maintain the RTK fix for a limited amount of time after the RTK correction data stream stops. The time usually ranges from 10 to 60 seconds. For receivers that only go to 10 seconds, this can potentially be an issue when using the Internet to transport the correction data due to unexpected network congestion on the Internet or wireless carrier. The question is, how beneficial is it to maintain RTK fix with stale correction data?
Old correction data causes two issues:
1) The accuracy of the position data degrades with correction age.
2) The receiver will eventually give up on RTK and drop to SBAS. That usually results in a large position shift as the SBAS solution and the RTK solution are calculated separately and are usually several feet apart at any given time.
Using a receiver that will report the standard deviation of accuracy for each direction (latitude, longitude, altitude); I set it up to log data while running on RTK, and then stopped the correction data stream. The following list shows the correction data age (in seconds), the vertical standard deviation (in millimeters), and the difference in reported elevation relative to where it was when the data was fresh (in millimeters). Bigger numbers means less accuracy.
For those of you who don't think in metric, the ratio is approximately 25 mm = 1 inch.
| Correction Data Age | Vertical Deviation | Vertical Movement |
| (in seconds) | (in mm) | (in mm) |
| 01 | 15 | 0 |
| 02 | 15 | -1 |
| 03 | 15 | -5 |
| 04 | 15 | -6 |
| 05 | 16 | -4 |
| 06 | 18 | -3 |
| 07 | 19 | +1 |
| 08 | 20 | +2 |
| 09 | 21 | +4 |
| 10 | 21 | +6 (10 seconds old, not much degradation yet) |
| 11 | 22 | +9 |
| 12 | 23 | +11 |
| 13 | 24 | +10 |
| 14 | 25 | +9 |
| 15 | 30 | +9 |
| 16 | 31 | +8 |
| 17 | 32 | +7 |
| 18 | 33 | +3 |
| 19 | 33 | +9 |
| 20 | 31 | +10 (20 seconds old, less confident of the data, but still not much degradation) |
| 21 | 32 | +15 |
| 22 | 33 | +15 |
| 23 | 34 | +14 |
| 24 | 35 | +19 |
| 25 | 36 | +19 |
| 26 | 37 | +17 |
| 27 | 38 | +17 |
| 28 | 39 | +15 |
| 29 | 40 | +19 |
| 30 | 41 | +18 |
| 31 | 42 | +20 |
| 32 | 43 | +19 |
| 33 | 44 | +20 |
| 34 | 45 | +23 |
| 35 | 46 | +28 (35 seconds old, vertical data has now moved an inch) |
| 36 | 47 | +30 |
| 37 | 48 | +32 |
| 38 | 55 | +34 |
| 39 | 56 | +36 |
| 40 | 58 | +36 |
| 41 | 59 | +38 |
| 42 | 59 | +38 |
| 43 | 54 | +39 |
| 44 | 55 | +41 |
| 45 | 56 | +43 |
| 46 | 57 | +48 |
| 47 | 58 | +46 |
| 48 | 59 | +50 |
| 49 | 60 | +52 (49 seconds old, vertical data has now moved 2 inches) |
| 50 | 61 | +55 |
| 51 | 62 | +58 |
| 52 | 63 | +63 |
| 53 | 64 | +65 |
| 54 | 65 | +66 |
| 55 | 66 | +70 |
| 56 | 67 | +72 |
| 57 | 68 | +75 |
| 58 | 69 | +79 |
| 59 | 70 | +84 (59 seconds old, receiver thinks the vertical data could be off by + or - 2.75 inches The data was actually off by 3.3 inches.) |
For auto-steer (horizontal) work, the degradation of accuracy even at 1 minute won't be a big deal. For vertical work like on a tile plow, you may not like the degradation of accuracy with data much past 30-40 seconds old, even if the receiver is capable of holding the RTK fix for longer than that.
The other issue is with the huge position shift when going from the RTK solution to the SBAS solution. This is why most auto-steer systems will disengage when the fix type changes. Ideally the receiver would synchronize the SBAS solution to the RTK solution so there is minimal position shift when the RTK fix is lost. That would at least let you re-engage steering on the lower quality signal without needing to move your AB line around to keep the machine somewhat centered on the path. I have suggested this to both Trimble and NovAtel, but I am not aware of either company implementing this feature.
I should also mention that John Deere thought of this years ago and calls the feature RTK Extend. Basically if you lose the RTK data stream, the receiver reverts to SF2 for 15 minutes. I assume the SF2 solution is synchronized to the RTK solution so that the user doesn't notice a position shift when transitioning between them.
Last updated: March 4, 2011