Custom Query (104 matches)

Recently I bought a ntripcaster from bkg. I installed it with the help of manual provided by your side. Evrything is in /usr/local/ntripcaster. I created a admin in /usr/local/ntripcaster/users.aut and added the user to a group. The group was mounted on /admin. But after I login through the web interface <myip/admin> I cannot create users or mountpoints there. All i can do is view sources,listeners etc. I cannot create users or mountpoints. What shoul I do now?

I am using BNC v2.12.18 under Windows 10 64-bit. I have configured it to receive an NTRIP stream containing RTCM3 messages from a local caster, and this appears to be working. I now wish to configure BNC to forward the RTCM3 messages to a serial-connected GNSS receiver.

The GNSS receiver is an embedded module (mini-PCIe form factor) which appears in Windows as a virtual serial port (COM49). I have entered the mountpoint, port name and baud rate on the Serial Output tab, but BNC is consistently unable to open the port.

I have confirmed that the baud rate is correct and that the port exists in Device Manager.

I have confirmed that no other application has opened a connection to the port.

I have attached my BNC config file (with my credentials removed), a log file, and two screenshots.

What am I doing wrong?

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.