| 1 | Todo's sorted by priority:
|
|---|
| 2 |
|
|---|
| 3 | (1) Should we spend time to improve BNC's convergence? Should we follow a
|
|---|
| 4 | procedure like the one Oscar implemented? If not: Can we do something which
|
|---|
| 5 | helps a bit and does not involve too much work? Or should we better do nothing?
|
|---|
| 6 |
|
|---|
| 7 | (a) Calculate, for each satellite, the STD of the code multipath in the
|
|---|
| 8 | iono-free combination Pc, as a combination the carrier phase and the code.
|
|---|
| 9 | Do this continuously, using a circular register that contains the observations
|
|---|
| 10 | of the previous 10 minutes.
|
|---|
| 11 | (b) Introduce a default STD that is used when, either at the beginning or
|
|---|
| 12 | after an interruption in the data, there is less than 10 minutes worth of
|
|---|
| 13 | data for finding the multipath STD as in (1), and the STD with insufficient
|
|---|
| 14 | data is less than this default.
|
|---|
| 15 | (c) Introduce use a "fudge factor" to multiply the data-based STD and get the
|
|---|
| 16 | actual value used to get the data. This is necessary, because the correct weight
|
|---|
| 17 | of the data depends on numerous factors, particularly the weights assigned to
|
|---|
| 18 | the phase and to the a priori values of the unknowns. This problem also is true
|
|---|
| 19 | for (b), (c), and (d). So the fudge factor really depends on the overall strategy
|
|---|
| 20 | and cannot be used in different software implementations.
|
|---|
| 21 | Everyone has to find it the hard way, by trial and error, making lots of solutions.
|
|---|
| 22 | (The variance of unit weight is of very limited help for this purpose.)
|
|---|
| 23 | (d) Downweight the code by a large factor when a satellite is below 20 degrees
|
|---|
| 24 | in elevation, or the 3-D precision of the coordinates being estimated falls
|
|---|
| 25 | below something like 25 cm (again, this will be a different threshold with
|
|---|
| 26 | different software).
|
|---|
| 27 |
|
|---|
| 28 | (2) NMEA GGA string is not fully compatible with the standard.
|
|---|
| 29 | The following are observations by Tamas Horvath:
|
|---|
| 30 | (a) Time tag should refer to UTC time and not GPS system time.
|
|---|
| 31 | (b) Time tag format is hhmmss.ss and not hhmmss.
|
|---|
| 32 | (c) The GPS Quality indicator field is 1 (GPS SPS Mode), which is correct, as
|
|---|
| 33 | there is no category for PPP. In my opinion the NMEA protocol should be
|
|---|
| 34 | extended by a new indicator number for PPP to make a clear difference between
|
|---|
| 35 | autonomous GNSS and PPP.
|
|---|
| 36 | (d) The HDOP value is constantly 2.0, which is obviously not real. I think this
|
|---|
| 37 | field is filled with 2.0 as a default value in BNC.
|
|---|
| 38 | (e) The Age of Differential GPS data field is not populated. I believe here the
|
|---|
| 39 | age of RTCM SSR data should be put.
|
|---|
| 40 |
|
|---|
