Contiki: Preguntas sobre el proceso de sincronización de EB en STM32-S2LP

Creado en 1 nov. 2018 · 10Comentarios · Fuente: contiki-os/contiki

Hola
Estoy trabajando en TSCH para radio STM32-S2LP. S2LP es la última versión de Spirit1 que se basa en código contiki.
Tengo algunos problemas con la sincronización del nodo con el coordinador. Tengo al coordinador enviando EB cada 35 segundos (una selección aleatoria). Llego a un punto donde el nodo recibe y analiza el EB del coordinador. A continuación se muestra el archivo de registro del nodo. Agregué una impresión de depuración para la carga útil para ver qué se está transmitiendo.

la carga útil es 00:EB:CD:AB:FF:FF:CD:AB:59:10:A6:EF:FF:F3:00:0C:00:3F:11:88:06:1A:58:02: 00:00:00:00:01:1C:00:01:C8:00:01:1B:00:
TSCH: asociación: paquete recibido (37 bytes) en el canal 0
TSCH: parse_eb: sin horario, configurando un horario mínimo
Horario TSCH: add_slotframe 0 300
Horario TSCH: add_link 0 15 1 0 0 255
TSCH: fuente de tiempo de actualización: 0 -> 89
TSCH: asociación realizada, sec 0, PAN ID abcd, asn-0.258, jp 1, timelot id 0, hopping id 0, slotframe len 0 con 0 enlaces, desde 0c:00:f3:ff:ef:a6:10:59

Pregunta- Supongo que no hay horario en la EB porque el coordinador aún no sabe si hay algún nodo en el área. ¿Estoy en lo correcto aquí?

Después de la asociación, veo lo siguiente en el registro del nodo

TSCH-queue: se agrega el paquete put_index=0, paquete=0x20002d04
TSCH: enviar paquete a 89 con seqno 1, cola 0 1, len 21 21
TSCH: enviando KA al 89

Pregunta: ¿Qué es una señal de mantenimiento de vida porque no veo nada en mi analizador de espectro cuando aparece? ¿Esto se envía con difusión UC al coordinador?

Continuando con el archivo de registro, veo lo siguiente para el nodo. Nuevamente agregué algo de depuración para la carga útil.

la carga útil justo antes de xmission es 01:E9:CD:AB:FF:FF:CD:AB:C2:0E:3D:F1:FF:F5:00:0A:7A:3B:3A:1A:9B:00:69 :21:00:00:Spirit1: preparación 26

TSCH: {asn-0.384 link-0-300-0-0 ch-0} !dl-miss TxBeforeTx 944 100
TSCH: {asn-0.384 link-0-300-0-0 ch-0} !dl-miss TxBeforeAck 2370 268
TSCH: {asn-0.384 link-0-300-0-0 ch-0} uc-1-0 21 tx 89, st 2-1

Entonces aquí, supongo, ha perdido algunas ranuras de transmisión, pero finalmente envía con éxito un mensaje Unicast a 89 (coordinador).

Ahora cuando se envía el mensaje de UC, veo lo siguiente en el archivo de registro del coordinador

Receptor escuchando mensajes.
SINCRONIZAR
RECIBIÓ
Spirit1: sondeado
LEER EN
La carga útil de EB justo después de recibir es 01:E9:CD:AB:FF:FF:CD:AB:C2:0E:3D:F1:FF:F5:00:0A:7A:3B:3A:1A:9B:00: 69:21:00:
LEER

Lamentablemente, después de esto, el coordinador no parece estar utilizando estos datos en ningún sentido. Ignora el mensaje y continúa enviando más EB al aire. Después de algún tiempo, el nodo se desvincula de la red y luego, después de recibir otro EB, repite el proceso anterior.

Revisé el código y vi que la única forma en que los archivos TSCH pueden analizar datos es cuando hay algo en el búfer de anillo de recepción que está marcado en la función "tsch_rx_process_pending()"
o cuando se llama "tsch_scan".
tsch_scan es llamado solo por un nodo y el búfer de anillo parece estar poblado solo si la función tech_rx_slot() es generada por tsch_slot_operation(). tsch_slot_operation solo se programa mediante un rtimer para una ranura tx.

Pregunta: no estoy seguro de cómo hacer que el coordinador procese este mensaje de unidifusión desde el nodo. ¿Simplemente lo codifico en los archivos del controlador de radio para completar el búfer de anillo o hay algo que agregar a los archivos tsch? ¿O me estoy perdiendo algo más aquí?

última pregunta: ¿es este el proceso normal de unión de un nodo al coordinador? Una vez que el coordinador procese el mensaje de unidifusión, volverá a enviar otro mensaje de unidifusión al nodo con un horario y espacios en los que se supone que debe comunicarse.

Busqué en esta página web https://tools.ietf.org para obtener información sobre el funcionamiento de TSCH.

Agradecería cualquier información para obtener una idea aquí.
Gracias

Fuente

ragbagger16

Todos 10 comentarios

Algunos comentarios aquí: -

