BNS 
=========================
(*) BNS reconnect behavior with respect to caster is sometimes a problem.
I checked the situation with breaking/re-establishing the Internet
connection. BNS just stops operation.

LM: it should be better now. At least it works fine on my notebook.
GW: Started BNS on euref-ip with BNC and RTNet on clock-ip.

(*) BNS reconnect behavior with respect to BNC is sometimes a problem.
Reason: Once BNC is stopped and restarted, BNS does not continue
its operation.

LM: it should be better now. At least it works fine on my notebook.
GW: Started BNS on euref-ip with BNC and RTNet on clock-ip.

(*) Outlier in orbit corrections, concerning only GLONASS.
Comment from Georg: I don't have an idea where to look for the problem.
Does anybody have an idea for a test scenario?

LM: I do not see the problem right now (on my notebook). Maybe is is already
    O.K. due to other changes. Georg, could you test it?
GW: Test is running in euref-ip.

(*) DLR started (and unfortunately meanwhile stopped) sending 30sec
SP3 in realtime to euref-ip.bkg.bund.de:7777. Andre Hauschild promised
to restart sending SP3 again after the upcoming ION once he is back in Germany.

(*) Allow dummy clock values 999999.999999 as input?
Reason: DLR real-time engine (Oliver Montenbruck) uses dummies.
The general question behind this is: Could it be done that the
input for BNS(from RTNet) is more closely coming in SP3 format?
The differences to SP3 we have today are just the 999999.999999
and the 2i/3i integers for orbit and clock corrections.
However, this touches RTNet's output.

(*) How about clocks and orbits coming in sampling rates .ne. 1sec? 
Does it make sense to support i.e. 3sec/5sec/10sec?
Reason: DRL provides clocks and orbits with 30sec sampling.

(*) I found line "TODO: handle old ephemeris" in bns.cpp


BNC
=========================
(*) Georg: Keep an eye on www.igs-ip.net/PENC0.
Reason: Have seen 100% CPU. Dirk Stoecker says he has not seen
this over a period of several days. He also says the reason
could actually only be that the decoding function is called
although no new data available.
Georg, observation from 080915: BNC again shows 100% CPU because of PENC0.
Could it really be that the decoder is called although no new
data available? I deleted PENC0 from the configuration.

(*) Die BNC-Routine füllt den rtcm3torinex-Puffer byteweise.  Das ist unnötig
langsam. Der Puffer kann bis zum Rand gefüllt werden.

LM: Das ist doch nicht wahr! Wo? In RTCM3/RTCM3Decoder.cpp fuellt man das
    "_Parser.Message" mit "_Parser.NeedBytes" und erst dann startet das
    dekodierung. Oder sprechen wir ueber einer anderen Stelle?
GW: Dirk Stoecker is informed. I asked him to comment on this.

(*) Zdenek: Include GLONASS in RTCMv2 20/21 messages.

(*) Zdenek: Include Loss of Lock indicator in socket output for RTNet
Comment from Georg: Doesn't have this consequences for RTNet?

(*) Concerning the new RTCMv3 clock/orbit messages, it looks like
RTCM will now exchange input files between manufacturers. Each
Manufacturer will do the encoding and decoding and results will
be exchange to check them.
Leos: BNC can't read from files. Would it be possible to have an
additional function in BNC which allows that? (It may be, that
this is not easy to implement.) Input would be the full path
to the file plus a string describing the expected stream format.