Implemente rápidamente un sistema de localización en tiempo real con precisión de 10 cm.

Colaboración de Editores de Digi-Key de América del Norte

Los sistemas de radiolocalización se han convertido en una característica omnipresente en casi todos los tipos de dispositivos móviles y aplicaciones relacionadas. Entre los enfoques de radiolocalización, los sistemas de localización en tiempo real (RTLS) basados ​en comunicaciones de RF de banda ultraancha (UWB) desempeñan un papel central para garantizar la información de localizaciones disponible cuando tecnologías más familiares como el GPS no pueden proporcionar cobertura.

Con la creciente demanda de RTLS más precisos, los desarrolladores se encuentran atrapados en la complejidad de los métodos de alta precisión, como la ubicación de dos vías o la diferencia de tiempo de llegada (TDOA).

Un módulo y software integrados de Decawave proporcionan a los desarrolladores una solución de RTLS más simple capaz de ofrecer resultados de localización más precisos con el mínimo esfuerzo.

Este artículo revisa las aplicaciones y algoritmos de los RTLS, que incluyen ubicación de dos vías y la TDOA, y analiza las compensaciones de implementación asociadas con los diferentes métodos de los RTLS. A continuación, el artículo presenta un transceptor UWB de Decawave, que hace hincapié en los requisitos específicos para el diseño con este. El artículo concluye con una discusión sobre la arquitectura del software de Decawave y el desarrollo del firmware correspondiente, que muestra técnicas específicas para desarrollar aplicaciones de usuario en la plataforma de Decawave.

El papel de los sistemas RTLS

Los RTLS de precisión se han convertido en un método eficaz para determinar la ubicación o el seguimiento de personas o activos móviles en complejos de oficinas, almacenes, plantas de fabricación y líneas de ensamblaje. Bajo este enfoque, un objeto móvil (etiqueta) intercambia información con dispositivos de posición fija (anclas) mediante formatos estándar y tecnologías UWB especificadas en IEEE 802.15.4-2011 para redes inalámbricas de área personal de baja tasa (LR-WPAN). Al determinar la distancia entre la etiqueta y varias anclas, las aplicaciones pueden determinar la posición relativa de la etiqueta con respecto a esas anclas conocidas, y por lo tanto, la posición absoluta de la etiqueta.

Métodos RTLS

Las aplicaciones RTLS utilizan una variedad de técnicas para determinar la distancia. En el enfoque más simple, la aplicación o etiqueta puede usar el parámetro indicador de intensidad de señal recibida (RSSI) disponible con la mayoría de los transceptores para evaluar la ubicación de la etiqueta con respecto a las anclas de transmisión. Debido a los muchos factores que pueden afectar el presupuesto del enlace, este enfoque puede proporcionar, en el mejor de los casos, solo una estimación amplia de la posición. Por el contrario, muchas aplicaciones emergentes basadas en RTLS requieren la determinación de la ubicación absoluta dentro de unos pocos centímetros.

Los RTLS de alta precisión utilizan métodos de tiempo de vuelo que son en gran medida inmunes a los cambios significativos en la variación de la intensidad de la señal de RF. Bajo este enfoque, la ubicación de una etiqueta se puede determinar al medir el tiempo requerido para que una señal de RF pase desde la etiqueta a varias anclas. Mediante el uso del conocido retardo de propagación de las señales de RF a través del aire, las aplicaciones de RTLS pueden traducir el tiempo de vuelo en distancia.

Por ejemplo, si el tiempo de vuelo entre una etiqueta y cada una de las tres anclas resulta ser exactamente el mismo. Esta situación solo puede ocurrir razonablemente si la etiqueta se encuentra equidistante de esas anclas. Como la aplicación conoce la ubicación exacta de cada ancla, puede determinar la ubicación absoluta de la etiqueta.

Sin embargo, para medir el tiempo de propagación desde el transmisor de etiquetas, el receptor de ancla necesita usar la misma base de tiempo que la etiqueta para evaluar correctamente la información de tiempo incrustada en el mensaje de la etiqueta. Si la base de tiempo de un ancla se retrasa o conduce la base de tiempo de una etiqueta, la distancia calculada será, respectivamente, más corta o más larga que la distancia real.

