DWM1001 System Overview and Performance

Machine Translated by Google
Descripción general del sistema DWM1001

y rendimiento
Versión 2.1
Este documento está sujeto a cambios sin

previo aviso
© Decawave 2018 OP-DWM1001-System-Deview-2.1

TABLA DE CONTENIDO
1. INTRODUCCIÓN................................................ .................................................... ...................8
1.1 VISIÓN GENERAL ............................................. .................................................... ..........................8

1.2 AUDIENCIA................................................... .................................................... ....................................8
1.3 EL MÓDULO DWM1001 Y RTLS .................................................. .................................................... 8
1.4 MÁS INFORMACIÓN ............................................... .................................................... ...................8
2 RENDIMIENTO RESUMEN ............................................... .................................................... .10
3 ARQUITECTURA DEL SISTEMA OBJETIVO ............................................... ............................................. 11
3.1 RED DRTLS.................................................... .................................................... ......................12

3.2 DWM1001 SISTEMA DE LOCALIZACIÓN EN TIEMPO REAL DE DOS DIRECCIONES
(DRTLS).................................... .....12 3.3 PUERTA DE ENLACE ...................................... .................................................... ..............................
3.4 PUNTOS FINALES ............................................... .................................................... ..............................13
3.4.1 Clientes web DWM1001................................................ .................................................... .....13 3.4.2 Tabletas/ teléfonos
inteligentes conectados por Bluetooth local ........................... ........................14
4 RED DRTLS, CONFIGURACIÓN Y CONTROL ............................................... .................. 15
4.1 FUNCIONAMIENTO DE LA RED DRTLS ........................................... .................................................... .......15

4.2 INICIALIZACIÓN DE LA RED .................................................. .................................................... ............dieciséis
4.2.1 Criterios para la inscripción de anclas ............................................... .................................................... 17 4.2.2
Proceso de alta ............................................... .................................................... ....................17 4.3 DETECCIÓN Y RESOLUCIÓN
DE COLISIONES DE INFRAESTRUCTURA .................. ..........................................18 4.4 FUNCIONAMIENTO DE UN ANCLA
CONECTADA/ ANCLA-INICIADOR ............................................................... ..........18 4.5 FUNCIONAMIENTO DE UN NODO
PUENTE / PASARELA .................. .................................................... ..........19 4.6 FUNCIONAMIENTO DE UNA
ETIQUETA ........................... .................................................... ..............................19
4.7 PROTOCOLO TWR Y RESERVA DE SLOT TWR .................................................. ....................................20
4.8 DETECCIÓN Y RESOLUCIÓN DE COLISIONES TWR ........................................... .....................................21 4.9 ESTRATEGIA
TWR DE TAG ........ .................................................... .................................................... .....22
5 ESCALABILIDAD .............................................. .................................................... ...................... 23
5.1 EXPANSIÓN DEL SISTEMA - ANCLAJES ............................................. .................................................... .....23

5.1.1 Reglas de escala................................................. .................................................... ...........24 5.2 LIMITACIONES DE
LA INSTALACIÓN .......................... .................................................... ..........................24
5.2.1 Limitación 1: El número máximo de asientos de anclaje es 30 ........................................... ...........24 Limitación 2: El
5.2.2 número máximo de niveles de reloj es 127 ........................... .......................24 5.3 EXPANSIÓN DEL SISTEMA –
ETIQUETAS .................. .................................................... .....................................25
5.4 COEXISTENCIA ENTRE MÚLTIPLES REDES ............................................... ....................................25
5.5 COBERTURA Y EXPANSIÓN DE LA RED .................................................. ..........................................25
6 LOCALIZACIÓN DEL MOTOR ............................................... .................................................... ............. 27
7 ESTRATEGIA DE GESTIÓN DE ENERGÍA ............................................... .......................................... 28
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
8 USO DE LA MEMORIA Y ACTUALIZACIÓN DEL FIRMWARE .................................. ............................. 30
8.1 ACTUALIZACIÓN DEL FIRMWARE .................................... .................................................... ....................30

8.2 ACTUALIZACIÓN DE FIRMWARE INICIADA A TRAVÉS DE BLUETOOTH ........................................... ..........................30
8.3 ACTUALIZACIÓN DE FIRMWARE VÍA UWB........................................... .................................................... ........30
8.4 ACTUALIZACIÓN MANUAL DEL FIRMWARE .................................... .................................................... ........31
© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 2

9 APÉNDICE: FORMATOS DE FOTOS ............................................... .................................................. 32
9.1 TRAMA IEEE 802.15.4 ............................................... .................................................... ....................32
9.1.1 Mensaje de baliza ............................................. .................................................... ...............34 9.1.2 Mensaje de solicitud de

incorporación .................. .................................................... ..........................35 9.1.3 Mensaje de confirmación de
incorporación .................. .................................................... .........................35 9.1.4 Mensaje de
almanaque ............... .................................................... ......................................36 9.1.5 Mensaje de
servicio ......actualización
.................................................... ....................................................
de firmware ........................... ..........................37 9.1.7....36 9.1.6 de
Mensaje Mensaje de actualización
datos de solicitud de datos
de de
firmware ........ .................................................... ..........................37 9.1.8 Mensaje de
posición .................. .................................................... ............. ..........................38 9.1.9 Mensaje de sondeo de
grupo ............... ....................................................
respuesta .......................................38
... .................................................... 9.1.10 Mensaje...39
.................................................... de 9.1.11 Mensaje de baliza de nodo
puente.................................... .................................................... 40 9.1.12 Mensaje de datos

