Changeset 286 in ntrip


Ignore:
Timestamp:
Nov 8, 2006, 5:43:03 PM (17 years ago)
Author:
weber
Message:

* empty log message *

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/BNC/todo.txt

    r281 r286  
    2121           ein "Muss" gewählt habe. was denkst Du dazu? Ist das mit
    2222           vertretbarem Aufwand machbar?
    23 ^^^^^^^^^^ CANCELED ^^^^^^^^^^^^^
    2423
    2524(5 Kann) Die Orientierung im Logfile wäre einfacher, wenn vor jede
    … …  
    6463
    6564
    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 ^^^^^^^^^^^^^
     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.
    7066
    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 ^^^^^^^^^^^^^
     67(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.
    8268
    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 ^^^^^^^^^^^^^
     69(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.
    8870
    89 (4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen
    90     Ausnahme. Die Mountpoints:
     71(4 kann) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen Ausnahme. Die Mountpoints:
    9172
    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 ^^^^^^^^^^^^^
     73WETTZELL
     74FRANKFURT
     75FRANCE
     76BRUS0
     77BRUS0
    11578
    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 ^^^^^^^^^^^^^
     79weürden im Augenblick folgende Skeleton-Files suchen
    12080
    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
     81WETT.skl
     82FRAN.skl
     83BRUS.skl
    12584
    126     sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
     85Ich denke wir sollten das so einstellen, dass nach Skeleton-Files des endgültigen Dateinamens gesucht wird, also:
    12786
    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 ^^^^^^^^^^^^^
     87WETT.skl
     88FRAN_KFURT.skl
     89FRAN_CE.skl
     90BRUS_0.skl
     91BRUS_1.skl
    13192
    132 (7) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP
    133     Broadcaster angefordert wird. Beispiel:
     93Ich hoffe, das ist nicht zu kompliziert einzurichten.
    13494
    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 ^^^^^^^^^^^^^
     95(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.
    16096
    161 (8) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit
    162     ausgeben? Z.B.:
     97(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
     98
     99sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
     100
     101wobei "rand" eine Zufallszahl zwischen 0 und 5 ist.
     102Ich denke, dass das einfach ist (ueber den Sinn kann man streiten).
     103
     104(7 muss) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP Broadcaster angefordert wird. Beispiel:
     105
     106www.igs-ip.net:2101/ALBH0
     107www.igs-ip.net:2101/ALBH0
     108
     109Das macht keinen Sinn - ist aber ausgezeichnet zum Testen! Ich kann beliebig viel "Workload" fuer BNC und insbesondere auch fuer den NTRIP Broadcaster erzeugen!
     110
     111Leider 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
     113ALBH*_0.*
     114ALBH*_1.*
     115
     116getrennt 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
     118BRUS*_0.*
     119BRUS*_1.*
     120
     121angelegt. Ich hoffe, Du kannst das Problem mit www.igs-ip.net:2101/ALBH0 plus www.igs-ip.net:2101/ALBH0 finden.
     122
     123(8 kann) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit ausgeben? Z.B.:
    163124    30.000                                                  INTERVAL
    164     fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software
    165     einen solchen Record erwartet.
    166 ^^^^^^^^^^ CANCELED ^^^^^^^^
     125fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software einen solchen Record erwartet.
    167126
    168 (9) Sollten wir in die Routinen irgendwie eine Datei Copyright.cpp aufnehmen
    169     mit Hinweis auf GNU GPL?  Der RTIGS-Konverter hat schon einen
    170     Copyright-Hinweis von Ken MacLeod drin, ebenso der Konverter fuer RTCM
    171     3. Beim RTCM 2 Konverter muesste man noch einen Copyright-Hinweis fuer
    172     Oliver Montenbruck aufnehmen. In Deine Programmteile koennte man
    173     schreiben:
     127(9 kann) Sollten wir in die Routinen irgendwie eine Datei Copyright.cpp aufnehmen
     128mit Hinweis auf GNU GPL?
     129Der RTIGS-Konverter hat schon einen Copyright-Hinweis von Ken MacLeod drin, ebenso der
     130Konverter fuer RTCM 3. Beim RTCM 2 Konverter muesste man noch einen Copyright-Hinweis
     131fuer Oliver Montenbruck aufnehmen. In Deine Programmteile koennte man schreiben:
    174132
    175133// Part of BNC, a utility for retrieving decoding and
    … …  
    197155// along with this program; if not, write to the Free Software
    198156// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
    199 ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    200157
Note: See TracChangeset for help on using the changeset viewer.