Re: Improving RFID reader throughput!
- From: "Ali" <abdulrazaq@xxxxxxxxx>
- Date: 11 Sep 2006 20:02:20 -0700
Ali wrote:
robertwessel2@xxxxxxxxx wrote:
Ali wrote:
Folks,
I'm doing performance measurements on our MCU based RFID
reader. The very problem I'm facing is redundancy of tag ID (say 12
bytes) transmission, every time my MCU receives a tag ID; will just
push that ID to UART without any prior knowledge of that it is sending
the same ID again and again. (Due to poor designs of RFID tag protocols
single tag can response its ID repeatedly unless some other tag steps
in). Is it possible to implement some AI or data structure technique to
avoid that? And to decide that this tag id was pushed before so no use
to resend go-on to process another incoming IDs.
I just can't ignore the incoming tags while executing some complex
comparison or say search algorithm even assuming that I have 2K free
memory.
Are you just looking for a fast way to filter tags, IOW, something
like: don't retransmit a tag already sent in the last N seconds?
Perhaps a hash to divide your search space into N buckets of M tags
(perhaps 64 buckets of four tags), then just search the M tags, and
manage those on a pseudo-LRU basis? Obviously all that depends on
exactly how much filtering you want to do, and how much CPU time and
memory you actually have available to do it.
Donald Wrote:
So the RFID tag should have enough code and memory to keep track of other tags in >its immediate area ??
Yes you are right the right place to handle this problem is tag side.
Well friend as I mentioned in my post that we are developing reader so
it is suppose to operate with third party products ( tags falling in
reader supported protocols i.e. ISO , EM , EPC Gen 1 or Gen 2 . )
All rfid tags use binary or aloha algorithm to backscatter their
response (ID), these algorithms assure to minimize the tags response in
anit-collision situation but neither of these algorithm consider that
tag should not be responding repeatedly. The bottom line is that I need
to provide logic on reader to avoid retransmitting the ID!
I was just thinking if following can work:
Assumptions :
RS = An double index array for holding the 15 tags ID.
RS_Counter = This counter will help to make that straight array look
like circular list.
Pseudo-code:
If(RS[RS_Counter] == Recently_Processed_ID)
//Do nothing and process new incoming ID because RS_Counter will always
point to last transmitted ID.
for(i=RS_Counter ; i == 0; i--)
if(RS[i] == Recently_Pocessed_ID)
//got it in list so no use to transmit skip to process more incoming
IDs
If(RS_Counter == 15)
//Ok here I'm! could not find any ID in my stored array so time to
put in array and transmit it.
RS_Counter = 0;
RS[RS_Counter++] = Recently_Processed_ID
//Send it to UART while storing it in array but before make sure that
that array is not full. If array is filled then overwrite the oldest ID
in array, whihc is allways at the starting index.
Not sure if it is worthy ,of course it simply can't be the solution
if I'm using more processing as compare to retransmission.
ali
Pseudo-code
Definitions:
row = represent the total number of tags that array can store.
ID_SIZE = Represents the tag ID size.
Search = Array will be treated as FIFO data structure while performing
the search; that is, start search from latest ID to oldest
Storing = Array will be treated as LIFO data structure while
performing the search; that is, replace the oldest ID first.
Pre-process
1) Set the tag ID_SIZE according to selected protocol tag ID size.
2) Flush the array.
3) Row points to 'zero' index at the start.
Algorithm
The below code is used once the incoming ID has passed the CRC check.
Because we increment after saving the ID start from current row to 0
for(k=row; k >=0 ; k--)
Start searching from CRC as it is 16 bit so there are ample chances
that these tow bytes are unique(but not for sure) and start with next
tag ID if there is even a single mismatch.
for(j=0 , i=ID_SIZE; i >=0 ; i--)
{
if(RS[k][i] == rawid[i])
j++;
else
break; leave this tag ID and iterate for another
if(j==ID_SIZE)
Ok ID is in the list so exit and indicate host if required
goto exit;
}
We could not find the ID in straight search, now start searching the
rest of the old IDs.
Start max size to row+1, as we always increment row after storing at
current location so it is already current row + 1.
for(k=14; k >= row ; k--)
Again start searching from CRC bytes first.
for(j=0 , i=ID_SIZE; i >=0 ; i--)
{
if(RS[k][i] == rawid[i])
j++;
else
break; leave this tag ID and iterate for another
Ok ID is in the list so exit. Indicate host if required
if(j==ID_SIZE)
goto exit;
}
Could not find it , so store it for further reference and push it to
UART
for(i=0; i <= ID_SIZE; i++)
sendbyte((RS[row][i] = rawid[i]));
Increment row.
row++;
Ok array is full start treating it as a LIFO for saving new incoming
IDs.
if(row == 0x0e) // this is size - 1 of rows
row=0;
The worse case of this algorithm is the overhead of searching, storing
and transmitting which requires extra time which counts to 25±
overhead. However, the ideal case is quite promising, as it just
requires ½ millisecond to search and notify the reader that tag is
already in the list. This can save next 5 to 8 milliseconds(Depending
on the communication datarate) for transmitting the same ID, that is
tow more tags can be processed in the same time.
ali
.
- Prev by Date: Re: Suggestions for ARM Single-Board Computer
- Next by Date: Re: 8 bit microcontroller market
- Previous by thread: SPI - can a slave initiate a transfer?
- Next by thread: Microprocessor with Graphic output upto UXGA/SXGA
- Index(es):
Relevant Pages
|