IOT ........................................... .................................................... ..............40
10 REFERENCIAS .............................................. .................................................... .................... 41
10.1 LISTADO................................................. .................................................... ...............................41
11 HISTORIA DEL DOCUMENTO ............................................... .................................................... ...... 42
11.1 HISTORIAL DE REVISIÓN .............................................. .................................................... ...............42
12 MÁS INFORMACIÓN.................................................... .................................................... .43
LISTA DE TABLAS
TABLA 1: RENDIMIENTO RESUMEN DEL SISTEMA ........................................... .................................................... ...10
TABLA 2: ESTRUCTURA DEL TRAMA DE DATOS IEEE 802.15.4 .................................. ..........................................32
TABLA 3: TABLA DE REFERENCIAS ........................................... .................................................... ....................41

TABLA 4: HISTORIA DEL DOCUMENTO ............................................... .................................................... .....................42
LISTA DE FIGURAS
FIGURA 1: ARQUITECTURA DEL SISTEMA OBJETIVO ........................................... .................................................... ......11
FIGURA 2: RED DRTLS ............................................... .................................................... ........................12

FIGURA 3: COMPONENTES DEL SOFTWARE DE LA PUERTA DE ENLACE .................................. .................................................... 13
FIGURA 4: MODELO DE INTERFAZ DE CLIENTE WEB ........................................... .................................................... ......14
FIGURA 5: CONFIGURACIÓN LOCAL Y VISUALIZACIÓN EN LA APLICACIÓN DE ANDROID ....................................... ...14
FIGURA 6: ESTRUCTURA DEL SUPERFRAME ........................................... .................................................... ..............dieciséis

FIGURA 7: FUNCIONAMIENTO DE LA ETIQUETA EN MODO DE BAJA ENERGÍA VS MODO DE RESPUESTA .................................. .....................19
FIGURA 8: SUPERFRAME QUE MUESTRA TWR FRAMES ........................................... ..........................................21

FIGURA 9: ETIQUETAS ELECCIÓN DE ANCLAJES PARA TWR ........................................... .................................................... ..22
FIGURA 11:ESCALA DE LOS DRTLS QUE MUESTRA LOS NÚMEROS DE ASIENTO DEL ANCLAJE ........................................... .......................23
FIGURA 12:ESCALA DE LOS DRTLS MOSTRANDO NIVELES DE RELOJ ........................................... ..........................................25
FIGURA 13: EJEMPLO DE DESPLIEGUE DE RED GRID ........................................... ..........................................26
FIGURA 13: PRINCIPALES COMPONENTES DEL SISTEMA DWM1001 ........................................... ..........................................28

FIGURA 14: MAPA DE DIRECCIONES FLASH DWM1001 ........................................... .................................................... ..30
FIGURA 15: FORMATO DE TRAMA MAC IEEE 802.15.4 , CON DIRECCIÓN DE BROADCAST POR EJEMPLO Y .................................. ..33

INFORMACIÓN DEL DOCUMENTO
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.
Copyright © 2017 Decawave Ltd.
PÓLIZA DE SOPORTE VITAL
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").
(2) El software Decawave se proporciona de las siguientes dos maneras: -

