Changeset 2629 in ntrip
- Timestamp:
- Oct 28, 2010, 12:47:50 PM (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/BNC/todo.txt
r2628 r2629 3 3 BNS 4 4 ========================= 5 (1) One would expect that a new ephemeris set always comes with a later validity 5 (1) We often have small (~20...30 sec) outages in the CLK* streams. I dont 6 know where this comes from. The situation can be checked through 7 http://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 6 11 time tag than a previously distributed ephemeris set. However, this is not always true. 7 12 Sometimes new ephemeris sets come with a validity time tag which is earlier than the … … 14 19 BNC 15 20 ========================= 16 (1) NMEA GGA string is not fully compatible with the standard. 17 The following are observations by Tamas Horvath: 18 1. Time tag should refer to UTC time and not GPS system time. 19 2. Time tag format is hhmmss.ss and not hhmmss. 20 3. The GPS Quality indicator field is 1 (GPS SPS Mode), which is correct, as 21 there is no category for PPP. In my opinion the NMEA protocol should be 22 extended by a new indicator number for PPP to make a clear difference between 23 autonomous GNSS and PPP. 24 4. The HDOP value is constantly 2.0, which is obviously not real. I think this 25 field is filled with 2.0 as a default value in BNC. 26 5. The Age of Differential GPS data field is not populated. I believe here the 27 age of RTCM SSR data should be put. 28 29 (2) Should we spend time to improve BNC's convergence? Should we follow a 21 (1) Should we spend time to improve BNC's convergence? Should we follow a 30 22 procedure like the one Oscar implemented? If not: Can we do something which 31 helps a bit and does not involve too much work? 23 helps a bit and does not involve too much work? Or should we better do nothing? 32 24 33 25 (a) Calculate, for each satellite, the STD of the code multipath in the … … 52 44 different software). 53 45 54 (3) BNC has a problem when the observation update rate is > 1Hz. Records get 46 (2) Could we use the XYZ from 'Plot origion' to improve BNC's conversion when 47 we start the program (supposed the user has good a-priori coordinates)? 48 So far the introduced XYZ is only used for the plot. 49 50 (3) NMEA GGA string is not fully compatible with the standard. 51 The following are observations by Tamas Horvath: 52 (a) Time tag should refer to UTC time and not GPS system time. 53 (b) Time tag format is hhmmss.ss and not hhmmss. 54 (c) The GPS Quality indicator field is 1 (GPS SPS Mode), which is correct, as 55 there is no category for PPP. In my opinion the NMEA protocol should be 56 extended by a new indicator number for PPP to make a clear difference between 57 autonomous GNSS and PPP. 58 (d) The HDOP value is constantly 2.0, which is obviously not real. I think this 59 field is filled with 2.0 as a default value in BNC. 60 (e) The Age of Differential GPS data field is not populated. I believe here the 61 age of RTCM SSR data should be put. 62 63 (4) BNC has a problem when the observation update rate is > 1Hz. Records get 55 64 mixed then in the RINEX files. A 10 Hz stream to test the situation is 56 65 available from GFZ caster 139.17.3.112:4080 through stream A17H. 57 66 58 ( 4) GW: Keep an eye on www.igs-ip.net/PENC0.67 (5) GW: Keep an eye on www.igs-ip.net/PENC0. 59 68
Note:
See TracChangeset
for help on using the changeset viewer.