HF RFID fast read time (response time)

Vlad -

Please see attached to start for the air interface timings (slide 13 for summary of highest speed with this protocol and slide 14 for lower speed.) For inventory command it take ~1.5mSec for TX and about 4.5mSec for RX, total time of about 6mSec to complete that.

7658.ISO_15693_timing_JDW_05_27_2011.pdf

Let me know if you have more questions.

Hello Josh,

Thanks for the pdf file. I have a few Questions.

Is ISO15693 the fastest standard in terms of communication with tags? (Compared to ISO14443A/B, ISO18000-3, Tag-it, NFC, FeliCa.......)

Why does ISO15693 Inventory (Single Slot) TX Time of 1.8mS slower than Read Single Block of 1.72mSec if they have the same amount of bits to transfer?

Can you send an example of a TX and RX bit pattern using ISO15693 Inventory (Single Slot) at 1.8mSec (TX) 4.2mSec (rx)? (My calculations don't add up)

Can you send an example of a TX and RX bit pattern using Read Single Block at 1.7mSec (TX) 2.84mSec (rx)?

The total time (chart on page 13) = TX time + Rx time but does not include wait time of T1 (VCD to VICC) and T2 (VICC to VCD) for continuous readings?

This project consists of 1 RFID reader (TRF7960EVM) and 4 known ID tags. The tags will come in and out of range of the reader at about 10mSec each. Since read single block seems to be the fastest solution, I thought to write in one block location a unique value for each of the 4 tags. I set up the command to read single blocks and I should be able to read a value of 1 from tag 1 ..... to value 4 from tag 4 consecutively. The air interface timing is about 6mS per tag. There also needs some processing time to store this capture data from the tag with a time stamp showing that when the tag was read. The EVM has the MCU which can provide that job but was wondering if you had an idea if all this still can be done within 10mSec.

What is the fastest communication time between rfid reader and mcu (parallel or spi)?

Should we process in real time MOD(bypass encoder/decoder)?

Thanks
Vlad

Vlad -

ISO15693 is the slowest of the technologies between the three. The tradeoff, generallly speaking is the faster you go, the less reliable reading distance you will have. So ISO15693, while slower than the others, allows for vicinity communication distances, while ISO14443 allows for proximity communication distances. In fact this is where the acronyms VCD/VICC and PCD/PICC, when used to describe readers and tags, for ISO15693 and ISO14443, respectively, come from.

ISO14443A and B allow for data rates from 106kbps up to 848kbps, although tags that go up the higher data rate are not common or the least expensive in this class of device.

FeliCa is Sony proprietary that operates at 212kbps and 424kbps.

NFC air interface and basic commands is exactly from these pre-existing RFID technologies, so no faster or slower really - it is the same. 

your questions:

A1. ISO15693 Inventory Command vs. Read Single Block TX time...the Inventory command is transmitting SOF, at least 5 bytes (flags, inventory command, mask length with (in this case a  half nibble pad) and CRC16) and EOF over the air. Read Single Block is transmitting SOF, at least 5 bytes (flags, read single block command, block # and CRC16) and EOF over the air. So they are not the same amount of bits by 2 and if you look at it this accounts for the extra 80uSec (rounded up, actually it is 75.52uSec for the half nibble pad)

A2.  Here are screen captures of SOF, 00, 01, 10, 11 and EOF for ISO15693 using 1 of 4 data coding

2376.ISO15693_Screen_Captures.zip

and the actual timing captures from when i did this testing back in 2005. These captures are MCU GPIO outputs going high when TX and RX are being done from the MCU code executing - so while i don't handily have exactly what you are looking for on that right this moment, you can see in a binary fashion the relationship. 

6545.Inventory_RSB_Screen-Caps.zip

also, here is a timing document which i did a while back which covers i think the rest of what you are asking about, plus i correlated this with 3rd part readers and their documentation as well to make sure that air interface timings i measured were correct.

5756.Tag-It HF-I Timing_Rev1.pdf

SPI or Parallel should both be OK for what you are describing as your project here.

Hello Josh,

I am still not able to get those numbers, can you see what is wrong with the timing below?

VCD TX - Read single block command

SOF = 2bits  75.52uS

Flags = 8 bits  302.08uS

Read single block = 8 bits 302.08uS

block number = 8 bits 302.08uS

crc16 = 16 bits 604.16uS

EOF = 1 bit 37.76uS

TX = 75.52+302.08+302.08+302.08+604.16+37.76 = 1.62mS (should be 1.72mSec)

T1 = 321uSec (VCD to VICC)

VICC Response

SOF = 149.85uS

Flags = 8 bits  300uS

Data = 32 bits 1200uS

crc16 = 16 bits 600uS

EOF = 149.85uS

RX = 149.85+300+1200+600+149.85 = 2.4mS (should be 2.84mSec)

Total time = Tx+T1+Rx = 1.62+0.321+2.4=4.34mS

Also the Inventory timing doesn't match for me can you break it down for me.

Thanks

Vlad

Vlad -

so your question is about the extra 100uSec on the RSB command...and this is over 43 bits (effective, with the SOF being equivalent of 2 bits and the EOF being equivalent of 1 bit)

and this is effectively 2.325581uSec of "slop" per bit (outside of the perfect world)  - which if you have a look at the ISO15693-2 standard, where they talk about Modulation of the Carrier, there are some minimum and maximum variations allowed here, which can account for the differences in the times i think. If your application is time critical to the point that using this protocol puts you on the edge of working here, i would suggest you use a higher data rate protocol so as to give yourself plenty of guardband.

Hello Josh,

Playing around with the TRF7960EVM, I hooked up my scope and set the following under the TFF7960 EVM control application under Test t ab using Firmware Revision 06_16_2011 (programmed LED5 to have trigger out)

0x10 Write single register - Chip Status Control (00h) "21" and ISO Control (01h) "06"
010C00030410002101060000 = 1000210106

0xF0 AGC selection, 0x00 – AGC enable or 0xFF – AGC disable
0109000304F0000000 = F000

0xF1 AM/PM input selection - 0x00 – FM input or 0xFF – AM input
0109000304F1FF0000 = F1FF

0x18 Request command ISO15693 - Cmd = 20, Read Single Block (no option flag), block "00"
010B000304180320000000 = 18032000 - flags = 03, FSK, HIGH bit rate

Reading block 00 from the tag. I noticed that if i leave the tag within the vicinity of the reader and let  the reader read over and over. I notice sometime the tag doesnt respond. See please attached screen grabs of a good trigger and bad trigger.

What conditions are needed to generate this trigger pulse?

Why does the tx of the reader only start 1.78mSec after falling edge of the trigger pulse? can this length be a varible to set the time shorter?

Same goes the for timing between the TAG EOF and the next trigger pulse edge (@1.2mS)

Does the Reader generate the IRQ signal that we measure on the pin or has it been conditioned by the MCU?

While in stand alone (viewing the LEDs blink) is it using the same setup (configursations) as working with the EVM control application?

Thanks

Vlad

Hallo,

I was just wondering if anyone has seen the questions from the previous message on March 16, 2012?

One added note to the problem, once in the 15693 tab we set protocol to read single block, double sub-carrier, high data rate.

We read blocknumber 00 and I can monitor on the scope a continious read of block 00 (as seen in capture images in previous message).

Trying to do any other command like change protocol setting causes the application to crash.Perhaps the image i download for the MCU is not the latest and greatest?

We are using TRF7960A C Code Samples  at http://www.ti.com/product/trf7960a, even though our chip is trf7960 with rev A pcb.  I see no source code for trf7960 to set the led5 to be a trigger signal (only for trf7960a)

Thanks

Vlad