(a) precargado en el Módulo en el momento de la fabricación por Decawave ("Firmware");
(b) suministrado por separado por Decawave ("Paquete de software").
(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:
• Módulo de kernel de Linux de puerta de enlace DRTLS

• Demonio de puerta de enlace DRTLS
• Proxy de puerta de enlace DRTLS
• Agente MQTT de puerta de enlace DRTLS
• Administrador web de puerta de enlace DRTLS
(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: -
(i) El kernel de Linux que se proporciona como código fuente en el paquete de

software. El kernel de Linux se proporciona bajo los términos de la licencia GPLv2
que se puede encontrar en: https://www.gnu.org/licenses/old licenses/
gpl-2.0.en.html y, como tal, el componente del controlador DWM1001 de DRTLS
La aplicación Gateway se proporciona bajo los mismos términos de licencia;
(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.
(9) EL SOFTWARE DECAWAVE SE PROPORCIONA "TAL CUAL". DECAWAVE NO OFRECE GARANTÍAS

O REPRESENTACIONES CON RESPECTO AL SOFTWARE DECAWAVE O EL USO DEL
SOFTWARE DECAWAVE, EXPLÍCITAS, IMPLÍCITAS O LEGALES, INCLUYENDO LA EXACTITUD
O LA INTEGRIDAD. DECAWAVE NIEGA CUALQUIER GARANTÍA DE TÍTULO Y CUALQUIER
GARANTÍA IMPLÍCITA DE COMERCIABILIDAD, IDONEIDAD PARA UN PROPÓSITO PARTICULAR
Y NO INFRACCIÓN DE CUALQUIER DERECHO DE PROPIEDAD INTELECTUAL DE TERCEROS
CON RESPECTO AL SOFTWARE DECAWAVE O EL USO DEL MISMO.
(10) DECAWAVE NO SERÁ RESPONSABLE Y NO LO DEFENDERÁ O INDEMNIZARÁ CONTRA

CUALQUIER RECLAMACIÓN DE INFRACCIÓN DE TERCEROS QUE ESTÉ RELACIONADA O
BASADA EN EL SOFTWARE DECAWAVE O EL USO DEL SOFTWARE DECAWAVE. EN NINGÚN
CASO DECAWAVE SERÁ RESPONSABLE DE CUALQUIER DAÑO REAL, ESPECIAL, INCIDENTAL,
CONSECUENTE O INDIRECTO, CUALQUIERA QUE SEA CAUSADO, INCLUYENDO SIN
LIMITACIÓN A LA GENERALIDAD DE LO ANTERIOR, PÉRDIDA DE GANANCIAS ESPERADAS,
FONDO DE COMERCIO, REPUTACIÓN, RECIBOS O CONTRATOS COMERCIALES, COSTOS DE
ADQUISICIÓN DE BIENES SUSTITUTOS O
SERVICIOS; PÉRDIDA DE USO, DATOS O BENEFICIOS; O INTERRUPCIÓN DEL NEGOCIO),

PÉRDIDAS O GASTOS DERIVADOS DE RECLAMACIONES DE TERCEROS. ESTAS
LIMITACIONES SE APLICARÁN INDEPENDIENTEMENTE DE LA FORMA DE ACCIÓN, YA SEA
POR ESTATUTO, CONTRATO O AGRAVIO, INCLUYENDO NEGLIGENCIA O CUALQUIER OTRA
FORMA DE ACCIÓN, Y SI DECAWAVE HA SIDO ADVERTIDO O NO DE LA POSIBILIDAD DE
DICHOS DAÑOS QUE SURJAN DE CUALQUIER MANERA DEL SOFTWARE DECAWAVE O EL
USO DEL SOFTWARE DECAWAVE.
(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.
(12) Decawave se reserva el derecho de hacer correcciones, mejoras, mejoras y

otros cambios en su software, incluido el software Decawave, en cualquier momento.
Dirección postal: Decawave Ltd.,
cámaras de adelaida,
Calle Pedro,
Dublín D08 T6YA
IRLANDA.
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
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.
1.3 El módulo DWM1001 y RTLS
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 también incorpora el IC nRF52832 de Nordic Semiconductor que proporciona la conectividad

Bluetooth utilizada para la configuración y el microprocesador que ejecuta el firmware que controla el DW1000 y
proporciona la funcionalidad de habilitación RTLS. Una descripción más completa de esto se puede encontrar en
la sección 3.
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.
1.4 Más información
Puede encontrar información sobre el DWM1001 y los productos relacionados en la siguiente

documentación:
• 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)
• MDEK1001 (kit de desarrollo y evaluación)

o Resumen del producto MDEK1001
o Manual de usuario del sistema MDEK1001
o Guía de inicio rápido de MDEK1001 (en la caja)
o MDEK1001 Guía de código fuente del administrador de aplicaciones
• www.decawave.com

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.
Tabla 1: Resumen del rendimiento del sistema
Parámetro Descripción notas

Rendimiento del sistema RTLS
Precisión de ubicación XY <10 cm (típico) Línea de visión (LOS)
Capacidad del sistema/clúster 150 Hz 750 etiquetas a 0,2 Hz
150 etiquetas a 1 Hz
15 etiquetas a 10 Hz, etc.
máx. Ubicación Tasa / Etiqueta 10 Hz
Mín. Ubicación Tasa / Etiqueta N.º 0,0167 Hz cada 1 minuto
máx. de anclas (teóricas) Dependiente del área Ver apartado 5.1.1
máx. # Etiquetas / clúster (teórico) 9000 @ mín. tasa de 0.0167 Hz (cada 1
minuto)
Memoria disponible
Memoria flash disponible para el usuario 40kB
RAM disponible para el usuario 5kB
Rendimiento de datos
Etiquetas a la puerta de enlace Enlace ascendente o enlace descendente: cada etiqueta
(datos del sensor) 340 bytes por segundo
Anclas a la puerta de enlace Enlace ascendente:

cada ancla
(datos del sensor) 34 bytes por 12 s
Enlace descendente:
34 bytes por 12 s
Latencia del sistema 100ms De la etiqueta a la puerta de enlace
Cifrado Cifrado AES de tramas UWB Mutuamente excluyente con

BLE
Parámetros UWB
Canal UWB Canal 5 (6,5 GHz) Fijado
Velocidad de datos 6,81Mbps Fijado
PPR 64MHz 128 9 Fijado
Longitud del preámbulo Fijado
Código de preámbulo Fijado

3 ARQUITECTURA DEL SISTEMA OBJETIVO
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.
Los componentes principales de un sistema de este tipo son:

• Red DWM1001 de sistema de ubicación en tiempo real de alcance bidireccional (DRTLS):
o Una red UWB que consta de anclas y etiquetas basadas en el DWM1001
módulo.
o Una puerta de enlace para conectar las anclas y las etiquetas de la red UWB a la red IP más
amplia. Este consta de un DWM1001 configurado como nodo puente y un host Linux (por
ejemplo, Raspberry PI 3 modelo B)
o Configuración local y visualización a través de una aplicación Android o cliente Web
solicitud
• Infraestructura de backhaul, por ejemplo, Ethernet o Wi-Fi
• End Points (consumidor de datos):
o Clientes web DWM1001
o Clientes MQTT
o Tabletas/teléfonos inteligentes locales conectados por Bluetooth
Figura 1: Arquitectura del sistema de destino

3.1 Red DRTLS
3.2 DWM1001 Sistema de ubicación en tiempo real de alcance bidireccional (DRTLS)
Los componentes de la red DRTLS se muestran en la Figura 2. El DRTLS consta de:

• Varios dispositivos DWM1001 que se pueden configurar como un ancla, una etiqueta o un nodo de
puente en una puerta de enlace. Las etiquetas suelen ser móviles y anclas fijas en su lugar.
• Una unidad de puerta de enlace opcional, que contiene un módulo DWM1001 ("nodo puente"), que
conecta el sistema a la red exterior (LAN/WAN).
• Aplicaciones externas (PC/servidor y tableta/teléfono, por ejemplo, Decawave DRTLS
Manager) que se puede utilizar para instalar, poner en marcha y configurar el DRTLS. La ubicación
de la etiqueta se puede mostrar en la aplicación local (tableta) o en la aplicación remota.
El funcionamiento de la red DRTLS se describe en la Sección 4.
Figura 2: red DRTLS
3.3 Puerta de enlace
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 componentes del software de la puerta de enlace se muestran en la Figura 3.

La puerta de enlace consta de una combinación de componentes de software que se ejecutan en el
DWM1001-DEV o en el Raspberry Pi 3 Model B.
© Decawave 2018 OP-DWM1001-System-Deview-2.1 Pagina 12

Componente de software DWM1001-DEV:

• Cuando una unidad con firmware PANS se configura como nodo puente, actúa como puente entre la red
UWB y el host Linux. Recopila información sobre los anclajes circundantes, pasa los datos del enlace
descendente desde el host Linux a los anclajes o etiquetas y los datos del enlace ascendente desde los anclajes
y etiquetas al host Linux.
Los componentes del software Raspberry Pi 3 B son:

• módulo del núcleo de Linux
• Demonio DWM
• Proxy DWM
• Corredor MQTT
• Servidor HTTP
• Anfitrión de Linux
Figura 3: Componentes del software de puerta de enlace
3.4 Puntos finales
Los datos del sistema se visualizan a través de clientes Web, MQTT o Bluetooth.
3.4.1 Clientes web DWM1001
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.

Figura 4: maqueta de interfaz de cliente web
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.
3.4.2 Tabletas/teléfonos inteligentes locales conectados por Bluetooth
Figura 5: Configuración local y visualización en la aplicación de Android

4 RED DRTLS , CONFIGURACIÓN Y CONTROL
4.1 Operación de la red DRTLS
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
mensaje de enlace descendente tu D

L L
3ms
Figura 6: estructura de supertrama
4.2 Inicialización de la red
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

4.2.1 Criterios para la inscripción de anclas
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.
4.2.2 Proceso de registro
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.
Durante el proceso de registro pueden ocurrir los siguientes escenarios:

• Todos los anclajes en red que el anclaje que se une puede escuchar responderán con un
número de asiento (0 a 29), eso significa que el ancla de unión se conectó a la red recientemente y se
está reconectando. No sería necesario que se le asigne un nuevo asiento y puede continuar usando el
asiento anterior si todos los presentadores de la red respondieron con el mismo número. Si los números
de asiento respondidos no son los mismos, entonces el ancla que se une deberá elegir un asiento libre
(es decir, uno que no esté usando ninguno de los anclas de la red).
Si no hay un asiento libre disponible, el nuevo presentador no puede unirse a la red y tendrá que
esperar e intentar conectarse más tarde.
• Algunas anclas en red responderán con un número de asiento válido y algunas con el número de asiento
0xFF. El número de asiento 0xFF significa que esos anclajes aún no conocen el anclaje de unión. El
anclaje que se une deberá elegir un asiento libre (es decir, uno que no esté utilizando ninguno de los
anclajes en red).
• Algunas anclas en red no responden después del mensaje de solicitud de unión al clúster .
El ancla de unión los marcará como desaparecidos (es decir, fuera de rango). Cuando todos los
demás anclajes están bloqueados, puede elegir un asiento libre.

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.
4.3 Detección y resolución de colisiones de infraestructura
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.
4.4 Funcionamiento de un ancla conectada/ ancla-iniciador
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.
Al recibir el mensaje de solicitud de datos de actualización de firmware , el ancla proporcionará firmware

al dispositivo solicitante a través de UWB (si la actualización de firmware está habilitada), para obtener más
información sobre este proceso, consulte la sección 8.
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.
4.5 Funcionamiento de un nodo de puente/ pasarela
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].
4.6 Funcionamiento de una etiqueta
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
Por ejemplo, TWR

