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