source: ntrip/branches/BNC_LM/todo.txt@ 3955

Last change on this file since 3955 was 2631, checked in by weber, 14 years ago

Gross check for GLONASS ephemeris ?

File size: 4.4 KB
Line 
1Todo's sorted by priority:
2
3BNS
4=========================
5(1) We often have small (~20...30 sec) outages in the CLK* streams. I dont
6know where this comes from. The situation can be checked through
7http://products.igs-ip.net/admin?mode=sources (ntrip:ntrip)
8(see column 'Connected for')
9
10(2) One would expect that a new ephemeris set always comes with a later validity
11time tag than a previously distributed ephemeris set. However, this is not always true.
12Sometimes new ephemeris sets come with a validity time tag which is earlier than the
13validity time tag of a previously distributed ephemeris set. This is something
14we should consider in BNS. Gerhard observed that we dont consider this right
15now. The consequence is that a satellite gets lost for PPP clients because
16they deal with another ephemeris set than the correctors provided by
17BNS.
18
19(3)
20Shall We add the following validity check to BNS and BNS for the GLONASS broadcast
21ephemeris messages?
22(a) If the time of validity differs by more than +/- 30 min from the time
23of reception, then the 1019/1020 messages are rejected.
24(b) However, if correcting the time of validity of such rejected 1019/1020
25message by exactly 3 hours leads to a new validity time within +/- 30 min of
26the reception time, then the broadcast ephemeris are nevertheless accepted.
27(c) The following is Gerhard's opinion:
28Die 1020 Message ist sauber definiert. Es gab zwar in der Anfangsphase
29hier und da Probleme mit einigen Implementation, die sind aber meines Wissens
30gelöst. Ich halte es für sehr kritisch, eine 3-Stunden Differenz automatisch zu
31akzeptieren und vielleicht sogar zu korrigieren.
32
33
34BNC
35=========================
36(1) Should we spend time to improve BNC's convergence? Should we follow a
37procedure like the one Oscar implemented? If not: Can we do something which
38helps a bit and does not involve too much work? Or should we better do nothing?
39
40(a) Calculate, for each satellite, the STD of the code multipath in the
41iono-free combination Pc, as a combination the carrier phase and the code.
42Do this continuously, using a circular register that contains the observations
43of the previous 10 minutes.
44(b) Introduce a default STD that is used when, either at the beginning or
45after an interruption in the data, there is less than 10 minutes worth of
46data for finding the multipath STD as in (1), and the STD with insufficient
47data is less than this default.
48(c) Introduce use a "fudge factor" to multiply the data-based STD and get the
49actual value used to get the data. This is necessary, because the correct weight
50of the data depends on numerous factors, particularly the weights assigned to
51the phase and to the a priori values of the unknowns. This problem also is true
52for (b), (c), and (d). So the fudge factor really depends on the overall strategy
53and cannot be used in different software implementations.
54Everyone has to find it the hard way, by trial and error, making lots of solutions.
55(The variance of unit weight is of very limited help for this purpose.)
56(d) Downweight the code by a large factor when a satellite is below 20 degrees
57in elevation, or the 3-D precision of the coordinates being estimated falls
58below something like 25 cm (again, this will be a different threshold with
59different software).
60
61(2) Could we use the XYZ from 'Plot origion' to improve BNC's conversion when
62we start the program (supposed the user has good a-priori coordinates)?
63So far the introduced XYZ is only used for the plot.
64
65(3) NMEA GGA string is not fully compatible with the standard.
66The following are observations by Tamas Horvath:
67(a) Time tag should refer to UTC time and not GPS system time.
68(b) Time tag format is hhmmss.ss and not hhmmss.
69(c) The GPS Quality indicator field is 1 (GPS SPS Mode), which is correct, as
70there is no category for PPP. In my opinion the NMEA protocol should be
71extended by a new indicator number for PPP to make a clear difference between
72autonomous GNSS and PPP.
73(d) The HDOP value is constantly 2.0, which is obviously not real. I think this
74field is filled with 2.0 as a default value in BNC.
75(e) The Age of Differential GPS data field is not populated. I believe here the
76age of RTCM SSR data should be put.
77
78(4) BNC has a problem when the observation update rate is > 1Hz. Records get
79mixed then in the RINEX files. A 10 Hz stream to test the situation is
80available from GFZ caster 139.17.3.112:4080 through stream A17H.
81
82(5) GW: Keep an eye on www.igs-ip.net/PENC0.
83
Note: See TracBrowser for help on using the repository browser.