Etiqueta de modo
inactivo RX inactivo en la ranura inactivo
de respuesta
1
Por ejemplo, TWR

Etiqueta de modo despertarse
dormir en la ranura dormir
de bajo consumo arriba
1
Figura 7: Operación de etiqueta en modo de bajo consumo frente a modo de respuesta
Una etiqueta tiene dos modos de funcionamiento:

• Un modo de respuesta : después del intercambio de TWR, programará la próxima escucha
periodo de escucha de las Beacons de la supertrama en la que tiene reservado el slot de intercambio de TWR. El
DW1000 no se pondrá en su estado de bajo consumo, sino que permanecerá en estado inactivo (reloj en marcha). La
MCU nRF52832 estará en modo de suspensión si no se están ejecutando otras tareas en el módulo. Este modo se usa
normalmente si se requiere Bluetooth.
• Un modo de bajo consumo: después del intercambio de TWR, el DW1000 se pondrá en

DEEPSLEEP y se despertará antes del próximo intercambio de TWR. La MCU también se pondrá en suspensión con
otros componentes del módulo, excepto el RTC y el acelerómetro (si el acelerómetro está habilitado). El módulo está
en el modo de consumo de energía más bajo. No escuchará las balizas a menos que se mueva fuera del área en la
que están ubicadas las anclas con las que actualmente está midiendo. Una vez que abandone el área, la etiqueta
procederá con la reserva de espacios TWR como se describe a continuación en 4.7. con BLE

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).
4.7 Protocolo TWR y reserva de intervalos TWR
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
Figura 8: Supertrama que muestra tramas TWR
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).
4.8 Detección y resolución de colisiones TWR
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:
• Las anclas seleccionadas pueden estar fuera de rango

