Index: trunk/BNC/todo.txt
===================================================================
--- trunk/BNC/todo.txt	(revision 1133)
+++ trunk/BNC/todo.txt	(revision 1134)
@@ -18,5 +18,5 @@
 
 (*) Outlier in orbit corrections, concerning only GLONASS.
-Comment from Georg: I don't have an idea where to look for the problem.
+GW: I don't have an idea where to look for the problem.
 Does anybody have an idea for a test scenario?
 
@@ -42,4 +42,8 @@
 Reason: DRL provides clocks and orbits with 30sec sampling.
 
+GW 08-09-24: DLR again started to send SP3 stream to euref-ip.bkg.bund.de:7777
+BNS can't handle that because of 30sec sampling. DLR promised to switch
+to 10sec within the next 2 months.
+
 (*) I found line "TODO: handle old ephemeris" in bns.cpp
 
@@ -47,12 +51,12 @@
 BNC
 =========================
-(*) Georg: Keep an eye on www.igs-ip.net/PENC0.
+(*) GW: 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.
+GW 08-09-15: 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.
+data available? Deleted PENC0 from the configuration.
 
 (*) Die BNC-Routine füllt den rtcm3torinex-Puffer byteweise.  Das ist unnötig
@@ -67,5 +71,5 @@
 
 (*) Zdenek: Include Loss of Lock indicator in socket output for RTNet
-Comment from Georg: Doesn't have this consequences for RTNet?
+GW: Doesn't have this consequences for RTNet?
 
 (*) Concerning the new RTCMv3 clock/orbit messages, it looks like