Changeset 279 in ntrip for trunk/BNC


Ignore:
Timestamp:
Nov 8, 2006, 12:09:33 PM (18 years ago)
Author:
mervart
Message:

* empty log message *

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/BNC/todo.txt

    r272 r279  
    2121           ein "Muss" gewählt habe. was denkst Du dazu? Ist das mit
    2222           vertretbarem Aufwand machbar?
     23^^^^^^^^^^ CANCELED ^^^^^^^^^^^^^
    2324
    2425(5 Kann) Die Orientierung im Logfile wäre einfacher, wenn vor jede
    … …  
    6364
    6465
    65 (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.
     66(1) Als ASCII-Output werden SNR1 und SNR2 nicht mit ausgegeben. Da der binaere
     67    Output SNR1 und SNR2 jedoch mit ausgibt schlage ich vor, diese beiden
     68    Parameter auch beim ASCII-Output mit auszugeben.
     69^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    6670
    67 (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.
     71(2) Ich habe Tests mit 300..400 Datenstroemen gemacht. (Der NTRIP Broadcaster
     72    macht das mit. Fuer BNC scheint die Grenze mit der Hauptspeichergroesse in
     73    Verbindung zu stehen - bei 300..400 Datenstroemen ist auf dem
     74    Linux-Rechner "gref-ip" Schluss.) Ein kleines Problem kann die quasi
     75    zeitgleiche Anforderung aller Datenstroeme fuer den NTRIP Broadcaster
     76    darstellen. Wir koennten ihm die Situation erleichtern, wenn wir nach
     77    jedem "GET" fuer eine Datenstromanforderung etwa 0.1sec warten bis zum
     78    naechsten "GET". Laesst sich z.B. ein 'usleep' an passender Stelle
     79    hinzufuergen? Bei 100 Datenstoemen mueüsste man dann etwa 10 sec warten
     80    bis alles angelaufen ist - da sehe ich aber kein Problem.
     81^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    6882
    69 (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.
     83(3) 'Append files' wirkt im Augenblick nur fueür die RINEX-Files. Ich schlage
     84    vor, dieses auchfuer "Log-file" und "ASCII-Output" einzufueühren. Wenn BNC
     85    wirklich einmal nach einem Programmabsturz neu gestartet werden muss, dann
     86    ist es sicher gut einen Blick in das alte Log-file werfen zu koennen.
     87^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    7088
    71 (4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen Ausnahme. Die Mountpoints:
     89(4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen
     90    Ausnahme. Die Mountpoints:
    7291
    73 WETTZELL
    74 FRANKFURT
    75 FRANCE
    76 BRUS0
    77 BRUS0
     92    WETTZELL
     93    FRANKFURT
     94    FRANCE
     95    BRUS0
     96    BRUS0
     97   
     98    weürden im Augenblick folgende Skeleton-Files suchen
     99   
     100    WETT.skl
     101    FRAN.skl
     102    BRUS.skl
     103   
     104    Ich denke wir sollten das so einstellen, dass nach Skeleton-Files des
     105    endgültigen Dateinamens gesucht wird, also:
     106   
     107    WETT.skl
     108    FRAN_KFURT.skl
     109    FRAN_CE.skl
     110    BRUS_0.skl
     111    BRUS_1.skl
     112   
     113    Ich hoffe, das ist nicht zu kompliziert einzurichten.
     114^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    78115
    79 weürden im Augenblick folgende Skeleton-Files suchen
     116(5) Ebenso wie die Strings "decoder" sind im Mountpoint-Bereich im Augenblick
     117    auch die Strings "bytes" editierbar. Das muss allerdings nicht
     118    sein. Editiert braucht nur der "decoder" String zu sein.
     119^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    80120
    81 WETT.skl
    82 FRAN.skl
    83 BRUS.skl
     121(6) Was das Re-connect betrifft, so hat RTCM darum gebeten eine
     122    Random-Variable einzufuehren zusaetzlich zu dem "sleep:
     123    2,4,8,16,32,64,128". Dieser Zufallsgroesse sollt zwischen 0 und 5 sec
     124    liegen. Man muesste dazu also so eine sleep-Reihenfolge einrichten wie
    84125
    85 Ich denke wir sollten das so einstellen, dass nach Skeleton-Files des endgültigen Dateinamens gesucht wird, also:
     126    sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
    86127
    87 WETT.skl
    88 FRAN_KFURT.skl
    89 FRAN_CE.skl
    90 BRUS_0.skl
    91 BRUS_1.skl
     128    wobei "rand" eine Zufallszahl zwischen 0 und 5 ist.
     129    Ich denke, dass das einfach ist (ueber den Sinn kann man streiten).
     130^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    92131
    93 Ich hoffe, das ist nicht zu kompliziert einzurichten.
     132(7) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP
     133    Broadcaster angefordert wird. Beispiel:
    94134
    95 (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.
     135    www.igs-ip.net:2101/ALBH0
     136    www.igs-ip.net:2101/ALBH0
     137   
     138    Das macht keinen Sinn - ist aber ausgezeichnet zum Testen! Ich kann beliebig
     139    viel "Workload" fuer BNC und insbesondere auch fuer den NTRIP Broadcaster
     140    erzeugen!
     141   
     142    Leider ist in der RINEX-Ausgabe bei dieser Situation ein Bug drin: Beide
     143    RINEX-Daten werden in der selben Datei "ALBH*_1.* abgelegt. Tatsaechlich
     144    muessen sie aber in den beiden Dateien
     145   
     146    ALBH*_0.*
     147    ALBH*_1.*
     148   
     149    getrennt abgelegt werden. Das klappt auch schon in dem Fall, in dem ein
     150    identischer Mountpoint bei zwei verschiedenen Broadcastern vorliegt. Beispiel
     151    www.euref-ip.net:2101/BRUS0 und www.igs-ip.net:2101/BRUS0. Dann werden korrekt
     152    die Dateien
     153   
     154    BRUS*_0.*
     155    BRUS*_1.*
     156   
     157    angelegt. Ich hoffe, Du kannst das Problem mit www.igs-ip.net:2101/ALBH0 plus
     158    www.igs-ip.net:2101/ALBH0 finden.
     159^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    96160
    97 (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
    98 
    99 sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
    100 
    101 wobei "rand" eine Zufallszahl zwischen 0 und 5 ist.
    102 Ich denke, dass das einfach ist (ueber den Sinn kann man streiten).
    103 
    104 (7) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP Broadcaster angefordert wird. Beispiel:
    105 
    106 www.igs-ip.net:2101/ALBH0
    107 www.igs-ip.net:2101/ALBH0
    108 
    109 Das macht keinen Sinn - ist aber ausgezeichnet zum Testen! Ich kann beliebig viel "Workload" fuer BNC und insbesondere auch fuer den NTRIP Broadcaster erzeugen!
    110 
    111 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
    112 
    113 ALBH*_0.*
    114 ALBH*_1.*
    115 
    116 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
    117 
    118 BRUS*_0.*
    119 BRUS*_1.*
    120 
    121 angelegt. Ich hoffe, Du kannst das Problem mit www.igs-ip.net:2101/ALBH0 plus www.igs-ip.net:2101/ALBH0 finden.
    122 
    123 (8) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit ausgeben? Z.B.:
     161(8) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit
     162    ausgeben? Z.B.:
    124163    30.000                                                  INTERVAL
    125 fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software einen solchen Record erwartet.
     164    fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software
     165    einen solchen Record erwartet.
    126166
    127167(9) Sollten wir in die Routinen irgendwie eine Datei Copyright.cpp aufnehmen
    128 mit Hinweis auf GNU GPL?
    129 Der RTIGS-Konverter hat schon einen Copyright-Hinweis von Ken MacLeod drin, ebenso der
    130 Konverter fuer RTCM 3. Beim RTCM 2 Konverter muesste man noch einen Copyright-Hinweis
    131 fuer Oliver Montenbruck aufnehmen. In Deine Programmteile koennte man schreiben:
     168    mit Hinweis auf GNU GPL?  Der RTIGS-Konverter hat schon einen
     169    Copyright-Hinweis von Ken MacLeod drin, ebenso der Konverter fuer RTCM
     170    3. Beim RTCM 2 Konverter muesste man noch einen Copyright-Hinweis fuer
     171    Oliver Montenbruck aufnehmen. In Deine Programmteile koennte man
     172    schreiben:
    132173
    133174// Part of BNC, a utility for retrieving decoding and
Note: See TracChangeset for help on using the changeset viewer.