• Podría haber habido una colisión con otra etiqueta
• Podría haber habido detección de colisión en el lado del ancla
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.
4.9 Estrategia TWR de Tag
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).
Figura 9: Tags elección de anclajes para TWR

5 ESCALABILIDAD
5.1 Expansión del Sistema - Anclajes

La infraestructura de la red consiste en anclas-iniciadores y anclas. Toda la red utiliza un esquema
TDMA y, por lo tanto, todos los nodos de anclaje deben mantenerse sincronizados con el tiempo de
supertrama del iniciador para que puedan enviar en sus ranuras designadas.
La red utiliza técnicas de prevención de colisiones, detección de colisiones y resolución de colisiones.

Cada ancla obtiene un espacio/asiento BCN (4.2.2) y luego puede participar en la red y transmitir
mensajes Beacon y Almanac .
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

5.1.1 Reglas de escala
• A cada ancla se le debe asignar un número de asiento entre 0 y 29

• Ningún ancla puede escuchar 2 anclas con el mismo número de asiento
• Todos los nodos deben estar sincronizados con el tiempo de supertrama del iniciador
• El nivel de reloj máximo es 127
5.2 Limitaciones de instalación

5.2.1 Limitación 1: El número máximo de asientos de anclaje es 30
• 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)
• La implicación de esta restricción es que es mejor colocar anclas razonablemente lejos

separados para permitir la reutilización de los números de asiento, es decir, no sobrepoblar un solo espacio
con demasiadas anclas
5.2.2 Limitación 2: el número máximo de niveles de reloj es 127
• 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.

Figura 11:Escalado del DRTLS que muestra los niveles de reloj
5.3 Expansión del sistema – Etiquetas
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.
5.4 Coexistencia entre múltiples redes
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.
5.5 Cobertura y expansión de la red
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:
• El rango DWM1001 es de hasta 60 metros (punto a punto) para la mejor antena

orientación y con condiciones ideales de línea de visión. Dentro de un sistema RTLS, una etiqueta debe oscilar
con anclas en varias orientaciones, por lo que es probable que no se pueda alcanzar el alcance máximo. Para
garantizar un rendimiento fiable en una red, se recomienda utilizar un rango reducido entre anclajes.
• Para un mejor rendimiento, se recomienda espaciar los anclajes de 20 a 25 metros

separados cuando se colocan en una cuadrícula cuadrada. Esto equivale a una diagonal de 28 a 35 metros entre
anclajes opuestos.
• Para mejorar el rendimiento, se recomienda considerar un rango máximo de 30-
35 metros para pasarelas
• En caso de que no haya línea de visión, el espacio entre los nodos puede reducirse para garantizar una fuerte
calidad de la señal
• Todas las métricas anteriores son indicativas. Queda a discreción del usuario determinar la
intervalo correcto entre los nodos para alcanzar un rendimiento satisfactorio.
La Figura 12 es un ejemplo de una implementación de red de cuadrícula para condiciones de LOS moderadas.
Figura 12: Ejemplo de despliegue de red grid

6 LOCALIZACIÓN DEL MOTOR
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.

7 ESTRATEGIA DE GESTIÓN DE ENERGÍA
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
Figura 13: Componentes principales del sistema DWM1001
7.1 Control de gestión de energía de los componentes principales del sistema
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.
• Al registrarse con la tarea de administración de energía y notificarla mediante llamadas a la API
7.2 Fuentes de despertador
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.
7.3 Dos tasas de actualización de ubicación
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.

