The Open Lidar Project - Hack the Neato XV-11 Lidar for a $200 Bounty!

[hash79]

Staring at the hex editor the last few hours and trying to figure out this "checksum" made me ask a more fundamental question. Why would you include a checksum on a hard wired serial link? I know the standard answer of good practice, but it seems like a checksum is a complete waste. Data errors are almost non-existent in a scenario like this.

Maybe we are going about this in the wrong way, perhaps this is not a checksum at all... Or perhaps I just need sleep!

EDIT: I did not think about the slip ring though, that is a good reason to add a checksum...

Another EDIT: What has me thinking along this line is the fact that it is really REALLY simple to implement a checksum that works. Complexity seems too high for this to JUST be a checksum... Maybe there is some data being sent here we are not taking into consideration...

[Xevel]

Staring at the hex editor the last few hours and trying to figure out this "checksum" made me ask a more fundamental question. Why would you include a checksum on a hard wired serial link? I know the standard answer of good practice, but it seems like a checksum is a complete waste. Data errors are almost non-existent in a scenario like this.
[...]
EDIT: I did not think about the slip ring though, that is a good reason to add a checksum...
[...]

Int the white paper, they say :

Power for the laser module is supplied through a 2-wire
slip ring on the rotation center. Communication to the
module is via a short-range radio frequency modem, at
115 Kbaud, sufficient to send 2-byte data for each
reading.

So it looks like enough uncertainty on the communication to add a checksum to me...

[DaveC]

I believe that between the time of the paper and production the RF link went away and was replaced by the slip ring. The checksum may also be there to detect framing misalignment -- mistaking FA in data for the sync byte. But, I agree, why a complex checksum? Good question.

[Xevel]

Ok, found it.

def checksum(data):
    # group the data by word, little endian
    data_list = []
    for t in range(10):
        data_list.append( data[2*t] + (data[2*t+1]<<8) )
    
    # compute the checksum.
    chk32 = 0
    for data in data_list:
        chk32 = (chk32 << 1) + data

    # return a value wrapped around on 15bits, and truncated to still fit into 15 bits
    checksum = (chk32 & 0x7FFF) + ( chk32 >> 15 ) # wrap around to fit into 15 bits
    checksum = checksum & 0x7FFF # truncate to 15 bits
    return int( checksum )

This is implemented and tested in the last version of the code here : https://github.com/Xevel/NXV11
(package attached for your convenience)

[Nammo]

But, I agree, why a complex checksum? Good question.

Just guessing here: Some types of links are subject to polarity inversion, and you need more than a simple sum of bytes to detect that kind of problem.

But I'm not sure this checksum has that property anyway, since it seems like a simple sum of rotated words. That is, you can cancel out a word with addition/subtraction, and the only complicated bit is that the word is rotated as hash demonstrated.

That kind of checksum only helps if you have a problem with words arriving out of order, or buffers slipping, or something. Maybe it's a guard against buggy code or buggy DMA hardware?

- Nammo

[hash79]

Nammo - yea, not really sure without knowing the troubles faced by the designers...

Xevel - Do you want me to test that code with live data? Is there anything displayed regarding the checksum?

The whitepaper should be looked at as a loose guide, it looks like they made a lot of improvements from that initial device and probably did quite a bit to reduce cost/complexity such as the removal of the RF link. The theory is still the same, but I wouldn't rely too heavily on specifics...

-Hash

[Xevel]

But, I agree, why a complex checksum? Good question.

M understanding is that you put control data in a data stream for various reasons. Sometimes authentication, sometimes error detection, sometimes error correction...
The choice of an algorithm is most probably directed by it's ability to check for the problems the system can have (polarity inversion, noise flipping bits, data loss, data ordering, security concerns, etc).

I guess this particular checksum just does the job for whatever problem this data link might have, and at the same time is way easier to compute than CRCs and fancy stuff like that.

[Xevel]

Xevel - Do you want me to test that code with live data? Is there anything displayed regarding the checksum?

Sure
If the data is wrong, it will write a message in the python console. However now that I think of it, this approach of signaling the problem is not the best... but it proves the point.

[hash79]

Xevel - As soon as I complete the tasks on the wife checklist I will check it out! If I see some messages I will modify the code to use an error counter instead so we can keep track...

-Hash

[Xevel]

Xevel - As soon as I complete the tasks on the wife checklist I will check it out! If I see some messages I will modify the code to use an error counter instead so we can keep track...

Yeah nice idea. And I just added it to the code in the repository.


EDIT: Gallamine, could you check your PM please ?