Ah, it’s just an unrelated part of the application runtime rigging. You shouldn’t use it.
You are computing the CRC incorrectly; also, you do not seem to be escaping it. The correct CRC algorithm is CRC32C (Castagnoli), as stated in the Popcop description. Relevant sources:
- GitHub - google/crc32c: CRC32C implementation with support for CPU-specific acceleration instructions
- popcop/c++/popcop.hpp at b873e1ff79d4919b6b1d4f2dfffc74b31d2052cc · Zubax/popcop · GitHub
- popcop/python/popcop/transport.py at b873e1ff79d4919b6b1d4f2dfffc74b31d2052cc · Zubax/popcop · GitHub
Castagnoli has superior error detecting properties compared to the standard CRC32 (polynomial 0xedb88320).
You can dump the exchange between the device and Kucher to study it offline using this feature of the PySerial library: URL Handlers — pySerial 3.4 documentation. To use it, just replace the serial port name in Kucher with spy://<port-name>?file=dump.txt, for example:
spy:///dev/serial/by-id/usb-Zubax_Robotics_Telega_2F0057000B5136313036383800000000-if00?file=/home/pavel/dump.txt
Then click Connect and you’ll end up with a nice dump file: dump.txt (280.9 KB)
In the attached file you will see the initialization in the beginning, then the registers being read, and, near the end of the log, you will notice Kucher polling the general status message:
000003.825 TX 0000 8E 00 51 53 7D 52 8E ..QS}R.
(the protocol frame is 8E 00 51 53 7D 52 8E)
Response:
000003.826 RX 0000 8E .
000003.826 RX 0000 7E 95 8A 1F 18 00 00 00 01 20 00 00 00 00 00 2C ~........ .....,
000003.826 RX 0010 01 00 00 00 8A B6 99 43 B4 D8 95 43 00 00 00 00 .......C...C....
000003.826 RX 0020 48 63 8D 40 00 00 00 00 AE 7D B2 37 95 BF D6 33 Hc.@.....}.7...3
000003.826 RX 0030 F6 23 69 3F 00 00 00 00 00 00 00 00 01 00 00 00 .#i?............
000003.826 RX 0040 06 FE 00 29 30 8D 15 8E ...)0...