Sir or Madam,
I am using the TRF7964A in a proprietary design which incorporates a 1 uH barrel inductor as the antenna communicating with a custom tag with an NTAG216 RFID IC. The tag antenna is 13 x 13 mm and has a fixed distance of 3 mm from the top of the inductor. The original prototypes worked reasonably well with the tag sitting on the top of the inductor rather than in its normal position in a special cartridge. It was then necessary to replace the inductors on three boards to raise their mounting position to meet the 3 mm height below the tags. After replacing the inductors two of the three prototypes these units had terrible communication and the third was still usable but with many retries and frequent failures.
The circuit is identical to your recommended circuit and uses 1% resistors and 2% capacitors but unfortunately the inductor tolerance is 10%. The antenna tuning component values were selected using SimSmith and verified with a VNWA on one sample inductor yielding an antenna impedance of 52 Ohms. From your experience how much will the receive sensitivity vary with 10% tolerance inductors? The internal RSSI level is always read as 7.
Now to my main question, retrying CRC, parity, framing and noise/collision errors. When any of these errors occur during selection I disable the IC (EN low) then re-enable the IC and restart the selection process. This appears to work quite well. However when I am reading tag data I retry these errors by re-initiating the read sequence. This mostly works but on occasion after transmitting the read sequence to the IC, the IC does not start transmitting to the tag and the firmware signals a timeout error. I have verified this on my DSO. It appears that once a timeout occurs further retries also fail with timeout errors. When a timeout occurs the IRQ service subroutine is disabled so it will not interfere with the retry attempt. The IRU service subroutine is re-enabled immediately after the read sequence has been transmitted to the IC.
Is this retry scheme correct or should the firmware send some other command sequence to properly terminate the prior read operation before starting a new operation?
Best regards,
Al Otis Jr
