Which checksum is this?

I have some data we're querying from a device. It is coming in as 6 columns, separated by tabs, and the line ends with a CRLF.

The final column appears to be a checksum (in the red box), but I am trying to figure out which checksum it is.

The blue lines do not come from the device. I've just looped through each character printing the integer ord() value so I could see what it was.

Does anyone recognize this?
LVL 32
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Unfortunately those sorts of things are often wheel reinventions in that kind of context
It would seem to be a crc, but there is not enough data to confirm this.
I do confirm that when the xor between two column 3 values are the same, the xor between the column 6 values are also the same, as would be true for a crc.
ste5anSenior DeveloperCommented:
What device? Does the same sequence of bytes result in the same code?
Introduction to Web Design

Develop a strong foundation and understanding of web design by learning HTML, CSS, and additional tools to help you develop your own website.

there's really no way to get more details about the device, its name, it's manufacturer, its protocol?
This would definitely help.

As others said already. There's quite some variations of 16 bit CRCs.
you had to try each algorithm and check whether to apply this algorithm over either the bytes or the decoded ASCII numbers and to see whether you find a match, whether to include the first byte or not, . . .

I have somewhere a python implementation of one 16 bit CRC used by a medical device.
Chances are low though that it's your algorithm, but you might try it out. Shall I try to find it?
DrDamnitAuthor Commented:

Yeah... I wish people would stop inventing their own checksums and crypto. It's just so hard to do it correctly, and with the mountain of excellent libraries out there, why people reinvent stuff is beyond me.

CRC was the first thing that came to mind as well.

It's one of these: http://is.gd/TslXgR. We have a call into the home office to see if they can tell us, but they are in Europe, and there are apparently some holidays, etc... So, we don't really want to wait if we don't have to. We've reverse engineered most of the columns (explained below).

The script that is reading this is done in python, so if you had some CRC code, that would be great.

I was hoping to get a list of checksums that it might be, and then I (we) could test them.  TO that end, here is some sample data (attached).


You'll notice that the rows come in two flavors: 6 columns and 9 columns.

The 9 column rows indicate a go kart that has passed the timing line sensor.

There are two types of records sent:

Heartbeat (6 columns), which is probably the decoder and the sensor going: "You there?" "Yep. I'm still here. You there?" "Yep."

Kart passings (9 columns).

This second type is more important than the first for our project.
Column 1: I confirmed this morning that column 1 is the data record indicator. It consists of two bytes, 0x01 (SOH) and a record length (35). So, that means the decoder tells us: "Here is the beginning of the record I am sending you: it is 35 bytes long).

Column 2: we are not sure what this means. It is always "20". So, this means two things: it is either related to hardware or a hardware setting, and / or it is not necessarily useful.

Column 3: this is a counter that increments by 1 every time it sends us a message. It starts at 0 when you connect. Disconnecting from the decoder and reconnecting restarts it at 0. This is useful only in determining: "Did I miss a message from you?"

Column 4 is the transpoder ID on a kart. We confirmed the numbers on the transponder label as we pushed a kart across the line.

Column 5 is the timestamp out to three significant digits. It is the number of seconds elapsed since the unit was powered on.

Column 6 and 7 are a mystery so far. We're not sure what they are.

Column 8 appears to be a track number.

Column 9 the checksum that started this thread.

My current theory is that this checksum either:
* already happened between the transponder and the decoder, and so it is just an FYI, ro
* Performs a checksum on the values we are reading, and is therefore useful.

If it is the latter, I would like to be able to re-perform the checksum so that I can ... do the checksum.
DrDamnitAuthor Commented:
OH ... one thing regardin the sample data, I removed the SOH, 35, and first tab to make the text file play nice with EE.

If you want to add it back in, the bytes (as noted in my first screenshot) are:

1 35 9
Attached a small module calculating a crc in python for the polynom 0x8408 (the lookup table
is precalculated)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.