Our new door entry system at BuildBrighton went live on Thursday night. It not only looked great, but worked a treat too.
We were happily giving out new keyfobs to all our members, and recording the RFID numbers as they displayed on the screen. Entering the RFID values against the member’s profiles on our members website at http://members.buildbrighton.com/ saw the ‘fobs becoming “live” almost instantly. Success!
Originally we’d planned on designing and building a pcb for the entry system but, this being a hackspace, we thought it might be nice to keep the circuitry on it’s original breadboard – complete with loops of wires and ad-hoc amendments that were added into the system as it was designed and tested.
The reasoning being that other members could add to the system some time in the future (maybe adding a wav player or something, instead of the current monotone beeps we have to indicate success or failure).
Everything was working well – members could have keyfobs to “swipe in” to the hackspace, allowing their presence to be recorded on the members website. Even if the fob hasn’t been activated to open the main space door (new members are given discretionary 24/7 access after an initial welcome period of a few weeks) new members can have fobs to record their presence at the ‘space. This is really useful for our growing community as it allows everyone to put a name to a face (rather than ask amongst themselves “who was that guy who was hear the week before last, with the moustache and the stepper motors” for example).
BuildBrighton members can log into the members website and see examples of this at http://members.buildbrighton.com/visits.asp?date=20140328
Then disaster struck.
Leon proudly took his new ‘fob to the reader and presented it. The familiar bleep went off, it connected to the internet and retrieved his (newly updated) keyfob data. “Accepted” said the display and the door mechanism triggered. “Welcome Holly” it said.
A duplicate RFID tag??
It’s not beyond the realms of possibility, but highly unlikely.
We already have about 40 or so “older” RFID tags that long-standing members have.
The newer tags are more oblong, and were sourced from a generic chinese supplier off eBay – so it’s possible that there’s duplication. Or maybe even something wrong with the tags. But the most likely reason is something wrong with the reader of course!
It was noticeable that the duplication was all with the new fobs: none of the “older” style (round) tags generated duplicate values. But with the new tags, the same six or seven names kept appearing on the screen – even for tags that were “fresh out of the box”. Something was definitely awry.
A quick hunt around on Google and we may have a solution:
Most RFID tags work with both “serial/UART” style readers, and the Wiegand protocol. We’re using a Wiegand RFID reader, so that’s the format we’re reading the data from the tags. Wiegand is a 26-bit value and most RFID tags produce 26 bit values. We’re taking a 26-bit value and presenting it as a 12 character, 4-byte string, in the form AAABBBCCCDDD (where AAA is a byte value between 0 and 255, including leading zeros, BBB is a byte value and so on).
Apparently, it’s not unknown for some manufacturers to use 32-bit values in their RFID tags.
If this what is happening in our case, it would make sense of what we’re seeing – the last 6 bits of the RFID value could be being truncated. And if the tags in our batch are numbered, even roughly, serially, dropping the least-significant bits of the value would result in the same value being produced when two different tags are presented!
Imagine one tag had a 32-bit value 00000011 11110000 10101010 00000001. This would be 3,240,170,1 and we present this is 003240170001.
Now imagine another tag had the value 00000011 11110000 10101010 00000010. This would be 3,240,170,2 – the next number in a sequence. A 26-bit version of this number would be 11 11110000 10101010 00000010 and give the same results. But, of course, if we’re reading a 32-bit value as if it were a 26-bit one, we’re losing the last six bits, and both tags would read 00000011 11110000 10101010 00. This would give the vale 3,240,170,0 for both tags. And this would, of course, result in “duplicate” tag ids.
Luckily, we had some different style RFID readers.
As well as the Wiegand reader (which was originally bought for use outdoors, as it came in a fully weather-proof enclosure) we also have two or three serial/UART style readers hanging around. These are not only very easy to interface with (simply provide power and when an RFID tag is presented, they spit out a 14-character string over serial) but they’re also much cheaper than a fully weatherproofed reader.
A quick bit of poking-wires-into-holes and we quickly had a replacement for our Wiegand reader, while able to leave the rest of the firmware (and hardware setup) pretty much as it was. In fact, it actually tidied up the breadboard quite a bit. It seems quite fortuitous that we didn’t go to the trouble of making up a PCB now – as swapping one reader out for another will be much easier to do (with the rest of the hardware mounted in place on the back of the door) while everything is still on the prototyping breadboard!
So what does all this mean?
Well, everyone who has been given a (working) keyfob for the new door entry system will find that it no longer works. As we’re reading the RFID value back as a 14-character string (the first and last bytes are start/end markers, and the next-to-last two bytes are a checksum) all our keyfob IDs are now 10 character strings (using the numbers 0-9 and A-F, whereas before we were completely numerical). To make integration with the earlier system easier, we’ll simply prefix the “new style” IDs with the characters BB (for BuildBrighton) to make them 12 characters again.
So with this new reader in place, everyone should expect their RFID tag to be reported as BB-something-something. We’ll have to update the members website, and once this is done, we can finally put the project to bed and move on to something else (CNC pick-n-place anyone?)