Custom Query (104 matches)

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

Hello,

We are using the BKG Ntrip Caster in the following setup:

Corrections Data Source [IPv4 / UDP / RTP / RTCM] -> BKG Caster [TCP / NTRIP] <-> Web Proxy [IPv4 / TCP / TLS / NTRIP] <-> BNC

What we found is that the following check in store_udp_data() at main.c:997:

if((int)(seq-con->udpbuffers->seq) > 0)

Is always false once the Corrections Data Source has sent more than 65535 messages, which is the maximum number of messages that can be sent without repeating sequence numbers in RTP (the sequence numbers wrap around 0). After some seconds, the mountpoint expires.

We believe the Caster should be able to support wrap around of sequence number for very long-lived mountpoints. Is that limit imposed in some standard?

The check could be changed to something like

#define MAX_RTP_SEQNUM 0x00FFFFU #define MAX_PACKETS_IN_FLIGHT (MAX_RTP_SEQNUM/2) choose a value between 1 and MAX_RTP_SEQNUM

if ((seq != con->udpbuffers->seq) && (((seq - con->udpbuffers->seq) & MAX_RTP_SEQNUM) <= MAX_PACKETS_IN_FLIGHT))

so that it would allow jumps of upto MAX_PACKETS_IN_FLIGHT RTP messages. We have found that this proposed check is similar to the ones performed in rtp_recieve_datagram_buffered() in rtp.c.

Given that the old check allowed jumps from 0 to 65535, MAX_PACKETS_IN_FLIGHT could be set upto to MAX_RTP_SEQNUM, but this would allow accepting packets potentially from the past if there is a very high rate of packets per second, which it didn't with the original check. Thus a threshold less than half the range seems reasonable (and it would be very similar to the checks in rtp.c).

We would like some feedback on this issue and the proposed solution.

Thank you, Kind regards.

Since BNC 2.6 the GLONASS ephemerids are stored in the GPS navigation file. The GLONASS navigation file only contains the header.