ACK Messages

[gabrielecoppi]

With reference to #169 (no need to re-open the issue), I have done some tests and in general I can say that everything works (sort of). The main thing that I have noticed, it's that sometimes I don't get any ACK message after config_set. The piece of code that I wrote to do this operation is this one:

for i in range(2):
            count = 0
            t0 = time.perf_counter()
            if conn.inWaiting() == 0 and i == 0:
                conn.write(cfgs.serialize())
                msg_count += 1
                logging.info(
                    f"Sent UBLOX configuration message {cfgs} - Count: {msg_count}"
                )

            _, parsed_data = reader.read()

            if parsed_data.identity == "ACK-ACK":
                ack_count += 1

            while parsed_data.identity != "ACK-ACK":
                _, parsed_data = reader.read()
                logging.info(f"Count: {count} - {parsed_data}")
                if conn.inWaiting() == 0 and parsed_data.identity != "ACK-ACK":
                    conn.write(cfgs.serialize())
                    msg_count += 1
                    logging.info(
                        f"Sent UBLOX configuration message {cfgs} - Count: {msg_count}"
                    )

                if parsed_data.identity == "ACK-ACK":
                    ack_count += 1

                if count >= 30:
                    break
                count += 1

            while time.perf_counter() - t0 <= 1.0:
                pass

        if ack_count == 2:
            logging.info("UBlox Sensor Configured Correctly")

        if new_baudrate:
            msg_baud = ubx.UBXMessage.config_set(
                1, 0, [("CFG_UART1_BAUDRATE", new_brate)]
            )
            conn.write(msg_baud.serialize())

            while time.perf_counter() - t0 <= 1.0:
                pass

            del reader
            conn.close()

            while time.perf_counter() - t0 <= 0.5:
                pass

            conn = serial.Serial(port, new_brate, timeout=1)

            if conn.is_open:
                logging.info(f"Connected to ublox sensor {name} @ {new_brate}")

                reader = ubx.UBXReader(conn)

What I am observing is that every time I am looking at the parsed_data then no ACK messages appear. The sensor seems to be configured correctly (I can see the corrected data out).

[semuadmin]

In short, your code is far too simplistic. The UBX protocol does not implement synchronous ACK responses so you can't assume that commands and their responses will occur in strict linear sequence.

In order to reliably process commands (or polls) and their responses concurrently, your code needs to implement some kind of Python concurrency model, which in practical terms means either threading or asyncio, of which the former is arguably the easier for high transaction rate serial operations.

As stated in the README, there are plenty of examples of suitable code in the pyubx2 \examples folder e.g. look here or here.

Alternatively, you could look into the pygnssutils library, which supports a wide variety of concurrent command line operations with UBX devices.

Also bear in mind that there are various circumstances in which a UBX device will fail to send ACK responses (at least in a timely manner) e.g. if the TX buffer is full (txbuf alloc error), or the navigation solution rate is very high (>=10Hz). In essence, any time the UBX device's hardware is under stress for any reason, it may attempt to reduce load by skipping outgoing messages.

Refer to the F9P Integration and Interface Manuals for further details.

If you have general queries on the UBX protocol, please refer to the u-blox support forum in the first instance.

[gabrielecoppi]

Thanks, I was looking at the examples, but for how the main code is written, it would be very hard to implement a similar structure. This snippet is already part of a thread of its own that first configure and then reads it. The idea looking at the example is that I don't have a real queue because I know already the messages, so it would be like another argument passed to the read thread.

I think that looking at the output I am filling very quickly the buffer (if I print the inWaiting I get after few iteration 4095), so I think that the ACK message is somewhere hidden and it does not shows up before the counter.

[semuadmin]

Thanks, I was looking at the examples, but for how the main code is written, it would be very hard to implement a similar structure. This snippet is already part of a thread of its own that first configure and then reads it. The idea looking at the example is that I don't have a real queue because I know already the messages, so it would be like another argument passed to the read thread.

I would recommend you revisit your main code at some point (have a look at the internal workings of pygnssutils.gnssstreamer, for example) - the code snippet above will NOT be a reliable model for configuring or polling UBX devices.

I think that looking at the output I am filling very quickly the buffer (if I print the inWaiting I get after few iteration 4095), so I think that the ACK message is somewhere hidden and it does not shows up before the counter.

That is certainly a possibility.

[gabrielecoppi]

Yea I will do at some point. I am looking particularly here

[semuadmin]

Yea I will do at some point. I am looking particularly here

Though by no means the only pattern available (many swear by asyncio), the thread/queue pattern is in my experience a very simple and reliable model to implement. It completely divorces the complexity of generating and/or processing outbound or inbound UBX messages from the comms layer, and can be readily adapted for serial, socket and file operations.

FYI the so-called 'Global Interpeter Lock' (GIL) has traditionally been seen as an obstacle to implementing 'true' concurrency using Python threads (though it's rarely an issue in practice for most Python applications), but work is already in hand in Python 3.13 and 3.14rc with the intention of mitigating or eliminating this issue.