Accessing (memory in) multiple types of contactless tags?

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?

Thanks

EUG

Reply to
ElderUberGeek
Loading thread data ...

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".

Dirk

Reply to
Dirk Dreßler

Snip:

different (due >

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.

ali

Reply to
Ali

Hey thanks, good input. I will look up the specifications you mention.

So in summary I understand the following:

  1. There is a standard for at least some part of the memory, for tags that comply
  2. I should have the firmware first check for the type of tag by querying that location
  3. And based on the type of tag (and its unique memory map), branch off in to a different logic for each type of tag

Is that a fair assessment?

Thanks

Ali wrote:

different (due >

firmware in >all the readers to read the new tag's memory structure?

Reply to
ElderUberGeek

Check the standard for Information on tag memory size. If memory size field is present then it will make your life easier.

ali

Reply to
Ali

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

Reply to
ElderUberGeek

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 .

ali

Reply to
Ali

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)?

Reply to
ElderUberGeek

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.

  1. Reader starts while issuing the query command and waits for the specific time to expire.
  2. Tag will respond to command.
  3. When Reader receives a response in due time then another check is valid preamble wave following with RN16.
  4. Reader issues acknowledge command packed with received step 3 RN16 and wait for certain time
  5. Tag validates the RN16 with its previously transmitted RN16 (see step 2).
  6. 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.

ali

Reply to
Ali

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.