source: ntrip/trunk/BNC/todo.txt@ 279

(1 Muss) Beim ersten Start von BNC sollte das Programm mit den
         Default-Optionen beginnen, die in bnchelp.html genannt sind.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(2 Muss) Problem: Mehr als ein Datenstrom haben den selben 4CharID Mountpoint.
         Problem: Keine eindeutige Möglichkeit zur Vergabe von
         RINEX-Dateinamen.  Beispiel: Mountpoints FRANKFURT und
         FRANCE. Mögliche Lösung: Siehe Vorschlag in "bnchelp.html".
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(4 Muss) Eigenes Timeout in BNC auf 20sec festsetzen.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(6 Muss) Maximum des Reconnect-Delays auf 128 sec festsetzen
         (1,2,4,8,16,32,64,128).
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(10) Muss) Im Datenfeld Nummber 7 der NET-Records steht das FTP-Verzeichnis
           für die Sitelogs.  Aus den Sitelogs kann optional ein RINEX-Header
           generiert werden. Das erscheint mir so wichtig, dass ich hierfür
           ein "Muss" gewählt habe. was denkst Du dazu? Ist das mit
           vertretbarem Aufwand machbar?
^^^^^^^^^^ CANCELED ^^^^^^^^^^^^^

(5 Kann) Die Orientierung im Logfile wäre einfacher, wenn vor jede
         Ausgabezeile eine Zeitmarke und der zugehörige Mountpoint geschrieben
         werden könnten.  Das mit der Zeitmarke ist sicher machbar. Das mit
         dem zugehörigen Mountpoint könnte ein Problem sein. Wenn es ein
         größeres Problem ist, dann bitte weglassen.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(8 Kann) Falls Rückmeldung vom Caster:

               Caster Response: HTTP/1.1 401 Unauthorized

               dann die Sourcetable nochmals anfordern und das Datenfeld
               Nummer 8 des zugehörigen NET-Records im Logfile mit ausgeben
               damit der Nutzer weiss, wo er sich registrieren lassen muss für
               User-ID und Password. Die Zeile im Logfile könnte z.B. lauten:

               Adjust User-ID and Password Register through
               http://igs.bkg.bund.de/index_ntrip_reg.htm
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(9 Kann) Im Default-RINEX-Header die Zeile:

         GENERATED FROM RTCM 2.x STREAM ON www.igs-ip.net            COMMENT
         ändern in
         RTCM 2.x STREAM ON www.igs-ip.net                           COMMENT

         Begründung: bei langen IP-Adressen wird Platz gebraucht, deshalb
         "generated from" einfach weglassen.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(3, Luxus) "Get Data" durch zwei Buttons "Start" und "Stop" unten auf dem
           Hauptfenster ersetzen.  Den jetzigen Button "Quit" so lassen wie er
           ist.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(7 Absoluter Luxus) Ladebalken aus sich bewegendem graphischen Element
                    einführen um dem Nutzer zu bestätigen, dass BNC am
                    Arbeiten ist.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^


(1) 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.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(2) 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.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(3) '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.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen
    Ausnahme. Die Mountpoints:

    WETTZELL
    FRANKFURT
    FRANCE
    BRUS0
    BRUS0
    
    weürden im Augenblick folgende Skeleton-Files suchen
    
    WETT.skl
    FRAN.skl
    BRUS.skl
    
    Ich denke wir sollten das so einstellen, dass nach Skeleton-Files des
    endgültigen Dateinamens gesucht wird, also:
    
    WETT.skl
    FRAN_KFURT.skl
    FRAN_CE.skl
    BRUS_0.skl
    BRUS_1.skl
    
    Ich hoffe, das ist nicht zu kompliziert einzurichten.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(5) 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.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(6) 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

    sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand

    wobei "rand" eine Zufallszahl zwischen 0 und 5 ist.
    Ich denke, dass das einfach ist (ueber den Sinn kann man streiten).
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(7) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP
    Broadcaster angefordert wird. Beispiel:

    www.igs-ip.net:2101/ALBH0
    www.igs-ip.net:2101/ALBH0
    
    Das macht keinen Sinn - ist aber ausgezeichnet zum Testen! Ich kann beliebig
    viel "Workload" fuer BNC und insbesondere auch fuer den NTRIP Broadcaster
    erzeugen!
    
    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
    
    ALBH*_0.*
    ALBH*_1.*
    
    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
    
    BRUS*_0.*
    BRUS*_1.*
    
    angelegt. Ich hoffe, Du kannst das Problem mit www.igs-ip.net:2101/ALBH0 plus
    www.igs-ip.net:2101/ALBH0 finden.
^^^^^^^^^^ DONE ^^^^^^^^^^^^^

(8) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit
    ausgeben? Z.B.:
    30.000                                                  INTERVAL
    fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software
    einen solchen Record erwartet.

(9) Sollten wir in die Routinen irgendwie eine Datei Copyright.cpp aufnehmen
    mit Hinweis auf GNU GPL?  Der RTIGS-Konverter hat schon einen
    Copyright-Hinweis von Ken MacLeod drin, ebenso der Konverter fuer RTCM
    3. Beim RTCM 2 Konverter muesste man noch einen Copyright-Hinweis fuer
    Oliver Montenbruck aufnehmen. In Deine Programmteile koennte man
    schreiben:

// Part of BNC, a utility for retrieving decoding and
// converting GNSS data streams from NTRIP broadcasters,
// written by Leos Mervart.
//
// Copyright (C) 2006
// German Federal Agency for Cartography and Geodesy (BKG)
// http://www.bkg.bund.de
// Czech Technical University Prague, Department of Advanced Geodesy
// http://www.fsv.cvut.cz
//
// Email: euref-ip@bkg.bund.de
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License
// as published by the Free Software Foundation, version 2.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.