| 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 |
|
|---|
