__group__	ticket	summary	component	version	type	owner	status	created	_changetime	_description	_reporter
BNC 2.1	216	Galileo HAS corrections vary from ones, recieved via E6B signal	BNC	BNC 2.1	defect	stuerze	new	2026-05-01T19:54:35+02:00	2026-05-12T16:57:01+02:00	"A discrepancy has been observed in the Galileo High Accuracy Service (HAS) orbit corrections when comparing data distributed via BNC Ntrip Caster against data received directly from the Galileo E6B Signal-in-Space (SIS).

The issue affects the radial component of the orbit corrections. The streams recieved through BNC show a measurable offset in the radial component (orbit correction) compared to the same data, recieved via SIS. This affects whole Galileo constellation (~8-10cm offset) and several GPS satellites (~65-70cm offset). Two files with corrections are attached.
Thank you in advance.
With regards,
Vladyslav Kerker."	vladyslav.v.kerker@…
BNC 2.2	213	BNC 2.13.4 macOS build blocked by Gatekeeper and crashes due to invalid code signature (Code 2, CODESIGNING)	BNC	BNC 2.2	defect	stuerze	new	2026-02-14T15:10:22+01:00	2026-05-19T12:02:28+02:00	"Dear BNC Development Team,
I would like to report an issue with the macOS build of BNC 2.13.4.
On macOS 26.3 (Apple Silicon, M2), the application initially shows the system warning:
“bnc.app is damaged and can’t be opened. You should move it to the Trash.”
After manually removing the quarantine attribute, the application no longer shows the “damaged” message, but it immediately crashes on launch with:

Termination Reason: Namespace CODESIGNING, Code 2
Exception Type: SIGKILL (Code Signature Invalid)
The crash report also shows the bundle identifier as:
com.yourcompany.bnc

As a temporary workaround, I was able to run the application by re-signing it locally using:
codesign --force --deep --sign - /Applications/bnc.app

After applying an ad-hoc signature, the application launches and runs normally.
It appears the distributed macOS build may not be properly signed and/or notarized. On current macOS versions, this results in Gatekeeper blocking the application and the system terminating the process at launch.
Could you please confirm whether the macOS build is intended to be signed and notarized for distribution?
Best regards,
Arda Yeşil"	ardayesil@…
	201	Connect BKG NtripCaster to LDAP using LDAP authentication	Professional Caster		defect	stoecker	new	2025-03-06T13:54:40+01:00	2025-03-11T11:13:31+01:00	"Dear BKG team,

We are trying to integrate our BKG NtripCaster V2.0.47 with an LDAP server using simple LDAP authentication (i.e. providing the bind DN and bind password) but we don't know if the BKG supports the LDAP bind authentication and in this case how to configure it. We have tried several options using the configuration ldap parameters included in the ntripcaster.conf but we couldn't make it work.

For us this is relevant as, due to cybersecurity constraints, the anonymous access to the LDAP server is not permitted and we need to integrate our external caster with a LDAP directory for managing the access of external users to our Galileo Ntrip service.

Thank you in advance!!
Jorge
"	jrocamora@…
	205	BKG NTRIP client seems not to open com ports with higher numbers, e.g. COM11 or COM17	BNC		defect	stuerze	new	2025-04-03T13:45:46+02:00	2025-07-01T14:30:44+02:00	"We are using the BKG client to provide correction data streams to uBlox f9P receivers. We now faced the issue that it seems we can not open serial connections for com ports with higher numbers, e.g. COM17. This has been observed on multiple PCs.

The issue was discovered after we changed the test PC which needed re-installation of GNSS receivers (leading to different com port mapping for the same receivers compared to the old PC). The BKG client version was 12.xxx but we also now updated to the recent version.

On the PC multiple GNSS receivers are connected and the correct ports are used, i.e. RTCM corrections can be provided on this ports theoretically. While we can successfully open the connection to ports like COM4. Stopping the client and using the same settings for higher ports (multiple receivers are connected at same time with same settings) leads to the connection is not being accepted.

In the below example we automatically try to open the connection which fails. Than we manually just change the com port number from 17 (receiver 1) to Com5 (another receiver) and it immediately works (the name of the file coincidentally has ""...Com5.bnc"" in it on, on another PC it is between com11 not working and com4 working).