Un método de RTLS adopta un enfoque sencillo para resolver este problema al sincronizar el transmisor de etiquetas y los receptores de ancla, lo que garantiza que cada ancla reciba el mensaje con la misma base de tiempo que la etiqueta. La implementación de la sincronización de tiempo puede ser desafiante en el mejor de los casos, y simplemente poco práctica en aplicaciones de RTLS donde las etiquetas inalámbricas se están moviendo.

Otro método, la TDOA, sincroniza solo las anclas, lo que elimina los problemas asociados con la sincronización de etiquetas móviles. Para determinar la localización, la aplicación de RTLS utiliza las diferencias entre los tiempos de llegada de una señal de etiqueta medida a través de múltiples anclas. Por ejemplo, considere el ejemplo anterior de tres anclas (A1, A2 y A3) dispuestas de forma equidistante alrededor de una etiqueta. Después del movimiento de la etiqueta, si se encuentra que la TDOA para cada ancla es 0, 1 nanosegundo (ns), 0, respectivamente, significa que la etiqueta se ha movido en una línea directa alejándose del ancla A2 durante aproximadamente 30 centímetros (estimando la propagación de RF a la velocidad de la luz). El requisito de la TDOA para la sincronización de anclas es un problema significativamente más sencillo que intentar sincronizar anclas y etiquetas. Aun así, la precisión de este enfoque depende de una sincronización muy precisa. Incluso una diferencia de un nanosegundo en la sincronización puede traducirse en una diferencia de centímetros en la medición de la ubicación.

Ubicación de dos vías

Los métodos de RTLS de dos vías eliminan por completo la necesidad de una sincronización de tiempo precisa, pero presentan un requisito para la capacidad de transmisión en la etiqueta. Este enfoque evita la incertidumbre de diferentes bases de tiempo al permitir que la etiqueta y las anclas intercambien información de temporización entre ellas. En lugar de sincronizar sus bases de tiempo, la etiqueta y las anclas utilizan un breve protocolo de mensajería de dos vías que permite una determinación precisa del tiempo de vuelo y un cálculo preciso de la ubicación de la etiqueta.

Bajo este enfoque, una etiqueta transmite una breve señal de identificación para anunciarse a las anclas circundantes. Cada ancla que recibe el mensaje de identificación inicial de la etiqueta activa, después, la etiqueta en un corto intercambio de dos vías de datos, utilizado para determinar el tiempo de vuelo a pesar de las diferencias en las bases de tiempo a través de las anclas y la propia etiqueta.

En su protocolo de RTLS de dos vías, Decawave define este proceso en términos de fase de descubrimiento y fase de rango (Figura 1). Durante el descubrimiento, una etiqueta transmite periódicamente una breve señal de identificación, o parpadeo, y espera una respuesta de un ancla. Después de que la etiqueta y el ancla se reconocen entre sí, la etiqueta y el ancla conectadas utilizan un breve intercambio de mensajería de dos vías que contiene la información necesaria para calcular el alcance.

Diagrama del protocolo de medición de dos vías de Decawave

Figura 1: En el protocolo de dos vías de Decawave, las etiquetas y las anclas intercambian una serie de mensajes para completar el descubrimiento y proporcionar información de rango. (Fuente de la imagen: Decawave)

Para los desarrolladores, los desafíos relacionados con la implementación de estos protocolos de intercambio de mensajes coreografiados con precisión y sus subsistemas subyacentes de radio UWB pueden ser desalentadores. Sin embargo, al utilizar el módulo DWM1001 de Decawave, los desarrolladores pueden agregar rápidamente capacidades de RTLS de precisión a sus aplicaciones con un pequeño esfuerzo adicional.

Módulo de RTLS integrado

