Hi.
I have been trying to diagnose a problem I've seen when data is received on a serial port which exceeds 64bytes in length. I am aware that USB CDC ACM has a maximum payload length of 64bytes, but this is odd behaviour to me.
Our system, connected to the rpi (model 3B+) sends data to the RPI at set intervals. this is normally very short and less than 64 bytes. However, some data is longer than 64 bytes (i.e. 70 bytes). I use ubuntu to develop the applicaiton on and here the full 70 bytes are received and is working without a problem. I presume that under water the CDC drivers break the packet up in smaller pieces and this is re-assembled when received, so that on application level, 70 bytes of data is received again.
However, when starting to test on a raspbery pi, I noticed that the last few bytes are almost always corrupted. Specifically the last 6 bytes. The first 64 bytes are always correct.
I use Java, using jSerialComm, but even when using `stty` on the command line I can see the exact same behaviour, taking any java or it's libraries out of the loop. and in another window
I ensure the serialport is in raw mode, and as said, the exact same configuration with the exact same USB device connected works fine in ubuntu.
As a test, I send 70 bytes of data, starting with 0x00 and each following character incrementing with 1.
Output on the rpi: note that sometimes the packet works (i.e. the first packet) but the 2nd packet goes wrong (at 000086, which should be 0x40). The packet after that starts again at 000008c with 0x00.on ubuntu the same command as above works flawlessly, with each packet ending with 0x40, 0x41, 0x42, 0x43, 0x44, 0x45I have repeated above using a fresh rpi install using the latest OS available, and the same behaviour is happening here.
Note that the jSerialComm library actually reports that 70 bytes are received, and will return 70 bytes of data, of which the last 6 bytes are corrupted the same way as seen above. If the 64byte buffer limit was the problem, I would the data to simply go missing, and some form of receive buffer overrun error to be triggered - which is not happening. Also, I would then expect the same behaviour on ubuntu. I have tried different baudrates and configurations of the serial port but all have the same behaviour.
The only way forward from here that I can see is to make sure we break up a large message in 64byte chunks before sending this, but this feels a bit like a workaround? Is there anyone who has a similar experience?
Thanks
Johan
I have been trying to diagnose a problem I've seen when data is received on a serial port which exceeds 64bytes in length. I am aware that USB CDC ACM has a maximum payload length of 64bytes, but this is odd behaviour to me.
Our system, connected to the rpi (model 3B+) sends data to the RPI at set intervals. this is normally very short and less than 64 bytes. However, some data is longer than 64 bytes (i.e. 70 bytes). I use ubuntu to develop the applicaiton on and here the full 70 bytes are received and is working without a problem. I presume that under water the CDC drivers break the packet up in smaller pieces and this is re-assembled when received, so that on application level, 70 bytes of data is received again.
However, when starting to test on a raspbery pi, I noticed that the last few bytes are almost always corrupted. Specifically the last 6 bytes. The first 64 bytes are always correct.
I use Java, using jSerialComm, but even when using `stty` on the command line I can see the exact same behaviour, taking any java or it's libraries out of the loop.
Code:
(stty raw; cat > received.log) < /dev/ttyACM0 Code:
tail -f received.log | hexdump -CI ensure the serialport is in raw mode, and as said, the exact same configuration with the exact same USB device connected works fine in ubuntu.
As a test, I send 70 bytes of data, starting with 0x00 and each following character incrementing with 1.
Output on the rpi: note that sometimes the packet works (i.e. the first packet) but the 2nd packet goes wrong (at 000086, which should be 0x40). The packet after that starts again at 000008c with 0x00.
Code:
00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................|00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./|00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?|00000040 40 41 42 43 44 45 00 01 02 03 04 05 06 07 08 09 |@ABCDE..........|00000050 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 |................|00000060 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 |...... !"#$%&'()|00000070 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 |*+,-./0123456789|00000080 3a 3b 3c 3d 3e 3f 87 a1 02 00 00 00 00 01 02 03 |:;<=>?..........|00000090 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 |................|000000a0 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 |............ !"#|000000b0 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 |$%&'()*+,-./0123|000000c0 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 |456789:;<=>?@ABC|000000d0 00 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d |................|000000e0 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d |................|000000f0 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d |.. !"#$%&'()*+,-|Code:
➜ serialised-captures tail -f received.log |hexdump -C00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................|00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./|00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?|00000040 40 41 42 43 44 45 00 01 02 03 04 05 06 07 08 09 |@ABCDE..........|00000050 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 |................|00000060 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 |...... !"#$%&'()|00000070 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 |*+,-./0123456789|00000080 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 00 01 02 03 |:;<=>?@ABCDE....|00000090 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 |................|000000a0 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 |............ !"#|000000b0 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 |$%&'()*+,-./0123|000000c0 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 |456789:;<=>?@ABC|000000d0 44 45 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d |DE..............|000000e0 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d |................|000000f0 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d |.. !"#$%&'()*+,-|00000100 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d |./0123456789:;<=|00000110 3e 3f 40 41 42 43 44 45 00 01 02 03 04 05 06 07 |>?@ABCDE........|00000120 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 |................|00000130 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 |........ !"#$%&'|00000140 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 |()*+,-./01234567|Note that the jSerialComm library actually reports that 70 bytes are received, and will return 70 bytes of data, of which the last 6 bytes are corrupted the same way as seen above. If the 64byte buffer limit was the problem, I would the data to simply go missing, and some form of receive buffer overrun error to be triggered - which is not happening. Also, I would then expect the same behaviour on ubuntu. I have tried different baudrates and configurations of the serial port but all have the same behaviour.
The only way forward from here that I can see is to make sure we break up a large message in 64byte chunks before sending this, but this feels a bit like a workaround? Is there anyone who has a similar experience?
Thanks
Johan
Statistics: Posted by johan-nz — Mon Apr 29, 2024 5:16 am