Blogs

RFID / Streepjescode-interoperabiliteit

bc-rfid

Dit artikel is iets technischer dan het meeste wat we hebben uitgebracht, maar we dachten dat het nuttig zou zijn om met anderen te delen.

Wanneer klanten bij ons EPC-GEN2 Type UHF RFID-tags bestellen, willen ze vaak een product dat zowel een door mensen leesbaar nummer als een barcode heeft. En in hun gedachten moet het elektronische nummer overeenkomen met de streepjescode en het afgedrukte nummer. In de meeste gevallen hoeven ze het EPC Tag Data Standard om ervoor te zorgen dat elk van hun UHF RFID-tags uniek is onder de miljarden tags over de hele wereld. Ze geven er gewoon om dat het nummer uniek is in hun systeem.

Hieronder ziet u een voorbeeld van een UHF RFID-tag die de verschillende technologieën laat zien die in een tag worden gebruikt - met overeenkomende nummers voor alle technologieën.

  1. UHF RFID (weergegeven in blauwe schaduw) - Snelle inventarisatiemogelijkheid, mogelijkheid om een ​​object te vinden
  2. Barcodes (1D en 2D) - Mogelijkheid om een ​​specifiek nummer te lezen waarnaar door een lezer wordt verwezen - dit is moeilijk te doen met een RFID-lezer, aangezien vaak meerdere tags tegelijk worden gelezen.
  3. Gedrukt tekstnummer - voor mensen om te kunnen lezen zonder apparatuur.
tag voorbeeld
Volledige 96 Bit / 12 Byte UHF RFID-gegevensweergave

In de meeste gevallen willen klanten echter niet zo'n lang nummer. Ze geven de voorkeur aan een kort en gemakkelijk te lezen nummer, zoals in de volgende afbeelding wordt weergegeven:

korte gegevensweergave
Korte gegevensweergave

Dus wat doen we in deze gevallen met het UHF RFID-tagnummer, dat altijd 96 bits is? Telaeris heeft een interne gegevensstandaard waarmee we een aantal verschillende UHF RFID-tagsstandaarden tegelijkertijd kunnen lezen, die zowel lange gegevenstypen als korte gegevenstypen ondersteunen.

  1. Als de gegevens stringgegevens zijn - zoals iets dat u op een toetsenbord zou kunnen typen - coderen we dit als een string en plaatsen deze vooraan de 12 bytes en vullen de laatste bytes (minimaal 2) met nulwaarden. Dit is onze voorkeurscodering en het is goed voor maximaal 10 tekens, wat de meeste van onze gebruiksscenario's dekt. Voor een grafiek met de toewijzing van tekenreekskarakters en hun hexadecimale representaties, klik hier.
  2. Veel van onze partners coderen de gegevens aan het einde van de 12 bytes. Als we aan het begin nulwaarden vinden (minimaal 2), gaan we ervan uit dat het dit type codering gebruikt en geven we de gegevens weer als hexadecimale gegevens.
  3. Als beide structuren falen, gebruiken we standaard de onbewerkte gegevens en geven deze weer als 23 hexadecimale tekens.

Dit wordt getoond door het voorbeeld hieronder:

Encoding Type 1: 
54 33 35 30 30 30 00 00 00 00 00 00 
'T' '3' '5' '0' '0' '0' <---- Nulwaarden --->
<------- Gegevens --------> <---- Nulwaarden --->
Encoding Type 2:
00 00 00 00 00 00 00 00 0A 12 34 56
<--------- Nulwaarden ---------><--- Gegevens ->

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

Kunnen er problemen zijn waarbij deze aannames elkaar overlappen? Ja, maar er zijn er maar weinig tussen. En naar onze ervaring zal het hebben van een korter om te lezen nummer uiteindelijk de eindklant een betere algehele gebruikerservaring bieden.

Door David Carta, CEO van Telaeris

Laat een reactie achter

*

E-mail Abonnement

Ontvang de laatste updates rechtstreeks in uw inbox