El módulo DWM1001 de Decawave proporciona una implementación completa de RTLS, al integrar el transceptor UWB DW1000 de Decawave con una MCU inalámbrica NRF52832 de Nordic Semiconductor y un sensor de movimiento de 3 ejes LIS2DH12 de STMicroelectronics. Mientras que el DW1000 proporciona señalización de RF compatible con IEEE 802.15.4-2011, la MCU NRF52832 ejecuta su firmware incorporado para aplicaciones de RTLS. El sensor LIS2DH12 juega un papel importante en la administración de energía.

En cualquier aplicación de RF sofisticada, el diseño de RF generalmente presenta algunos de los mayores desafíos, particularmente en aplicaciones móviles que requieren un consumo mínimo de energía y espacio. El módulo DWM1001 soluciona estos problemas al aprovecha al máximo el diseño de RF integrado que proporciona el transceptor DW1000 (Figura 2).

Diagrama del transceptor DW1000 de Decawave

Figura 2: El transceptor DW1000 de Decawave integra rutas de señal de radio y lógica de control digital para proporcionar un sistema completo compatible con IEEE802.15.4-2011. (Fuente de la imagen: Decawave)

El DW1000 proporciona un transceptor UWB completo que integra un Front End de RF capaz de admitir seis canales IEEE802.15.4-2011 de 3.5 GHz a 6.5 GHz a velocidades de bits estándar de 110 Kbits/s, 850 Kbits/s y 6.81 Mbits/s. El subsistema de control digital integrado del dispositivo gestiona el transceptor, y admite sistemas de RTD de TDOA y de dos vías con una precisión de ubicación de 10 cm. Una memoria programable de un solo uso integrada (OTP) permite a los desarrolladores almacenar los datos utilizados para la calibración y corrección de errores, mientras que la memoria siempre activa (AON) configurable del dispositivo conserva los datos de configuración durante los estados de baja potencia del dispositivo que se describen a continuación.

En funcionamiento, el dispositivo transmite y recibe armazones estándar IEEE802.15.4-2011 que comprenden un encabezado de sincronización (SHR), un encabezado de capa física (PHR) y hasta 127 bytes de datos que componen la Unidad de datos de servicio PHY (PSDU) general. Además del armazón estándar, el dispositivo también admite un formato de armazón patentado que proporciona hasta 1023 bytes de datos para aplicaciones que necesitan enviar cargas útiles de datos más grandes y no requieren conformidad con IEEE802.15.4-2011.

Para aplicaciones compatibles, los desarrolladores pueden elegir entre una variedad de modos de operación con combinaciones preestablecidas de velocidad de datos, tamaño de carga útil y longitud de preámbulo preconfigurados para cumplir con casos de uso específicos para operaciones de dos vías y TDOA. Por ejemplo, los modos destinados a aplicaciones de largo alcance combinan baja velocidad de datos con largos preámbulos que facilitan el descubrimiento y la variación en medio de interferencia o señales débiles. Por el contrario, los modos con altas velocidades de datos y preámbulos cortos admiten aplicaciones de corto alcance. Otros modos admiten estas características de corto y largo alcance con diferentes tamaños de carga útil.

Minimización de potencia

En la práctica, los desarrolladores optarán por modos de funcionamiento con el tamaño de armazón más corto posible para minimizar el consumo general de energía y devolver el dispositivo rápidamente a un estado de baja potencia. El DW1000 ofrece varios modos de baja potencia. Durante períodos inactivos, se puede colocar el dispositivo en modo inactivo, que consume solo 19 miliamperios (mA). Para períodos de inactividad prolongada, los desarrolladores pueden colocar el dispositivo en un modo de reposo de baja potencia que consume solo 1 microamperio (μA) aproximadamente y un modo de reposo profundo que consume 100 nanoamperios (nA) como máximo (50 nA por lo general).

Sin embargo, al igual que con cualquier diseño de RF, el consumo de energía aumenta significativamente durante la operación del transceptor. Para transmitir un armazón compatible con IEEE802.15.4-2011, por ejemplo, los componentes de cuadro más largos, como la cabecera de sincronización y el paquete de datos, son responsables de la mayoría del consumo de energía (Figura 3).

Diagrama de transmisión de un armazón RTLS con el DW1000 de Decawave

