¡NUEVO! XPressEntry HealthChek Workplace y detección de COVID-19. CLIC AQUÍ para obtener más información.

Blogs

Interoperabilidad RFID / Código de Barras

bc-rfid

Este artículo es un poco más técnico que la mayoría de lo que publicamos, pero pensamos que sería útil compartirlo con otros.

Cuando los clientes nos piden etiquetas RFID UHF tipo EPC-GEN2, a menudo quieren un producto que también tenga un número legible por humanos y un código de barras. Y en su mente, el número electrónico debe coincidir con el código de barras y el número impreso. En la mayoría de los casos, no necesitan implementar la Estándar de datos de etiqueta EPC para garantizar que cada una de sus etiquetas RFID UHF sea única entre los miles de millones de etiquetas en todo el mundo. Solo les importa que el número sea único en su sistema.

A continuación, se muestra un ejemplo de una etiqueta RFID UHF que muestra las diferentes tecnologías utilizadas en una etiqueta, con números coincidentes para todas las tecnologías.

  1. RFID UHF (se muestra en la sombra azul): capacidad de inventario rápido, capacidad de encontrar un objeto
  2. Códigos de barras (1D y 2D): capacidad para leer un número específico al que apunta un lector; esto es difícil de hacer con un lector RFID ya que a menudo se leen varias etiquetas a la vez.
  3. Número de texto impreso: para que las personas puedan leer sin ningún equipo.
ejemplo de etiqueta
Representación completa de datos 96 Bit / 12 Byte UHF RFID

Sin embargo, en la mayoría de los casos, los clientes no quieren un número tan largo. Prefieren un número corto y fácil de leer como se muestra en la siguiente imagen:

representación de datos cortos
Representación de datos cortos

Entonces, ¿qué hacemos en estos casos con el número de etiqueta RFID UHF, que siempre es de 96 bits? Telaeris tiene un estándar de datos interno que nos permite leer varios estándares de etiquetas UHF RFID diferentes simultáneamente, admitiendo tanto tipos de datos largos como tipos de datos cortos.

  1. Si los datos son datos de cadena, como algo que podría escribir en un teclado, lo codificamos como una cadena y lo colocamos al principio de los 12 bytes y llenamos los últimos bytes (mínimo de 2) con valores cero. Esta es nuestra codificación preferida y es buena para hasta 10 caracteres, lo que cubre la mayoría de nuestros casos de uso. Para obtener un gráfico que muestre el mapeo de caracteres de cadena y sus representaciones hexadecimales, haz clic aquí.
  2. Muchos de nuestros socios codifican los datos al final de los 12 bytes. Si encontramos valores cero al principio (mínimo de 2), asumimos que está usando este tipo de codificación y mostramos los datos como datos hexadecimales.
  3. Si estas dos estructuras fallan, los datos en bruto se muestran de forma predeterminada y se muestran como caracteres de datos hexadecimales 23.

Esto se muestra en el siguiente ejemplo:

Tipo de codificación 1: 
54 33 35 30 30 30 00 00 00 00 00 00 
'T' '3' '5' '0' '0' '0' <---- Valores cero --->
<---Declaración de privacidad  Datos --------> <---- Valores cero --->
Tipo de codificación 2:
00 00 00 00 00 00 00 00 0A 12 34 56
<--------- Valores cero ---------><--- Datos ->

Tipo de codificación 3:
11 22 33 44 55 66 77 88 99 00 AA BB
<------------------- Datos ------------------->

¿Puede haber problemas en los que estas suposiciones se superpongan? Sí, pero son pocos y distantes entre sí. Y en nuestra experiencia, tener un número más corto para leer proporcionará al cliente final una mejor experiencia general de usuario.

Por David Carta, CEO de Telaeris

Deja un comentario

*

Suscripción de e-mail

Reciba las últimas actualizaciones enviadas directamente a su bandeja de entrada