8 USO DE MEMORIA Y ACTUALIZACIÓN DE FIRMWARE
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.
Figura 14: Mapa de direcciones flash DWM1001
8.1 Actualización de firmware
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.
8.2 Actualización de firmware iniciada por Bluetooth
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".
8.3 Actualización de firmware a través de UWB
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.
8.4 Actualización manual del firmware
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.

9 APÉNDICE: FORMATOS DE MARCO
9.1 Trama IEEE 802.15.4
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.
Tabla 2: Estructura de la trama de datos IEEE 802.15.4
Campo Octetos Descripción
control de 2 Tal como se define en IEEE 802.15.4

fotogramas
Secuencia de 1 Módulo 256 número de secuencia

números
IDENTIFICADOR DE PAN 2 IDENTIFICACIÓN DE PAN
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
Comprobación de fotogramas 2 DW1000 FCS generados automáticamente

secuencia

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).
El encabezado y la carga útil de IEEE MAC se muestran en la Figura 15.
Índices de búfer de cuadro: 0, 1 2 3, 4 5, 6 7, 8 9 y más
2 octeto 1 octeto 2 octetos 2 octetos 2 octetos Variable # octetos 2 octetos
Cuadro Secuencia Destino Fuente

IDENTIFICADOR DE PAN
Carga útil SFC
Mando (FC) Número Dirección Dirección
0x41 0x88 0xF F 0xF F
Control de fotogramas (FC)
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
Marco de datos SEGUNDO PENDIENTE ACK 0 1 0 1

16 bits 16 bits
Figura 15: Formato de trama MAC IEEE 802.15.4, con, por ejemplo, dirección de transmisión y

9.1.1 Mensaje de baliza
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).
Descripción de octetos de campo de carga útil
ID de mensaje 1 0x10 - UWBMAC_FRM_TYPE_BCN
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:
• AUTOPOS: el posicionamiento automático está en progreso en toda la red, se

puede usar para ubicar automáticamente los anclajes en el rango del iniciador
• DAT_DL: los datos de enlace descendente se enviarán en esta

supertrama
• SVC_DL: la ranura de servicio en esta supertrama es de enlace descendente
• SVC_UL: la ranura de servicio en esta supertrama es de enlace ascendente
• INIT - el nodo es el iniciador
• BH: el nodo puede escuchar al menos un BN cercano

• EXT: cuando se establece, hay otro mensaje a continuación.
el mensaje de baliza, en la carga útil de la misma trama de datos IEEE
802.15.4; la longitud de la trama adicional se especifica en la carga útil
inmediatamente después del mensaje de baliza
• 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.
número SF 2 Número de supertrama utilizado para la sincronización.
Número de 1 Número de ranura del grupo ~ número de asiento

ranura del clúster
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
MIENTRAS TANTO 10 NONCE de la red actual utilizada para el cifrado/descifrado

9.1.2 Mensaje de solicitud de incorporación
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.
ID de mensaje 1 0x12 - UWBMAC_FRM_TYPE_CL_JOIN
Versión del 4 0xDE00002A = versión de hardware DWM1001.

hardware
Versión de 4 0x01010001 = 01.01.00.0.1 =

firmware Mayor.Menor.Parche.Reservado.Variante de firmware
Suma de 4 Suma de comprobación de firmware - CRC32

comprobación de firmware
Opciones 4 Mapa de bits que indica las capacidades del nodo
asiento del grupo 1 Solicitud de asiento de grupo
9.1.3 Mensaje de confirmación de incorporación
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.
ID de mensaje 1 0x13 - UWBMAC_FRM_TYPE_CL_JOIN_CFM
Dirección 2 Dirección bloqueada del nodo de unión
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

9.1.4 Mensaje de almanaque
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.
Octeto de campo de carga útil Descripción

s
ID de mensaje 1 0x23 - UWBMAC_FRM_TYPE_ALMA
MIENTRAS TANTO 10 Red NONCE utilizada para el cifrado/descifrado en el siguiente

período de cambio NONCE
Banderas 1 Indicadores especiales, por ejemplo, fuerza de actualización de firmware.
Versión de hardware 4 Versión de hardware del nodo emisor
Versión de firmware 4 Versión de firmware del nodo emisor
Firmware 1 tamaño 4 Firmware 1 tamaño del nodo emisor
Firmware 2 tamaño 4 Tamaño del firmware 2 del nodo emisor
Firmware 1 suma 4 Firmware 1 checksum del nodo emisor

de comprobación
Suma de 4 Firmware 2 suma de comprobación del nodo emisor

comprobación del firmware 2
ID de nodo 8 Dirección completa de 64 bits del nodo emisor
Opción de nodo 4 Mapa de bits que indica las capacidades del nodo
9.1.5 Mensaje de servicio
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.
Campo de carga útil Octetos Descripción
ID de mensaje 1 0x11 - UWBMAC_FRM_TYPE_SVC
Código 1 Código de servicio
Argc 1 Número de octetos de argumento
Argv 0-14 Argumentos

