Checksum calculation

Hello, I'm using this datasheet to interface a Nano ESP32 to a Lidar sensor. The Sensor has a set of commands that allow you to change settings. I have managed to get output on/off to work and changing of format from mm to cm. However, I am having difficulties with baud rate as I do not understand how to calculate the checksum.

From the datasheet it says the checksum is calculated as the "Checksum: the lower 8 bits of the sum of the first N-2 bytes" and this is the command format

It provides one example:

"For example, to change the baud rate to 460800, first change 460800 to HEX
(0x00 07 08 00), then calculate the checksum to 0x77, and you can get the
following instruction - 5A 08 06 00 08 07 00 77.

But I don't understand how the checksum of 0x77 is created? Any ideas?

so you have "5A 08 06 00 08 07 00 77"

if you add up the first bytes up to 'N-2' (the red part) 5A+08+06+00+08+07+00 you get 0x77

(they start counting at byte 0 so the last byte is N-1 where N is the total number of bytes)

Oh, thank you ever so much. I was taking N-2 as the definition in the command format table where it also mentions ByteN-2 which just so happens to be 0x7 in the example so I thought they were doing some weird bit shifting of 0x7 to 0x77.

to build the frame

byte 0 = 0x5A
byte 1 = 0x08 since our payload will have a total of 8 bytes
byte 2 = 0x06, this is the command to change baud rate apparently

then you need the baud rate on 4 bytes, representation is little endian (so LSB first). 460800 bauds in hexadecimal is 0x00070800 so represented starting from the LSB is 00 08 07 00

that's how you get to 5A 08 06 00 08 07 00

then you only need to sum those bytes and if it were to go over 0xFF only keep the LSB. here the sum is 0x77 so you don't have to worry about dropping anything.

Thank you - it works \o/ I got the expected response back.

The one command I still can't get to work is changing the frame rate as the command in the datasheet makes no sense. 0x5A is the head, 0x4 means 4 bytes being sent, 0x1 is the ID of the command and 0x5F is the first byte of the payload. It doesn't seem to explain how you send the required frame rate in the command as not enough bytes!

I sent just 0x5A 04 01 5F and get back :
12:15:58.704 -> 5A
12:15:58.704 -> 7
12:15:58.704 -> 1
12:15:58.704 -> 4
12:15:58.704 -> 4
12:15:58.704 -> 1
12:15:58.704 -> 6B

which is total nonsense as it is supposed to return 0x5A 06 03 LL HH Checksum. Do you have any thoughts here as strangely the (4) footnote against the command refers to the checksum?

they say

probably the (4) should have been written next to SU in the next column

5F is the right check sum for 5A + 04 01 and there are really 4 bytes, so that's coherent.

What is indeed cryptic is where the parameter is...

could it be that the command 00 would refer to 0hz, 01 would be 20Hz, 02 would be 50Hz, 03 would be 100Hz and 04 would be 250 Hz ?

feels weird

I suggest contacting Benewake support. From the data sheet:

For technical questions, please contact: support@benewake.com

Did you solve the "dropped first byte" problem from your other thread on this topic? If so, it might be beneficial to others having problems with this sensor to post the solution.

On second thought it might be possible they mixed up the command and the response.

if you feel adventurous, you could try to send 5A 06 03 LL HH + checksum where LL HH is the uint16_t little endian value of the frame rate 0, 20 50 100 250 Hz (which all fit on one byte)

0x5A 0x06 0x03 0x00 0x00 0x59 for 0 Hz
0x5A 0x06 0x03 0x14 0x00 0x6D for 20 Hz
0x5A 0x06 0x03 0x32 0x00 0x8B for 50 Hz
0x5A 0x06 0x03 0x64 0x00 0xBD for 100 Hz
0x5A 0x06 0x03 0xFA 0x00 0x53 for 250 Hz

and may be you would get an ACK as 0x5A 0x04 0x01 0x5F

side note:

I've seen this mention in their user manual

Note: Please turn off the anti-virus software before decompressing the
host computer software to avoid the files in the host computer software
being deleted as viruses. The host computer currently only supports running
on Windows systems

The request to turn off antivirus software raises concerns about security and best practices. Generally, reputable software should not require users to disable antivirus protections, as this exposes the system to potential vulnerabilities. If the software is falsely flagged as a virus, the company should ideally address the issue through trusted software certification or by working with antivirus vendors to whitelist their files.

Requiring users to disable security measures suggests potential risks, such as the software containing poorly coded elements that trigger false positives or, in worse cases, actual security issues.

If someone were to as me if it's fine to blindly download an executable on windows, from China, with anti-virus off, my answer would be never do that... (even though Benewake is a well-known company).

The Benewake TFmini actually works as advertised.

I've used it, and will avoid the TFS20-L, so thanks for the warning!

I tried the A 06 03 LL HH + checksum command and it worked so I have been able to now successfully config and read the TFS20-L via serial. I2C was not as successful but the Nano ESP32 has enough h/w serial ports to do the job so will stick to those :slight_smile: Thanks again for your help with the checksums

Glad it did!

Have fun