Figura 3: La transmisión de un armazón RTLS con el DW1000 de Decawave da como resultado un aumento significativo en el consumo de energía para cada componente del armazón, lo que lleva a los desarrolladores a buscar modos de funcionamiento con la cabecera de sincronización y la carga útil de datos más cortos. (Fuente de la imagen: Decawave)

Un desafío adicional para los diseños de potencia limitada se debe al consumo de potencia aún mayor asociado con las operaciones del receptor (Figura 4). Los desarrolladores pueden programar el DW1000 para que regrese a uno de los estados de baja potencia después de transmitir o recibir. Aun así, la naturaleza del protocolo y el armazón estándar dejan pocas opciones para reducir la potencia durante las operaciones de cuadro.

El diagrama de recepción de un armazón impone requisitos de potencia aún mayores que la transmisión

Figura 4: La recepción de un armazón impone requisitos de potencia aún mayores que la transmisión, en gran parte debido a la duración extendida de la fase de búsqueda del preámbulo. (Fuente de la imagen: Decawave)

El DW1000 proporciona una característica única de ahorro de energía para reducir la potencia durante la fase RX del preámbulo. En lugar de mantener el receptor en funcionamiento, los desarrolladores pueden programar el dispositivo con un modo especial de detección de preámbulos. En este, el DW1000 enciende periódicamente el receptor, busca el preámbulo y vuelve al estado inactivo si no se encuentra el preámbulo (Figura 5).

Diagrama de la función de detección del DW1000 de Decawave que alterna entre el modo inactivo y el modo de receptor activo

Figura 5: Los desarrolladores pueden reducir el consumo de energía asociado con las operaciones del receptor mediante la función de detección del DW1000, que alterna entre el modo inactivo y el modo de receptor activo. (Fuente de la imagen: Decawave)

Las características como la detección de preámbulo son particularmente importantes para las etiquetas alimentadas por batería. Los desarrolladores pueden aplicar una variedad de métodos para reducir la potencia durante las operaciones de RTLS. Un enfoque aprovecha los distintos retardos conocidos que existen en el protocolo de rango de dos vías que se muestra en la Figura 1.

Por ejemplo, la respuesta de init de alcance del ancla al parpadeo de una etiqueta durante la fase de descubrimiento se producirá después de un cierto retardo. Los desarrolladores pueden estimar este retardo en función de la velocidad de armazones y otros parámetros, medir su valor real en sus diseños de anclaje o incluso crear un tiempo de retardo de respuesta específico en sus diseños de anclaje. Entonces, el desarrollador puede mantener el receptor de la etiqueta apagado durante el tiempo de retardo esperado, encenderlo para buscar una respuesta y apagarlo nuevamente si la respuesta del init de alcance no llega dentro de un período razonable.

Del mismo modo, los desarrolladores pueden tomar medidas para limitar el tiempo que la radio necesita activarse durante el proceso de determinación del alcance. Por ejemplo, los desarrolladores pueden precargar el dispositivo con todos los datos requeridos y usar el acceso directo a la memoria para acelerar la transferencia de datos entre el DW1000 y la memoria del host.

Si bien estas optimizaciones de bajo nivel pueden proporcionar un ahorro de energía progresivo, los desarrolladores pueden lograr resultados aún mejores al cambiar dinámicamente la velocidad de actualización de la ubicación. Después de que una etiqueta ha dejado de moverse, no hay ninguna ventaja en continuar con las fases de descubrimiento de consumo de energía y alcance. La etiqueta puede entrar de manera segura en un estado de reposo de baja potencia y despertarse para reanudar las actualizaciones a la velocidad nominal cuando comienza a moverse.

El módulo DWM1001 admite el ajuste de frecuencia dinámico con su sensor de movimiento LIS2DH12 integrado y soporte para dos modos operativos relacionados con el movimiento: de baja potencia y receptivo. Los desarrolladores pueden configurar el módulo para operar el transceptor del DW1000 en modo de baja potencia cuando el LIS2DH12 detecta que el módulo está estacionario. Cuando el LIS2DH12 detecta movimiento, el transceptor puede regresar al modo receptor, donde el transceptor del DW1000 reanuda su velocidad de actualización normal.

