The general concept behind static testing is that the GNSS receivers are in constant motion (due to the rotation of the earth), but speed over ground (SOG) is known to be zero. Any speed reported by the receiver is therefore an error and may be regarded as noise.
The purpose of this particular test was to determine if there is any difference in behavior between motions logging at 1 / 2 / 5 / 10 Hz. It is clear from the results that higher logging rates do indeed suffer from greater levels of noise, and may be prone to larger outliers.
The tests were performed on calm days, within the security of a garden where the motions could be left unattended for approximately 6 hours.
The motions were placed on a raised table to minimize the effects of a nearby wall, but otherwise a pretty decent open-sky environment.
Once the test was underway the motions were left untouched, right until the end of the test when they were switched into WiFi mode.
All of the data is available for download in OAO format:
It is important to top and tail the data, prior to analysis:
The significance of a 15 minute warm up period is apparent after loading the data for 660, 661, 662 and 665 into GPS Speedreader:
After removing the first 15 minutes of data the wander and > 0.5 knot spikes are completely eliminated, leaving the majority of data for the analysis:
Testing on 18 June used the older style mini motions, logging at 1 / 2 / 5 / 10 Hz.
The test was intended to run for 6 hours but was actually stopped after 5 hours 20 minutes, thus providing slightly over 5 hours worth of useful data.
The last digit of the serial numbers indicates the logging rates and the motions were arranged as follows:
There was some cloud cover, but no rain was to be expected during the day. View to north, prior to testing:
View to south, prior to testing:
Visual inspection of the 5 hours of data in GPS Speedreader provides the following insights:
A Python script within GPS Wizard generated the following statistics, using knots as units:
Motion | Rate (Hz) | Max | Median | Mean | StdDev |
---|---|---|---|---|---|
631 | 1 | 0.109 | 0.01555 | 0.01650 | 0.00976 |
661 | 1 | 0.080 | 0.01361 | 0.01422 | 0.00839 |
632 | 2 | 0.194 | 0.01361 | 0.01481 | 0.00903 |
662 | 2 | 0.243 | 0.01166 | 0.01221 | 0.00739 |
635 | 5 | 0.134 | 0.01944 | 0.02223 | 0.01247 |
665 | 5 | 0.156 | 0.01944 | 0.02020 | 0.01132 |
630 | 10 | 0.309 | 0.03499 | 0.03731 | 0.02120 |
660 | 10 | 0.257 | 0.02916 | 0.03184 | 0.01787 |
Observations for these statistics:
Testing on 19 June used the newer style mini motions, logging at 1 / 2 / 5 Hz. It’s not currently possible to configure them for 10 Hz.
The test was run for around 6 hours 20 minutes, providing over 6 hours worth of actual data, after excluding the warm up period.
The last digit of the serial numbers indicates the logging rates and they were arranged as follows:
The first 15 minutes should be regarded as the warm up, allowing for complete acquisition of the ephemerides. Much like the data from the previous day there is a fair amount of wander during the first 15 minutes, most likely due to use of the almanac data which is less precise than the ephemeris data. This is quite apparent when loading the data for motions 811 / 812 / 815 into GPS Speedreader.
Visual inspection of the remaining 6 hours of data in GPS Speedreader provides the following insights:
A Python script within GPS Wizard generated the following statistics, using knots as units:
Motion | Rate (Hz) | Max | Median | Mean | StdDev |
---|---|---|---|---|---|
801 | 1 | 0.105 | 0.00972 | 0.01026 | 0.00661 |
811 | 1 | 0.091 | 0.00972 | 0.01134 | 0.00740 |
802 | 2 | 0.235 | 0.00972 | 0.01194 | 0.00822 |
812 | 2 | 0.354 | 0.00972 | 0.01242 | 0.00862 |
805 | 5 | 0.130 | 0.01749 | 0.01827 | 0.01063 |
815 | 5 | 0.381 | 0.01555 | 0.01794 | 0.01039 |
Observations for these statistics:
The basic conclusions are as follows:
The following caveats should also be listed:
It might be worth testing the statistical significance of differences in the 1 Hz and 2 Hz data: