What kind of data can a Wiegand 26 reader read from an NFC card?

Question

I can read an 13.56 MHz NFC card with my phone's NFC reader and I get a hexadecimal value like:

1BF52327

This represents the card UID or serial number.

What data can I expect from a Wiegand reader? Will it be able to read the same serial number?

As the Wiegand reader can read only 26 bits, what exact data will it read?

---

Update

I was able to test the above. I have used a HID SE r10 reader and a non-brand reader.

So here are the results.

This is the value of the above card (1BF52327) in binary that is ready by my phone's NFC:

11011111101010010001100100111

Next this is the value I get from a HID reader for the same card:

1101100011011100000010101110010000000000

This is the value I get from a non brand reader for the same card:

1101110000001010111001000

I can quickly find the correlation between the HID and non branded reader, in the end they are the almost the same.

But I cannot related the values read by Wiegand readers to the original value read by the NFC.

Any ideas on what I am doing wrong? I have used several libraries Joan, Wiegand-Protocol-Library-for-Arduino on an RPI and arduino and I get the same values from the Wiegand readers

Answer 1

Will the Wiegand reader be able to read the same serial number as the phone?

Wiegand readers for 13.56 MHz (more specifically ISO/IEC 14443 Type A) typically read the anti-collision identifier of cards/tags. The phone also seems to display the anti-collision identifier (UID) to you. So, yes, both devices read the same data element.

However, as you correctly found out, the reader only transmits a 26 bit value over the Wiegand interface (actually only 24 bits, since two of them are parity bits). As the UID has either 4 bytes, 7 bytes or 10 bytes, it needs to truncate the UID into a 3 byte value to transmit it over the Wiegand interface.

What data can I expect from a Wiegand reader?

Frames on the Wiegand interface look like this:

b0  b1  b2  b3  b4  b5  b6  b7  b8  b9  b10 b11 b12 b13 b14 b15 b16 b17 b18 b19 b20 b21 b22 b23 b24 b25
PE  D23 D22 D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9  D8  D7  D6  D5  D4  D3  D2  D1  D0  PO

The first line being the bits numbered as they arrive over the Wiegand wires. The second line being the same bits as they are interpreted by the receiver, where PE (b0) is an even parity bit over D23..D12 (b1..b12), PO (b25) is an odd parity bit over D11..D0 (b13..b24), and D23..D0 are the data bits representing an unsigned integer number (actually two, since the upper 8 bits are the site code and the lower 16 bits the tag ID).

Even though there is a logical split into site code and tag ID, these readers typically just use a truncated form of the tag ID as the 24 bit value.

How this value would map to the hexadecimal value you received on the phone strongly depends on how that hexadecimal representation was created (specifically its byte order). It might be as easy as just taking the last 3 bytes (F52327), but it could just as well be that it's 1BF523 (or any byte-reversed (or even bit-reversed) variation of that).

---

UPDATE: Regarding the values that you get for your readers...

First of all, you seem to have dropped leading zeros from the values. For instance, 1BF52327 is a 4-byte value and, consequently, has 32 bits:

   1    B     F    5     2    3     2    7
0001 1011  1111 0101  0010 0011  0010 0111

The same seems to be the case for the values received from the readers (either that or the library automatically dropped the leading parity bit or dropped both parity bits and added an arbitrary number(?) of zeros at the end of the values).

So your values are: 1101 1000 1101 1100 0000 1010 1110 0100 0000 0000 1101 1100 0000 1010 1110 0100 0

As you found out yourself, these clearly correlate in that one byte is missing at the beginning and that the value from the HID reader is filled with more zeros in the end.

Looking more closely, these values also correlate with the first binary value. The trick is to invert the values first. Thus, the values

1101 1000  1101 1100  0000 1010  1110 0100  0000 0000
           1101 1100  0000 1010  1110 0100  0

become

0010 0111  0010 0011  1111 0101  0001 1011  1111 1111
           0010 0011  1111 0101  0001 1011  1

For the value from the Wiegand reader, this would also fix the trailing odd parity bit (PO) since there are 7 '1' bits (incl PO) now (though this could just be coincidence).

You can now see that these values represent exactly the first value in reversed byte-order. If you reverse the byte-order of

   1    B     F    5     2    3     2    7
0001 1011  1111 0101  0010 0011  0010 0111

you get

   2    7     2    3     F    5     1    B
0010 0111  0010 0011  1111 0101  0001 1011

Comparing that to the other two values, you see that they match:

0010 0111  0010 0011  1111 0101  0001 1011
0010 0111  0010 0011  1111 0101  0001 1011  1111 1111
           0010 0011  1111 0101  0001 1011  1

Consequently, the value that you receive from the HID reader represents 2723F51B and the value that you receive from the Wiegand reader represents 23F51B. Hence, the byte 27 is truncated.