9.1.6 Mensaje de solicitud de datos de actualización de firmware
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.
ID de mensaje 1 0x21 - UWBMAC_FRM_TYPE_FWUP_DATA_REQ
Banderas 1 Banderas
Período de actualización 2 Período de actualización en ms
Dirección16 8 Máximo cuatro direcciones de 2 bytes de proveedores de firmware
Compensar 4 Solicitud de compensación de datos
Tamaño del firmware 4 Solicitud de tamaño de firmware
Suma de comprobación de firmware 4 Solicitud de suma de comprobación de firmware
9.1.7 Mensaje de datos de actualización de firmware
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.
ID de mensaje 1 0x22 - UWBMAC_FRM_TYPE_FWUP_DATA
Banderas 1 Banderas
Mapa de datos de ranura 2 Indicación en el mapa de la próxima ocupación de la ranura
Compensar 3 Compensación de firmware de los datos de envío
Longitud 1 Longitud de los datos de envío
Buffer 1-44 Contenido del búfer de firmware de envío

9.1.8 Mensaje de posición
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.
ID de mensaje 1 0x18 - UWBMAC_FRM_TYPE_POS
X 4 Coordenada X (de la posición del ancla), m
Y 4 Coordenada Y (de la posición del ancla), m
Z 4 Coordenada Z (de la posición del ancla), m
relleno 4 Relleno para el cifrado
9.1.9 Mensaje de encuesta de grupo
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.
ID de mensaje 1 0x30 - UWBMAC_FRM_TYPE_TWR_GRP_POLL
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.
Período de actualización 2 Solicitud de período de actualización en ms
Dirección 8 Cuatro direcciones de 16 bits de los anclajes para rango con
Secuencia de números 1 Número de secuencia TWR
Bandera estacionaria + 1 Factor de calidad de posición (bits 1-7), indicador estacionario en

Factor de calidad el bit 0 (si es 1, el dispositivo está estacionario).
X 4 Coordenada X en metros (de la última posición calculada)
Y 4 Coordenada Y en metros (de la última posición calculada)
Z 4 Coordenada Z en metros (de la última posición calculada)
Relleno 2 Relleno para el cifrado

9.1.10 Mensaje de respuesta
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.
Carga útil Octetos Descripción

Campo
ID de mensaje 1 0x31 - UWBMAC_FRM_TYPE_TWR_POLL
Banderas 1 TWR_FL_ECOLL_RSP- Colisión detectada en TWR

Respondedor
TWR_FL_ETYPE_RSP - Tipo de marco incorrecto en TWR
Respondedor
TWR_FL_IOT_DATA: los datos de IOT de enlace descendente seguirán al último
mensaje de respuesta
TWR_FL_ACK: reconocimiento de que el AN de rango tiene un BN dentro del rango
y que los datos de ubicación en el grupo
Es probable que la encuesta sea recibida por el BN
TWR_FL_BH: el respondedor indica que un BN está dentro del rango
TWR_FL_SL_CFM - Confirmación de la próxima ranura
Mapa de tragamonedas
2 Mapa que indica la próxima ocupación de la ranura
marca de tiempo del médico de cabecera

4 Recibir la marca de tiempo de la encuesta grupal
marca de tiempo R 4 Este mensaje (Respuesta) Marca de tiempo de TX
MIENTRAS TANTO 10 Red NONCE para el próximo ciclo de actualización

9.1.11 Mensaje de baliza de nodo de puente
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.

Campo
ID de mensaje 1 0x6A - UWBMAC_FRM_TYPE_BN_BCN
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.
Dirección 2 Dirección del nodo puente de unión
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
Contar 1 Número de direcciones de etiqueta (especificado a continuación)
Dirección de etiqueta 2xTID Una lista de direcciones de etiquetas de 2 bytes (máx. 15)
9.1.12 Mensaje de datos IOT
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.

Campo
ID de mensaje 1 0x63/0x65 - UWBMAC_FRM_TYPE_DL/UL_IOT_DATA
IDENTIFICACIÓN
2 Dirección de nodo (para UL puede ser TN/AN; para DL es la dirección del
nodo receptor)
Banderas 1 Bit 0 - Tasa de actualización: 0=Nominal 1=Estacionario

Bit 1: sobrescribir los datos escritos anteriormente
Bit 2 - Establecer si está en modo Tag
Bit 3 - Indicación de calidad del enlace: 0=mala 1=buena (para fines de enlace descendente, se usa solo entre
BN y KM)
Bit 4-7 - Tipo de datos
Frecuencia de actualización 2 Tasa de actualización del próximo ciclo
Longitud de datos 1 Longitud de datos IOT
Carga útil IOT 1-34 1-34 bytes: carga útil de datos IOT

10 REFERENCIAS
10.1 Listado
En el curso de este documento se hace referencia a los siguientes documentos:

Tabla 3: Tabla de Referencias
Referencia Autor Título de la versión

[1] onda deca [2] Resumen actual del producto DWM1001C
onda deca [3] Resumen actual del producto DWM1001-DEV
onda deca [4] Resumen actual del producto MDEK1001
onda deca [5] Manual de usuario actual de MDEK1001
onda deca [6] Guía del usuario actual del firmware DWM1001
onda deca DWM1001_Gateway_Quick_Deployment_Guide actual

11 HISTORIA DEL DOCUMENTO
11.1 Historial de revisiones
Tabla 4: Historial del documento
Revisión 2.1 Fecha Descripción

