I have a RFID reader (CS101). When it starts to scan, it reads one and the same RFID tag again and again. So to read 1000 tags, after the 500th for each uniquely read, it makes a thousant empty 1000 empty turnover already read tags.
What can I do to prevent reading the same tags so many times again?
At the reader level you can look into manipulating the RFID session state. Impinj has good information on how each session works and how your reader will report tag events:
https://support.impinj.com/hc/en-us/articles/202756158-Understanding-EPC-Gen2-Search-Modes-and-Sessions
You can also programmatically add some sort of dwell time, so your program will ignore the tag for so many seconds or minutes after being seen.
Related
I have a access control system from act365. I have Mifare Classic 1k RFID tags, the system works like expected. Now I want to create a software to register the tags in the act365 system.
I read the tags on the act365 reader the cloud gives me a decimal number that representing the UID of the tag. To register a new tag in the system I will scan the tag with an "ACS 1252 Reader" and put the UID in the act365 system by the API.
The Problem is when I convert the HEX UID read from the ACS reader to Decimal number, it is not the same number that the act365 cloud gives me, the System does not recognize the given tag number.
What I have done:
I have tried little and big endian, remove bits from both or the
right. But nothing gives me the same decimal number.
I have tried different NFC readers.
Note:
I called the Vanderbilt support, they told me the reader reads the uid send it to the cloud, they have no idea where the problem is.
Numbers:
Read from the ACT365 System:
78575056
Read from the ACS reader:
76:A2:14:5F
I'm happy for every hint or idea!
When doing scanning with passive RFID tags, you can set the SESSION to '2' in order for the tag state of 'B' to persist for "an indefinite amount of time" even when it is not being energized by the scanner, according to the standards. Your tag will then not be visible to the scanner until this indefinite amount of time expires.
My question is, does anyone have any idea what the maximum amount of time is for RFID tags? I'm sure it's different for different tag manufacturers , etc. However, are we talking seconds, minutes, hours, or even days? I don't want to keep seeing the same tags over and over again while doing a scan in the storeroom, but at the same time, I don't want the tag to be hidden if they need to be scanned again at a later time.
The answer is: it depends. Please note that the standard says 'indefinite when powered'. When powered, it is really indefinite. When not powered, the standard defines it is longer than 5 seconds. For most modern tags, it is typically less than 30s, of course depending on environment conditions.
About the definition of 'powered': please note that this power can originate from any RFID reader, not only the one you are using to interrogate the tags with. Or any other radio device that transmits at the same frequency.
To circumvent this, you can use a SELECT statement to revert the session flag back from B to A.
I'm reading the EPCGlobal Gen2 protocol and RFID and Sensor Networks, and was confused by the following description about the Use of Session: " Session S0 has a persistence time of zero, so in this case, the reader must continually energize the tags. This is achieved by the reader transmitting the CW between commands. When using session S0, the inventoried flag of any tag that loses power during this process will revert to A regardless of its previous value. "
Does it mean that the reader will only energizing tags while transmitting CW, and the tags will not be powered when the reader sends commands like Select/Query, etc?
The tags will stay energized as long as they stay within the electromagnetic field of the antenna.
In other words, an do try to make it simply, the tags will be energized from the moment they have been detected by the RFID reader antenna and until they leave that detection range (even briefly).
I'm having a problem about the Read Interval of my RFID Reader. The Read Interval and SameID interval are all set in x10ms which is declared in Byte. In configuration the max ms i can set is 255 ms and that is equal to 2,550 seconds. Can someone help me? This is the screenshot of the configuration.
Please the piture:
The SameID Interval in the form is in s but the max number is only 255
It is only the specification of the product you are using, and does not specify the behavior of the application program you make.
Applications can incorporate their own Same ID checks.
For example, when tag data is read from an RFID reader, it memorizes time and tag data pair in the application.
Every time the tag data is read, it compares it with the read data stored in the application, if there is the same tag data, compare it with the reading time, and if it is within the time specified yourself, read it later you can discard the data.
P.S.
You can also comment on the manufacturer and wait for it to be realized, or request and fund it to make a special product for you.
Rfid Readers perform switches between antennas while using multiple antennas. Reader runs one antenna while others sleeping and switches one by one. It makes it fast so running one antenna at a time doesn't matter. According to my observations, the time for every switch is 1 second.
(After sometime I realised this 1 second is only for Motorola FX7500. Most other readers do it the right way, light fast like in miliseconds)
That is what I know so far.
Now, in my specific application I need this procedure to run faster, like 200ms instead of 1s.
Is this value changeable? If so, which message and parameter in LLRP can modify this value?
Actually the 1 second problem is with MotorolaFX7500 reader. By examining LLRP messages that Motorola's own library generates between FC7500, I discovered there are vendor specific parameters that can be used via custom extensions fields of LLRP. These params and settings can be found in Motorola Readers' software guide. This switch time is one of these vendor specific parameters, it's not a parameter of generic LLRP. A piece of code generating LLRP message including the custom extension with the proper format, solved my issue.