Los desarrolladores pueden optimizar aún más sus aplicaciones RTLS para controlar la velocidad de actualización en función de la velocidad y la aceleración del objeto. Por ejemplo, una etiqueta de movimiento lento podría requerir solo actualizaciones poco frecuentes para mantener la precisión posicional requerida. A medida que la etiqueta se acelera, la aplicación podría responder al aumentar la velocidad de actualización de la ubicación.

Desarrollo de RTLS

Más allá de su capacidad para soportar características de RTLS, como las velocidades de actualización dinámicas, el módulo ofrece una ventaja fundamental para el desarrollo de RTLS. Por ejemplo, el transceptor del DW1000 impone una serie de requisitos de interfaz específicos para el desacoplamiento de fuentes de alimentación, el emparejamiento de la red de antena, el oscilador de referencia y otros (Figura 6). De manera similar, la MCU inalámbrica NRF52832 y el sensor de movimiento LIS2DH12 presentan sus propias demandas de diseño de interfaz.

Diagrama del transceptor del DW1000 de Decawave (haga clic para agrandar)

Figura 6: El transceptor DW1000 de Decaware impone estrictos requisitos de interfaz para garantizar energía confiable, RF y señales de tiempo. (Fuente de la imagen: Decawave)

Aunque los dispositivos avanzados como estos tienen un diseño muy simplificado, los desarrolladores, sin embargo, pueden enfrentar un desafío significativo al optimizar su integración en diseños que requieren un rendimiento máximo con la mínima potencia. El módulo de DWM1001 reduce los requisitos de integración a unas pocas conexiones para las interfaces de alimentación, a tierra y digital (Figura 7).

Diagrama del módulo DWM1001 de Decawave que simplifica el desarrollo de RTLS

Figura 7: El módulo de DWM1001 de Decawave simplifica el desarrollo de RTLS al proporcionar un diseño totalmente integrado que une el transceptor DW1000 con una MCU inalámbrica y un sensor de movimiento. (Fuente de la imagen: Decawave)

Modelo de software

Del mismo modo, el módulo simplifica enormemente el desarrollo y la integración del software con su firmware precargado para la biblioteca de posicionamiento y pila de protocolo de red (PANS) de Decawave. Construida sobre la pila de Bluetooth de bajo consumo (BLE) en chip de la MCU, la biblioteca PANS incluye el sistema operativo de código abierto eCos en tiempo real (RTOS), una capa de red y capas de aplicaciones que admiten servicios BLE, servicios de administración RTLS y el motor de ubicación de dos vías (TWR) (Figura 8).

Imagen de la biblioteca de posicionamiento y pila de protocolo de red (PANS) de Decawave

Figura 8: La biblioteca de posicionamiento y pila de protocolo de red (PANS) de Decawave ofrece una plataforma enriquecida para aplicaciones RTLS con su combinación de una pila Bluetooth, RTOS, capa de red y capa de servicio de aplicaciones. (Fuente de la imagen: Decawave)

Al construir aplicaciones de firmware para que se ejecuten en la MCU del DWM1001, los desarrolladores acceden a la biblioteca PANS a través de una interfaz de programación de aplicaciones (API) que proporciona los puntos de entrada apropiados a cada módulo de PANS para configurar y controlar el módulo. La API de PANS comprende una serie de conjuntos de API para módulos separados, incluido el código C del desarrollador, bibliotecas de interfaz en serie (CPI y UART) y la biblioteca BLE (Figura 9).

Las aplicaciones trabajan directamente con estas cuatro API de nivel superior, que a su vez acceden a la biblioteca PANS a través de un analizador genérico de la API que convierte esas llamadas en llamadas de API genéricas hacia la biblioteca PANS. En esta función, la capa genérica proporciona una interfaz común a la biblioteca PANS.

Imagen de Decawave que expone la biblioteca PANS a través de API extensas

Figura 9: Decawave expone la biblioteca PANS a través de API extensas, cada una de las cuales proporciona un acceso simple al modelo de ejecución de hilos de ejecución subyacente. (Fuente de la imagen: Decawave)

Arquitectura roscada

Dentro de esta arquitectura, el software de firmware del DWM1001 utiliza un modelo de hilos de ejecución, que proporciona esencialmente un hilo de ejecución independiente para cada módulo y biblioteca de la pila. Los hilos de ejecución de cada uno de los cuatro módulos de la parte superior de la pila envían solicitudes para analizar el hilo del analizador genérico de la API, que valida cada solicitud y llama a la biblioteca PANS para generar una respuesta adecuada. El hilo genérico de la API, a su vez, usa una función de retrollamada proporcionada en la llamada de origen para enviar el resultado al módulo que llama de la parte superior de la pila.

A pesar de la aparente complejidad de este sistema multicapa, la visión del desarrollador del modelo de programación es relativamente simple. El uso de llamadas de la API con devoluciones de llamadas a hilos de ejecución independientes ayuda a optimizar la utilización de los recursos y el rendimiento general de la aplicación.

Al mismo tiempo, la complejidad subyacente queda enmascarada por una serie de API que traducen llamadas orientadas a la aplicaciones de mayor nivel a las operaciones de hilos de ejecución optimizadas específicas que interactúan con el hardware del DWM1001. El modelo de programación del DWM1001 simplifica aún más la interacción del desarrollador con este sistema. En lugar de interactuar con múltiples hilos de ejecución y API, los desarrolladores usan un hilo de ejecución de aplicación de usuario dedicado integrado en el sistema.

Como se ilustra en el Listado 1, los desarrolladores invocan al hilo de ejecución de la aplicación del usuario con una simple llamada de API (dwm_thread_create), que registra la función de hilo de ejecución de la aplicación del usuario (app_thread_entry).

Copiar

/* Crear hilo de ejecución */

rv = dwm_thread_create(THREAD_APP_PRIO, app_thread_entry, (void*)NULL, "app", THREAD_APP_STACK_SIZE, &hndl);

APP_ERR_CHECK(rv);

 

/* Iniciar hilo de ejecución */

dwm_thread_resume(hndl);

Listado 1: Con el modelo de hilos de ejecución de Decawave, los desarrolladores registran e inician su hilo de ejecución de aplicaciones de usuario con un simple par de llamadas a la API. (Fuente código: Decawave)

Decawave proporciona un código de muestra para un hilo de ejecución de aplicación de usuario y retrollamada. El código de muestra viene incluido en una imagen de máquina virtual para Oracle Virtual Box, que incluye una cadena de herramientas completa, bibliotecas y la aplicación de muestra simple. Diseñado para funcionar con el tablero de desarrollo DWM1001-DEV de Decaware conectado a una PC con Windows, el paquete de software ofrece un marco para la creación de software de aplicación RTLS personalizado.

Incluido en el paquete de software, el código de muestra enseña los patrones de diseño clave para la función de hilos de ejecución del usuario (Listado 2). En este ejemplo, la función de hilos de ejecución del usuario (app_thread_entry) establece parámetros de configuración específicos de la aplicación, como la velocidad de actualización, y registra su retrollamada mediante la función de API dwm_evt_cb_register con el nombre de su función de retrollamada (on_dwm_evt). Después de registrar la retrollamada, el hilo de ejecución de muestra ingresa en su bucle principal; en este caso, una serie de llamadas a una función de retardo utilizada para reducir la utilización de recursos.

Copiar

void app_thread_entry(uint32_t data)

{

.

.

.

/* Configuración de velocidad de actualización de 1 segundo, configuración de velocidad de actualización estacionaria de 5 segundos */

APP_ERR_CHECK(dwm_upd_rate_set(10, 50));

 

/* Registrar retrollamada de evento */

dwm_evt_cb_register(on_dwm_evt, 0);

 

.

.

.

 

while (1) {

/* Bucle de hilos de ejecución */

dwm_thread_delay(100);

}

}

Listado 2: En este fragmento del paquete de desarrollo de firmware de Decawave, el código de muestra ilustra los patrones básicos de diseño para registrar la retrollamada y ejecutar el bucle principal en la rutina de hilos de ejecución de la aplicación del usuario. (Fuente código: Decawave)