25-04-03 11:29:59 ========== Start BNC v2.13.2 (WIN32) ==========
25-04-03 11:29:59 Panel 'Serial Output' active
25-04-03 11:29:59 RS01: Cannot open serial port

25-04-03 11:29:59 RS01: Get data in RTCM 3.x format
25-04-03 11:29:59 Configuration read: tests/Gnss/RTK/BNC_Template_NTRIP_viaPort4022ToCom5.bnc, 1 stream(s)
25-04-03 11:32:09 ========== Start BNC v2.13.2 (WIN32) ==========
25-04-03 11:32:09 Panel 'Serial Output' active
25-04-03 11:32:09 RS01: Get data in RTCM 3.x format
25-04-03 11:32:09 Configuration read: tests/Gnss/RTK/BNC_Template_NTRIP_viaPort4022ToCom5.bnc, 1 stream(s) "	carsten.stoeber@…
	206	BNC for IPAD	Other		defect	wiese	assigned	2025-04-16T07:16:52+02:00	2026-05-19T12:01:35+02:00	is there a BNC that will run on Apple IPAD from what i can tell there is none on the download page. Thanks	nick.townsend@…
	215	Difference observed with BNC RT latency	Other		defect	stuerze	assigned	2026-04-15T09:19:57+02:00	2026-05-04T17:08:36+02:00	"We observe a difference of latency in RTCM real time logs between BNC 2.12.17 and last BNC 2.13.4.

If a RT RTCM MSM7 flow doesn’t contain 1127 packet (MSM7 Beidou) and 1042 packet (Beidou ephemeris),
-	When using BNC 2.13.4, latency looks good :
26-04-14 15:15:00 SAG100FRA1 Observations: Mean latency 0.27 sec, min 0.06, max 0.50, rms 0.29, 900 epochs, 0 gaps
-	When using BNC 2.12.17 latency is increased of 1 second which looks abnormal (local network test conditions for this log) :
26-04-14 15:45:01 SAG100FRA1 Observations: Mean latency 1.27 sec, min 1.07, max 1.57, rms 1.28, 900 epochs, 0 gaps
If we add this Beidou packets, latency is the same for both versions.
Are you aware of that and if yes, can you tell us in which version it was fixed? Is it mentioned in changelog?

Thank you

CNES REGINA Team
Thierry Lawrence
regina.operation@cnes.fr"	regina.operation@…
	218	Technical Support: High RAM usage/data drop issues and mountpoint relay failures in BNC 2.13.2+	BNC		defect	stuerze	new	2026-05-26T13:23:57+02:00	2026-06-09T11:47:51+02:00	"Dear BKG BNC Support Team,
We are currently encountering two critical issues after upgrading from BNC version 2.13.1, and we would appreciate your guidance or any suggestions you can provide.
**Environment Details:**
**OS / Environment:** Ubuntu 24.04 running inside Docker containers.
**Execution:** We run BNC in no-window mode using the -nw option (generally launched as /opt/bnc-[version] -nw -conf BNC.ini).
**Working Version:** 2.13.1 (and v2.13.2 for the relay feature)
**Problematic Versions:** 2.13.2 & 2.13.4 (RAM issue) / 2.13.4 (Relay issue)
**Server Specs:** Tested across multiple environments, including a 256 GB RAM / HDD setup.

**Issue 1:** High RAM Usage and Data Drops (v2.13.2 & v2.13.4)
When running BNC 2.13.2 and 2.13.4, the application begins to ignore incoming data, and its RAM usage climbs exponentially—reaching up to 100 GB on our 256 GB machine.
Here is some information regarding this:
We do not experience this issue in Version 2.13.1 under the exact same load.
We initially thought this might be related to HDD disks not handling the I/O load, but version 2.13.1 works perfectly with the exact same HDD setup.
We have replicated this RAM issue across different machines running the same Ubuntu 24.04 Docker setup.
While it happens consistently with a large number of mountpoints, we have also occasionally experienced it when testing with a low number of mountpoints.
The issue appears significantly more likely to happen if the casters are accessed via a secure port (e.g., 443, 2102).
Has there been a change in how BNC handles internal queuing, threading, or secure port connections in no-window mode within these newer versions that could account for this memory accumulation?

