Custom Query (105 matches)

when trying to launch the BNC client v 2.12.9 on an Ubuntu 18.04 machine using the SSL certificate from ​https://cddis.nasa.gov/Data_and_Derived_Products/Caster_client_config.html the software encounters a segmentation fault

When trying to log some RINEX 3 observables on a ubuntu 18.04 machine using the bnc 2.12.9 ubuntu 64 machine I noticed that if the time zone is not set ones get the warning "Wrong observation epoch(s)" for each satellite and no RINEX file is produced. This does not happen if the time zone is set.

Hi. We have seen an issue with Galileo week rollover when we use BNC (2.12.10) to log the RTCM v3 straight to RINEX. We are getting message types 1045 and 1046 for Galileo, and for both we see in the RINEX files written by BNC that some messages received just after the week rollover (i.e. early on Sunday morning) have week number increment by 1 but the toe is still a high number (e.g. 604000) and the toc jumps forward by 1 week. I attach an example file when you can see this for E01, E05, E15 and others. From what I can tell, the receiver manufacturer is simply putting the week number of the message (i.e. when it was received) in the WN field in 1045 and 1046 and expecting that the user of the RTCM data will modify this as necessary (allowing for rollover) to derive the reference week number of the toe and toc, but this does not seem to be happening. Can you check how you are using the WN field in the 1045 and 1046 messages and confirm the correct interpretation of the RTCM standards? Thank you.