source: ntrip/trunk/BNC/todo.txt@ 1129

Last change on this file since 1129 was 1129, checked in by weber, 16 years ago

* empty log message *

File size: 3.3 KB
Line 
1BNS
2=========================
3(*) BNS reconnect behavior with respect to caster is sometimes a problem.
4I checked the situation with breaking/re-establishing the Internet
5connection. BNS just stops operation.
6
7LM: it should be better now. At least it works fine on my notebook.
8GW: Started BNS on euref-ip with BNC and RTNet on clock-ip.
9
10(*) BNS reconnect behavior with respect to BNC is sometimes a problem.
11Reason: Once BNC is stopped and restarted, BNS does not continue
12its operation.
13
14LM: it should be better now. At least it works fine on my notebook.
15GW: Started BNS on euref-ip with BNC and RTNet on clock-ip.
16
17(*) Outlier in orbit corrections, concerning only GLONASS.
18Comment from Georg: I don't have an idea where to look for the problem.
19Does anybody have an idea for a test scenario?
20
21LM: I do not see the problem right now (on my notebook). Maybe is is already
22 O.K. due to other changes. Georg, could you test it?
23
24(*) DLR started (and unfortunately meanwhile stopped) sending 30sec
25SP3 in realtime to euref-ip.bkg.bund.de:7777. Andre Hauschild promised
26to restart sending SP3 again after the upcoming ION once he is back in Germany.
27
28(*) Allow dummy clock values 999999.999999 as input?
29Reason: DLR real-time engine (Oliver Montenbruck) uses dummies.
30The general question behind this is: Could it be done that the
31input for BNS(from RTNet) is more closely coming in SP3 format?
32The differences to SP3 we have today are just the 999999.999999
33and the 2i/3i integers for orbit and clock corrections.
34However, this touches RTNet's output.
35
36(*) How about clocks and orbits coming in sampling rates .ne. 1sec?
37Does it make sense to support i.e. 3sec/5sec/10sec?
38Reason: DRL provides clocks and orbits with 30sec sampling.
39
40(*) I found line "TODO: handle old ephemeris" in bns.cpp
41
42
43BNC
44=========================
45(*) Georg: Keep an eye on www.igs-ip.net/PENC0.
46Reason: Have seen 100% CPU. Dirk Stoecker says he has not seen
47this over a period of several days. He also says the reason
48could actually only be that the decoding function is called
49although no new data available.
50Georg, observation from 080915: BNC again shows 100% CPU because of PENC0.
51Could it really be that the decoder is called although no new
52data available? I deleted PENC0 from the configuration.
53
54(*) Die BNC-Routine füllt den rtcm3torinex-Puffer byteweise. Das ist unnötig
55langsam. Der Puffer kann bis zum Rand gefüllt werden.
56
57LM: Das ist doch nicht wahr! Wo? In RTCM3/RTCM3Decoder.cpp fuellt man das
58 "_Parser.Message" mit "_Parser.NeedBytes" und erst dann startet das
59 dekodierung. Oder sprechen wir ueber einer anderen Stelle?
60
61(*) Zdenek: Include GLONASS in RTCMv2 20/21 messages.
62
63(*) Zdenek: Include Loss of Lock indicator in socket output for RTNet
64Comment from Georg: Doesn't have this consequences for RTNet?
65
66(*) Concerning the new RTCMv3 clock/orbit messages, it looks like
67RTCM will now exchange input files between manufacturers. Each
68Manufacturer will do the encoding and decoding and results will
69be exchange to check them.
70Leos: BNC can't read from files. Would it be possible to have an
71additional function in BNC which allows that? (It may be, that
72this is not easy to implement.) Input would be the full path
73to the file plus a string describing the expected stream format.
74
Note: See TracBrowser for help on using the repository browser.