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 | ^^^^^^^^^^ CANCELED ^^^^^^^^^^^^^
|
---|
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 |
|
---|
65 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
70 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
82 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
88 |
|
---|
89 | (4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen
|
---|
90 | Ausnahme. Die Mountpoints:
|
---|
91 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
115 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
120 |
|
---|
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
|
---|
125 |
|
---|
126 | sleep: 2+rand,4+rand,8+rand,16+rand,32+rand,64+rand,128+rand
|
---|
127 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
131 |
|
---|
132 | (7) BNC laesst es zu, dass ein Datenstrom zweifach vom selben NTRIP
|
---|
133 | Broadcaster angefordert wird. Beispiel:
|
---|
134 |
|
---|
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 ^^^^^^^^^^^^^
|
---|
160 |
|
---|
161 | (8) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit
|
---|
162 | ausgeben? Z.B.:
|
---|
163 | 30.000 INTERVAL
|
---|
164 | fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software
|
---|
165 | einen solchen Record erwartet.
|
---|
166 | ^^^^^^^^^^ CANCELED ^^^^^^^^
|
---|
167 |
|
---|
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:
|
---|
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.
|
---|
199 | ^^^^^^^^^^ DONE ^^^^^^^^^^^^^
|
---|
200 |
|
---|