Changeset 4248 in ntrip


Ignore:
Timestamp:
Jun 20, 2012, 10:03:08 AM (12 years ago)
Author:
weber
Message:

Obsolete BNS topics deleted

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/BNC/todo.txt

    r2631 r4248  
    11Todo's sorted by priority:
    22
    3 BNS
    4 =========================
    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
    11 time tag than a previously distributed ephemeris set. However, this is not always true.
    12 Sometimes new ephemeris sets come with a validity time tag which is earlier than the
    13 validity time tag of a previously distributed ephemeris set. This is something
    14 we should consider in BNS. Gerhard observed that we dont consider this right
    15 now. The consequence is that a satellite gets lost for PPP clients because
    16 they deal with another ephemeris set than the correctors provided by
    17 BNS.
    18 
    19 (3)
    20 Shall We add the following validity check to BNS and BNS for the GLONASS broadcast
    21 ephemeris messages?
    22 (a) If the time of validity differs by more than +/- 30 min from the time
    23 of reception, then the 1019/1020 messages are rejected.
    24 (b) However, if correcting the time of validity of such rejected 1019/1020
    25 message by exactly 3 hours leads to a new validity time within +/- 30 min of
    26 the reception time, then the broadcast ephemeris are nevertheless accepted.
    27 (c) The following is Gerhard's opinion:
    28 Die 1020 Message ist sauber definiert. Es gab zwar in der Anfangsphase
    29 hier und da Probleme mit einigen Implementation, die sind aber meines Wissens
    30 gelöst.  Ich halte es für sehr kritisch, eine 3-Stunden Differenz automatisch zu
    31 akzeptieren und vielleicht sogar zu korrigieren.
    32 
    33 
    34 BNC
    35 =========================
    363(1) Should we spend time to improve BNC's convergence? Should we follow a
    374procedure like the one Oscar implemented? If not: Can we do something which
     
    5926different software).
    6027
    61 (2) Could we use the XYZ from 'Plot origion' to improve BNC's conversion when
    62 we start the program (supposed the user has good a-priori coordinates)?
    63 So far the introduced XYZ is only used for the plot.
    64 
    65 (3) NMEA GGA string is not fully compatible with the standard.
     28(2) NMEA GGA string is not fully compatible with the standard.
    6629The following are observations by Tamas Horvath:
    6730(a) Time tag should refer to UTC time and not GPS system time.
     
    7639age of RTCM SSR data should be put.
    7740
    78 (4) BNC has a problem when the observation update rate is > 1Hz. Records get
    79 mixed then in the RINEX files. A 10 Hz stream to test the situation is
    80 available 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 TracChangeset for help on using the changeset viewer.