Question about receiving longer console messages from the hub

[skezell]

I am running my python program on the hub and it outputs some logging messages that appear to be too long for the code to handle. I am hitting the if case in this code in the on_data callback being registered with the client.

        def on_data(_: BleakGATTCharacteristic, data: bytearray) -> None:
            if data[-1] != 0x02:
                # packet is not a complete message
                # for simplicity, this example does not implement buffering
                # and is therefore unable to handle fragmented messages
                un_xor = bytes(map(lambda x: x ^ 3, data))  # un-XOR for debugging
                logger.info(f"Received incomplete message:\n {un_xor}")
                return

The note there seems to indicate that this is a known issue, that it doesn't handle messages that are long enough to be split into multiple ... chunks? packets? not sure what the right term is here?

Could you provide an example of how one would implement buffering in order to receive longer messages? Or could you provide some description of how this would work? I get that the general idea is that you would put incoming messages into a buffer until the message is complete, then return the entire buffer contents. However, how do you know that the message is complete? is the last byte in data the thing I should be using? And since this is a callback function, I'm unclear on where exactly we can store a buffer? Can this effectively be a global or could there be different messages being received simultaneously, so each 'stream' needs it's own buffer?

Thanks for any help! The capability to upload and run from the IDE is for me a game changer :) and I so appreciate the example you posted!

[skezell]

I don't know if it's related or not, but the first longer message also seems like it's being received one character as a time from the hub, rather than the way shorter console messages are coming in a single string.

[SteffenLEGO]

I think you'll find answers to your questions here: https://lego.github.io/spike-prime-docs/encoding.html#escaping-and-framing
Basically you are looking for the value 0x02, that always signals the end of a message.

In some cases you may need to also look for 0x01 and have two buffers (one for high priority messages and one for low priority messages) but I think with what you are doing all you really have to do is add data to your buffer until you find a 0x02 and when you do, that means you have a message. In theory there could be many messages in a single packet from the hub, but I don't think that happens much.

The code provided is just an example and doesn't represent what we have in the app, what you really want to do is see if there is a 0x02 in the data received, and if there is, split the data by the 0x02 values and if the message doesn't end with 0x02 that just means there is something in the buffer that should be continued with the next received packet.