2.0 1.3 1.2 28 de septiembre de 2020 Actualizaciones según PANS R2.1
1.1 1.0 29 de marzo de 2019 Actualizaciones por software PANS R2
7 de julio de 2018 Cambio de logotipo
8 de mayo de 2018 Actualización para la versión 2 (alfa )
7 de febrero de 2018 Actualizaciones menores
18 de diciembre de 2017 Comunicado para publicación

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.

DWM1001 System Overview and Performance

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DWM1001 System Overview and Performance

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Descripción general del sistema DWM1001

Este documento está sujeto a cambios sin

© Decawave 2018 OP-DWM1001-System-Deview-2.1

Descripción general del sistema DWM1001

1. INTRODUCCIÓN................................................ .................................................... ...................8

1.1 VISIÓN GENERAL ............................................. .................................................... ..........................8

2 RENDIMIENTO RESUMEN ............................................... .................................................... .10

3 ARQUITECTURA DEL SISTEMA OBJETIVO ............................................... ............................................. 11

3.1 RED DRTLS.................................................... .................................................... ......................12

inteligentes conectados por Bluetooth local ........................... ........................14

4 RED DRTLS, CONFIGURACIÓN Y CONTROL ............................................... .................. 15

4.1 FUNCIONAMIENTO DE LA RED DRTLS ........................................... .................................................... .......15

5 ESCALABILIDAD .............................................. .................................................... ...................... 23

5.1 EXPANSIÓN DEL SISTEMA - ANCLAJES ............................................. .................................................... .....23

6 LOCALIZACIÓN DEL MOTOR ............................................... .................................................... ............. 27

7 ESTRATEGIA DE GESTIÓN DE ENERGÍA ............................................... .......................................... 28

8 USO DE LA MEMORIA Y ACTUALIZACIÓN DEL FIRMWARE .................................. ............................. 30

8.1 ACTUALIZACIÓN DEL FIRMWARE .................................... .................................................... ....................30

© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 2

Descripción general del sistema DWM1001

9 APÉNDICE: FORMATOS DE FOTOS ............................................... .................................................. 32

9.1 TRAMA IEEE 802.15.4 ............................................... .................................................... ....................32

9.1.1 Mensaje de baliza ............................................. .................................................... ...............34 9.1.2 Mensaje de solicitud de

puente.................................... .................................................... 40 9.1.12 Mensaje de datos

10 REFERENCIAS .............................................. .................................................... .................... 41

10.1 LISTADO................................................. .................................................... ...............................41

11 HISTORIA DEL DOCUMENTO ............................................... .................................................... ...... 42

11.1 HISTORIAL DE REVISIÓN .............................................. .................................................... ...............42

12 MÁS INFORMACIÓN.................................................... .................................................... .43

TABLA 1: RENDIMIENTO RESUMEN DEL SISTEMA ........................................... .................................................... ...10

TABLA 2: ESTRUCTURA DEL TRAMA DE DATOS IEEE 802.15.4 .................................. ..........................................32

TABLA 3: TABLA DE REFERENCIAS ........................................... .................................................... ....................41

FIGURA 1: ARQUITECTURA DEL SISTEMA OBJETIVO ........................................... .................................................... ......11

FIGURA 2: RED DRTLS ............................................... .................................................... ........................12

FIGURA 6: ESTRUCTURA DEL SUPERFRAME ........................................... .................................................... ..............dieciséis

FIGURA 8: SUPERFRAME QUE MUESTRA TWR FRAMES ........................................... ..........................................21

FIGURA 13: PRINCIPALES COMPONENTES DEL SISTEMA DWM1001 ........................................... ..........................................28

© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 3

Descripción general del sistema DWM1001

INFORMACIÓN DEL DOCUMENTO

Copyright © 2017 Decawave Ltd.

PÓLIZA DE SOPORTE VITAL

© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 4

Descripción general del sistema DWM1001

(2) El software Decawave se proporciona de las siguientes dos maneras: -

• Módulo de kernel de Linux de puerta de enlace DRTLS

© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 5

Descripción general del sistema DWM1001

(i) El kernel de Linux que se proporciona como código fuente en el paquete de

© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 6

Descripción general del sistema DWM1001

(9) EL SOFTWARE DECAWAVE SE PROPORCIONA "TAL CUAL". DECAWAVE NO OFRECE GARANTÍAS

(10) DECAWAVE NO SERÁ RESPONSABLE Y NO LO DEFENDERÁ O INDEMNIZARÁ CONTRA

SERVICIOS; PÉRDIDA DE USO, DATOS O BENEFICIOS; O INTERRUPCIÓN DEL NEGOCIO),

(12) Decawave se reserva el derecho de hacer correcciones, mejoras, mejoras y

Descripción general del sistema DWM1001

1.3 El módulo DWM1001 y RTLS

El módulo también incorpora el IC nRF52832 de Nordic Semiconductor que proporciona la conectividad

1.4 Más información

Puede encontrar información sobre el DWM1001 y los productos relacionados en la siguiente

Descripción general del sistema DWM1001

• MDEK1001 (kit de desarrollo y evaluación)

© Decawave 2018 OP-DWM1001-System-Deview-2.1 Página 9