Custom Query (104 matches)

Dear BKG staff, we are running BKG Ntripcaster v 2.0.21, and monitoring RTCM3 streaming latencies with BNC Client 2.10 (log latency set to every 5 minutes).

We probably found a bug (or something we could not explain) in one of the modules of the BKG Ntripcaster software.

The module src/source.c has a variable named READ_RETRY_DELAY

The value for this is set to 400. Leaving this value, we observe an unexpected high latencies on all of our data streams. If we change the variable to a lower value (we are currently using READ_RETRY_DELAY value of 50), latencies measured by BNC Client decrease systematically by about 0.5 seconds.

The figure attached shows an example for AUCK_RTCM streaming. Red values are the one with READ_RETRY_DELAY set as default (400), whereas green values has this value set to 50. Any comments/suggestions from you would be really appreciated!

Thanks,

Elisabetta D'Anastasio GNS Science - Te Pu Ao

I used BNC (version 2.8 and 2.10) in post processing mode to validate my own software i am currently working on. When i compared the orbits and clocks i found a difference which is caused by the use of the orbit and clock corrections. I attached an advanced log file of BNC. As you can see it seems that their is a shift of one epoch between the orbit and clock corrections and the epoch processed. So in the first epoch at 00:00:00 the corrections of 00:00:30 are applied. In case of the orbits this has almost no effect but it hase a big effect on the clocks. But maybe i am just getting something wrong.

Best regards, Fabian

First message from Loukis:

Attached is a spreadsheet with the results of a manual reconstruction of the clocks for two GLONASS satellites and comparison against the batch files. The following are noted:

1. There is a bias in the DLR results which is constant for both satellites
   
2. The BKG and CNES results are very close for R02 (non-zero drift term) but significantly different for R01 (zero drift term). The BKG difference for R01 is very large.
   
3. The GMV results for R02 are closer than for R01, but still different.
   

My suspicion is that there is a problem in using the GLONASS brdc drift term (or a misunderstanding on my part). In any case I am attaching extracts of the BNC decoded CLK files, the batch clock files that are submitted by the ACs, the reconstructed clock files that I generated and the brdc file for the relevant epoch (from CDDIS). Please note that the results I generated (gma, bka, cna, dla) are in exact agreement with the manual reconstruction in the spreadsheet. Also, the GPS results are very close, showing that the GPS satellites are properly encoded and decoded.

Files attached

Test results from Andrè Hauschild:

1. I can confirm a 400ns (=120m) offset, which is identical for all GLONASS satellites, which corresponds to the GPS-GLONASS system time offset.
   
2. After removing this offset, the batch and SSR clocks are virtually identical (~1mm level differences).
   

I conclude from these findings, that your way and my way of converting from RTCM-SSR to SP3 are consistent.
The 400ns-offset for all GLONASS sats shows up, because the clocks in my batch and my SSR solution refer to different system times. I could remove this offset, but I do not believe it does any harm (SPP/PPP users should estimate separate GPS and GLONASS clocks in any case), so I would prefer not having to make a software update. However, please let me know your thoughts on this!

Concluding remarks from Loukis:
Andre’s response reinforces my suspicion that there is an issue in the BNC encoding for GLONASS clocks where the drift term is non-zero.