As RAIN RFID matures both technologically and businesswise, tagging requires scalable and flexible processes. I recently heard James Goodland, RAIN RFID Solutions Manager at NXP stating: “Going forward, the RAIN-ability of an item will be more likely integral to product design, rather than just added on an item” This implies a steady flow of new players and end-users getting into our industry, and the RAIN technology vendors need to be ready to support and help them out.
Beginning with this, the first of blog series with NXP® Semiconductors, Voyantic will address technical issues that should be considered when adopting RAIN RFID in various manufacturing environments. We shall start by understanding how the cycle time greatly affects your options, even down to the selection of the tag IC.
Translating Line Speed Into Available Cycle Time
Accelerating into the new decade 2020 RAIN tagging still dominantly relies on inlays which are converted either into tickets or labels. Printing of variable data, and encoding of RAIN labels, is done in a process that runs tens of meters per minute. Taking a figure of 30 m/min as a challenging benchmark example, and assuming a label or ticket length of mere 3.2 cm (1.25 Inch), the processing speed translates into 16 labels/sec.
Turning the numbers around 1 Sec / 16 labels gives 62.5 ms/label. This is the available cycle time in which you need to move in, process, and move out the label. If your RAIN encoding sequence stays within this cycle time, your production capacity stays unaffected.
Singulating the Tag Without Wasting Time
Quite often in a manufacturing environment, you need to singulate a RAIN label among others in the proximity. You can either use the protocol to do it or rely on skilled engineering.
Going with the protocol, you would first perform an inventory followed by the encoding process for the label. Inventory requires time specifically if high Q-values are used. This increases timing overhead, which you barely have in high process speeds.
An RF engineer can have a label singulated with careful triggering, use of dedicated antennas and appropriate reader settings. As a result, singulation does not add timing overhead at all. The Voyantic solution supports both of these approaches. Specifically, in high process speed, we usually prefer to handle singulation based on the antennas.
Efficient Cycle Time Can Be Close To 100%
A label does not need to be in the optimal position in relation to the antenna all the time for a robust encoding system to successfully complete the job. Thus, the efficient cycle time can be fairly close to 100%. This means the reader won’t idle at all when the machine runs at the specified maximum speed.
However, if encoding fails at high line speeds, you rarely have the luxury to retry encoding. If you’re working with an encoding system that is not reliable or stable enough, but you want to protect the production yield, you may need to bring the cycle time down to < 50% simply to reserve the time for a second encoding try.
An alternative strategy is to have a second reader available to process the failed labels. Obviously, a second reader adds cost and complexity and increases the space needed in the machine.
I would say that your overall preferred strategy in a production environment is to utilize RAIN encoding systems that have high reliability and high stability.
A Few Alternative Commands to Write With
All the GS1 EPC Gen2 (aka ISO 18000-63 standards family) ICs need to support the WRITE-command. The protocol also includes an optional command BLOCKWRITE, which was specifically developed to speed up the encoding processes.
It is up to the design of the IC to either support the BLOCKWRITE or not. Also, beware that the number of words that can be written with one BLOCKWRITE-command varies. Let’s look at how the NXP UCODE® 8 performs:
a) WRITE
WRITE protocol control (PC) word, UID / EPC 96 bits and access password (nine words) + lock + read : 66.5 ms
b) BLOCKWRITE
BLOCKWRITE PC word (1 word at the time), UID / EPC 96 bits (3 blockwrites, 2 words at the time), and access password (1 blockwrite, 2 words) + lock + read : 49.4 ms
Only the latter case satisfies the example limit of 62.5ms and even leaves a comfortable margin to play with. With that said Blockwrite can be a lifesaver. At the same time, the example shows that specifying the encoding sequence using Blockwrite requires expertise.
RAIN Tag ICs Keep on Improving
The design teams of IC’s need to calmly work in a crossfire of conflicting requests: please deliver a tag IC design which boasts a fantastic feature set, is smaller than the previous model and complies with RED. “And yeah,” adds the marketing expert with colourful graphs, “kindly make the new IC also more sensitive than any other RAIN IC in the market. OK?”
“OK, no problem” responds the Engineering Director, takes a longer-than-average-sip of Dr. Pepper and starts orchestrating the design effort.
Eventually, the new IC lands at the Voyantic lab, where various issues will be verified and addressed:
RAIN RFID Tag ICs Benchmarked for Write Speed
One of the IC characteristics we look at is the time required to perform the WRITE or the BLOCKWRITE operation. You rarely find those numbers in datasheets, and even if you do, it’s really difficult to make sense out of them. Although meaningless for the majority of RAIN end-users, when one encodes labels at max speed, this timing parameter has to be known.
If you’re fascinated to learn more, please download the “RAIN Tag IC Encoding Speed Test Result Overview”. As we’re writing the UID / EPC, ACCESS password, locking the memory and verifying the UID / EPC, not all the IC’s are under the example target of 62,5ms.
The write speed of ICs may be dependent on the protocol settings. For the purpose of this story, we have used the same settings for all the different ICs, and those are specified in the document.
Is That All?
There are plenty of fascinating details of how an encoding system is engineered to perfection, but if you’re either designing or operating a label processing machine, this is pretty much the story of encoding speed.
Read the next part in our blog series with NXP: Scaling Up with RAIN RFID Tags: The Path to a World Where Every Item Has Its Own Digital Identity
All blog posts