La función de retrollamada de muestra (on_dwm_evt) presenta un controlador de eventos básico al que se invoca cuando se produce un evento (Listado 3). En este ejemplo de código, el único evento válido es la disponibilidad de nueva información de posición (DWM_EVT_NEW_LOC_DATA). Dentro del controlador para ese evento, el código muestra el conjunto simple de llamadas necesarias para recuperar los datos de ubicación generados por las anclas disponibles. Después de completar sus tareas de procesamiento de eventos, la retrollamada simplemente entra en reposo.

Copiar

/**

* Retrollamada del evento

*

* @param[in] p_evt  Puntero para la estructura del evento

* @param[in] p_data Puntero para los datos de usuario

*/

void on_dwm_evt(dwm_evt_t *p_evt, void *p_data)

{

int i;

 

switch (p_evt->header.id) {

/* Nuevos datos de ubicación */

case DWM_EVT_NEW_LOC_DATA:

/* Procesar los datos */

 

printf("\nT:%lu ", dwm_systime_us_get());

if (p_evt->data.loc.p_pos == 0) {

/* El motor de ubicación está desactivado */

} else {

printf("POS:[%ld,%ld,%ld,%u] ", p_evt->data.loc.p_pos->x,

p_evt->data.loc.p_pos->y, p_evt->data.loc.p_pos->z,

p_evt->data.loc.p_pos->qf);

}

 

para (i = 0; i < p_evt->data.loc.anchors.dist.cnt; ++i) {

printf("DIST%d:", i);

 

printf("0x%04X", (unsigned int)(p_evt->data.loc.anchors.dist.addr[i] & 0xffff));

if (i < p_evt->data.loc.anchors.an_pos.cnt) {

printf("[%ld,%ld,%ld]",

p_evt->data.loc.anchors.an_pos.pos[i].x,

p_evt->data.loc.anchors.an_pos.pos[i].y,

p_evt->data.loc.anchors.an_pos.pos[i].z);

}

 

printf("=[%lu,%u] ", p_evt->data.loc.anchors.dist.dist[i],

p_evt->data.loc.anchors.dist.qf[i]);

}

printf("\n");

break;

 

default:

break;

}

 

/* Indicar que la aplicación ha terminado con las tareas y puede ahora */

dwm_sleep ();

}

Listado 3: Este fragmento de la aplicación de muestra Decawave muestra una retrollamada que proporciona un controlador de eventos básico para acceder a nuevos datos de ubicación. (Fuente código: Decawave)

En una aplicación RTLS completa para el Internet de las cosas (IoT), por ejemplo, las etiquetas y las anclas se comunicarían a través de los anclajes de enrutamiento vinculados a un sistema de puerta de enlace conectado a Internet. Decawave está preparando una segunda versión de su paquete de firmware que incluirá soporte para puertas de enlace a través de un paquete de software basado en Linux que utiliza protocolos de mensajería de IoT familiares que incluyen HTTP, WebSockets, MQTT y AMQP.

Conclusión

El RTLS juega un papel cada vez más importante en una amplia gama de aplicaciones. Aunque los métodos de RTLS se basan en principios relativamente simples, la implementación de estos métodos requiere diseño de RF/analógico, diseño del sistema y desarrollo de software sofisticados para garantizar la máxima precisión con un consumo de energía mínimo.

El módulo DWM1001 de Decaware proporciona un sistema RTLS completo que combina el transceptor de UWB de DW1000 integrado de Decawave con una MCU inalámbrica y un sensor de movimiento. Mediante este módulo y el paquete de software que lo acompaña, los desarrolladores pueden implementar rápidamente sistemas RTLS alimentados por batería de alta precisión.

Descargo de responsabilidad: Las opiniones, creencias y puntos de vista expresados por los autores o participantes del foro de este sitio web no reflejan necesariamente las opiniones, las creencias y los puntos de vista de Digi-Key Electronics o de las políticas oficiales de Digi-Key Electronics.

Información sobre la editorial

Editores de Digi-Key de América del Norte