Ni ST ni la comunidad implementaron soporte para TSCH en la plataforma spirit1.
ST actualizó su diseño de referencia basado en Cube desde su sitio web con soporte S2LP, pero aún no es compatible con TSCH, ni enviaron las actualizaciones a GitHub.
La mayor parte de la comunidad se ha mudado a Contiki-NG, que ha eliminado por completo el soporte de la plataforma ST.

Será difícil encontrar apoyo para esto, pero tal vez @atiselsts podría tener algo que decir en general sobre el proceso de unión/asociación de TSCH.

firmwareguru en 1 nov. 2018

Respecto a la sincronización horaria en TSCH:

Un nodo envía un mensaje KA (mantener vivo) a su fuente de tiempo (principal RPL) siempre que:
- Se une al DODAG
- Cambia su padre preferido
- Después de un tiempo de espera (4 segundos por defecto)
El mensaje KA en realidad es un paquete de datos IEEE 802.15.4 (23 bytes de encabezado + 0 bytes de carga útil), cuando el nodo de fuente de tiempo recibe un KA de su hijo, responde un ACK. El nodo secundario recibe ACK, calcula la marca de tiempo recibida y vuelve a sincronizar con su fuente de tiempo. Este proceso es sincronización adaptativa.

p / s: tenga en cuenta que TSCH usa múltiples canales, por lo que alguna herramienta de análisis podría configurarse para capturar en un solo canal, por lo tanto, no funciona.

hieunq95 en 22 nov. 2018

Esta línea:

TSCH: {asn-0.384 link-0-300-0-0 ch-0} !dl-miss TxBeforeTx 944 100

indica que hay un problema con el tiempo. Te estás perdiendo la transmisión por 944 - 100 = 844 ticks. A menos que los tictacs del rtimer sean muy cortos, es mucho tiempo. Puede ser después del final del intervalo de tiempo cuando finalmente se envía el paquete. Si está imprimiendo todo el paquete antes de enviarlo, no es ninguna sorpresa. TSCH es sensible al tiempo y UART es lento: imprimir cosas mientras / antes de realizar la operación TSCH interferirá con sus tiempos.

atiselsts en 29 nov. 2018

👍1

Respecto a la sincronización horaria en TSCH:
Un nodo envía un mensaje KA (mantener vivo) a su fuente de tiempo (principal RPL) siempre que:
Se une al DODAG
Cambia su padre preferido
Después de un tiempo de espera (4 segundos por defecto)
El mensaje KA en realidad es un paquete de datos IEEE 802.15.4 (23 bytes de encabezado + 0 bytes de carga útil), cuando el nodo de fuente de tiempo recibe un KA de su hijo, responde un ACK. El nodo secundario recibe ACK, calcula la marca de tiempo recibida y vuelve a sincronizar con su fuente de tiempo. Este proceso es sincronización adaptativa.
p / s: tenga en cuenta que TSCH usa múltiples canales, por lo que alguna herramienta de análisis podría configurarse para capturar en un solo canal, por lo tanto, no funciona.

Hola Hieu Nguyen,
Soy un novato y estaba tratando de entender cómo se calcula la marca de tiempo. Por favor, ayúdenme a responder algunas preguntas sobre la marca de tiempo y el paquete ieee 802.15.4.

¿El encabezado del paquete de fuente de tiempo ieee 802.15.4 contiene la marca de tiempo cuando envía el ACK?
En caso afirmativo, ¿qué representa la marca de tiempo? comienzo del paquete, etc.?
Supongo que la marca de tiempo del cuadro transmitido se está utilizando aquí, ¿verdad?
¿Hay alguna manera de que pueda agregar esta marca de tiempo del marco transmitido a mi paquete transmitido si la radio no lo admite?

TayyabaZainab0807 en 6 feb. 2019

@TayyabaZainab0807 El encabezado IEEE 802.15.4 no contiene la información de la marca de tiempo, la marca de tiempo se calcula localmente en cada nodo mediante su propio temporizador. Puede encontrar la referencia en los documentos estándar IEEE.

ieee-estándar-para-redes-de-área-local-y-metropolitana parte-154-l.pdf

hieunq95 en 6 feb. 2019

👍1

@TayyabaZainab0807 puede ejecutar TSCH en Cooja y extraer todos los paquetes al archivo pcap, luego puede usar Wireshark para ver la estructura de cada paquete

hieunq95 en 6 feb. 2019

Entonces, ¿la marca de tiempo en el nodo secundario contiene cuándo se recibió el paquete en este lado secundario? ¿Y se calcula localmente?

TayyabaZainab0807 en 6 feb. 2019

@ TayyabaZainab0807 sí, lo es.

hieunq95 en 6 feb. 2019

De hecho, estoy confundido acerca de la sincronización de tiempo ... si la marca de tiempo en el nodo secundario captura la hora en que se recibe un paquete en la cola rx ... y si la fuente de tiempo no adjunta su marca de tiempo al paquete, entonces cómo el nodo secundario obtiene su sincronización de reloj con respecto al nodo principal usando solo su hora local?

TayyabaZainab0807 en 6 feb. 2019

@TayyabaZainab0807
Lamento mucho la respuesta incorrecta a su pregunta, revisé el documento y encontré esto, puede encontrarlo en la sección "5.1.4.2a.2 Sincronización de nodos" en el documento que le envié anteriormente.