/begin Wiegand rant/
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.