RFID spurious reads
JetForMe
Posts: 5
Hi. I'm trying to develop a product using the RFID reader module. One thing I'm noticing is that, with no cards nearby, the module sends apparently valid strings periodically. That is, they start with 0xA and end with 0xD, and have 12 bytes, but there is no card present with the reported ID.
Is the controller on the reader properly checking the parity bits encoded in the card (according to the datasheet, there are numerous parity bits)?
TIA,
Rick
Is the controller on the reader properly checking the parity bits encoded in the card (according to the datasheet, there are numerous parity bits)?
TIA,
Rick
Comments
I can look further into this (I did not write the firmware). In my experience these erratic readings are rare (in terms of how many customers are affected) and caused by EMI/RFI interference from a nearby source. In any event, other than the $0A and $0D the returned data is not usually valid, containing only $00’s. In a typical use the received tags are compared against known tags and unknown tags are rejected. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
We have seen this issue before and as with any device·that receives a signal, you are susceptible to also receiving interference.
·
As Chris mentions,· "In a typical use the received tags are compared against known tags and unknown tags are rejected."
·
However, there may be a circumstance that you want to be "notified" if someone that is not authorized··attempts to gain access.
·
There are a couple of solutions in software that modify the basic serial·input string to make it a little more robust that might work for you to prevent·random "No Tag" reads.
·
This information below·is extracted from an internal E-mail thread at Parallax, sparked by the following thread... http://forums.parallax.com/showthread.php?p=670723
·
Internal Email thread:
--------------------------------------------------------------------------------------- Email 1 ------------------------------------------------------------------------------ What I see happening in BOTH programs (<-- Demo programs available from the RFID product page) and could easily be corrected in software. In our software we are checking for the MSB or Start character of $0A from the RFID data string. Which apparently in some cases CAN be randomly generated. Following the Start Character we look for the next 10 characters which represent the RFID data stream. If the Start Character is initially a random character, then the next ten data characters are junk or as the current software implementation sees it as an invalid tag # There is a final Character that goes unchecked that we should modify the code so that it is checked in the future. The LSB or Stop character of $0D is also sent from the reader. So, instead of reading 10 Characters after the $0A character detection, we should read 11 Characters and confirm that the last Character reads as a $0D before accepting and comparing the received data. I can probably modify the code that I have this evening and allow it to run in a situation that previously caused false reads. --------------------------------------------------------------------------------------- Email 2 ------------------------------------------------------------------------------ After running a week with the modified code that checks for the Stop Character, the number of false reads Seems to be greatly reduced, but there are still a few that fall through. The RFID data packet looks something like this... Start MSB<----10Characters---->LSB Stop Another thought to refine this even further, would be to read two consecutive RFID data packets or simply add another character in the WAIT string. The current Serial input line reads.... SERIN RX, T2400, 1000, TimeOut, [noparse][[/noparse]WAIT($0A), STR buf\11] ' wait for... header + ID + footer ; Timeout after 1 second By changing this to read... SERIN RX, T2400, 1000, TimeOut, [noparse][[/noparse]WAIT($0D,$0A), STR buf\11] ' wait for... footer + header + ID + footer ; Timeout after 1 second ...You effectively test for two incoming packets. If the duration between the Stop of the first Packet (footer) and the Start of the second Packet (header) is longer than 1 second, the unit times out and the data is ignored. Start MSB<----10Characters---->LSB Stop Start MSB<----10Characters---->LSB Stop |<-- Read data from Here to... ...Here -->| |<-- Invalid -->| if this time exceeds 1 second The latest implementation seems to all but eliminate any false RFID reads I have experienced. I suppose you could read the RFID packet twice and compare the Bytes to make sure that they match, but the buffer would be twice the size now, and variable overhead might be an issue in the Customers application.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
However, I still get the occasional spurious read. I don't really like the double-read approach because of the extra time the user has to hold the badge to the reader.
My real question is for Grand Idea (I've sent them an email, but I don't know if they're going to respond). The EM4100 RFID IC has numerous parity bits that, if checked, should prevent all but the truly rarest of spurious reads. I'd like someone to confirm that the onboard firmware currently either a) DOES check or b) DOES NOT check those parity bits (at the very least so I can characterize how well the EM4100 series works.
If it doesn't check, how hard would it be to get Grand Idea to update the firmware and have you guys update the product?
(And, is it possible to get a product that works down to 3.3V?
You don't have to read two full data streams, just the·stop character·of the previous·stream.· A total of 13 Characters as opposed to only 12.
It's unlikely that there will·be a 3.3V version, because·a reduced voltage will also mean that the detection field·is also·reduced.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I have checked into this and the RFID Reader does check the parity bits. Nonetheless it is possible to get random EMI/RFI interference in any RF system. One other possible detection validation possibility is some sort of sensor that can sense the presence of someone in front of the RFID Reader. Something like a PING))) or IR emitter/detector. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Thanks for checking!
Parity is a very simple test. If you're checking even parity, an all zero value is valid, yet might be complete garbage.
Of the 64 bits transmitted by the card, the first 9 bits must be 1s, the last bit must be a 0, and the rest are data and parity interleaved. I find it hard to believe that random EFI could so often make a valid transmission.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He who dies with the most toys wins!