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

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

* empty log message *

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