Forum / MIFARE general topics and applications / Different numbers being read on different types of readers
-
I was hoping someone could help with the following. Hopefully my description of the issue makes sense.
We are currently using mifare 1K classic cards (http://www.digitalid.co.uk/products/164/Pack-of-100-NXP-and-Philips-S50-1K-MIFARE-Cards/) for access to our PAC door entry system.
When we scan this card into the PAC SecureNet software it reads back the card number as a hex number (4CDDA15F). Coverting that number into decimal reads as 1289593183. As the cards are physically blank we have no idea if this is actually the card ID number or not!
The problem then comes to the following. We are looking to rollout Equitrac printing solution. We were hoping to use our existing ID cards and not have to recall them all. We were going to export the card information from the door entry system, import into AD and have the cards all pre-staged for existing employees and all new cards. The Equitrac system reads teh cards in decimal format. The problem is the number it reads is not the one that we would expect, ie 1289593183 from the example above.
Help!
+ 0 | - 0
Dear JimSmith,
The value you read from Mifare Classic card seems to be the UID of the card. You said your card is empty, and actually UID values are inserted during manufacturing, so they exist even in the empty cards.
Regarding the decimal value you had read within your existing system, we should first be sure that if this value is the decimal representation of the UID itself, or is it a value read from Mifare blocks (which was written before). If you are sure that it is UID value of the card, then you will need to check if the conversion from hexadecimal to decimal value conversion is in the same way you do.
Regards,
Ismail.
+ 0 | - 0
Hi Jim,
you can check if the card number is the ID reading the first 4 bytes of the block 0 of sector 0 (manufacturer block), see figure 6 of http://www.nxp.com/documents/data_sheet/MF1S50YYX.pdf
To read this out you can use for example teh NXP Pegoda reader with MIFARE Discovery (see NXP web-site) or any NFC Android phone using the NXP TagInfo application from the Google Play store.
Regards
Francesco
+ 0 | - 0
hi Ismail,
what I meant by "empty" was the cards have nothing physically stamped on them to verify what the UID of the card is for us to compare between the two scanned in entries to check.
And that is the crux of the issue. We have no idea what the real UID of the card is!
+ 0 | - 0
Thanks Francesco,
Here was me thinking (hoping!) it would be a simple thing to solve!
+ 0 | - 0
Hi JimSmith,
I assume that your PAC Door Entry System Reader and Equirtrac Printing Solution Reader are two different reader maker. I also assume that both two readers are reading UID of MIFARE card and you could verify this by checking individual reader supplier. I could think one of possibility of your problem is the 4 byte of the UIDs sequence order. Example PAC Reader reads the 4 byte UIDs as 4CDDA15F(1289593183) but the Equitrac Reader may reads the 4 byte of UID as 5FA1DD4C(1604443468).
+ 0 | - 0
Using an Equitrac reader we are seeing that the UID extracted from a card (decimal) does not match any of the numbers imprinted on the card. My customer has MIFARE cards which are pre-printed with numbers they use with their door entry system - first four digits of the number printed on the card equals a users "PIN". When we read the card into the equitrac system we receive a 20 digit length decimal value with no correspondence to the number printed on the card. Is this typical?
+ 0 | - 0
Darrel,
The most likely problem is how the UID is being interpreted by the reader. As Kevin described in the earlier post, determining where UID0 is located is key. Here is a simple test, take the number that was printed on the card, convert it to hexidecimal. Write that number down. Now take the value that is returned by the PACS system and convert that to hexidecimal. What you should see is the same hexidecimal values but at different locations ( see Kevin's post ).
Hope this helps
+ 0 | - 0
Thanks for the prompt reply! We will begin with the steps you suggested.
Darrel Summers
+ 0 | - 0
I just had the same problem using an Identive AMID2US00 reader, where our old kiosk readers gave a different number.
These posts gave me the answer to why it was happening.
(using your numbers as example)
Old readers : 4CDDA15F
Identive readers: 5FA1DD4C
After reading this post I noticed the pattern.
1st and 4th bytes were switched
2nd and 3rd bytes were switched
Old readers : 4C DD A1 5F
Identive readers: 5F A1 DD 4C
Is there a bit of software that can interface with e.g. an Identive reader and insert the switched number easily into another application (registration program for cards or when creating lists in excel/database/document) when read?
This would allow us to use the new readers but have them display the old numbers without using multiple steps of conversion of the ID-data.
+ 0 | - 0
"After reading this post I noticed the pattern.
1st and 4th bytes were switched
2nd and 3rd bytes were switched
Old readers : 4C DD A1 5F
Identive readers: 5F A1 DD 4C"
If you notice, this is not switched but reversed. There is a method called MSB (Most Sensitive Bit) and LSB (Least Sensitive Bit). This tells the reader how to send the information in what order. 32bit start from front or back. If you can display the full 32bits of data, you will notice where this portion is coming from.
+ 0 | - 0
-
AuthorPosts
Viewing 11 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic.