Changeset 1134 in ntrip

Timestamp:

Sep 24, 2008, 3:45:15 PM (17 years ago)

Author:

weber

Message:

* empty log message *

File:

• trunk/BNC/todo.txt (modified) (4 diffs)

trunk/BNC/todo.txt ¶

@@ -18 +18 @@
 
 (*) 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 +42 @@
 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 +51 @@
 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 +71 @@
 
 (*) 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