Need to run twice

[gabrielecoppi]

Describe the bug

I am running the latest version of pyUBX2 installed with pip on a RPi4. When I run for the first time the following code, I get the everything correct (I get the ACK message after configuring it) and I get the first 3/4 UBX messages on the UART1 and then nothing else. I checked and the code enters this loop here and stays there indefinitely. I also check that on UART2 I am not getting any NMEA messages.

At this point, if I stop the code and run it again, I get everything as expected.

import serial 
from pyubx2 import UBXReader, UBXMessage

port = '/dev/ttyAMA0'
baudrate = 38400
new_baudrate = 115200


msg = [
	('CFG_UART1OUTPROT_UBX', 1),
	('CFG_UART1OUTPROT_NMEA', 0),
	('CFG_UART2OUTPROT_NMEA', 1),
	('CFG_MSGOUT_UBX_NAV_POSECEF_UART1', 1),
	('CFG_MSGOUT_UBX_NAV_POSLLH_UART1', 1),
	('CFG_MSGOUT_UBX_RXM_SFRBX_UART1', 1),
	('CFG_MSGOUT_UBX_RXM_RAWX_UART1', 1),
	('CFG_RATE_MEAS', 1000),
	('CFG_MSGOUT_NMEA_ID_GGA_UART2', 1),
	('CFG_MSGOUT_NMEA_ID_GSV_UART2', 1),
	('CFG_MSGOUT_NMEA_ID_GSA_UART2', 1),
	('CFG_MSGOUT_NMEA_ID_GST_UART2', 1),
	('CFG_MSGOUT_NMEA_ID_GNS_UART2', 1),
	('CFG_MSGOUT_NMEA_ID_ZDA_UART2', 1)
]

ser = serial.Serial(port, baudrate, timeout = 1)

msg_baud = UBXMessage.config_set(1, 0, [('CFG_UART1_BAUDRATE', new_baudrate)])

ser.write(msg_baud.serialize())

ser.close()

ser = serial.Serial(port, new_baudrate, timeout = 1)

msg_cfg = UBXMessage.config_set(1, 0, msg)

print(msg_cfg)

ser.write(msg_cfg.serialize())

reader = UBXReader(ser)

while True:
	raw_data, parsed_data = reader.read()
	print(raw_data)
	print(parsed_data)

To Reproduce

You can just run after boot the code, stop it and then re-run it

Expected Behaviour

I just would expect it to work at the first time, not at the second.

Desktop (please complete the following information):

I am running on UART1 with a Raspberry PI 4 updated at Bookworm.

GNSS/GPS Device (please complete the following information as best you can):

• Device Model/Generation: ZED-F9P 04B
• Firmware Version: 1.50.

Additional context

Add any other context about the problem here.

[semuadmin]

Hi @gabrielecoppi,

Just to confirm, what physical port does port = '/dev/ttyAMA0' correspond to on your F9P device? I'm assuming UART1 - is this correct?

If you change the active baud rate on the port you're actually connected to, you will have to reconnect before proceeding. Also bear in mind that UART1 and UART2 are not wholly independent on the F9P in terms of configuration.

[gabrielecoppi]

It is uart1 (which is the one that I am physically connecting to) and I am reconnecting. I also did some tests and write the configuration before changing the baudrate. So I tried to remove some config pairs and just discovered that without enabling UART2 everything works

[semuadmin]

Not sure if this is the issue here, but section 3.8.1 of the F9P interface manual does mention allowing a short delay (100ms or so) after changing the baudrate before sending any further commands. Does introducing, say, sleep(.5) after the first send make any difference?

Also, in terms of 'looping indefinitely', there appears to be no termination or timeout clause in your while True loop (e.g. if raw_data is None: break) so UBXReader will loop indefinitely regardless of whether it's receiving data or not - that's expected behaviour.

[gabrielecoppi]

Yes, I tried with sleep(0.5) but it didn't help unfortunately. I also increased the time up to 2s but nothing. I tried to configure it before changing the baudrate, and still nothing happened.

I also noticed that the code works the second time, but if I close the serial and re-configure it won't.

It is expected to loop indefinitely, I will stop it using sigterm signal

[semuadmin]

It is expected to loop indefinitely, I will stop it using sigterm signal

with the code as it stands, sending a SIGTERM won't necessarily stop the UBXReader loop - you need to explicitly terminate it with e.g. a break clause, a stop Event() or a KeyboardInterrupt exception.

But, just to be absolutely clear, can you confirm that I have correctly understood your issue:

1. you're expecting to see 4 UBX message types at a rate of 1Hz via UART1 at 115200 baud, and no NMEA messages.
2. when you first run the code, you see a few UBX messages but then the stream stops unexpectedly?
3. when you run the code a second or subsequent time, you see a continous stream of UBX messages as expected?

Is this correct?

[gabrielecoppi]

Yes everything as described. The UART2 will output NMEA for other purposes (but also there nothing happens)

[semuadmin]

Yes everything as described. The UART2 will output NMEA for other purposes (but also there nothing happens)

OK thanks. One final clarification question - which specific F9P board are you using, and are you connecting directly between the board's RX/TX ports and the RPI's TX/RX GPIO ports, or are you using some kind of intermediate UART adapter (e.g. FTDI)?

I'll look into it further, but my gut feeling is that this is unlikely to be a bug in pyubx2. pyubx2 is simply a message parser and doesn't directly implement any comms functionality - it defers to external libraries like Serial or Socket. Unless there's evidence the UBX CFG-VALSET messages themselves are badly formed, I think it's more likely to be a quirk of the end-to-end UART stack and/or the F9P's firmware, but I'll endeavour to get back to you asap.

[gabrielecoppi]

I don' t use any adapter. The board has been developed in house but it basically just connect the UBlox to the GPIO of the RPi.

I can confirm that is weird implementation of the firmware. I checked with ucenter and also there I need to run twice the configuration.

Now what I did to get this thing to work, is:

1. Send the config twice with 1s distance
2. Wait 1s
3. Send the new baudrate
4. Wait 1s
5. Close the serial
6. Connect it again

[semuadmin]

OK so are you happy to close this issue now?

[gabrielecoppi]

Yes, it is not related to the code.