RFID reader checksum problem

[SonOfBc]

I am kind of new to this compiler (and programming in general) and this problem might be with my RFID reader format but I will bounce this off the forum anyway.
My RFID reader format is ASCII(RS232.TTL)9600,N,8,1
It reads as follows:

STX (02H) DATA(10 ASCII) CHECK SUM (2 ASCII) CR LF ETX (03H)


I do not have any problems getting the information out of the RFID reader but I am having problems with the check-sum.
For instance my output of one of my RFID tags is as follows:
STX (Hex) = 2 (Header)
Data (Ascii) = 0415AF7941
Check-sum (Hex) = 86
ETX (Hex) = 3 (End of file)

According to the datasheet to verify the check-sum you do the following:
Check-sum (Hex) = 0X04 XOR 0X15 XOR 0XAF XOR 0X79 XOR 0X41

It appears to me that the datasheet is suggesting that I take the Data in Ascii and divide it into 5 sets of 2 Ascii then convert it somehow into Hexadecimal before I can do the Check-sum function.
Can anyone help me here?
Thanks
SamB

[Senacharim]

How checksums work: Essentially, you "mash together" in some way (byte addition, binary XOR operation, etc) all of the values prior to the checksum value.

If you've correctly received the data and checksum, then your checksum operation should bear out the same value as the received checksum.

So, make yourself an independent checksum value (and zero it) and as you receive your data XOR the byte value into your checksum byte.

Once you get to the last byte, compare.

If memory serves, you'll be ignoring the 2 (start) and 3 (end) bytes, but you'll need to play around with it a bit.

Easy peasy, right?

Please follow up on your post with your success/difficulties. Cheers.

[Jerry Messina]

Yes, if the RFID reader sends all the data in ASCII, you'll have to convert the ASCII data from the reader to hex

Here's a long-handed example using the HexToDec() library function that shows each of the steps involved (I'm ignoring the extra framing chars)

Code: Select all

include "convert.bas"

dim
    packet_data as string(11),      // 10 chars + null
    checksum as string(3)           // 2 chars + null

dim
    hex_str as string,              // temp string
    hex_data as byte,               // converted string
    packet_xsum as byte,            // converted packet checksum
    xsum as byte,                   // computed checksum
    i as byte

// RFID ASCII packet data
packet_data = "0415AF7941"
checksum = "86"

// zero xsum to start
xsum = 0

// process packet data
i = 0
while (i < 10)
    hex_str = packet_data(i) + packet_data(i+1)     // get two chars from the packet_data
    hex_data = HexToDec(hex_str)                    // convert the string to hex
    xsum = xsum xor hex_data                        // XOR xsum
    i = i + 2
end while

// now, convert the ascii checksum chars to a byte
hex_str = checksum(0) + checksum(1)
packet_xsum = HexToDec(hex_str)

// compare the two checksums...
if (xsum = packet_xsum) then
    xsum = 1    // checksum ok
else
    xsum = 0    // checksum fails
endif

[Senacharim]

When looking at binary and hex and decimal decimal are all equivalent, it's just a matter of how it's displayed for human consumption.

Seriously, decimal 16, hex 0x10, and binary 00010000 are all the same number, you're letting an artificial constraint cloud how you're thinking about the code.

Additionally, ascii or not is irrelevant for what you're working on. It's all just byte values.

Make a simple byte array, receive all of the sent data, then perform calculations upon it. You'll get it, it's just you're over-complicating things presently.

(Simplify! Simplify! Simplify!)

[Senacharim]

(Ooops, sorry Jerry, didn't notice I was responding to you...)

(Also, your code is over-complicated. ;-P )

[Jerry Messina]

Well, it's not necessarily how I'd do it, but just an example of the steps involved.

Additionally, ascii or not is irrelevant for what you're working on. It's all just byte values.

That's not true. If the reader is sending the data (including the checksum) as ASCII chars, you'll have to convert them. You can't just XOR the ASCII chars... try it.

[Senacharim]

I've done this plenty with a variety of radar units (and other serial devices) which use checksums.

In my experience:
Byte array, XOR appropriately, done.

ASCII is just a byte value--unless you're working with unicode, in which case the lower 256 unicode characters overlap the ASCII byte values anyhow.

[Jerry Messina]

That would be true if the data was being sent in binary, but my understanding from the description is that it is an ASCII representation of the data:
STX (02H) DATA(10 ASCII) CHECK SUM (2 ASCII) CR LF ETX (03H)

So the data being transferred actually looks like this:

Code: Select all

data(10) = $30, $34, $31, $35, $41, $46, $37, $39, $34, $31			// "0415AF7941"

checksum(2) = $38, $36												// "86"

You're not going to xor that data and end up with "86" in any form

[Senacharim]

Ascii 2 (start of text) and binary 2 are the same value.
Ascii 3 (end of text) and binary 3 are the same value.
(etc)

Try it the way I described, far simpler, same data.

Code: Select all

STX (Hex) = 2 (Header)
Data (Hex) =  0X04  0X15  0XAF  0X79  0X41 'from original post example
'decimal data = {4, 21, 175, 121, 65}
'decimal results
'4 XOR 21 = 17
'17 XOR 175 = 190
'190 XOR 121 = 199 
'199 XOR 65  = 134
Check-sum (Hex) = 86 'decimal 134
ETX (Hex) = 3 (End of file) 

See? They're not ASCII values, they're just byte values. You're maintaining an artificial mental barrier which is doing you no good.

[SonOfBc]

I want to thank all of you for your help. Jerry, your code work perfectly and I have been following your thread with Senacharim and you are correct in that the RFID reader Tag number is sent out as ascii and has to be converted. I had already found that XOR did not work with the original output but was not sure how to tackle the problem.
In any case it is great that there are so many experience people here to help us floundering newbies...


SamB

[Senacharim]

I'm glad you were helped.

(Jerry, you were right.)

[Jerry Messina]

Good to know my mental barrier still has all its bricks intact.