notre blog

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 nos clients nous commandent des étiquettes RFID de type UHF de type EPC-GEN2, ils souhaitent souvent un produit comportant à 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 la Norme de données d'étiquette EPC pour s'assurer que chacune de leurs étiquettes RFID UHF est unique parmi les milliards d'étiquettes à travers le monde. Ils se soucient simplement que le nombre est unique dans leur système.

Vous trouverez ci-dessous un exemple d'étiquette RFID UHF illustrant les différentes technologies utilisées dans une étiquette - avec les 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 numéro spécifique pointé par un lecteur. Cela 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 nombre 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 d’étiquette RFID UHF, qui correspond toujours aux bits 96? Telaeris a 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 les types de données longs et les types de données courts.

  1. Si les données sont des données de chaîne - telles que quelque chose que vous pouvez taper sur un clavier -, nous codons cela en tant que chaîne, nous le plaçons au début des octets 12 et nous remplissons les derniers octets (minimum de 2) avec des valeurs nulles. C'est notre encodage préféré et il convient aux caractères 10, 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, cliquez ici.
  2. Beaucoup de nos partenaires encodent les données à la fin des octets 12. Si nous trouvons des valeurs zéro au début (minimum de 2), nous supposons qu'il utilise ce type de codage et affichons 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 
'T' '3' '5' '0' '0' '0' <---- Zero Values ​​--->
<------- Données --------> <---- Zero Values ​​--->
Type de codage 2:
00 00 00 00 00 00 00 00A 0 12 34
<--------- Zero Values ​​---------><--- Données ->

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

Peut-il y avoir des problèmes où ces hypothèses causent un chevauchement? Oui, mais ils sont rares. Et, d’après notre expérience, disposer d’un nombre plus court en lecture offrira au client final une meilleure expérience utilisateur.

Par David Carta, PDG de Telaeris

Laisser un commentaire

*

Blog mises à jour

Newsletters


parler à un représentant

Contactez-Nous

Téléphone: 858-627-9700
Fax: 858-627-9702
-------------------------------
9123 Chesapeake Dr.
San Diego, CA 92123
-------------------------------
sales@telaeris.com