Wiegand card numbers are seen different on Hikvision and ZKteco

Question

I have a problem with two access control panels, one is Hikvision and the other one is a ZKTeco CCA-400, those two panels see the Wiegand card in a different way, this is a big problem because I cannot import cards from ZKteco to Hikvision or the other way around.

Currently I have a card that is physically labeled with the following: 0002821060 043,03012

Hikvision panel sees the card as: 2821060 ZKTeco panel sees the card as: 04303012

My final goal is to understand why is this happening and build a custom Wiegand rule on the Hikvision in order to transform the card id's to be seen identical by both panels.

I searched and couldn't figure it out, so in my pursuit to debug this issue I connected a Wiegand reader to a Arduino UNO just to see that is coming on the wire from the reader, the results just made the problem even confusing:

I tried to Wiegand libraries: https://github.com/paulo-raca/YetAnotherArduinoWiegandLibrary and https://github.com/monkeyboard/Wiegand-Protocol-Library-for-Arduino

Surprise! The first library sees the card as: Read 26 bits. 0001010110000101111000100100000000 FC = 43, CC = 3012 This is exactly what the ZKTeco panel sees.

The second library sees the card as: Card readed: 24bits / 2B0BC4 That in decimal is 2821060, exactly what the Hikvision is seeing.

Can anyone explain to me why this is happening ? From reading the docs of the protocol is pretty straight forward and should not really have two independent ID's.

Hopefully I managed to explain the issue in a good way.

Thanks!

Answer 1

It sounds like the difference in what you are seeing is the two parity bits. Each half of the number encoded into the card has its own parity bit, with one half odd parity, and the other half even parity. In addition to detecting read errors, these two bits allow detection of use of a Wiegand card normally vs. upside-down.

You might check that by determining the reaction of the two devices to running the card through with the front side toward the back. My guess would be the one that only reports 24-bits may ignore reversed reads, but the other might report a different number (with bits reversed from the first one.)

I worked for Kastle Systems on what was probably the first commercial application of Wiegand cards for security almost 40 years ago. The parity scheme was similar to that used on UPC barcode readers. I see there are still documents out on the web describing the, Wiegand Kastle format 32-bit format, which looks like it may be helpful to you.

Answer 2

I managed to sort this out, it seems that ZKTeco and Hikvision handles the conversion from HEX to DEC in a different way, that's the reason there are two different numbers on the card.

So it goes like this, we have a card that has physically printed the following sequence of numbers: 0002821060 043,03012

We convert 2821060 to HEX = 2B0BC4 ( This is what ZKTeco sees )

For Hikvision: We convert 2B to DEC = 43 We convert 0BC4 to DEC = 3012

The result decimal number is 43 3012, pretty close to what the access panel sees. Now, we have to pad it so it has 8 digits like this: 04303012

If the first bits are <100 in decimal we have to add a 0 in front. We also need to pad the rest of the bits so the second part reaches a length of 5 digits.

Conclusion: Hikvision correctly converts the card to Wiegand 26 format ( facility code + card id ), ZKTeco instead converts the entire card number to decimal directly without splitting the facility id / card id.

Hopefully this will be helpful to other people having to deal with this type of access control panels.

I wrote a fragment of messy code that will convert a ZK exported personel file to Hikvision card format.

import sys

def convert(dec):
    h = hex(dec)
    h = h[2:]
    #print "HEX {}".format(h)
    first = h[:2]

    first = int(h[:2], 16)
    if first < 100:
        first = "0{}".format(first)
    second = int(h[2:6],16)

    first = str(first)
    second = str(second)
    if len(first)+len(second) == 8:
        final = "{}{}".format(first,second)
    else:
        final = "{}0{}".format(first,second)

    #print "HIK {}".format(final)
    #print "ZK {}".format(int(h,16))
    return str(final)


pid=1
with open("zk.csv") as f:
    lis = [line.split(",") for line in f]
    for i, x in enumerate(lis):
        persid = pid
        if x[1] == "":
            name = "Fara nume"
        else:
            name = "{} {}".format(x[1], x[2])
        cardid = convert(int(x[3]))
        if cardid[:1] == "0":
            cardid = "'{}".format(cardid)
        print "{},NAN,{},1,,,,,{},,".format(pid, name, cardid)
        pid+=1

Answer 3

This is the only post on internet I am finding on this topic. I report similar issue. Please do not delete as was done previously because this might help someone.

What I did is convert serialized RFID to site+cardID (hikvision way) with Excel:

M88 is DEC2HEX(L88) (M88 is the Hex of the serialized card number)

first 3 decimal digits

=IF(LEN(HEX2DEC(MID(M88;1;2)))=1;"00"&HEX2DEC(MID(M88;1;2));IF(LEN(HEX2DEC(MID(M88;1;2)))=2;"0"&HEX2DEC(MID(M88;1;2));HEX2DEC(MID(M88;1;2))))

last 5 decimal digits

=IF(LEN(HEX2DEC(MID(M88;3;4)))<5;"0"&HEX2DEC(MID(M88;3;4));HEX2DEC(MID(M88;3;4)))

This is a good calculator I've found but not suitable for hundreds of lines of RFIDs https://btrockford.com/security/card-access-control/proximity-card-calculator/

Probably there is an option to use custom Wiegand rules to modify the hikvision default behavior (I didn't have success with that till now).