**Issue 2:** Mountpoint ""Relay"" Feature in v2.13.4
In version 2.13.1, we successfully used BNC to relay a specific mountpoint to an internal service. Our configuration relied primarily on the following options:
mountPoints
casterPort
miscMount
miscPort
This setup allowed a downstream service (for example, running str2str -in tcpcli://my_server:port/MOUNTPOINT) to successfully listen to and consume the relayed mountpoint.
As of version 2.13.4, this functionality has stopped working for us.
The incoming data works and can be seen in a file if the outFile option is used
Could you please indicate if there was a change to how miscPort / casterPort broadcasting is handled in the latest release, or if we need to adjust our configuration format to achieve the same result?
We would be happy to provide our configuration files (BNC.ini) or bnc log outputs if that helps diagnose the issue. Looking forward to your insights.

Many thanks for the help in advance,

Best regards,"	altmb297@…
	219	make me download this pls	Other		defect	stuerze	assigned	2026-06-08T17:34:21+02:00	2026-06-11T22:35:50+02:00	Hello, i'd like to download the ntrip files but it seems like you can only download them one at a time, i'm a uni student doing a project.	riccardo.zordan2000@…
	170	structured logging	BNC		enhancement	stuerze	new	2023-12-07T09:11:23+01:00	2023-12-07T09:11:23+01:00	"Currently the logfiles are not easy to parse, as they are not structured. Nowadays the logs are often JSON formated or key=value pairs separated by spaces.
JSON example line: {{{{""level"":""debug"",""time"":""2023-12-07T08:03:47.162"",""sender"":""SCP"",""message"":""executed command \""/usr/local/bin/myHooks\"", elapsed: 1.007732187s, error: <nil>""}}}}

To facilitate the monitoring purposes with BNC, this should be introduced.
To discuss: 
- as new log to not break existing workflows?
- new log with metrics only?
- write to port instead of file?
- ...

See #168 and #108."	wiese
	195	BNC Analyze Elevation cut-off angle	Other		enhancement	team	new	2025-01-28T17:34:50+01:00	2025-02-28T10:55:13+01:00	"Hi BKG Team

It would be very interesting to be able to set an elevation cut-off angle for the analysis module. 
Similarly for the Edit module, being able to filter all observations below a certain threshold would be really cool."	sgonnet@…
	196	Users.aut modification	Professional Caster		enhancement	stoecker	new	2025-02-07T14:54:18+01:00	2025-05-14T15:08:51+02:00	"Hi,

We are currently working on a project based on your Professional Caster and have a question regarding the users.aut configuration file. 

From our understanding reading the manual, adding N users does not require a restart of the caster since a rehash can be commanded; however, editing a username or removing an existing user are actions that require this restart.

Is it possible to not restart the Caster after a user has been removed for the change to take place? In case that the current version does not allow it, is this a functionality planned to be included in the future?

Thanks in advance!
"	mvargasp
	210	"help on ""14_SaveSp3.bnc"""	BNC		task	stuerze	reopened	2025-05-30T00:00:21+02:00	2025-06-06T23:48:51+02:00	"HI,

This is a question that I need help with BNC 2.13.2.
I wanted to save corrections to SP3 file in CoM, and I'm using example config file ""14_SaveSp3.bnc"".
My question is that the example is using APC correction ""SSRA00BKG1"", so BNC is using ""igs20.atx"" to convert orbits to CoM?
What if I use CoM correction ""SSRC00BKG1"", and still check the ""CoM"" box, will BNC try to convert orbits to CoM again? (which will be wrong)

Best Regards,
Gary"	garyli@…
	220	Question about code BIA states and ionosphere constraints in BNC PPP	BNC		task	stuerze	new	2026-06-10T17:51:26+02:00	2026-06-10T17:51:26+02:00	"Dear BNC developers,

I am currently studying the PPP/PPP-AR model implemented in BNC 2.13.6, especially the dual-frequency uncombined PPP parameterization in the src/PPP/ path. I would like to ask for clarification about the theoretical interpretation of the code BIA states and the ionosphere constraint model in BNC.

In a GPS-only test configuration, for example:

PPP/lcGPS=P12&L12
PPP/constraints=no

my understanding is that the LC string is parsed as:

cG1, cG2, lG1, lG2

At the same time, the PPP filter creates the following code-bias-like states:

BIA cG1
BIA cG2

together with per-satellite ionosphere states ION and per-satellite, per-phase-LC ambiguity states. From my current reading of the source code and the PPP output, BIA cG1/cG2 appear to be real Kalman filter states, not merely diagnostic output quantities.

We also noticed that the common mode of BIA cG1/cG2 is datum-coupled with the receiver clock. BNC seems to regularize this direction through the prior variance of the code BIA states, for example through aprSigCodeBias. Therefore, we do not think that the absolute values of BIA cG1/cG2 should be interpreted as independently observable physical receiver code hardware delays.

According to my understanding of conventional dual-frequency UDUC PPP, when no external ionosphere product is used as a constraint, receiver code biases are usually not estimated as a separate receiver DCB parameter. Instead, they are absorbed through re-parameterization into receiver clock, ionosphere states, ambiguities, and related datum definitions. Explicit handling of receiver DCB becomes necessary mainly in ionosphere-constrained PPP, where GIM, SSR/VTEC/STEC, or regional ionosphere products are used to constrain the ionosphere states. Otherwise, receiver code biases may contaminate the ionosphere states and cause datum inconsistency with the external ionosphere constraints.

Therefore, my main question is why BNC still estimates BIA cG1/cG2 for the dual-frequency code LCs even when:

PPP/constraints=no

This seems different from a conventional minimal full-rank UDUC PPP parameterization. It looks more like a code-LC-wise bias-like nuisance-state parameterization.

Under this interpretation, BIA cG1/cG2 can be re-parameterized into a receiver-clock common component and a receiver-DCB-like differential combination, for example:

DCB_like = BIA cG2 - BIA cG1

However, the absolute values of BIA cG1/cG2 would then be datum-dependent and prior-dependent.

Could you please help clarify the following points?

1. What is the intended interpretation of BIA cG1 and BIA cG2? Should they be interpreted as physical receiver code hardware delays, or rather as datum-dependent code-bias-like nuisance states?
2. Why does BNC estimate separate BIA cG1/cG2 states for the enabled code LCs in dual-frequency uncombined PPP even when constraints=no and no external ionosphere constraint is used?
3. What is the recommended interpretation of aprSigCodeBias in the BNC model? Is it mainly a numerical regularization parameter, or should it also be understood as a physical prior for receiver code biases?
4. When ionosphere constraints are enabled, for example using GIM/IONEX or real-time SSR/VTEC/STEC ionosphere corrections, what exactly does the BNC ION state represent?an absolute slant ionosphere delay, or a residual correction with respect to the external ionosphere model?
5. Does the ionosphere pseudo-observation directly constrain the absolute value of the ION state, or does BNC first apply the external SSR/GIM ionosphere correction on the computed side and then constrain the residual ION state close to zero?
6. If the receiver code-bias datum and the external ionosphere-model datum are not perfectly consistent, why does BNC use an absolute ionosphere pseudo-observation rather than, for example, a satellite-differenced ionosphere constraint or an explicit receiver DCB random-walk parameter?
7. Is the BIA cG1/cG2 code BIA parameterization mainly intended to support ionosphere-constrained PPP, especially real-time SSR/VTEC/STEC ionosphere constraints, by reducing receiver-code-bias contamination in the ionosphere state? If so, why is the same code BIA parameterization retained when constraints=no?

I am asking these questions because this implementation appears to differ from some common IC-PPP formulations in the literature, where receiver DCB is explicitly handled mainly when external ionosphere constraints are introduced. In BNC, the BIA cG* states look more like code-LC-wise bias-like nuisance states, and they seem to be used independently of whether ionosphere constraints are enabled. I would like to understand and document the BNC model correctly and avoid misinterpreting these states as directly observable physical receiver hardware delays.

Thank you very much for providing BNC as open-source software, and thank you in advance for your help in clarifying these model details.

Best regards,
Melissa Grove"	asdf123hb67@…