Strange reading results when using RFID R/W module 28440

propellifly

Hi everyone,

I'm in the process of writing a simple library for the Netduino to read RFID tags using R/W module #28440. My test application just spins in a loop and reads the serial number. If there is no tag, the serial number returned is 00000000. I print all bytes send by the reader to double-check the serial number information.

Generally, it works, but I have some questions for the RFID experts here.

1. I have been testing by swapping tags in and out, keeping them parallel to the face of the reader (as specified in the datasheet). When I remove a tag and keep it plenty far away, the reader continues to send the serial number data for 2-3 seconds. Is there a reason for this?
2. Sometimes when I remove a tag, the serial number changes. Usually, the last byte is incremented, and I have no idea why this happens.
3. Sometimes, the MSB of the serial number gets shifted and becomes the LSB. So if the serial number is usually 01ABCDEF, in the weird case it would be returned as ABCDEF01. My serial stream that gets printed directly from the serial port verifies this.

Here's a sample output when it exhibits behavior #2: (serial number is already messed up in this example)

=> 01 B5 BD 7E 01
Serial number: B5BD7E01
=> 01 B5 BD 7E 01
Serial number: B5BD7E01
=> 01 B5 BD 7E 02
Serial number: B5BD7E02
=> FF FF FF FF 00
A first chance exception of type 'BioNex.NETMF.RFIDException' occurred in RFIDLibrary.exe
Serial number: 00000000

Here's a sample output when it exhibits behavior #3:

=> 01 01 B5 BD 7E
Serial number: 01B5BD7E
=> 01 00 00 00 00
Serial number: 00000000
=> 02 FF FF FF FF
A first chance exception of type 'RFIDException' occurred in RFID.NETMF.exe
Serial number: 00000000
=> 02 FF FF FF FF
A first chance exception of type 'RFIDException' occurred in RFID.NETMF.exe
Serial number: 00000000
=> 02 FF FF FF FF
A first chance exception of type 'RFIDException' occurred in RFID.NETMF.exe
Serial number: 00000000
=> 02 FF FF FF FF
A first chance exception of type 'RFIDException' occurred in RFID.NETMF.exe
Serial number: 00000000
=> 02 FF FF FF FF
A first chance exception of type 'RFIDException' occurred in RFID.NETMF.exe
Serial number: 00000000
=> 02 FF FF FF FF
A first chance exception of type 'RFIDException' occurred in RFID.NETMF.exe
Serial number: 00000000
=> 01 B5 BD 7E 01
Serial number: B5BD7E01
=> 01 B5 BD 7E 01
Serial number: B5BD7E01

The only explanation I can come up with is that the data is shifted, i.e. the 0x01 at the end of the serial data is really ERR_OK. I do not believe this comes from my code, as I flush the serial receive buffer before I send each command.

Can anyone provide insight into these three things? Have any of you experienced these issues before?

EDIT -- I should also add that while I have the reader plugged into +5 on my Netduino, I also have the external 7.5V power supply connected.

EDIT #2 - I just witnessed a new behavior:

=> 01 01 B5 BD 7E
Serial number: 01B5BD7E
=> 01 BD 7E 00 00
Serial number: BD7E0000
=> 01 01 B5 BD 7E
Serial number: 01B5BD7E
=> 01 01 B5 BD 7E

Do people typically read RFID tags multiple times and go with whatever value was read the most?

propellifly

I figured it out, and I posted a reply here, but because I got logged out, my response never got posted!!! Argh.

Short summary -- it was a bug in my code. I think bombarding the reader with read requests was allowing it to send more than one response at a time. Due to ill-timed serial port flushing, I was leaving a packet fragment in the buffer. This would cause the data to get misinterpreted, because the first 0x01 in the tag's serial number was getting interpreted as a success message from the reader! I changed my serial reading approach (read *all* data instead of just the number of bytes that I want) and the problem looks like it is gone.

Chris Savage

I got to your post too late, but will still suggest that, when you get a valid read you delay sending any more commands to the reader for about 3 seconds. Once a tag has been read every reader I know of delays reading again for a few seconds. This makes sense since often the valid read then has to be looked up in a database and then perhaps a door lock release is activated or some other action taken.

kwinn

Chris Savage wrote: »

I got to your post too late, but will still suggest that, when you get a valid read you delay sending any more commands to the reader for about 3 seconds. Once a tag has been read every reader I know of delays reading again for a few seconds. This makes sense since often the valid read then has to be looked up in a database and then perhaps a door lock release is activated or some other action taken.

Same here, every one I have seen has a delay of 3 to 5 seconds. Some doors have a magnetic door contact as well, and the controller will not send another read command until either the door contact has opened and closed or the time delay has finished.