Pileup.gif 80 KB

Other Continuous Encoding Systems

Other RFID companies have had relatively fast encoding systems for several years. These systems have two main drawbacks:

  • They depend on proprietary extensions, so are not standards based
  • They are not protected against pileups, so depend on chips to enter in good order

Proprietary Extensions

Alien has Blast. Impinj has Item Encode, which was once called STP, and Continuous Encode before that. Both require reader and chip to match, so lock label converters into one brand, or multiple systems. Some have onerous costs and ongoing fees, but this page is about technical issues. It is widely believed that standards based solutions are more robust than proprietary ones. GlueLogix Encode In Motion is standards based.


In 2013, when the Encode In Motion patent was filed, the state of the art was to place an antenna near a box of tagged items, or a moving web of tags, and encode everything you could see. That worked ok for boxes, especially given big shielded tunnels. Most such systems halted the box inside the tunnel until encoding was complete. So for this discussion, that was more or less the same as stop-start encoding on a rewind system.

Continuous label encoding systems presented some different challenges. One of the worst is what we call "pileups." That happens when more than one chip enters the antenna field while an encoder is working with the last chip.

Imagine you have a process set up to encode UHF Gen2 RFID chips at around 10/sec. You figure a new chip will enter the antenna area about every 100 mS, and your reader takes about that long to find and encode a chip, so everything should be ok. But Gen2 has one key feature that makes the protocol work great for dock doors but not so great for encoding on press: the 20 mS holdoff. If a reader is talking to a chip, and misses any chip reply, the reader is required by the Gen2 standard to wait 20 milliseconds (mS) before retrying its command. Some readers have an option to cheat that, but most don't, and no reader can be Gen2 compliant if it doesn't observe this condition by default. So even in a process that is meant to encode EPCs in 100 mS, any little glitch makes the process longer in 20 mS increments. That's 20%.

So say your "well-tuned" encoder gets preoccupied with a chip that may be a little weak. It can easily hang on, trying to encode that chip, for 200 mS or more. That means, by the time the reader goes back to look for new chips, TWO new chips will be in the antenna field, not just one. This is a pileup. The reader does not know there are two chips there - it will pick one and encode it. By the time that's over, another new chip will be in the field, so you are still backed up. A practical system may have an antenna the size of 3 or 4 labels, so there is no time to "catch up." The most likely scenario is that one chip out of the next few will go through the encode station untouched. A downstream read station could catch and mark it, but this happens too often to be economical.

When the early work was being done on Encode In Motion, the official line from Impinj was that "Sequence doesn't matter. Tune the system correctly and it will all work ok." Since then, they have embraced sequencing, but still rely on proprietary extensions. GlueLogix invented standards based sequenced continuous encoding, and we hold the patent on it.

UHF Only

And of course, the systems from Impinj and Alien are UHF only, and probably will be for a while.