Changeset 272 in ntrip


Ignore:
Timestamp:
Nov 7, 2006, 5:53:32 PM (18 years ago)
Author:
weber
Message:

* empty log message *

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/BNC/todo.txt

    r197 r272  
    6262^^^^^^^^^^ DONE ^^^^^^^^^^^^^
    6363
     64
     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
     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.
     68
     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.
     70
     71(4) Das mit den Skeleton-Files funktioniert prima - mit einer kleinen Ausnahme. Die Mountpoints:
     72
     73WETTZELL
     74FRANKFURT
     75FRANCE
     76BRUS0
     77BRUS0
     78
     79weürden im Augenblick folgende Skeleton-Files suchen
     80
     81WETT.skl
     82FRAN.skl
     83BRUS.skl
     84
     85Ich denke wir sollten das so einstellen, dass nach Skeleton-Files des endgültigen Dateinamens gesucht wird, also:
     86
     87WETT.skl
     88FRAN_KFURT.skl
     89FRAN_CE.skl
     90BRUS_0.skl
     91BRUS_1.skl
     92
     93Ich hoffe, das ist nicht zu kompliziert einzurichten.
     94
     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.
     96
     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
     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) 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) Kannst Du im RINEX-Header noch einen Record fuer das Sampling mit ausgeben? Z.B.:
     124    30.000                                                  INTERVAL
     125fuer 30sec Sampling. Die Kollegen sagen mir, dass die Berner Software einen solchen Record erwartet.
     126
     127(9) 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:
     132
     133// Part of BNC, a utility for retrieving decoding and
     134// converting GNSS data streams from NTRIP broadcasters,
     135// written by Leos Mervart.
     136//
     137// Copyright (C) 2006
     138// German Federal Agency for Cartography and Geodesy (BKG)
     139// http://www.bkg.bund.de
     140// Czech Technical University Prague, Department of Advanced Geodesy
     141// http://www.fsv.cvut.cz
     142//
     143// Email: euref-ip@bkg.bund.de
     144//
     145// This program is free software; you can redistribute it and/or
     146// modify it under the terms of the GNU General Public License
     147// as published by the Free Software Foundation, version 2.
     148//
     149// This program is distributed in the hope that it will be useful,
     150// but WITHOUT ANY WARRANTY; without even the implied warranty of
     151// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
     152// GNU General Public License for more details.
     153//
     154// You should have received a copy of the GNU General Public License
     155// along with this program; if not, write to the Free Software
     156// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
     157
Note: See TracChangeset for help on using the changeset viewer.