RFID Tag ID #'s & conversion

JBWolf · 2012-05-22 18:24

Hello,
I am learning how to work with RFID and am a little confused about the tag ID's.
I am using the parallax reader model #28140 with this PASM Code from obex #561... unfortunately the forum discussion link is dead.

I have everything working and it is reading tags, but I cannot figure out how the tag ID's are encoded.
For example I have some keyfobs with the rfid # marked on them:
#1 = 0007947861
#2 = 0007961938

When I scan them using the PASM code I get an ID on the display of:
#1 = 4C00794655
#2 = 4C00797D52

Also in the PASM code I do not understand the ID conversions there either:
'' Key#" - " Key Byte values " - ' Key ID '
tags
{1} byte "1234567890" ' 0098765432
{2} byte "2345678901" ' 0087654321
{3} byte "3456789012" ' 0076543210
{4} byte "4567890123" ' 0065432109
{5} byte $23, $89, $6F, $58, $69, $11, $12, $A2, $7C, $41 ' 0023569832
{6} byte "5678901234" ' 0054321098

I am quite confused.
Can someone please explain how I convert "1234567890" to 0098765432.
I typed this into a hex to dec converter $23, $89, $6F, $58, $69, $11, $12, $A2, $7C, $41 but did not get anything close to 0023569832.

Thanks,
J

kuroneko · 2012-05-22 18:28

FWIW, try http://forums.parallaxinc.com/forums/default.aspx?f=25&m=287204.

JBWolf · 2012-05-22 18:51

I couldnt get anything related to resolving my Q out of that.
It looks like someone else in that thread was having similar trouble... "Also, my key fob's seem to have more digits in the ID number associated with them. I can't seem to match it up with yours."

kuroneko · 2012-05-22 19:11

JBWolf wrote: »

I couldnt get anything related to resolving my Q out of that.

Apologies, you mentioned a broken link and that was the corrected version (old forum).

Note, I'm convinced I saw #374 mentioned in the top post (given that #561 doesn't mention a link). Too late now

JBWolf · 2012-05-22 19:14

I'm still not getting this figured out.... but I did notice something:
In the example from the PASM code :$23, $89, $6F, $58, $69, $11, $12, $A2, $7C, $41 is supposed to equal 0023569832
What I noticed is $23, $89, $6 are the last 5 digits in reverse of 0023569832... but then it trails off into obscurity

JBWolf · 2012-05-22 19:18

The link you provided is to a different object, #374.
This object is not for a parallax reader, rather a custom made one.
I could not get it to work

mikea · 2012-05-23 03:35

Hi JB, I had a similar problem. "It's the difference between the raw data from the RFID IDs and the ASCII codes of that data"(the read numbers apparently don't match the number stamped on the outside of the tag)............this is a quote from PJ Allen when i was looking for the same answer.-mike.

Bobb Fwed · 2012-05-23 10:17

I am the author of the object you are using.

There is a correlation. There seems to be a "header" of sorts, maybe to signify different batches or makers, or something, but that's just the first byte. After that it's a hexadecimal conversion. In your examples, if you ignore the "4C" byte, the rest converts from $00794655 to 7947861, and the same goes for your second key. So the real "key" part of the RFID is the lower 4 bytes of the number. So there may be some way to store it like the written value, as a long or something, but my guess is there is not.

The list of tags I gave were completely made up, I didn't (until literally 5 minutes ago when I wrote the above explanation) even think there was a direct correlation between the two numbers, I was just showing examples of how to input the values. The first part is the value given by the reader, a string in the form of HEX values, and the part after that, which is commented out, is the number printed on the card (guess I didn't show that in the object).
On the system we use here, I have 50+ cards, and I want to be able to quickly see the scanned card's value and track it backward to the physical card by seeing the written value.

So with the cards you gave, I would write it like this:

tags
                 { 1}   byte    "4C00794655"    ' 0007947861
                 { 2}   byte    "4C00797D52"    ' 0007961938

Does this help at all?

Bobb Fwed · 2012-05-23 14:07

I misspoke in the last post, I said "ignore the '4C' byte", well it's a bit confusing. What is actually happening is the values of the RFIDs' codes are a string of 10 bytes, but are representative of 5 bytes. Simply, each byte of the actual value is stored on the card as a 2-byte string, a hexadecimal value representing the original byte. So when I said "the...byte" I meant the first two bytes (representative of one).

If you wanted to convert them to a decimal format (like the one printed on the card), you would have to ignore the first 2 bytes, then convert the following 8-byte string from hexadecimal to decimal, there are objects in the OBEX that do that (if you intend to automate the process). You could reverse the process too, but as to how to account for the two "header" bytes, I'm not sure what to do.

JBWolf · 2012-05-23 17:26

how did you convert $00794655 to 7947861 ?
That is the correct ID on the tag... but I do not understand what is being used to perform the number conversion....as far as I see from HEX, numbers are equal to their value, A-F is 10-15.
there are 8 digits in $00794655, but 7 in 7947861... I do not understand at all

JBWolf · 2012-05-23 17:31

ok I was able to use this hex to dec converter and it does give the value you also gave, which is matching the rfid tag.
But I guess I just do not understand hex to dec conversion at all.
I will look into this.
Is there a simple SPIN command to perform hex to dec conversion?

