Custom Query (105 matches)
Results (55 - 57 of 105)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #106 | fixed | BNC Client v 2.12.6 latency metrics stop recording in the log at beginning of UTC week | ||
| Description |
Hello, We are running the BNC Client to collect latency metrics and create 1s Rinex2 files from our streaming stations across New Zealand. We manage about 50 streaming sites with one instance of the BNC client. We have upgraded to the latest BNC version (2.12.6) last week on 2018/05/16. BNC Client stopped logging metrics at the beginning of the midnight of UTC day 2018- 05-20. The latency records restarted normally after a restart of the BNC Client. I have enclosed the configuration file we use with the BNC Client (only username and password are changed in there) and the BNC log file for the day that had the latency metrics dropping off. We run BNC Client on: Linux 3.10.0-862.2.3.el7.x86_64 x86_64 x86_64 x86_64 GNU/Linux with the following command: /usr/local/bin/bnc -nw --conf /work/bnc/conf/BNC.ini I know that our colleagues at Geoscience Australia are having the same problem, and they experienced the same behavior at the beginning of each UTC week. We were previously using v 2.12.3 of the software with no issues. Thanks a lot for your attention, Kind regards, Elisabetta --- Elisabetta D’Anastasio Geodetic Processing Specialist Geohazards Monitoring Department, GNS Science - Te Pῡ Ao |
|||
| #110 | fixed | Missing GLONASS slot numbers in RINEX | ||
| Description |
I have BNC 2.12.6 generating RINEX 3 observation files for a number of stations that have RTCM MSM 4 streams. The manual indicates that in order to decode the slot number I need to add an ephemeris stream with message 1020. I have added the RTCM3-MGEX IGS stream for this. I can see I am getting GLONASS ephemerides as BNC will write out the RINEX 3 navigation file with this data. However all my observation files have an empty GLONASS slot header:
|
|||
| #112 | fixed | Case sensitive when checking request headers, not HTTP standard | ||
| Description |
Hello, we receveived an email describing a problem with the professional NtripCaster: "One thing I just happened to notice is that the caster seems to be case sensitive when checking request headers. It would be nice if this was case insensitive to follow the HTTP standard. This was an issue for me because I was trying to use a service which converts request headers to lowercase and so all requests were NTRIP v1 because "ntrip-version" isn't "Ntrip-Version", and since v1 responses aren't HTTP they were being dropped by the service." Best regards, Peter Neumaier |
|||
