Blogs

Interopérabilité RFID / codes à barres

bc-rfid

Cet article est un peu plus technique que la plupart de ce que nous avons publié, mais nous avons pensé qu’il serait utile de le partager avec d’autres.

Lorsque les clients nous commandent des étiquettes RFID UHF de type EPC-GEN2, ils veulent souvent un produit qui possède également à la fois un numéro lisible par l'homme et un code-barres. Et dans leur esprit, le numéro électronique doit correspondre au code-barres et au numéro imprimé. Dans la plupart des cas, ils n'ont pas besoin de mettre en œuvre le Norme de données d'étiquette EPC pour garantir que chacune de leurs étiquettes RFID UHF est unique parmi les milliards d'étiquettes dans le monde. Ils se soucient simplement que le numéro soit unique dans leur système.

Vous trouverez ci-dessous un exemple d'étiquette RFID UHF qui montre les différentes technologies utilisées dans une étiquette - avec des numéros correspondants pour toutes les technologies.

  1. RFID UHF (ombrée en bleu) - Capacité d'inventaire rapide, possibilité de trouver un objet
  2. Codes à barres (1D et 2D) - Possibilité de lire un nombre spécifique pointé par un lecteur - c'est difficile à faire avec un lecteur RFID car plusieurs étiquettes sont souvent lues à la fois.
  3. Numéro de texte imprimé - pour que les personnes puissent lire sans aucun équipement.
exemple de tag
Représentation complète des données RFID UHF 96 Bit / 12 Byte

Cependant, dans la plupart des cas, les clients ne veulent pas d'un numéro aussi long. Ils préfèrent un numéro court et facile à lire, comme le montre l'image suivante:

courte représentation des données
Représentation courte des données

Alors, que faisons-nous dans ces cas avec le numéro de tag RFID UHF, qui est toujours 96 bits? Telaeris dispose d'une norme de données interne qui nous permet de lire simultanément un certain nombre de normes d'étiquettes RFID UHF différentes, prenant en charge à la fois les types de données longs et les types de données courts.

  1. Si les données sont des données de type chaîne - comme quelque chose que vous pouvez taper sur un clavier - nous l'encodons sous forme de chaîne et la plaçons au début des 12 octets et remplissons les derniers octets (minimum de 2) avec des valeurs nulles. Il s'agit de notre encodage préféré et il peut contenir jusqu'à 10 caractères, ce qui couvre la plupart de nos cas d'utilisation. Pour un graphique montrant le mappage des caractères de chaîne et leurs représentations hexadécimales, cliquer ici.
  2. Beaucoup de nos partenaires encodent les données à la fin des 12 octets. Si nous trouvons des valeurs nulles au début (minimum de 2), nous supposons qu'il utilise ce type de codage et afficher les données sous forme de données hexadécimales.
  3. Si ces deux structures échouent, nous utilisons par défaut les données brutes et les affichons sous forme de caractères de données hexadécimales 23.

Ceci est illustré par l'exemple ci-dessous:

Type de codage 1: 
54 33 35 30 30 30 00 00 00 00 00 00 
'T' '3' '5' '0' '0' '0' <---- Valeurs nulles --->
<------- Données --------> <---- Valeurs nulles --->
Type de codage 2:
00 00 00 00 00 00 00 00 0A 12 34 56
<--------- Valeurs nulles ---------><--- Données ->

Type de codage 3:
11 22 33 44 55 66 77 88 99 00 AA BB
<------------------- Données ------------------->

Peut-il y avoir des problèmes où ces hypothèses entraînent des chevauchements? Oui, mais ils sont rares. Et d'après notre expérience, avoir un nombre plus court à lire fournira en fin de compte au client final une meilleure expérience utilisateur globale.

Par David Carta, PDG de Telaeris

Laissez Un Commentaire

*

Email Subscription

Recevez les dernières mises à jour directement dans votre boîte de réception