NXP handles the assignment of Chip UIDs during the manufacturing process before the chips are inserted into the cards.
As a supplier of Mifare cards, we have no control over what UID numbers are on the card chip. This is the case for most suppliers of Mifare cards.
When a customer inspects a card on their system the UID may show with decimal digits (0-9) but it is not the case that a
Mifare UID viewed in decimal always has a set number of digits.
The Mifare UID is a 4 Byte hexadecimal value e.g 4E DC F0 81, see attached screenshot (Mifare UID.png ) from the NXP tag info Android app. This illustrates the UID on sector 0 block 0 known as the manufactures block.
The decimal value (e.g 1567935364 ) is a conversion of the native hexadecimal value. You can see in the attached document Mifare UID Handling AN10927 in the introduction section 1.
Note: A UID is not a “serial number”, but a unique identifier. There is no recommendation how to turn the array of bytes into an integer.
A 4 Byte NXP Mifare UID always has 4 Bytes. However, when the 4 Byte UID is viewed in decimal the number can vary in length so if we supply a box of cards some UID's may be longer than others when viewed as a decimal value.
A simple analogy would be a Police car that can only read number plates in the new format eg MA67 SED and not the old numbering scheme of Y999 YYY or Personalised plates that are still valid. So the Police card system in not reading a valid number when it should do.
NXP Mifare documents make no mention of 8, 9 or 10 digit decimal numbers. They are 4 or 7 Byte values.
The Mifare Classic EV1 cards we supply have 4 byte UIDs’ and we can source 7 Byte UID if required which have a much longer decimal number, usually 16 or 17 digits, you could send samples of 7 byte cards if you have them as sometimes this can help.
Attachments (3)
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article