GNSSNTRIPClient: Logger Initialization Fails in Thread + Difficulty Achieving RTK-FIX

[Paulo-Junio]

Dear maintainers,

I am currently working on a Scientific Initiation project that uses pygnssutils and pyubx2 to implement a Python-based NTRIP client which injects RTCM corrections into a u-blox GNSS receiver through a serial connection.

I am facing two technical issues and would greatly appreciate any guidance or clarification.

1. Logging configuration issue when using GNSSNTRIPClient in a separate thread

When attempting to configure logging for the GNSSNTRIPClient running inside a dedicated thread (Windows, Python 3.11), I encounter the following error:

AttributeError: 'NoneType' object has no attribute 'setLevel'

This suggests that the logger instance returned inside the threaded context may be None.
Is there a recommended approach for safely initializing and configuring the logger for GNSSNTRIPClient in a multithreaded environment?
Should set_logging() be invoked before thread creation, or is there a specific pattern the library expects when running the client asynchronously?

2. Difficulty achieving stable RTK-FIX despite receiving RTCM corrections

The NTRIP connection is established successfully, and RTCM messages are being received and forwarded to the receiver’s serial port. However, the u-blox module remains in RTK-FLOAT or 3D-FIX, and does not converge to a stable RTK-FIX solution.

My current configuration:

Static IP, port, and mountpoint (RBMC – Brazil).

ggamode=1 with fixed reference coordinates (reflat, reflon, refalt) provided to satisfy the caster’s position requirement.

Output stream is directly connected to the serial port (output=serial_obj).

Using the default parameters for ggainterval and other GNSSNTRIPClient settings.

Is there any specific configuration detail — such as ggainterval, incorrect reference coordinates, or parameter interaction — that could be preventing the receiver from reaching RTK-FIX?
Does pygnssutils require any additional settings to optimize convergence for u-blox modules?

Thank you very much for your time and for the excellent work on these tools — they are invaluable to the GNSS research community. Any help or insight would be sincerely appreciated.

Additionally, I would like to share part of the code I am currently using.
The implementation is partially based on the architecture and threading model used in pygpsclient, adapted for my project’s requirements. I am including it below in case it helps clarify the context or highlight potential mistakes in how the NTRIP client, logging system, or RTCM injection pipeline are being handled. The module I use is UBLOX C102-F9R and the antenna is the ANN-MB-00-00.

[semuadmin]

Hi @Paulo-Junio

(quick safety tip - please embed any Python code snippets in the body of your message, rather than providing *.py attachments)

Logging configuration issue when using GNSSNTRIPClient in a separate thread

Have a look at the set_logging method here: https://github.com/semuconsulting/pygnssutils/blob/main/src/pygnssutils/helpers.py#L134

For general guidance on using Python logging within Threads, refer to (for example): https://coderivers.org/blog/python-logging-in-threads/

Difficulty achieving stable RTK-FIX despite receiving RTCM corrections

Not an easy question to answer - there could be any number of reasons why you're not obtaining an RTK FIXED status which may for example be environmental or hardware/antenna related, rather than code issues. Have a look at this wiki in the first instance, which may offer some clues for further investigation: https://www.semuconsulting.com/gnsswiki/rtktips/

Couple of observations on your start_ntrip_client() code:

                ggainterval=-1, # is this correct? this effectively disables GGA messages to the caster, so the following arguments are redundant
                ggamode=1,
                reflat=FIXED_LAT,
                reflon=FIXED_LON,
                refalt=FIXED_ALT,
                refsep=FIXED_SEP, # <== don't forget the geoid separation argument (it will default to 0, but that may not be correct)
                output=serial_obj, 

If your intention was to send GGA sentences to the caster, you need to set ggainterval to a value > 0 e.g. 60 seconds. Check the sourcetable entry for your RBMC mountpoint to see if GGA sentences are required.

As an aside, have you considered using gnssstreamer here? As far as I can understand your intentions from the code snippet you've provided, it may do most of what you need out of the box e.g. https://github.com/semuconsulting/pygnssutils#5-serial-input-with-concurrent-ntrip-rtk-input-outputting-to-python-lambda-expression

[semuadmin]

Hi @Paulo-Junio

I see you've removed your code snippet. Do you require any further assistance or shall I close this discussion?

[Paulo-Junio]

Hi, how are you?

I'm trying to implement the code using gnssstreamer, but without much success.

I'm still analyzing it a bit more so that, if I can't get it 100%, I can post a more complete question here.

[Paulo-Junio]

Hello @semuadmin ,

I'm implementing a Python GNSS logger for a u-blox F9R (C10) receiver using the pyubx2 and pygnssutils libraries (specifically GNSSStreamer). My goal is to receive NTRIP corrections and log navigation and observation data.

The issue I'm facing is that after initiating serial communication and sending the configuration messages (CFG-MSG), the GNSSStreamer is not triggering the outputhandler for the expected UBX messages (like NAV-PVT or RXM-RAWX). It seems the messages are either not being received or not being parsed by the streamer.

⚙️ Implementation Details

My script uses GNSSStreamer to manage the serial port (COM5) and the NTRIP connection. I send the CFG-MSG commands directly to the serial port before starting the streamer's thread.

1. Receiver Configuration (configure_ublox)
   I'm sending CFG-MSG to enable NAV-PVT, NAV-DOP, and RXM-RAWX on the UART1 port (Serial). I've corrected previous errors by using 'U1' for val2bytes and msgmode=1 for SET.

Python

Messages to be enabled on UART1 (Serial Port)

messages_to_configure = [
(0x01, 0x07, 1), # NAV-PVT at 1 Hz
(0x01, 0x04, 1), # NAV-DOP at 1 Hz
(0x02, 0x15, 1), # RXM-RAWX at 1 Hz
]

for msg_class, msg_id, rate in messages_to_configure:
# Payload to enable on UART1 (index 3) and USB (index 5)
full_payload = (
val2bytes(msg_class, 'U1') + val2bytes(msg_id, 'U1') +
val2bytes(0, 'U1') + # rate_DDC
val2bytes(rate, 'U1') + # rate_UART1
val2bytes(0, 'U1') + # rate_UART2
val2bytes(rate, 'U1') + # rate_USB
val2bytes(0, 'U1') + # rate_SPI
val2bytes(0, 'U1') # rate_res
)

# msgmode=1 for SET
cfg_msg = UBXMessage('CFG', 'CFG-MSG', payload=full_payload, msgmode=1)

# Writing to the serial port
serial_instance.write(cfg_msg.serialize())
time.sleep(0.1)

2. Streamer Initialization
   The streamer is configured to parse UBX messages and call the process_gnss_data callback.

Python

streamer = GNSSStreamer(
None, ser, protfilter=7, outputhandler=process_gnss_data,
# ... NTRIP and fixed position settings
)

streamer_thread = threading.Thread(target=streamer.run, daemon=True)
streamer_thread.start()

❓ The Current Problem

Serial Connection: The COM5 port is opened successfully.

UBX Configuration: The configure_ublox(ser) command executes without any pyubx2 errors (the previous TypeError and UBXMessageError are resolved).

Expected Output: After configuration, I should see log messages like "✅ Processando NAV-PVT!" (or equivalent) in the console, and the reported GNSS status should update.

Actual Output: The program remains in the main loop, printing the static, uninitialized status (Lat/Lon 0.0, Sol: NO_FIX). The process_gnss_data callback is never called for any UBX messages, suggesting the streamer is not receiving or parsing the required data.

I am not seeing any UBX data activity in the console.

💡 Hypotheses and Questions

Hypothesis 1 (Timing/Conflict): Could sending the CFG-MSG commands directly via ser.write() before starting the GNSSStreamer interfere with how the streamer initializes the port or its internal read buffer?

Hypothesis 2 (Receiver Default): The u-blox C10/F9R often defaults to NMEA output on its primary ports. Is it possible my CFG-MSG commands are being ignored or overwritten, or are they enabling the messages on a different port than the one I'm reading from (COM5)?

Question: What is the recommended method for configuring a u-blox receiver (like enabling UBX messages) when using the GNSSStreamer? Should the configuration messages be sent using the streamer's own internal methods, or is writing directly to the serial instance before calling streamer.run() acceptable?

Any guidance on how to confirm that the receiver is actively transmitting UBX data on COM5 after the configuration, or any known issues with this sequence of operations, would be greatly appreciated.

Thank you for your time and help!

[semuadmin]

Hi again @Paulo-Junio

If understand correctly, all you're trying to achieve here is:

1. configure F9P to output a specific set of UBX navigation and raw messages.
2. monitor the output of the F9P whilst receiving RTK corrections from an NTRIP caster.

This is a very common use case, and there are plenty of examples in the README for gnssstreamer, and also in the pyubx2 /examples folder, that illustrate exactly how to do this. I strongly recommend that you:

