Changeset 571 in ntrip for trunk


Ignore:
Timestamp:
Nov 9, 2007, 1:18:57 PM (17 years ago)
Author:
weber
Message:

* empty log message *

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/BNC/todo.txt

    r308 r571  
    1 (1 Muss) Beim ersten Start von BNC sollte das Programm mit den
    2          Default-Optionen beginnen, die in bnchelp.html genannt sind.
    3 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    4 
    5 (2 Muss) Problem: Mehr als ein Datenstrom haben den selben 4CharID Mountpoint.
    6          Problem: Keine eindeutige Möglichkeit zur Vergabe von
    7          RINEX-Dateinamen.  Beispiel: Mountpoints FRANKFURT und
    8          FRANCE. Mögliche Lösung: Siehe Vorschlag in "bnchelp.html".
    9 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    10 
    11 (4 Muss) Eigenes Timeout in BNC auf 20sec festsetzen.
    12 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    13 
    14 (6 Muss) Maximum des Reconnect-Delays auf 128 sec festsetzen
    15          (1,2,4,8,16,32,64,128).
    16 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    17 
    18 (10) Muss) Im Datenfeld Nummber 7 der NET-Records steht das FTP-Verzeichnis
    19            für die Sitelogs.  Aus den Sitelogs kann optional ein RINEX-Header
    20            generiert werden. Das erscheint mir so wichtig, dass ich hierfür
    21            ein "Muss" gewählt habe. was denkst Du dazu? Ist das mit
    22            vertretbarem Aufwand machbar?
    23 
    24 (5 Kann) Die Orientierung im Logfile wäre einfacher, wenn vor jede
    25          Ausgabezeile eine Zeitmarke und der zugehörige Mountpoint geschrieben
    26          werden könnten.  Das mit der Zeitmarke ist sicher machbar. Das mit
    27          dem zugehörigen Mountpoint könnte ein Problem sein. Wenn es ein
    28          größeres Problem ist, dann bitte weglassen.
    29 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    30 
    31 (8 Kann) Falls Rückmeldung vom Caster:
    32 
    33                Caster Response: HTTP/1.1 401 Unauthorized
    34 
    35                dann die Sourcetable nochmals anfordern und das Datenfeld
    36                Nummer 8 des zugehörigen NET-Records im Logfile mit ausgeben
    37                damit der Nutzer weiss, wo er sich registrieren lassen muss für
    38                User-ID und Password. Die Zeile im Logfile könnte z.B. lauten:
    39 
    40                Adjust User-ID and Password Register through
    41                http://igs.bkg.bund.de/index_ntrip_reg.htm
    42 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    43 
    44 (9 Kann) Im Default-RINEX-Header die Zeile:
    45 
    46          GENERATED FROM RTCM 2.x STREAM ON www.igs-ip.net            COMMENT
    47          ändern in
    48          RTCM 2.x STREAM ON www.igs-ip.net                           COMMENT
    49 
    50          Begründung: bei langen IP-Adressen wird Platz gebraucht, deshalb
    51          "generated from" einfach weglassen.
    52 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    53 
    54 (3, Luxus) "Get Data" durch zwei Buttons "Start" und "Stop" unten auf dem
    55            Hauptfenster ersetzen.  Den jetzigen Button "Quit" so lassen wie er
    56            ist.
    57 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    58 
    59 (7 Absoluter Luxus) Ladebalken aus sich bewegendem graphischen Element
    60                     einführen um dem Nutzer zu bestätigen, dass BNC am
    61                     Arbeiten ist.
    62 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    63 
    64 
    65 (1 kann) Als ASCII-Output werden SNR1 und SNR2 nicht mit ausgegeben. Da der binaere Output SNR1 und SNR2 jedoch mit ausgibt schlage ich vor, diese beiden Parameter auch beim ASCII-Output mit auszugeben.
    66 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    67 
    68 (2 kann) Ich habe Tests mit 300..400 Datenstroemen gemacht. (Der NTRIP Broadcaster macht das mit. Fuer BNC scheint die Grenze mit der Hauptspeichergroesse in Verbindung zu stehen - bei 300..400 Datenstroemen ist auf dem Linux-Rechner "gref-ip" Schluss.) Ein kleines Problem kann die quasi zeitgleiche Anforderung aller Datenstroeme fuer den NTRIP Broadcaster darstellen. Wir koennten ihm die Situation erleichtern, wenn wir nach jedem "GET" fuer eine Datenstromanforderung etwa 0.1sec warten bis zum naechsten "GET". Laesst sich z.B. ein 'usleep' an passender Stelle hinzufuergen? Bei 100 Datenstoemen mueüsste man dann etwa 10 sec warten bis alles angelaufen ist - da sehe ich aber kein Problem.
    69 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    70 
    71 (3 kann) 'Append files' wirkt im Augenblick nur fueür die RINEX-Files. Ich schlage vor, dieses auchfuer "Log-file" und "ASCII-Output" einzufueühren. Wenn BNC wirklich einmal nach einem Programmabsturz neu gestartet werden muss, dann ist es sicher gut einen Blick in das alte Log-file werfen zu koennen.
    72 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    73 
    74 (4 kann) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen Ausnahme. Die Mountpoints:
    75 
    76 WETTZELL
    77 FRANKFURT
    78 FRANCE
    79 BRUS0
    80 BRUS0
    81 
    82 weürden im Augenblick folgende Skeleton-Files suchen
    83 
    84 WETT.skl
    85 FRAN.skl
    86 BRUS.skl
    87 
    88 Ich denke wir sollten das so einstellen, dass nach Skeleton-Files des endgültigen Dateinamens gesucht wird, also:
    89 
    90 WETT.skl
    91 FRAN_KFURT.skl
    92 FRAN_CE.skl
    93 BRUS_0.skl
    94 BRUS_1.skl
    95 
    96 Ich hoffe, das ist nicht zu kompliziert einzurichten.
    97 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    98 
    99 (5 kann) Ebenso wie die Strings "decoder" sind im Mountpoint-Bereich im Augenblick auch die Strings "bytes" editierbar. Das muss allerdings nicht sein. Editiert braucht nur der "decoder" String zu sein.
    100 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    101 
    102 (6 kann) Was das Re-connect betrifft, so hat RTCM darum gebeten eine Random-Variable einzufuehren zusaetzlich zu dem "sleep: 2,4,8,16,32,64,128". Dieser Zufallsgroesse sollt zwischen 0 und 5 sec liegen. Man muesste dazu also so eine sleep-Reihenfolge einrichten wie
    103 
    104 sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
    105 
    106 wobei "rand" eine Zufallszahl zwischen 0 und 5 ist.
    107 Ich denke, dass das einfach ist (ueber den Sinn kann man streiten).
    108 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    109 
    110 (7 muss) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP Broadcaster angefordert wird. Beispiel:
    111 
    112 www.igs-ip.net:2101/ALBH0
    113 www.igs-ip.net:2101/ALBH0
    114 
    115 Das macht keinen Sinn - ist aber ausgezeichnet zum Testen! Ich kann beliebig viel "Workload" fuer BNC und insbesondere auch fuer den NTRIP Broadcaster erzeugen!
    116 
    117 Leider ist in der RINEX-Ausgabe bei dieser Situation ein Bug drin: Beide RINEX-Daten werden in der selben Datei "ALBH*_1.* abgelegt. Tatsaechlich muessen sie aber in den beiden Dateien
    118 
    119 ALBH*_0.*
    120 ALBH*_1.*
    121 
    122 getrennt abgelegt werden. Das klappt auch schon in dem Fall, in dem ein identischer Mountpoint bei zwei verschiedenen Broadcastern vorliegt. Beispiel www.euref-ip.net:2101/BRUS0 und www.igs-ip.net:2101/BRUS0. Dann werden korrekt die Dateien
    123 
    124 BRUS*_0.*
    125 BRUS*_1.*
    126 
    127 angelegt. Ich hoffe, Du kannst das Problem mit www.igs-ip.net:2101/ALBH0 plus www.igs-ip.net:2101/ALBH0 finden.
    128 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    129 
    130 (8 kann) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit ausgeben? Z.B.:
    131     30.000                                                  INTERVAL
    132 fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software einen solchen Record erwartet.
    133 -> Geht technisch nicht, wird also nicht gemacht.
    134 
    135 (9 kann) Sollten wir in die Routinen irgendwie eine Datei Copyright.cpp aufnehmen
    136 mit Hinweis auf GNU GPL?
    137 Der RTIGS-Konverter hat schon einen Copyright-Hinweis von Ken MacLeod drin, ebenso der
    138 Konverter fuer RTCM 3. Beim RTCM 2 Konverter muesste man noch einen Copyright-Hinweis
    139 fuer Oliver Montenbruck aufnehmen. In Deine Programmteile koennte man schreiben:
    140 
    141 // Part of BNC, a utility for retrieving decoding and
    142 // converting GNSS data streams from NTRIP broadcasters,
    143 // written by Leos Mervart.
    144 //
    145 // Copyright (C) 2006
    146 // German Federal Agency for Cartography and Geodesy (BKG)
    147 // http://www.bkg.bund.de
    148 // Czech Technical University Prague, Department of Advanced Geodesy
    149 // http://www.fsv.cvut.cz
    150 //
    151 // Email: euref-ip@bkg.bund.de
    152 //
    153 // This program is free software; you can redistribute it and/or
    154 // modify it under the terms of the GNU General Public License
    155 // as published by the Free Software Foundation, version 2.
    156 //
    157 // This program is distributed in the hope that it will be useful,
    158 // but WITHOUT ANY WARRANTY; without even the implied warranty of
    159 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    160 // GNU General Public License for more details.
    161 //
    162 // You should have received a copy of the GNU General Public License
    163 // along with this program; if not, write to the Free Software
    164 // Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
    165 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    166 
    167 (10 kann) Im Log-Bereich des Hauptfensters sowie gegebenenfalls im Log-File
    168 sollte, sobald BNC neu gestartet wird oder nach einem Re-Start, also noch
    169 vor dem GET fuer die Datenstroeme, eine Meldung erscheinen wie:
    170 
    171 15:49:33 ============ Start BNC ============
    172 
    173 Begruendung: Wenn viele Datenstroeme angefordert werden (z.B. 100), dann
    174 passiert auf dem Bildschirm zunaechst nichts, weil ja etwa 100 x 0.1 = 10sec
    175 gebraucht werden, um die Verbindungen zum Caster herzustellen. Die Meldung
    176 'Start BNC' macht dem Nutzer sofort klar, dass BNC korrekt angelaufen ist
    177 obwohl im Log-Bereich nocht nichts weiter zu sehen ist. (Psychologisches
    178 Problem, wenn der Nutzer nach ein paar Sekunden auf dem Bildschirm nichts
    179 sieht dann glaubt er, etwas sei nicht korrekt.)
    180 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    181 
    182 (11 kann) Skeleton Files von EUREF einbauen, Datenfeld Nummber 8 im
    183 NET-Record von www.euref-ip.net zeigt bereits auf das richtige HTTP-Verzeichnis,
    184 Beispiel fuer ein Skeleton-File dort:
    185 http://www.epncb.oma.be/stations/log/skl/GOPE.skl.
    186 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    187 
     1Upgrade to NTRIP Version 2
Note: See TracChangeset for help on using the changeset viewer.