Getting frequent checksum errors with PUPRemote messages

[marnovdm]

I was trying to use the Pybricks beta on Mindstorms 51515 hub with PUPRemote on LMS ESP32 as shown here:

https://github.com/antonvh/PUPRemote/tree/main/examples/esp32_dummy_data

I only changed the code running on the hub to not call the num/small/data/largedata methods and to call the msg method in a loop instead:

from pybricks.parameters import Button, Color, Direction, Port, Side, Stop
from pupremote import PUPRemoteHub
from pybricks.tools import wait, StopWatch

p=PUPRemoteHub(Port.A)
p.add_command('msg',"repr","repr")
p.add_command('num',from_hub_fmt="3b",to_hub_fmt="3b")
p.add_command('smalldata',from_hub_fmt="16B", to_hub_fmt="16B")
p.add_command('largedata',from_hub_fmt="32B", to_hub_fmt="32B")

while True:
    p.call('msg', 'message from hub')

The code on the LMS ESP32 is as shown in that example, except that I added some extra debug output to lpf2.py in the part where the checksum error is printed, like this:

                    read_ck = self.readchar()
                    if ck == read_ck:
                        return buf
                    else:
                        print("Checksum error")
                        print('read_ck')
                        print(read_ck)
                        print('ck')
                        print(ck)
                        print('buf')
                        print(buf)
                        print('utime')
                        print(utime.ticks_ms())

When running this, it results in the following output from ESP:

('hello from hub',)
('hello from hub',)
Checksum error
read_ck
39
ck
244
buf
bytearray(b"'hello from hub'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8")
utime
1609533
('hello from hub',)
('hello from hub',)
('hello from hub',)
('hello from hub',)
Checksum error
read_ck
39
ck
244
buf
bytearray(b"'hello from hub'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8")
utime
1609833
('hello from hub',)
('hello from hub',)
('hello from hub',)
('hello from hub',)
Checksum error
read_ck
39
ck
244
buf
bytearray(b"'hello from hub'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8")
utime
1610153
('hello from hub',)
('hello from hub',)
('hello from hub',)
('hello from hub',)
Checksum error
read_ck
39
ck
244
buf
bytearray(b"'hello from hub'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8")
utime
1610473
('hello from hub',)
('hello from hub',)
('hello from hub',)
('hello from hub',)
Checksum error
read_ck
39
ck
244
buf
bytearray(b"'hello from hub'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8")
utime
1610793

I initially tried to use this to communicate servo positions using a list, but that has the same issue. It seems the data is mostly there, the first part of the bytearray is always the data I expect to be there, but followed by the \x00\x00...\xe8. If you need any more info to troubleshoot this please let me know :)

[antonvh]

Hi Marno,

You are trying to send 32 bytes. This is a known issue with Pybricks. I believe @ste7anste7an submitted a bug report with Pybricks. The only workaround is reducing the payload size to 16 bytes. Try reducing MAX_PKT to 16. https://github.com/antonvh/PUPRemote/blob/77cfc2d011fdefbd6e9c4fbd43ae38e5e20ca104/src/pupremote.py#L44C1-L44C24

[ste7anste7an]

@marnovdm , I haven't submitted a bug report for this checksum error to PyBricks, because they can not reproduce the error without using external hardware. We have to live with the limit of 16 bytes I am afraid. We might send an LMS-ESP32 with a demo program to the PyBricks team ;).

I noticed a recent change in the PyBricks firmware though, where now PyBricks expects signed bytes as input to the PUPDevice.write function and caps all bytes to max 0x7f. I made a temporarily fix in the PUPRemote library to deal with that. So, be sure to update to the new PUPRemote library.

[marnovdm]

Thanks for the quick response guys, amazing! Can confirm it works if I modify the MAX_PKT to 16 on both sides. Hope the PyBricks team reconsiders because it would be nice to have 32 bytes available.

And yes @ste7anste7an I noticed your comment about that in another issue and am using the latest version :) all good now.