This article is a little more technical than most of what we put out, but we thought it would be useful to share with others.

When customers order EPC-GEN2 Type UHF RFID tags from us, they often want a product that also has both a human readable number as well as a barcode. And in their mind the electronic number should match the barcode and printed number.  In most cases, they do not need to implement the EPC Tag Data Standard to ensure each of their UHF RFID tags are unique among the billions of tags around the world.  They just care that the number is unique in their system.

Below is an example of an UHF RFID tag that shows the different technologies used in a tag – with matching numbers for all technologies.

1. UHF RFID (shown in blue shadow) – Fast inventory capability, ability to find an object
2. Barcodes (1D and 2D) – Ability to read a specific number that is being pointed at by a reader – this is difficult to do with an RFID reader as multiple tags are often read at once.
3. Printed text number – for people to be able to read without any equipment.

Full 96 Bit / 12 Byte UHF RFID Data Representation

However, in most cases, customers don’t want such a long number.  They prefer a short and easy to read number as is shown in the next image:

Short Data Representation

So what do we do in these cases with the UHF RFID tag number, which is always 96 bits?  Telaeris has an internal data standard that allows us to read a number of different UHF RFID tags standards simultaneously, supporting both long data types and short data types.

1. If the data is string data – such as something you could type on a keyboard – we encode this as a string and put it at the front of the 12 bytes and fill the last bytes (minimum of 2) with zero values.  This is our preferred encoding and it is good for up to 10 characters which covers most of our use cases. For a chart showing the mapping from string characters and their hex representations, click here.
2. Many of our partners encode the data at the end of the 12 bytes.  If we find zero values at the start (minimum of 2), we assume it is using this type of encoding and display the data as hex data.
3. If both of these structures fail, we default to the raw data and display it as 23 hex data characters.

This is shown by example below:

Encoding Type 1: 
54  33  35  30  30  30  00  00  00  00  00  00 
'T' '3' '5' '0' '0' '0' <---- Zero Values --->
<------- Data --------> <---- Zero Values --->

Encoding Type 2:
00  00  00  00  00  00  00  00  0A  12  34  56
<--------- Zero Values ---------><--- Data -->

Encoding Type 3:
11  22  33  44  55  66  77  88  99  00  AA  BB
<------------------- Data ------------------->

Can there be problems where these assumptions cause overlap?  Yes, but they are few and far between. And in our experience, having a shorter to read number will ultimately provide the end customer with a better overall user experience.