I am planning to use some type of contactless tag with an RFID reader using one of the standard ISO protocols. I had thought, that a ISO14443B compliant reader can read a tag complying to that standard, regardless of the manufacturer. But I have a doubt. The memory structures in different types of tags are different (due to different manufacturer, size, or whatever). So how can a reader, that is supposed to be generic, read any type of tag if it's memory structure is not known? Or must you standardize on the type of tag you are going to use?
What I mean is, suppose I have reader R and tag T. You deploy like a zillion of these in the field. Then you want to use another tag (T2). Do you have to go and update the firmware in all the readers to read the new tag's memory structure? Does not sound logical, or am I missing something?
ISO14443 consists of several parts. A reader supporting the anticollision doesn't have to support the ISO14443 higher layer protocol.
You implement ISO14443 A+B anticollision and the ISO14443 protocol activation for type A. Then you have to decide which protocols you want to support as there are quite a few (take a look at
formatting link
to see what a "generic" reader = may be like)
That's it. Or you spend more time on development and implement the most widely used protocols even if you don't need them immediately. That won't save you if T2 uses some other protocol (you know Murphy, dont you ;-)), but it may. To avoid firmware-updates try to leave as much knowledge of the PICC structure to the application using your reader. But that won't help much, as most protocols are designed around the structure of a specific type of PICC.
Yeah, you're missing the point that everybody is inventing the wheel by itself over and over again. That's why you have to deal with several "standards".
I don't think so! I was involved for ISO 18000-6 and EPC gen2 reader, we were testing our product with different tags (different manufactures) and yes there was a bit performance issue involved but they were still the same for mandatory part. AFAIK, tags complying to certain standard shall have common mandatory memory structure. However, there is always optional part in ISO standards from memory to command set.
firmware in >all the readers to read the new tag's memory structure?
Read/Write operations would return success or error depending on the conditions. Firmware should consist on tow parts; read/write mandatory memory and another for optional. Mandatory part will be addressing the whole memory that will be always predefined according to underlying standard and optional part can perform following steps to read/write unknown memory size:
0) Though it is optional but some limit should be set (one should not expect one GB on passive tag;-)).
1) Start from end of the mandatory memory to one block plus, IIRC IOS
18000-6 block size is 4 bytes.
2) Check the tag response and 2 possibilities can occur a) Error : Retry to for an arbitrary number before announcing the end of memory. b) Success: Increment the counter to address the next block.
Yes, I will try but I have not yet found a copy...
By the way, is ISO 18000-6 to replace 14443A/B and 15693? With so many standard out there you have to be certified with crystal ball reading in order to predict the future so your apps will be safe.... :-s
IIRC ISO has three standards for RFID; ISO 14443 (for contact less systems), ISO 15693 (for vicinity systems, such as ID badges), and ISO
18000 (for variety of applications) . 18000-6 defines an air interface for RFID devices operating in the 860 MHz to 960 MHz range which covers the Industrial, Scientific, and Medical (ISM) band. The standard addresses 3 different categories 18000-6A, 18000-6B and 18000-6C.
Type C referred to 18000-6C is the latest amendment in mid of 2006 , It is a replica of EPC Gen2 .
So I am correct in understanding that applicable standard for contactless payment related applications using 13.56MHz is 14443 (but A or B? actually I don't think it matters)?
Well that can't be the thumb rule but yes many solution providers use the same spectrum that you have mentioned.
IMHO it does matter, for example ISO 18000 A and B tags use completely different techniques over communication links (different coding/encoding scheme, different sequence of command set as Type B is more less client/server architecture where as Type A is and C are quite different in this aspect). For example in type B every transaction is paired with command/response (getting tag ID etc. ) unlike Type C where you need to issue 3 commands (forward link) and encode 2 responses (reverse links) with tight time constrains to acquire the tag ID.
Anti-collision Algorithms : Type B is implemented with binary tree as compare to Type A/C that are backed with Alloha . Binary tree is in deed efficient with greater throughput but Alloha has its own benefits in anti-collision manipulation. In binary tree you are merely salve of counter and random number generator.
Security : Well its my personal opinion that strick time based protocols are more secure. And yeah there is always goodies with encryption/decryption. BTW Type C is having buil-in feature of data encryption.
Consider Type C tag ID enquiry sequence IIRC type A also uses somewhat the same thing with different sequence but ofcourse type C is latest development so they are not the exact match.
Reader starts while issuing the query command and waits for the specific time to expire.
Tag will respond to command.
When Reader receives a response in due time then another check is valid preamble wave following with RN16.
Reader issues acknowledge command packed with received step 3 RN16 and wait for certain time
Tag validates the RN16 with its previously transmitted RN16 (see step 2).
If everything was fine then reader will get tag ID. If CRC of incoming packet is correct then you've got the correct tag ID.
Now consider the tag TD enquiry for Type B
1) Issue GROUP_SELECT_EQ command
2) Wait to process tag response which will be done in ISR.
3) Check CRC for incoming packet and if its correct then you've got the correct tag ID.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.