JBWolf · 2012-05-23 17:40

thank you for the help btw, rare you get to work with authors

I noticed your code gets each byte individually from RFID.spin, displays it and then re-writes the outtag variable.
Is there a way to put the entire rfid value minus the header into a single variable for comparing?
I would like to use my tags and your code to make a simple access panel, but cannot figure out how to modify this with all the confusing assembly (which im sure makes perfect sense to those who know it.
I have so many things going on right now, I just do not have the time to learn ASM

Also, what does a $ represent.
I see this in two places... one is DEBUG.tx($D) and the other I see in $00794655.
Is DEBUG.tx($D) the same as DEBUG.tx(0D) which is the same as DEBUG.tx(13) ???
So $00794655 would be the same as 000794655???
Or is it a null character?

Bobb Fwed · 2012-05-23 19:47

I'll have to look at the code tomorrow to tell you how to ignore the header, but the header is an important part of what makes the RFID key unique. For small sets of RFID cards, where you can check for collisions, it can probably be ignored, but if you are worried about security issues, it wouldn't be a good idea to skip those bytes. Is it necessary to use the values printed on the card for these comparisons?

The $ is SPIN's symbol for a hexadecimal value, I figured I would use that here (being a Prop forum), rather than the generally more accepted "0x..." but it means the same thing. It says the following number is hexadecimal instead of an integer/decimal. It's often easier to put things down as HEX numbers because it is much easier to visualize each byte of the value. For example, you could write var := 1234567, but it becomes difficult to determine each byte's value, but if you write var := $12D687, you can easily see that byte 0 is $87, byte 1 is $D6, and so on.
Similarly, SPIN uses "%" to symbolize the following number is written in binary. So yes, $D is the same as 13. I use $D instead of 13 only because some other languages I work with require the ASCII values to be in HEX, so it's kind of a habit now.

PJAllen · 2012-05-23 20:55

mikea wrote: »

(the read numbers apparently don't match the number stamped on the outside of the tag)....

Well, they do, if you format your data right. You just need to decide if you're going to deal with it as ASCII codes or numeric data.

JBWolf · 2012-05-25 01:03

I do have several different brands of rfid tags.... I will probably be getting more cards or keyfobs of different brands at some point later on.
The ones used in those examples I posted are some of the cheap blue keyfobs for sale on ebay.
I also have some cards, from one of those I am getting an output of:
3600613E24

So I guess I may need to distinguish headers just in case.
Is it possible you could make it so that I can write my own program to make calls to?
I would love to be able to pass memory addresses for an indicator, the header and another for tag ID... then be able to retrieve the entire header and tag ID from each memory address... as opposed to one byte at a time being passed.
This way I could do something simple such as waiting for the indicator variable to = 1, then copy the header variable and tagID variable to temporary variables and use my own code for security check and pin functions.... then simply change the indicator variable back to 0 which tells the reader it is ready to read another card.
for example:

 RFID.start_rfid(2, 1, @indicator, @header, @tagID, 6, 0)     
   REPEAT 
        IF indicator = 1
               ++X
              tempheader(x) = header
              temptagid(x) = tagID
                  LaunchSecurityCheck (tempheader(x), temptagid(x))
              indicator = 0

And even more convenient is if the header and tagid could be pre-converted to decimal so I do not have to convert from hex every time

Bobb Fwed · 2012-05-29 13:41

Sorry I didn't catch this before the long weekend...

You can do exactly that, if you just ignore the indicator value (ignore the differences between the possible 1, 2 and 3 values), instead of "IF indicator == 1" do "IF indicator". You can ignore the table listed in the program, and setup your own testing function.

But there is no easy (well there is, I'm just lazy) way to break them apart in the current PASM code, it would be much easier to do it in SPIN. Something like this:

RFID.start_rfid(2, 1, @indicator, @keyvalue, @tagID, 6, 0)     
  REPEAT 
    IF (indicator)
      '' get these three done quickly so it is available to read another key
      bytemove(@header, @keyvalue, 2)                   ' header should be 3 byte string     (not sure, but you might need to add "+ 2" to the keyvalue address
      bytemove(@tag, @keyvalue + 2, 8)                  ' tag should be 9 byte string        (not sure, but you might need to add 2 more to the keyvalue address
      indicator := 0

      header[2] := 0                                    ' make sure string it terminated
      tag[8] := 0                                       ' make sure string it terminated
      LaunchSecurityCheck(hexstr_to_int(@header), hexstr_to_int(@tag)) ' send integer values to function

PUB hexstr_to_int (strAddr) : val
' takes "hexidecimal" string and converts it to an integer value
                             
  REPEAT
    CASE byte[strAddr]
      "0".."9": val := val << 4 + byte[strAddr++] - 48
      "A".."F": val := val << 4 + byte[strAddr++] - 55
      "a".."f": val := val << 4 + byte[strAddr++] - 87
      OTHER: QUIT

But what I don't get is...
Do you not have a predetermined list of valid keys? Are they changing all the time? Do you want to change them on the fly? Why doesn't a standard table work, maybe if I understood the hurdle, I could help a bit more.

RFID Tag ID #'s & conversion

Comments