DWM1001 System Overview and Performance
DWM1001 System Overview and Performance
DWM1001 System Overview and Performance
Versión 2.1
TABLA DE CONTENIDO
7.1 CONTROL DE GESTIÓN DE ENERGÍA DE LOS PRINCIPALES COMPONENTES DEL SISTEMA .................................. ..........28
7.2 FUENTES DE DESPERTADOR ............................................. .................................................... ......................29
7.3 TARIFAS DE ACTUALIZACIÓN DE DOS UBICACIONES .................................. .................................................... .......29
LISTA DE TABLAS
LISTA DE FIGURAS
Descargo de responsabilidad
Decawave se reserva el derecho de cambiar las especificaciones del producto sin previo aviso. En la medida de lo posible, los
cambios en la funcionalidad y las especificaciones se publicarán en hojas de erratas específicas del producto o en nuevas versiones
de este documento. Se recomienda a los clientes que consulten con Decawave las actualizaciones más recientes de este producto.
Nota: A los efectos de este documento, "DWM1001" también puede referirse a "DWM1001C". La única diferencia entre
ambos módulos es que DWM1001C está certificado y su memoria OTP está calibrada para cumplir con las normas FCC/ETSI.
Los productos Decawave no están autorizados para su uso en aplicaciones críticas para la seguridad (como soporte vital)
donde se esperaría razonablemente que una falla del producto Decawave causara lesiones personales graves o la muerte.
Los clientes de Decawave que usan o venden productos Decawave de esa manera lo hacen bajo su propio riesgo y aceptan
indemnizar completamente a Decawave y sus representantes por cualquier daño que surja del uso de productos Decawave en
tales aplicaciones críticas para la seguridad.
¡Precaución! Dispositivo sensible a ESD. Se debe tener precaución al manipular el dispositivo para evitar daños
permanentes.
DESCARGO DE RESPONSABILIDAD
(1) Este descargo de responsabilidad se aplica al software proporcionado por Decawave Ltd. ("Decawave") en apoyo
de su producto de módulo DWM1001 ("Módulo") todo como se establece en la cláusula 3 del presente ("Software
Decawave").
(3) El software Decawave consta de los siguientes componentes (a) a (d) inclusive:
(a) El Decawave Positioning and Networking Stack ("PANS"), disponible como una biblioteca acompañada de
un código fuente que permite un nivel de personalización del usuario.
El software PANS está preinstalado y se ejecuta en el módulo tal como se suministra, y permite
"etiquetas" móviles, "anclas" fijas y "puertas de enlace" que, en conjunto, ofrecen el sistema de ubicación
en tiempo real de alcance bidireccional DWM1001 ("DRTLS")
La red.
(b) Decawave DRTLS Manager, que es una aplicación de Android™ para la configuración de nodos DRTLS
(nodos basados en el Módulo) a través de Bluetooth™.
(c) La aplicación Decawave DRTLS Gateway , que proporciona una función de puerta de enlace (en una
Raspberry Pi ®) que enruta la ubicación DRTLS y el tráfico de datos del sensor a una red basada en IP
(p. ej., LAN), y consta de los siguientes componentes:
(d) Ejemplos de funciones de API de host, también diseñadas para ejecutarse en una Raspberry Pi, que
muestran cómo controlar el módulo desde un microprocesador de host externo.
(4) Decawave Software utiliza los siguientes componentes de terceros y están incorporados en el firmware o incluidos en el
paquete de software, según sea el caso: -
(a) El software PANS incorpora Nordic SoftDevice S132-SD-v3 versión 3.0.0 (producción) que se incluye en el
Firmware y también se incluye en el Paquete de software;
(b) El software PANS utiliza eCos RTOS que se incluye en el paquete de software. eCos RTOS se proporciona
bajo los términos de una licencia de código abierto que se puede encontrar en: http://ecos.sourceware.org/
license-overview.html;
(c) El software PANS utiliza una función CRC-32 de código abierto de FreeBSD que se incluye en el paquete de
software. Esta función CRC-32 se proporciona bajo los términos de la licencia BSD que se puede
encontrar en:
https://github.com/freebsd/freebsd/blob/386ddae58459341ec56760470780581
4a2128a57/DERECHOS DE AUTOR;
(d) La aplicación Decawave DRTLS Manager utiliza software de código abierto que se proporciona
como código fuente en el paquete de software. Este software de fuente abierta se
proporciona bajo los términos de la Licencia Apache v2.0 que se puede encontrar en http://
www.apache.org/licenses/LICENSE-2.0;
(e) La aplicación Decawave DRTLS Gateway utiliza los siguientes componentes de terceros: -
(ii) La biblioteca de JavaScript three.js, cuya versión descargable está disponible aquí
https://threejs.org/, se proporciona bajo los términos de la licencia MIT que se
puede encontrar en https://opensource.org/licenses /MIT.
Los elementos (a), (b), (c), (d) y (e) en esta sección 4 se denominan colectivamente como el
"Software de terceros".
(5) El software Decawave incorpora el código fuente licenciado a Decawave por Leaps sro, un proveedor
de Decawave, que está incluido en el firmware y el paquete de software en formato binario y/o
código fuente, según sea el caso, según los términos de una licencia. acuerdo celebrado entre
Decawave y Leaps sro
(6) Por el presente, Decawave le otorga una licencia mundial gratuita, no exclusiva e intransferible sin
derecho a sublicenciar para diseñar, fabricar, hacer fabricar, comercializar, vender, vender o
disponer de otro modo de productos que incorporen el software Decawave, para modificar el
Software Decawave o incorporar el Software Decawave en otro software y para diseñar, fabricar,
hacer fabricar, comercializar, vender, vender o disponer de cualquier otro modo de productos que
incorporen dicho software modificado o incorporado SIEMPRE QUE el uso por su parte del
Software de Terceros tal como se suministró por Decawave está sujeto a los términos y condiciones
de los respectivos acuerdos de licencia como se establece en la cláusula 4 del presente Y
SIEMPRE QUE el software Decawave se use solo en sistemas y productos basados en productos
semiconductores Decawave. NO SE OTORGA NINGUNA OTRA LICENCIA, EXPRESA O
IMPLÍCITA, POR ESTOPPEL O DE CUALQUIER OTRO DERECHO DE PROPIEDAD
INTELECTUAL DE DECAWAVE, NI NINGUNA LICENCIA A CUALQUIER TECNOLOGÍA DE
TERCEROS O DERECHO DE PROPIEDAD INTELECTUAL, SE OTORGA EN EL PRESENTE
DOCUMENTO, incluidos, entre otros, cualquier derecho de patente, derechos de autor, trabajo de
máscara derecho u otro derecho de propiedad intelectual relacionado con cualquier combinación,
máquina o proceso en el que se utilicen los productos semiconductores Decawave o el software Decawave.
(7) La descarga, la aceptación de la entrega o el uso del software Decawave indica su acuerdo con los
términos de (i) la licencia concedida en la cláusula 6 del presente, (ii) los términos de este Aviso
legal y (iii) los términos adjuntos al Software de terceros . Si no está de acuerdo con todos estos
términos, no descargue, acepte la entrega ni utilice el software Decawave.
(8) El software Decawave está destinado únicamente a ayudarlo a desarrollar sistemas que incorporen
productos semiconductores Decawave. Usted comprende y acepta que sigue siendo responsable de
usar su análisis, evaluación y juicio independientes en el diseño de sus sistemas y productos. LA
DECISIÓN DE UTILIZAR EL SOFTWARE DE DECAWAVE EN SU TOTALIDAD O EN PARTE EN
SUS SISTEMAS Y PRODUCTOS ES TOTALMENTE DE USTED Y DECAWAVE NO ACEPTA
RESPONSABILIDAD ALGUNA POR DICHA DECISIÓN.
(11) Usted reconoce y acepta que es el único responsable del cumplimiento de todos los requisitos legales,
reglamentarios y relacionados con la seguridad relacionados con sus productos y cualquier uso del
software Decawave en sus aplicaciones, independientemente de cualquier información o soporte
relacionado con las aplicaciones que pueda proporcionarse. por Decawave.
Copyright (c) 15 de noviembre de 2017 por Decawave Limited. Reservados todos los derechos. Todas las marcas
registradas son propiedad de sus respectivos dueños
© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 7
Machine Translated by Google
1 INTRODUCCIÓN
1.1 Resumen
Este documento describe los detalles y el rendimiento del sistema de localización en tiempo real (DRTLS) de
alcance bidireccional DWM1001. Los componentes principales son:
• Hardware del módulo Decawave DWM1001 •
Software Decawave Positioning and Networking Stack (PANS)
1.2 Audiencia
Este documento es adecuado para clientes (ingenieros, diseñadores de sistemas RTLS) de los productos
DWM1001 [1], DWM1001-DEV [2] y MDEK1001 [3] que integran la tecnología en sus propios productos.
El DWM1001 es un producto de módulo que viene completo con firmware para permitir a los desarrolladores
de sistemas implementar rápidamente un RTLS para adaptarse a su aplicación final particular, o agregar la
capacidad de RTLS a un sistema existente. El módulo puede configurarse para comportarse como un "ancla"
de uno de los nodos fijos del sistema, un "puente" de un nodo fijo que enruta los datos entre la red UWB y la
red IP o una "etiqueta" de uno de los nodos móviles ubicados en el sistema. La configuración del módulo se puede
lograr a través de Bluetooth utilizando la aplicación complementaria (Decawave DRTLS Manager [4]); a través de
una conexión SPI o UART desde un host externo [5] o de forma remota desde un cliente web a través del backhaul
UWB.
El módulo incorpora el transceptor DW1000 UWB de Decawave que el firmware integrado del módulo controla
para implementar la red de nodos de anclaje y realizar los intercambios bidireccionales con los nodos de
etiquetas, lo que permite que cada etiqueta calcule su propia ubicación.
El módulo normalmente se monta en una placa de circuito impreso, como el producto DWM1001-DEV. El kit
MDEK1001 proporciona 12 módulos DWM1001 ya montados en placas de "desarrollo" que permiten a los
desarrolladores de sistemas evaluar el producto y/o comenzar el desarrollo de su sistema antes de embarcarse
en sus propios diseños.
• DWM1001 (módulo)
o Resumen del producto DWM1001
o Hoja de datos de hardware DWM1001
o Guía del usuario del firmware DWM1001
o Guía de API de firmware DWM1001
• DWM1001-DEV (placa de desarrollo)
o Resumen del producto DWM1001-DEV
o Hoja de datos del hardware DWM1001-DEV
o Guía de inicio rápido de DWM1001-DEV (en la caja)
© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 8
Machine Translated by Google
2 RENDIMIENTO RESUMEN
La siguiente tabla resume el rendimiento del DRTLS. Consulte la hoja de datos del DWM1001 para obtener información más
detallada sobre el hardware del módulo.
34 bytes por 12 s
Latencia del sistema 100ms De la etiqueta a la puerta de enlace
El hardware y el software DWM1001 están diseñados para permitir a los usuarios construir rápidamente un sistema
como el que se muestra en la Figura 1.
El gateway es una solución de hardware y software que permite configurar y monitorear una red desde la red
LAN/WAN.
Los componentes de hardware de la puerta de enlace son:
• DWM1001-Dispositivo
• Raspberry Pi 3 modelo B
Los datos del sistema se visualizan a través de clientes Web, MQTT o Bluetooth.
Los clientes basados en web en una PC o un dispositivo móvil como una tableta proporcionarán la interfaz para la
configuración y visualización de los datos de ubicación. La Figura 4 muestra una maqueta de esta interfaz.
Clientes MQTT
Los clientes de MQTT podrán conectarse al MQTT Broker para acceder a la ubicación y los datos IOT enviados desde los
nodos.
Un sistema/red UWB DRTLS permite la ubicación de etiquetas, así como el envío de datos desde la "nube" (cliente MQTT)
hacia y desde las etiquetas y anclas a través de los nodos puente. La red está compuesta por nodos fijos (anclas), nodos
móviles (etiquetas) y nodos puente (puerta de enlace a la red IP). La instalación de la red se trata en la sección 4.2 a
continuación.
El DRTLS utiliza el acceso al canal TDMA. Los nodos operan utilizando una estructura de "supertrama" repetitiva de 100 ms
de duración. Esta estructura se muestra en la Figura 6. El iniciador controla la temporización y la supertrama consta de 30
intervalos de mensajes Beacon (BCN), en los que los anclajes envían mensajes Beacon (9.1.1). A esto le siguen dos intervalos
de Servicio (SVC) que se utilizan para Almanaque, mensajes de servicio de red (p. ej., solicitud de unión a la red) y datos de
enlace ascendente/descendente a los anclajes. También hay 15 ranuras de rango bidireccional (TWR) que se utilizan para
etiquetar para anclar intercambios de rango bidireccional y también para datos de enlace ascendente/descendente a la
etiqueta. Hay 30 balizas de nodo de puente adicionales que se utilizan para informar a las etiquetas si hay datos de enlace
descendente para ellas. Hay un tiempo de guardia/inactividad al final de la supertrama que completa la supertrama.
El DRTLS utiliza un esquema TWR de un solo lado, en el que los rangos de etiquetas tienen hasta cuatro anclas y luego
calcula su propia ubicación con respecto a las posiciones de las anclas, que ha aprendido de los mensajes de Beacon .
Necesita un mínimo de tres anclas para calcular una ubicación.
La operación del motor de ubicación se describe en 6. Las etiquetas escucharán inicialmente los mensajes de Beacon y
Almanac y aprenderán sobre la topología de la red, y luego seleccionarán los cuatro puntos de anclaje con los que establecer
el rango. Los detalles del rango se dan en 4.7. Luego, la posición de la etiqueta se envía a través de Bluetooth a la aplicación
Decawave DRTLS Manager (Bluetooth está habilitado cuando la etiqueta está en modo de respuesta , consulte la sección
4.6), donde se puede visualizar. Los datos de ubicación también se pueden pasar a través de los nodos puente a los clientes
MQTT para su posterior procesamiento/visualización.
Además de los datos de ubicación, las etiquetas y los anclajes pueden enviar hasta 34B de otros datos en los mensajes
de datos IOT. Al final del intercambio de alcance, las etiquetas pueden recibir datos 34B de la red o enviar 34B a la red a
través de las puertas de enlace. El enlace descendente tiene prioridad sobre el enlace ascendente. Los datos IOT hacia/
desde los anclajes se envían durante las ranuras SVC.
Tenga en cuenta que la información de ubicación y rango también se puede enviar a través de UART, cuando una
etiqueta está conectada a un dispositivo host o una PC. Esto se describe con más detalle en [5].
Supertrama (n)
100ms
Inactivo Barcelona BCN BCN Inactivo CVS Inactivo CVS Ranura TWR 0 Ranura TWR 1 TWR Inactivo BN_BCN 29 Inactivo
... ... BN_BCN 0 ...
Tiempo 0 1 29 Tiempo 0 Tiempo 1 Ranura 14 Tiempo Tiempo
15 ms
0,5 ms
Ranura de mensaje
Barcelona
Ranura servicio o S S Intercambio TWR y BN_BCN 0
V V de baliza de nodo
0
Almanaque o C C datos IoT
de mensaje de baliza 0 1 de puente
enlace ascendente
Tennesse Datos IOT
de datos IOT de anclaje/ yo yo
AN1 AN2 AN3 AN4
Encuesta
(arriba/
O O
ranura de
(Loc)
Rsp Rsp Rsp Rsp abajo)
T T
Un grupo de nodos que forman una red UWB debe tener el mismo PANID para poder medir y pasar datos.
El usuario debe establecer un PANID de red (un número único de 16 bits), ya sea mediante el comando Shell
o mediante el administrador DRTLS como parte de la configuración del nodo.
El ancla iniciadora iniciará y controlará la red. También es posible configurar más de un ancla como
iniciador, pero solo una estará activa y las demás tomarán el rol de ancla ordinaria. Inicialmente, cada
iniciador comienza escuchando mensajes UWB para una cantidad de supertramas, y si no recibe ninguno,
asume el rol de iniciador. Inicializa la red eligiendo el asiento número 0, lo que significa que transmitirá sus
mensajes Beacon en el slot 0 de BCN, e iniciará una red DRTLS emitiendo Beacons y Almanaques.
Si el iniciador escucha mensajes que pertenecen a otra red (es decir, tendrán un PANID diferente), el
iniciador asumirá el papel de ancla ordinaria. Se unirá a la red existente. Tenga en cuenta que PANS FW
admite la coexistencia de redes cooperativas; esto se describe en 5.4.
Cuando un ancla comienza su operación, inicialmente escucha balizas de otras anclas y luego intenta
unirse a la red. Una vez que se unan a la red DRTLS, también enviarán mensajes Beacon y Almanac en los
espacios asignados. Que contienen las coordenadas del ancla, información general de la red y la participación
de TWR del ancla con las etiquetas.
Cada anclaje utiliza un intervalo BCN y dado que hay 30 intervalos BCN en la supertrama, esto significa
que como máximo 30 anclajes pueden operar en la misma área, cada uno ocupando su propio intervalo de
tiempo BCN.
Nota: Esto no significa que el sistema esté limitado a 30 anclas, sino que en toda la red no se
puede agregar ninguna ancla nueva (tomar un espacio BCN) si cualquiera de sus anclas dentro
del rango puede escuchar a otra ancla que ya ocupa esa ranura. Este mecanismo se describe en
detalle a continuación, y más adelante en la sección 5.1.1
Antes de que un ancla pueda unirse a una red existente, se deben cumplir los siguientes criterios:
• El mapa de clúster y el mapa de vecinos de clúster (enviados como parte de los mensajes Beacon ) deben
indicar que hay un asiento libre para ocupar. (es decir, el número de intervalos BCN ocupados en la
supertrama es < 30)
• El nivel de reloj de los anclajes en rango es inferior a 127. Los anclajes que pueden escuchar las balizas
del iniciador están en el nivel de reloj 1. Los siguientes son el nivel de reloj 2, etc. • Todos los anclajes
en rango han confirmado que el asiento solicitado ( solicitado por el ancla que desea unirse) es gratuito y
no se produjeron colisiones con los otros dispositivos durante el proceso de registro.
• El firmware debe ser compatible (si la actualización de FW está habilitada), es decir, la versión debe
coincidir con la versión del iniciador. La versión de firmware se envía en el Almanaque
mensajes
Nota: los anclajes no necesitan tener el mismo PANID para unirse a la red, pero a menos que lo tengan, no podrán
realizar TWR ni transferir datos IOT a/desde etiquetas.
El nuevo ancla continúa escuchando los Beacons y crea una lista de anclas en red que puede escuchar. Después
de escuchar cada uno de los anclajes al menos 3 veces y ver que hay un asiento libre, comienza a buscar un
espacio SVC libre para enviar un mensaje de solicitud de unión al clúster . Los anclajes en red indican en sus
balizas cuándo se puede usar la ranura SVC para Up-Link, es decir, está disponible para unirse al anclaje para
enviar el mensaje de solicitud de unión de clúster a la infraestructura.
El mensaje de solicitud de unión al clúster contiene información sobre el ancla de unión (versión de hardware,
versión de firmware, suma de verificación de firmware y otras capacidades del nodo) y el número de asiento
solicitado. Los anclajes unidos envían una respuesta a la solicitud utilizando la parte extendida del mensaje
Beacon . Incorporan un mensaje de confirmación de unión al clúster al final de los mensajes de baliza . Repiten
esto durante 3 ciclos (supertramas) desde la última recepción del mensaje de solicitud de unión al clúster . Durante
este intercambio, los anclajes en la red y el anclaje que se une están "bloqueados" y no se podrán unir nuevos
anclajes. Si cualquier ancla nueva envía una solicitud de unión, se ignorará, lo que significa que solo una ancla
puede unirse a la vez. El primer mensaje de solicitud de unión al clúster contendrá el número de asiento 0xFF, lo
que significa que el ancla de unión está investigando si las anclas en red ya lo tienen en sus listas.
Una vez que el ancla que se une haya elegido un asiento, enviará un mensaje de solicitud de unión al clúster con
el número de asiento solicitado y luego, cuando todas las anclas en red confirmen el asiento, se considerará
conectado y el proceso de registro se completará con éxito. El ancla entonces comenzará a enviar los mensajes
Beacon y Almanac, y participará en el DRTLS.
Si la actualización de firmware por aire (OTA) está habilitada (deshabilitada de forma predeterminada en
DRTLS), un ancla primero escuchará los mensajes del Almanaque y verificará que la versión del hardware, la versión
del firmware y el tamaño del firmware sean compatibles con los otros dispositivos en el la red. Si la versión es
diferente, se inicia un proceso de actualización de firmware, consulte la sección 8; de lo contrario, el ancla puede
continuar con el proceso de registro como se describe anteriormente. Nota: el firmware del iniciador debe actualizarse
primero mediante SWD o BLE, después de lo cual el iniciador actualizará cada nodo a través de UWB.
Una colisión de infraestructura ocurre cuando dos anclas están transmitiendo en la misma ranura BCN
(es decir, ocupando el mismo asiento). Cada ancla que participa en la red, recibe Beacon
mensajes de todas las demás anclas que están dentro del alcance y, al mismo tiempo, monitorea cualquier
colisión. Luego, cada anclaje mantiene una lista de anclajes para los que ha detectado colisiones/conflictos, es
decir, detecta que el mismo asiento es utilizado por dos anclajes diferentes, lo informará si el contador de
colisiones alcanza un umbral durante un período definido. El ancla
recibir un informe de colisión dirigido a él dejará la red e intentará volver a unirse, lo que debería resultar en que
ocupe el número de asiento libre.
La colisión se informa utilizando un intervalo SVC en el mensaje de servicio con parámetros que indican
la dirección del ancla que colisiona y la dirección del ancla que informa.
Un ancla que puede escuchar al iniciador mantiene su reloj sincronizado con él, de modo que se alinea con
los tiempos de supertrama del iniciador. Se dice que el nivel del reloj de este ancla es 1. Un ancla que no
puede escuchar al iniciador mantendrá su reloj sincronizado con el ancla que está más cerca del iniciador (por
ejemplo, si puede escuchar dos anclas, una con nivel 1 y otra con nivel 3, utilizará el reloj del ancla de nivel 1 para
su estimación de sincronización de reloj). Cuanto más lejos esté el ancla del iniciador, mayor será su nivel de reloj.
El DRTLS admite un nivel de reloj máximo de 127.
Cada ancla enviará Beacons en su espacio BCN reservado, en función de su número de asiento. Y también
enviar almanaques en la ranura SVC durante su supertrama reservada. Cada ancla, en función de su número de
asiento, tiene una ranura SVC reservada para enviar el Almanaque. Las balizas se envían cada supertrama y los
almanaques cada supertrama 120 .
El ancla escuchará durante otras franjas horarias de BCN para cualquier baliza y durante las franjas horarias de
SVC para cualquier almanaque u otros mensajes de servicio . Escuchará al comienzo de la ranura TWR para Group Poll
mensajes Si la Encuesta grupal contenía su dirección, entonces responderá con una Respuesta
mensaje y realice TWR con la etiqueta.
Los anclajes unidos también escuchan las balizas del nodo puente (BN_BCN) para recibir la
lista de datos IOT disponibles para anclaje o etiquetas dentro del sistema. Si los datos de IOT de enlace descendente están
disponibles para una etiqueta determinada, el ancla informará a esta etiqueta de la disponibilidad de datos en el mensaje de
respuesta de TWR.
Para obtener más información sobre la configuración y la implementación de la puerta de enlace, consulte
DWM1001_Gateway_Quick_Deployment_Guide [6].
Inicialmente, una etiqueta duerme y se despierta periódicamente para escuchar la baliza y los almanaques del ancla.
mensajes Escucha durante un período de 5 superfotogramas antes de volver a dormir durante un período determinado.
Se activará automáticamente y volverá a intentarlo. El período de sueño será inicialmente de 10 s y se extenderá a 60 s.
Cuando la etiqueta recibe mensajes de balizas y almanaques válidos , primero verifica que tenga una versión de hardware, una
versión de firmware y un tamaño de firmware compatibles con los anclajes en red. Si las versiones son incompatibles, se inicia
un proceso de actualización de firmware (si está habilitado), según 8. Si las versiones son compatibles, la etiqueta continuará
con la reserva de ranuras TWR y el proceso TWR.
Supertrama (n)
100ms
Inactivo Barcelona BCN 1 BCN Inactivo CVS Inactivo CVS 1 Ranura TWR 0 Ranura TWR 1 TWR Inactivo BN_BCN 29 Inactivo
... ... BN_BCN 0 ...
Tiempo 0 29 Tiempo 0 Tiempo Ranura 14 Tiempo Tiempo
habilitado, el dispositivo realizará un escaneo BLE después de despertar cada período establecido (máximo 60
segundos). La ventaja de la exploración BLE es que es más eficiente energéticamente. El dispositivo se unirá a la red
UWB solo si puede detectar anclajes circundantes a través de BLE. Tenga en cuenta que
La publicidad BLE debe habilitarse a pedido con el botón de usuario SW2 (si se usa DWM1001-Dev). La
publicidad BLE se deshabilitará automáticamente si no se establece una conexión dentro de los 20 segundos (y como
consecuencia, el DWM1001 no podrá establecer una conexión con otro dispositivo BLE, como un dispositivo Android que
ejecute DRTLS Manager).
La etiqueta recopila los mapas de ranuras de rango y datos (que muestran la utilización de ranuras) de los mensajes Beacon
de todos los anclajes dentro del rango, y los combina para seleccionar una ranura de rango libre en el supertrama en la que medir.
Si no hay ranuras libres en la supertrama, intentará cada 60 s obtener nuevos datos y reservar una ranura TWR. Cada supertrama
de 100 ms contiene 15 intervalos de rango, cada uno de los cuales está dimensionado para permitir que la etiqueta tenga tiempo
suficiente para realizar un rango bidireccional con 4 anclas, lo que brinda una capacidad de tasa de ubicación máxima de 150 Hz.
Si todas las ranuras de rango están completamente ocupadas, la capacidad del sistema está llena y las nuevas etiquetas no podrán
para comenzar a medir hasta que las etiquetas existentes se muevan fuera del área o renuncien a sus espacios.
La etiqueta utilizará el tiempo de recepción de las balizas recibidas para estimar su desviación del reloj en comparación
con el tiempo de la red. Cuando se estima la deriva del reloj, la etiqueta puede comenzar a buscar una ranura TWR libre. Cuando
haya un espacio de datos disponible, iniciará un intento de ubicación mediante el envío de un mensaje de sondeo grupal .
Una etiqueta en modo de bajo consumo utilizará la hora de recepción del mensaje de respuesta del ancla para ajustar la
sincronización de su reloj.
La etiqueta envía un mensaje de encuesta de grupo que contiene: su período de ubicación (rango) y una lista de 4 direcciones
de los anclajes a los que desea rango (y un mapa de bits con banderas para indicar los números de asiento de los anclajes). El
mensaje de Encuesta de grupo es un mensaje de difusión, por lo que todas las anclas dentro del alcance deben recibirlo.
Cada ancla que aparece en la encuesta de grupo (asumiendo que recibió la encuesta de grupo) responderá enviando un
mensaje de respuesta a su vez, con el tiempo de transmisión determinado por la posición (índice, 0 a 3) de su dirección en la lista.
Los anclajes notificarán a la etiqueta si los datos IOT de enlace descendente están disponibles desde los nodos del puente.
En este caso, la etiqueta escuchará los datos IOT de enlace descendente del nodo puente en la subtrama que sigue al último
mensaje de respuesta de anclaje. (ver Figura 8). Si no hay datos IOT de enlace descendente disponibles, entonces la etiqueta
puede potencialmente transmitir datos IOT hacia el nodo del puente si hay datos listos para ser transmitidos.
Una vez que la etiqueta recibe respuestas de cada anclaje y sigue el subtrama de enlace ascendente/descendente de IOT,
procederá a calcular los rangos de cada uno de los anclajes. Si la etiqueta obtiene 3 o más rangos válidos, usará su motor de
ubicación interno para calcular su ubicación (en relación con las coordenadas de los anclajes). La Figura 8 muestra las ranuras de
mensajes TWR individuales dentro de la estructura de supertrama.
TWR TWR
SVC1
Ranura 0 Ranura 1
Etiquetar enlace
Grupo AN_A AN_B CONGRESO NACIONAL AFRICANO Y Calcular
ascendente IOT /
Encuesta
Resp. Resp. Resp. Resp. Ubicación
enlace descendente
3ms
La etiqueta envía su tasa de actualización en el mensaje de encuesta de grupo , cada uno de los 4 anclajes direccionados
enviarán sus mensajes de respuesta confirmando que tienen un espacio libre en la supertrama futura correspondiente a la tasa
de actualización de la etiqueta. Usando la información de los anclajes (p. ej., todos los anclajes informan que el espacio futuro
está disponible), la etiqueta asumirá que este espacio futuro estará reservado para ella. Los anclajes también marcarán la ranura
como reservada, por lo que
no estar disponible para otras etiquetas.
El ancla almacena la ocupación de ranuras en un mapa de bits TDMA. La longitud del mapa TDMA es de 60 s, es decir, el
período máximo que la etiqueta puede reservar por adelantado (tasa mínima de actualización de ubicación).
DRTLS emplea TDMA, lo que significa que las etiquetas realizan su alcance bidireccional a los anclajes en las ranuras reservadas,
por lo que no debería haber interferencia. Sin embargo, cuando una etiqueta se mueve (roaming) de un área a otra o durante la
selección inicial de espacios "libres", dos etiquetas pueden transmitir al mismo tiempo. Para ayudar a mitigar esto, las etiquetas y
los anclajes tienen un algoritmo de detección y resolución de colisiones. Si el número de mediciones de TWR es más bajo de lo
esperado, la etiqueta podría estar experimentando los siguientes escenarios:
Un ancla envía en un espacio de respuesta y recibe en otros tres espacios de respuesta, por lo que puede ver un mensaje de
un ancla que no está en la lista de encuestas grupales y esto significa colisión. Si durante la fase de respuesta , el ancla recibió
una trama de respuesta con una dirección de origen y/o destino diferente a la esperada, o si recibió un tipo de mensaje diferente
al esperado, señalará una colisión. Informará esto en el mensaje de respuesta .
La etiqueta señalará una colisión si se recibe un marco con diferente origen y/o destino
dirección de lo esperado, o se recibe un mensaje inesperado, o no se recibe Respuesta o se reciben menos de tres Respuestas .
Utilizará esta información para decidir si debe seguir usando la ranura de rango o si debe renunciar a ella e intentar buscar una
nueva ranura de datos. La decisión se basa en los siguientes criterios:
• Al final de la fase de Respuesta , si la etiqueta recibió menos Respuestas de las esperadas y se detectó una colisión,
entonces abandonará el espacio si la cantidad de Respuestas recibidas fue menor a tres (cantidad mínima de distancias
para calcular una posición) o la cantidad de la siguiente confirmación de reserva de ranura es menos de tres.
• Si todos los anclajes confirmaron la próxima ranura, entonces continuará usándola. • Si algunos
anclajes no confirmaron el siguiente intervalo, se asume una colisión y
renunciar a la ranura. Y luego, en la siguiente supertrama, verifique nuevamente la disponibilidad de una ranura
desde el mapa de bits de uso de la ranura del ancla, y si hay alguno libre, intentará reservarlo para su
usar.
Una etiqueta recopila información sobre anclas al escuchar los mensajes de Beacon . Creará una lista de anclajes
de los que ya recibió las posiciones. Luego, calculará las distancias a cada uno de los anclajes en la lista, en función
de su posición actual (si no conoce su posición, usará 0,0,0) y luego podrá decidir qué anclajes elegir para la próxima
medición utilizando el siguientes criterios:
• Si es posible, elija un ancla de cada cuadrante, es decir, la etiqueta estará rodeada por
las anclas con las que andará. La etiqueta está dentro del polígono creado por los anclajes seleccionados.
• Seleccione los anclajes que estén más cerca de la etiqueta. Seguirá usando el seleccionado
anclas hasta que abandona el polígono o ya no es posible medir con las anclas seleccionadas (TWR
falló o colisión detectada).
Considere la Figura 9, aquí T0 selecciona A1, A2, A9 y A7 como 4 anclas con las que medir. Cada ancla está
en un cuadrante separado (Q1, Q2, Q3 y Q4).
5 ESCALABILIDAD
El sistema se puede escalar a grandes tamaños de red, pero hay una serie de reglas de escala que se
deben seguir para permitirlo.
Figura 10: Escala del DRTLS que muestra los números de asiento del ancla
• Si el sistema tiene 30 anclas o menos, no hay restricciones en el posicionamiento de las anclas (todas pueden
estar dentro del alcance de las otras)
• Si se requiere un anclaje 31 (o más), entonces necesita reutilizar un número de asiento. Esto solo se puede lograr
si los otros anclajes están lo suficientemente separados, de modo que ningún ancla escuche a dos anclas con
el mismo asiento.
• Antes de permitir que se una el ancla 31 , todas las demás anclas que estén dentro del alcance de la 31 deben
confirmarle que hay un número de asiento disponible (según 4.2.1) • Por ejemplo, en el diagrama anterior, si
el ancla 11 está dentro del rango del ancla 0 y del ancla 31 , entonces el ancla 31 no puede usar el número de
asiento 0 (ya que eso significaría que el ancla 11 podría ver dos anclas con el mismo número de asiento, es
decir, 0)
• Cada nodo conectado tendrá su reloj derivado del reloj del iniciador de red o
de su ancla vecina que está más cerca del iniciador. • Todos los nodos
dentro del rango del iniciador tendrán un nivel de reloj de 1
• Los nodos que están en el rango de los nodos con el nivel de reloj 1, pero no en el rango del iniciador, tendrán
un nivel de reloj de 2 y así sucesivamente.
• El valor más alto permitido del nivel de reloj es 127. Esto significa que si un ancla nueva intenta unirse y puede
escuchar Beacons de anclas que ya están en el nivel de reloj 127, no podrá unirse a la red.
El sistema está diseñado para tener una capacidad de sistema de 150 Hz, por ejemplo
• 15 etiquetas a 10 Hz (tasa de ubicación máx.)
• 150 etiquetas a 1 Hz
• 300 etiquetas a 0,5 Hz
• 9000 etiquetas a 0,01667 (tasa de ubicación mínima)
A las etiquetas se les asigna una ranura TWR específica y tienen un rango de hasta 4 anclajes. Si todas las ranuras (hay 15
ranuras en 1 supertrama) ya se han asignado a las etiquetas, entonces una nueva etiqueta no podrá obtener una ranura en la
que establecer el rango. De la misma manera que los anclajes repartidos por el espacio pueden reutilizar los asientos cuando
están fuera del alcance de todos los demás usuarios de ese asiento, las ranuras de rango de un área más amplia podrán
reutilizarse de manera similar.
Al configurar la tasa de actualización de etiquetas, el instalador del sistema debe considerar qué nivel de servicio resultará si es
posible que las etiquetas se congreguen en un área y debe configurar la tasa de ubicación máxima para admitirlo. De lo contrario,
a medida que las etiquetas se congregan, algunas pueden volverse ilocalizables ya que no pueden acceder a una ranura de rango.
El PANS FW apoya la coexistencia. Esto significa que múltiples redes en la misma área comparten el mismo espacio aéreo y
no interfieren con mensajes superpuestos. Los anclajes y las etiquetas de una segunda red se unirán a la red existente y
compartirán los espacios disponibles. Las dos redes deben tener PANID separados (y pueden usar diferentes claves AES), por
lo tanto, los datos y la ubicación se mantendrán privados. Es decir, las etiquetas de una red solo podrán extenderse a los anclajes
de la misma red (deben tener el mismo PANID), y los datos de IOT solo se pueden pasar entre nodos del mismo PANID.
La gran escalabilidad de PANS permite al usuario cubrir una amplia gama de áreas. Cada red tendrá una topología diferente
según la geometría en la que se desplegará.
Con el fin de alcanzar el mejor rendimiento, hay algunos puntos a considerar y reglas a seguir.
saludos:
La Figura 12 es un ejemplo de una implementación de red de cuadrícula para condiciones de LOS moderadas.
El motor de ubicación interno de TWR se usa en el modo de etiqueta para calcular una estimación de la posición de la etiqueta
utilizando los resultados de medición bidireccional y las posiciones conocidas de las anclas seleccionadas para la medición. Se
puede calcular una estimación de ubicación con 3 o 4 resultados de rango, es decir, puede tolerar la falta de una respuesta de
cualquiera de los cuatro anclajes seleccionados para el rango y aun así calcular una nueva estimación de la ubicación de las
etiquetas.
El motor de ubicación utiliza la estimación de máxima verosimilitud. Cuando tiene cuatro resultados de rango, el motor de
ubicación crea conjuntos de datos (4 conjuntos de 3 rangos). Luego, los conjuntos se utilizan para calcular las posibles posiciones
de las etiquetas. La implementación usa caché para acelerar la estimación de las posiciones. Si los anclajes que se utilizan para el
cálculo no se han cambiado, se utilizará el valor almacenado en caché y no es necesario volver a calcular las matrices iniciales. El
motor de localización utiliza entonces diferentes criterios para elegirlos o combinarlos para calcular la estimación de la posición. La
posición estimada se verifica usando distancias medidas. Las posiciones que dan como resultado distancias más cortas que las
medidas se consideran menos precisas (los trayectos múltiples solo darán como resultado distancias más largas).
El motor de ubicación calcula los errores entre las posiciones estimadas y la distancia real y elimina las posiciones que
tienen muchos errores. La posición final se calcula utilizando las posiciones estimadas seleccionadas. El motor de ubicación
también informará un factor de calidad (0-100) basado en todos estos criterios y los errores calculados.
Se utiliza un promedio móvil fijo de los últimos 3 resultados de ubicación para la estimación de la posición final.
El FW del módulo DWM1001, cuando funciona en el modo de etiqueta de bajo consumo predeterminado, utiliza una
estrategia de administración de energía para ayudar a mantener el sistema y sus componentes en el modo de consumo más bajo
entre los intercambios de rango. Los anclajes son energéticamente eficientes, pero no tan eficientes como las etiquetas, ya que
están continuamente encendidos y esperando participar en el rango con las etiquetas. Se supone que los anclajes se alimentarán
a través de la red eléctrica.
El sistema operativo integrado DWM1001 (eCos) registrará todas las tareas con la función de administración de energía.
Cuando todas las tareas del sistema operativo hayan completado su operación y estén en modo inactivo, Power Management
pondrá la MCU en modo de suspensión sin marcar RTOS.
Mientras se ejecuta cualquier tarea, la marca RTOS está activa y la MCU no se puede poner en el
modo de sueño.
Administración de energía
UART
Mando a distancia radio UWB / SPI
LE Caparazón /
bluetooth MAC API aplicación de usuario
API
La administración de energía y los componentes principales del sistema se muestran en la Figura 13. Los controles de
administración de energía:
• Radio UWB: el uso de la radio DW1000 a través de su controlador y la máquina de estado MAC
• LE: Operación del motor de ubicación, se ejecuta tan pronto como se toman las medidas del nuevo rango.
disponible, y luego pasa a inactivo.
• Radio Bluetooth: los anuncios de Bluetooth se transmiten al encender el DWM1001 y cuando el usuario presiona el botón
de activación de Bluetooth. Los anuncios se transmiten durante 20 s. Cuando otro dispositivo Bluetooth (tableta) se
conecta al módulo, la conexión se mantiene y el módulo (es decir, la etiqueta) no podrá entrar en suspensión. Tan pronto
como el dispositivo se desconecte, el módulo Bluetooth enviará anuncios durante 20 s y, si no se establece ninguna
conexión, el módulo Bluetooth se desactivará y sus recursos se liberarán, lo que permitirá que el dispositivo entre en
estado de suspensión.
• Shell de UART: una vez que se habilite el shell , la MCU no entrará en modo de suspensión hasta que el usuario
ejecute el comando "salir" y deshabilite el shell. Eso significa que el shell y sus recursos se liberan de Power
Management. • API de UART: una vez que se habilita la API de UART (se inició una comunicación a través de
UART desde un dispositivo host; consulte [5]), la MCU no entrará en modo de suspensión y el host debe controlar la
suspensión de la MCU a través de una llamada API.
• API SPI: una vez que la API SPI está habilitada (se inició una comunicación a través de UART desde un dispositivo host;
consulte [5]), la MCU no entrará en modo de suspensión y el host debe controlar la suspensión de la MCU a través de
una llamada API.
• Aplicación de usuario: un usuario puede agregar su propia aplicación al DWM1001 FW. Esto se describe en detalle en
[5]. Esta aplicación tiene dos opciones para registrarse con Power Management e influir cuando la MCU está inactiva
o entrando en modo de bajo consumo:
• Al registrarse para recibir datos de ubicación: al recibir los datos de ubicación a través de la devolución de llamada, Power
Management espera automáticamente a que la aplicación de usuario lo notifique a través de la llamada API (cuando
finaliza) y luego Power Management puede poner la MCU en modo de suspensión si no hay otras tareas pendientes.
Para despertar la etiqueta del modo de baja potencia (suspensión), se utilizan varias señales:
• RTC: el RTC se usa para activar la radio UWB y su MAC para que el dispositivo
puede estar listo para el próximo intercambio de alcance.
• Acelerómetro: si el acelerómetro detecta movimiento, activará el dispositivo y la etiqueta cambiará para usar la tasa de
ubicación no estacionaria.
• UART RX GPIO: el host puede activar el dispositivo con UART RX GPIO para que
puede comunicarse con él a través de las API de UART.
• SPI CS GPIO: el host también puede usar la señal SPI CS para activar el dispositivo.
• Botón de usuario: El DWM1001 GPIO2 (por ejemplo, si está conectado a un botón, por ejemplo, DWM1001 –
DEV) también se puede usar para activar el dispositivo.
• BLE: si BLE está habilitado con el modo Etiqueta de bajo consumo, la radio UWB de la etiqueta se habilitará una vez que
la etiqueta esté en el rango BLE de los nodos de anclaje y se deshabilitará una vez que la etiqueta abandone la red
UWB.
Para ayudar a reducir el consumo de energía, la etiqueta tiene la opción de dos tasas de actualización de ubicación, la nominal
y la estacionaria. El acelerómetro incorporado se usa para detectar cuándo el dispositivo está estacionario y luego se usará la
velocidad estacionaria. Si el acelerómetro está deshabilitado, solo se utilizará la tasa de ubicación nominal.
El DW1001 viene precargado con el firmware DRTLS, que permite la creación de un RTLS completamente funcional sin más
cambios de firmware; sin embargo, si surge la necesidad, es posible reprogramar el firmware del módulo en su memoria flash.
Este proceso, llamado actualización de firmware, se describe en detalle en la Guía del usuario del firmware DWM1001 [5].
La estructura de la memoria flash se muestra en la Figura 14. El área etiquetada como FW2 contiene el bloque funcional principal
y la aplicación, y el área FW1 solo se usa para el proceso de actualización.
Cuando se está formando la red RTLS, el ancla del iniciador especifica la versión del firmware
necesario para la red. Cuando la actualización automática de FW está habilitada, cualquier dispositivo que desee participar
(unirse) a la red debe tener el mismo firmware (número de versión y suma de verificación). Si un nuevo dispositivo no tiene el
firmware correcto, se actualizará según las subsecciones a continuación.
Si uno quiere actualizar toda la red a una nueva imagen de firmware mientras la red está
operativo, basta con actualizar el iniciador a través de Bluetooth. El iniciador luego propagará el nuevo firmware a todos los
demás dispositivos a través del enlace de radio UWB automáticamente.
Tenga en cuenta que, dado que el iniciador se actualiza primero, reiniciará la red y, a medida que cada dispositivo vuelva a
unirse a la red, su firmware se actualizará. Por lo tanto, durante la actualización de FW, los nodos que están realizando la
actualización estarán "fuera de línea".
Cuando la actualización automática de FW está habilitada, todos los dispositivos que deseen unirse a la red deben tener la
misma versión de firmware. Cada nuevo dispositivo que se une escucha los almanaques para obtener la información de hardware
y firmware del sistema. Si se necesita una actualización de firmware, el nuevo dispositivo elegirá un ancla cercana con TWR/
ranura de datos libre y enviará un mensaje de solicitud de datos de actualización de firmware (9.1.6).
El ancla que recibió la solicitud para suministrar el firmware, verifica la solicitud y, si no se está ejecutando ningún proceso de
actualización de firmware, comenzará a enviar los datos de actualización de firmware al
solicitando ancla sobre UWB. Los mensajes de datos de firmware se transmiten para que cualquier nodo en estado de
actualización de firmware pueda recibir y procesar los datos.
El nodo receptor almacena los nuevos datos de la imagen del firmware en un búfer intermedio y cuando el búfer contiene el
tamaño de la página de la memoria flash interna, se escribirá en la memoria flash interna.
Tenga en cuenta que durante la actualización del firmware, Bluetooth SoftDevice está deshabilitado porque la escritura
en la memoria flash interna a través de SoftDevice es muy lenta (hasta 500 ms por página). Cuando SoftDevice está
deshabilitado, se puede escribir una página en ~120 ms.
Si el dispositivo receptor pierde algunos datos (debido a una recepción de trama fallida), volverá a solicitar los mismos datos
comenzando el desplazamiento donde se detuvo en el intento anterior. El ciclo se repetirá hasta que el nodo solicitante reciba
todos los datos del firmware. Luego, ejecutará un control de suma de verificación de todo el firmware y, si los valores de suma de
verificación son correctos, permitirá que el registro no volátil arranque desde el restablecimiento del otro firmware (FW1/FW2). Si
la suma de comprobación falla, se repetirá todo el proceso de nuevo.
En primer lugar, la unidad se ejecutará desde FW2 y actualizará FW1, luego se restablecerá y actualizará FW2.
Cuando la actualización automática de FW está deshabilitada, el usuario puede actualizar individualmente el firmware en un
dispositivo a través de Decawave DRTLS Manager o a través de la conexión SWD.
El sistema utiliza marcos estándar según lo definido por IEEE 802.15.4 en la capa MAC. El estándar define múltiples tipos
de marcos, solo el marco de datos se usa en este sistema. Tabla 2
muestra la estructura del marco de datos.
Dirección de 2 Dirección del nodo de destino, o 0xFFFF si se trata de una trama de difusión (p. ej .,
destino mensaje de sondeo de grupo )
Dirección 2 La propia dirección del nodo es fija y son los 16 bits inferiores de la dirección de
de la fuente 64 bits generada (derivada como 0xDECA + 28 bits de MCU
ID único + 20 bits de DW1000 Part ID)
Carga útil 1-53 Nota: el primer byte de la carga útil siempre denota el tipo de trama
que es seguido por el contenido del mensaje como se especifica en las tablas a
continuación.
Códigos de ID de mensaje:
0x10 - UWBMAC_FRM_TYPE_BCN
0x11 - UWBMAC_FRM_TYPE_SVC
0x12 - UWBMAC_FRM_TYPE_CL_JOIN
0x13 - UWBMAC_FRM_TYPE_CL_JOIN_CFM
0x18 - UWBMAC_FRM_TYPE_POS 0x21 -
UWBMAC_FRM_TYPE_FWUP_DATA_REQ
0x22 - UWBMAC_FRM_TYPE_FWUP_DATA
0x23 - UWBMAC_FRM_TYPE_ALMA
0x63 - UWBMAC_FRM_TYPE_DL_IOT_DATA
0x65 - UWBMAC_FRM_TYPE_UL_IOT_DATA
0x6A - UWBMAC_FRM_TYPE_BN_BCN
0x30 - UWBMAC_FRM_TYPE_TWR_GRP_POLL
0x31 - UWBMAC_FRM_TYPE_TWR_POLL
La carga útil de la trama de datos (ver Figura 15) puede contener uno o más de los mensajes
especificado en el subapartado siguiente. En general, solo se envía un mensaje por trama de datos, la única excepción es el
mensaje Beacon, que puede ir seguido de un mensaje adicional (por ejemplo,
Únase a los mensajes de Confirmación o Posición).
bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Bit 8 Bit 9 10 11 12 13 14 15
1 0 0 0 0 0 1 0 0 0 DestAddrMode 0 0 SrcAddrMode
Figura 15: Formato de trama MAC IEEE 802.15.4, con, por ejemplo, dirección de transmisión y
Estos mensajes son enviados por los anclajes en las ranuras BCN en la supertrama. Estas
los mensajes tienen el formato de trama de datos IEEE 802.15.4 con la carga útil especificada en la siguiente tabla. Los mensajes
Beacon contienen información sobre la supertrama actual y el uso de ranuras de red (es decir, qué ranuras TWR utilizan actualmente
las etiquetas/anclajes).
ID de sesión 1 Número aleatorio que genera Anchor Initiator durante la inicialización de la red. Todos
los anclajes unidos deben tener el mismo ID de sesión
Banderas de clúster 2 Campo de bits donde se pueden configurar los siguientes indicadores:
• NBR_SYNC: el nodo se sincroniza con el reloj de la red vecina. Los 7 bits más
altos se utilizan para indicar el nivel del reloj.
Mapa de conglomerados 4 Mapa de bits que indica asientos ocupados visibles por el ancla de envío (un bit establecido
indica asiento ocupado, por ejemplo, 0x000081 significa que los asientos 7 y 0 están
ocupados). La máscara del tamaño completo del clúster es 0x3fffffff, es decir, 30 asientos.
Mapa de ranuras de datos 2 Indica qué ranuras de datos TWR/IOT del ancla de envío están ocupadas
Estos mensajes son enviados por los anclas, durante el intervalo de Servicio (slots SVC) dentro de la supertrama, como una
solicitud para unirse a la red. Estas son las tramas de datos IEEE 802.15.4 con carga de mensaje especificada en la siguiente tabla.
Estos se envían a anclas en red como una solicitud para unirse a la red.
Estos mensajes son enviados por los anclas después de que se recibe una solicitud de unión. estos mensajes
se envían después del mensaje Beacon en la misma trama de datos IEEE 802.15.4 (ver el indicador EXT en el mensaje Beacon ) y
tienen el formato especificado en la siguiente tabla. Se envían en una respuesta a la solicitud de ingreso para asignar un asiento al
ancla que intenta unirse a la red.
Bloqueo de racimo 1 Contador de bloqueo (decreciente). 0 significa que la próxima baliza no contendrá
confirmación de ingreso a menos que se reciba una nueva solicitud
asiento del grupo 1 Confirmación del número de asiento asignado o 0xff que indica que no se ha
asignado ningún asiento
Estos son enviados por los anclas en red, durante el intervalo de servicio (slots SVC) dentro de la supertrama. Estos son
marcos de datos IEEE 802.15.4 con carga útil especificada en la siguiente tabla. Cada supertrama solo puede llevar un único
mensaje de Almanaque , por lo que cada una de las 30 anclas del clúster se turna para enviar su almanaque una vez cada 120
supertramas según su número de asiento. Proporcionan las versiones de FW del nodo y las capacidades del nodo.
Opción de nodo 4 Mapa de bits que indica las capacidades del nodo
Los mensajes de servicio se utilizan para enviar comandos de servicio y estado entre los dispositivos en red. Por ejemplo,
informes de colisión. Estos se envían en las ranuras SVC. Estos son marcos de datos IEEE 802.15.4 con carga útil como se
especifica en la siguiente tabla.
Estos mensajes son enviados por dispositivos que necesitan actualizar su FW. La solicitud se envía a uno de los anclajes en red. Estos son
marcos de datos IEEE 802.15.4 con carga útil como se especifica en la siguiente tabla.
Banderas 1 Banderas
Estos mensajes contienen los datos de la imagen del firmware y se envían desde el ancla en red al dispositivo que ha solicitado la
actualización. Estos son marcos de datos IEEE 802.15.4 con carga útil como se especifica en la siguiente tabla.
Banderas 1 Banderas
El mensaje de posición se envía como parte del mensaje Beacon extendido , contiene las coordenadas del ancla.
La carga del mensaje es como se especifica en la siguiente tabla.
Este mensaje se envía desde un dispositivo que quiere iniciar un intercambio TWR. Por lo general, será una etiqueta,
pero también puede ser un ancla (por ejemplo, durante el proceso de posicionamiento automático). Estos son marcos
de datos IEEE 802.15.4 con carga útil como se especifica en la siguiente tabla. Esto se envía como una transmisión
para que todos los dispositivos puedan recibirlo.
Banderas 2 Mapa de bits que indica los anclajes con los que se va a medir.
Anchor utiliza este mapa de bits para averiguar si su asiento
se corresponde con el bit indicado. Si lo hace, continuará
buscando su dirección en el campo Dirección a continuación; de
lo contrario, se ignorará el marco.
Un ancla que recibe una Encuesta de grupo que lo nomina como una de las cuatro anclas abordadas responderá con un mensaje de
Respuesta . Esta es una parte del protocolo TWR de un solo lado. Estos son marcos de datos IEEE 802.15.4 con carga útil como se
especifica en la siguiente tabla. Estos están dirigidos al dispositivo particular que envió la Encuesta de grupo.
Mapa de tragamonedas
2 Mapa que indica la próxima ocupación de la ranura
Estos son enviados por los nodos de puente en las ranuras de mensajes de baliza del nodo de puente. Estos son marcos de
datos IEEE 802.15.4 con carga útil como se especifica en la siguiente tabla.
grupo BN 4 Mapa de bits que indica los asientos del grupo BN ocupados visibles por el ancla de envío (el conjunto de bits
mapa significa asiento ocupado, por ejemplo, 0x000081 significa que los asientos 7 y 0 están ocupados). La máscara
del tamaño completo del clúster es 0x3fffffff, es decir, 30 asientos.
Bloqueo de 1 Contador de bloqueo (decreciente). 0 significa que el último mensaje y el siguiente no contendrán confirmación
grupo BN de unión a menos que se reciba una nueva solicitud
asiento del 1 Confirmación del número de asiento del grupo BN asignado o 0xff que indica que no se ha asignado ningún
grupo BN asiento
Dirección de etiqueta 2xTID Una lista de direcciones de etiquetas de 2 bytes (máx. 15)
Un mensaje que contiene la carga útil de datos IOT de la etiqueta o el ancla enviado al ancla de enrutamiento (enlace
ascendente) o enviado a la etiqueta o al ancla (enlace descendente) por el ancla de enrutamiento. Estos son marcos de datos
IEEE 802.15.4 con carga útil como se especifica en la siguiente tabla.
IDENTIFICACIÓN
2 Dirección de nodo (para UL puede ser TN/AN; para DL es la dirección del
nodo receptor)
Carga útil IOT 1-34 1-34 bytes: carga útil de datos IOT
10 REFERENCIAS
10.1 Listado
12 MÁS INFORMACIÓN
Decawave desarrolla soluciones de semiconductores, software, módulos, diseños de referencia, que permiten servicios de
microubicación de área local en tiempo real, ultra precisos y ultra confiables.
La tecnología de Decawave permite una clase completamente nueva de funcionalidad y servicios de ubicación inteligente,
altamente seguros y fáciles de implementar para IoT y productos y aplicaciones de consumo inteligente.
Para obtener más información sobre este o cualquier otro producto Decawave, consulte nuestro sitio web www.decawave.com.