1. have another good look at the READMEs and examples for pygnssutils and pyubx2.
2. try using the examples exactly as provided in the first instance, and then improvise around them with your own code once you've established they do what you want.

In broad terms, for any modern u-blox GNSS receiver running UBX protocol >= 23.01 (which includes the F9P and X20P), refer to pyubx2's static UBXMessage.config_set() method, as clearly explained in the pyubx2 README.

So, for example, to create a configuration message which enables NAV-PVT and RXM-RAWX message types on the USB port at a rate of 1 per navigation solution:

from pyubx2 import UBXMessage, SET_LAYER_RAM, TXN_NONE

cfgData = [("CFG_MSGOUT_UBX_NAV_PVT_USB", 1), ("CFG_MSGOUT_UBX_RXM_RAWX_USB", 1)]
msg = UBXMessage.config_set(SET_LAYER_RAM, TXN_NONE, cfgData)
print(msg)

(if you're using a UART port, simply substitute '_USB' for '_UART1').

If you want to save this configuration for use with gnssstreamer on a repeatable basis, you could write these UBX messages to a binary file and then use that binary file as an input source in gnssstreamer, e.g.

from pyubx2 import UBXMessage, SET_LAYER_RAM, TXN_NONE

with open ("f9pconfig.ubx",'wb') as output:
    cfgData = [("CFG_MSGOUT_UBX_NAV_PVT_USB", 1), ("CFG_MSGOUT_UBX_RXM_RAWX_USB", 1)]
    msg = UBXMessage.config_set(SET_LAYER_RAM, TXN_NONE, cfgData)
    output.write(msg.serialize())

and then run gnssstreamer from the command line:

gnssstreamer --port COM5 --baudrate 38400 --cliinput 5 --input f9pconfig.ubx --verbosity 2

The output will look something like this, with the UBX command acknowledgements and outputs mixed in with any existing NMEA output...

2025-12-08 15:14:02.200 - INFO - pygnssutils.gnssstreamer - Starting GNSS reader/writer using Serial<id=0x107edbeb0, open=True>(port='COM5', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=3, xonxoff=False, rtscts=False, dsrdtr=False)...
...
<NMEA(GNGSA, opMode=M, navMode=3, svid_01=, svid_02=, svid_03=, svid_04=, svid_05=, svid_06=, svid_07=, svid_08=, svid_09=, svid_10=, svid_11=, svid_12=, PDOP=1.95, HDOP=1.08, VDOP=1.63, systemId=5)>
...
<UBX(ACK-ACK, clsID=CFG, msgID=CFG-VALSET)>
<UBX(RXM-RAWX, rcvTow=141267.996, ..., subHalfCyc_21=0, reserved3_21=0)>
<UBX(NAV-PVT, iTOW=15:14:10, year=2025, month=12, day=8, ..., nmaFixStatus=0, reserved0=860630572, headVeh=0.0, magDec=0.0, magAcc=0.0)>
...
<NMEA(GNVTG, cogt=, cogtUnit=T, cogm=, cogmUnit=M, sogn=0.06, sognUnit=N, sogk=0.112, sogkUnit=K, posMode=A)>
...
Messages input:    {'ACK-ACK': 1, 'GAGSV': 15, 'GBGSV': 9, 'GLGSV': 15, 'GNGGA': 3, 'GNGLL': 3, 'GNGSA': 15, 'GNRMC': 3, 'GNVTG': 3, 'GPGSV': 15, 'GQGSV': 3, 'NAV-PVT': 3, 'RXM-RAWX': 3}
Messages filtered: {}
Messages output:   {'ACK-ACK': 1, 'GAGSV': 15, 'GBGSV': 9, 'GLGSV': 15, 'GNGGA': 3, 'GNGLL': 3, 'GNGSA': 15, 'GNRMC': 3, 'GNVTG': 3, 'GPGSV': 15, 'GQGSV': 3, 'NAV-PVT': 3, 'RXM-RAWX': 3}
Streaming terminated, 91 messages processed with 0 errors.

Once the receiver is properly configured, you can then run gnssstreamer from the command line again, but this time using NTRIP RTK data as the input, e.g.:

gnssstreamer --port COM5 --baudrate 38400 --cliinput 1 --input "http://rtk2go.com:2101/MYMOUNTPOINT" --rtkuser myusername@mydomain.com --rtkpassword mypassword --rtkggaint 10 --verbosity 2

For help with gnssstreamer input arguments, simply type gnssstreamer -h.

Hope this helps.