[197] | 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?
|
---|
[279] | 23 | ^^^^^^^^^^ CANCELED ^^^^^^^^^^^^^
|
---|
[197] | 24 |
|
---|
| 25 | (5 Kann) Die Orientierung im Logfile wäre einfacher, wenn vor jede
|
---|
| 26 | Ausgabezeile eine Zeitmarke und der zugehörige Mountpoint geschrieben
|
---|
| 27 | werden könnten. Das mit der Zeitmarke ist sicher machbar. Das mit
|
---|
| 28 | dem zugehörigen Mountpoint könnte ein Problem sein. Wenn es ein
|
---|
| 29 | größeres Problem ist, dann bitte weglassen.
|
---|
| 30 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
| 31 |
|
---|
| 32 | (8 Kann) Falls Rückmeldung vom Caster:
|
---|
| 33 |
|
---|
| 34 | Caster Response: HTTP/1.1 401 Unauthorized
|
---|
| 35 |
|
---|
| 36 | dann die Sourcetable nochmals anfordern und das Datenfeld
|
---|
| 37 | Nummer 8 des zugehörigen NET-Records im Logfile mit ausgeben
|
---|
| 38 | damit der Nutzer weiss, wo er sich registrieren lassen muss für
|
---|
| 39 | User-ID und Password. Die Zeile im Logfile könnte z.B. lauten:
|
---|
| 40 |
|
---|
| 41 | Adjust User-ID and Password Register through
|
---|
| 42 | http://igs.bkg.bund.de/index_ntrip_reg.htm
|
---|
| 43 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
| 44 |
|
---|
| 45 | (9 Kann) Im Default-RINEX-Header die Zeile:
|
---|
| 46 |
|
---|
| 47 | GENERATED FROM RTCM 2.x STREAM ON www.igs-ip.net COMMENT
|
---|
| 48 | ändern in
|
---|
| 49 | RTCM 2.x STREAM ON www.igs-ip.net COMMENT
|
---|
| 50 |
|
---|
| 51 | Begründung: bei langen IP-Adressen wird Platz gebraucht, deshalb
|
---|
| 52 | "generated from" einfach weglassen.
|
---|
| 53 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
| 54 |
|
---|
| 55 | (3, Luxus) "Get Data" durch zwei Buttons "Start" und "Stop" unten auf dem
|
---|
| 56 | Hauptfenster ersetzen. Den jetzigen Button "Quit" so lassen wie er
|
---|
| 57 | ist.
|
---|
| 58 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
| 59 |
|
---|
| 60 | (7 Absoluter Luxus) Ladebalken aus sich bewegendem graphischen Element
|
---|
| 61 | einführen um dem Nutzer zu bestätigen, dass BNC am
|
---|
| 62 | Arbeiten ist.
|
---|
| 63 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
| 64 |
|
---|
[272] | 65 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 70 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 82 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 88 |
|
---|
[279] | 89 | (4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen
|
---|
| 90 | Ausnahme. Die Mountpoints:
|
---|
[272] | 91 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 115 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 120 |
|
---|
[279] | 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
|
---|
[272] | 125 |
|
---|
[279] | 126 | sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
|
---|
[272] | 127 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 131 |
|
---|
[279] | 132 | (7) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP
|
---|
| 133 | Broadcaster angefordert wird. Beispiel:
|
---|
[272] | 134 |
|
---|
[279] | 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 ^^^^^^^^^^^^^
|
---|
[272] | 160 |
|
---|
[279] | 161 | (8) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit
|
---|
| 162 | ausgeben? Z.B.:
|
---|
[272] | 163 | 30.000 INTERVAL
|
---|
[279] | 164 | fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software
|
---|
| 165 | einen solchen Record erwartet.
|
---|
[281] | 166 | ^^^^^^^^^^ CANCELED ^^^^^^^^
|
---|
[272] | 167 |
|
---|
| 168 | (9) Sollten wir in die Routinen irgendwie eine Datei Copyright.cpp aufnehmen
|
---|
[279] | 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:
|
---|
[272] | 174 |
|
---|
| 175 | // Part of BNC, a utility for retrieving decoding and
|
---|
| 176 | // converting GNSS data streams from NTRIP broadcasters,
|
---|
| 177 | // written by Leos Mervart.
|
---|
| 178 | //
|
---|
| 179 | // Copyright (C) 2006
|
---|
| 180 | // German Federal Agency for Cartography and Geodesy (BKG)
|
---|
| 181 | // http://www.bkg.bund.de
|
---|
| 182 | // Czech Technical University Prague, Department of Advanced Geodesy
|
---|
| 183 | // http://www.fsv.cvut.cz
|
---|
| 184 | //
|
---|
| 185 | // Email: euref-ip@bkg.bund.de
|
---|
| 186 | //
|
---|
| 187 | // This program is free software; you can redistribute it and/or
|
---|
| 188 | // modify it under the terms of the GNU General Public License
|
---|
| 189 | // as published by the Free Software Foundation, version 2.
|
---|
| 190 | //
|
---|
| 191 | // This program is distributed in the hope that it will be useful,
|
---|
| 192 | // but WITHOUT ANY WARRANTY; without even the implied warranty of
|
---|
| 193 | // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
---|
| 194 | // GNU General Public License for more details.
|
---|
| 195 | //
|
---|
| 196 | // You should have received a copy of the GNU General Public License
|
---|
| 197 | // along with this program; if not, write to the Free Software
|
---|
| 198 | // Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
---|
[280] | 199 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
[272] | 200 |
|
---|