I’m a service and install technician who deals with many different access control systems on a day to day basis. I deal with both 125kHz prox and 13.56MHz readers and controllers.
Our typical install is using iClass readers, and most customers end up using iClass (13.56MHz) cards. However, I do see a fair amount of standard Prox II (125kHz) cards and readers.
Any suggestions towards implants as far as interference goes? Is the general consensus to get the NExT implant or would people suggest xNT in one hand and xEM in the other?
I know that presenting multiple credentials, even different technologies, to a reader can cause issues. I’m just curious what the recommendation from the community would be.
Interference with the NeXT is minimal. However if you use Multiclass readers, I don’t know of any way for it to discriminate between the 125k and 13.56 side besides disabling the fields using a config card.
Another thing to note is that if you’re using the OG iClass/Multiclass readers they will not read the 13.56 side. Those only read the Mifare Classic tags which is something a FlexM1+ would cover.
I don’t know what controller boards you primarily use, I do DMP or a custom solution (basically only my house). Sometimes the Wiegand bits get weird when you go from 125k to Classic to Ultralight. Just another thing to keep in mind.
We mostly use the new SE iClass or MultiClass readers. 90% of our installs are iClass, unless we’re doing something Homeland Security related, then it’s MultiClass. But I wouldn’t be using my credentials at that point anyway. I’ll have to take a look at our past installs and see what’s mostly out there.
I’ll keep that in mind about the Wiegand but issue, thanks.
Yeah, the default for the 125k is 26 bit, haven’t played with the others too much but I think Mifare classic is 34 and ultralight is 40-something. It’s in the HID docs if you want to get into the nitty gritty of it.
Yeah 26bit stuff is standard Wiegand, which is how basically every reader is wired to the controller… which is hilarious because even if the tag has a 40 bit ID, Wiegand can’t handle it. It’s such an old protocol, yet still the absolute defacto standard for connecting readers with controllers, that it just truncates all extra bits from basically all cards and devices… so even an HF reader reading a 64bit ID off an ISO15693 chip, it tosses all those extra bits in the trash and just sends the first 26 bits (or in some cases the last 26 bits).
That means you could have a production run of a million ISO15693 cards made with sequential IDs, and literally thousands and thousands of those cards would appear to have the same 26bit ID as each other to the controller board. They tried to mitigate this with a “site ID” prefix but omg the whole thing is just a giant pile of shit… get rid of it already.
/end Wiegand rant/
Ok… so with that out of the way… let’s talk about this in more depth.
/begin anti-collision rant/
Ok so there is this thing called anti-collision which is built into ISO14443 and ISO15693 and even some 125khz technologies. It’s part of the RF level spec to ensure multiple chips can be active in the reader field at the same time and not talk over each other (collisions)… but do software developers take advantage of this? No. They don’t. So when you smack a wallet up to a reader that has multiple cards in it, the software powering the reader application will just read the first card that happens to talk, and check it… if it’s not the card it’s looking for, it gives up and gives a “ERRRNT you have failed” error response and then just goes dark… and you have to take the wallet off the reader and pull that specific card out and present it… even though the entire hardware design and ISO standard body worked hard to ensure the application software could easily cycle through every card in the field to find the one it’s looking for… lazy ass software developers went “thanks but no thanks… RFID is about convenience, and I’m going to go ahead and ruin that convenience for others, because coding is my job, and I don’t care about going it well, and the only convenience I care about is my own, so you will all suffer for years because I didn’t want to spend a couple few minutes writing a for/next loop to check all cards in the field. sorry not sorry.”
/end anti-collision rant/
So yeah, you’re right… it will probably bork out hard if you present a NExT to a multiclass reader that is looking for both LF and HF cards.
To append a bit, Wiegand is about as old as it can get. However, with some readers they actually take advantage of more bits in the Wiegand data transmission. HID 125k prox and plenty of other readers out there do Wiegand 26 bit which is your standard 3 digit facility + 5 digit card code. I believe the original multiClass uses 34 bit for keypad and the 13.56 side while it can do either padded 34 bit or 26 bit for the 125k side. Wiegand actually goes all the way up to 40 bits but with things like certificates being stored on cards HID and others are moving to higher bandwidth serial connections on the readers (check out pivClass). This doc from HID gives a ton of info on how they use wiegand and how it all gets truncated/padded.
Also to tack on a random question @amal (when?) will we see the possibility of storing smart card certs on the vivokey flex one?
I think this is not accurate since 26 bits is literally 3 ID bytes and 2 parity bits… so there’s literally no room for 3 facility bytes and 5 card ID bytes. Maybe if you broke that down to smaller nibbles or words instead of full bytes for each “digit”… do you happen to know what the bit map might be for facility codes and card IDs in this schema? The doc does not enlighten
If you mean an HID applet… I have heard rumors and rumblings but nothing is confirmed. Of course if you had the spec you could just write and deploy your own
I may be a bit of an idiot with terminology, but I’m converting it all to decimal in my case. I do know for a fact though that my xEM is programmed as facility xxx, card code xxxxx which is on 3 different HID Wiegand 26-bit systems I regularly use.
Hehe that’s how it is a lot of the time. Time will tell when and if we see more PKI-based systems. So far I haven’t seen any in the wild but I’d imagine Homeland Security/military/DoD would have something like that. Windows and Smartcards are a different spec from HID (to the extend of my knowledge) which sucks. If only there was another standard…
Yes, been in the industry long enough that I can agree with the Wiegand frustrations.
As far as the collision issues go, I’ve dealt with it enough that when a customer claims their card doesn’t work, the first thing I ask is “Do you have any other cards for any other buildings? Gyms? Apartments? Other office complexes?” Frustrating.
We deal with enough multiCLASS and pivCLASS readers that I think I’ll get separate implants, starting with the 13.56MHz version.
Now I need to convince my boss to sponsor this little endeavor haha.
