Contiki: Perguntas sobre o processo de sincronização do EB no STM32-S2LP

Criado em 1 nov. 2018 · 10Comentários · Fonte: contiki-os/contiki

Olá
Estou trabalhando em TSCH para rádio STM32-S2LP. S2LP é a versão mais recente do Spirit1 que está na base de código contiki.
Estou tendo alguns problemas com a sincronização do nó com o coordenador. Eu tenho o coordenador enviando EBs a cada 35 segundos (uma escolha aleatória). Chego a um ponto em que o nó recebe e analisa o EB do coordenador. Abaixo está o arquivo de log do nó. Eu adicionei uma impressão de depuração para a carga útil para ver o que está sendo transmitido.

a carga útil é 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: associação: pacote recebido (37 bytes) no canal 0
TSCH: parse_eb: sem agendamento, configurando agendamento mínimo
TSCH-schedule: add_slotframe 0 300
Cronograma TSCH: add_link 0 15 1 0 0 255
TSCH: fonte de tempo de atualização: 0 -> 89
TSCH: associação concluída, sec 0, PAN ID abcd, asn-0.258, jp 1, timeslot id 0, hopping id 0, slotframe len 0 com 0 links, de 0c:00:f3:ff:ef:a6:10:59

Pergunta- Presumo que não haja agendamento no EB porque o coordenador ainda não sabe se há nós na área. Estou certo aqui?

Após a associação, vejo o seguinte no log do nó

Fila TSCH: o pacote é adicionado put_index=0, packet=0x20002d04
TSCH: envia pacote para 89 com seqno 1, queue 0 1, len 21 21
TSCH: enviando KA para 89

Pergunta- O que é um sinal de manter vivo porque não vejo nada no meu analisador de espectro quando isso acontece. Isso é enviado com transmissão UC para o coordenador?

Continuando com o arquivo de log, vejo o seguinte para o nó. Novamente eu adicionei alguns debug para a carga útil.

a carga útil logo antes do xmission é 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:Espírito1: preparação 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

Então aqui eu acho, ele perdeu alguns slots de transmissão, mas finalmente envia com sucesso uma mensagem Unicast para 89 (coordenador).

Agora, quando a mensagem UC é enviada, vejo o seguinte no arquivo de log do coordenador

Receptor escutando mensagens.
SINCRONIZAR
RECEBIDO
Spirit1: sondado
LEIA EM
A carga útil do EB logo após o recebimento é 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:
LEIA

Infelizmente depois disso, o coordenador não parece estar usando esses dados em nenhum sentido. Ele ignora a mensagem e retoma para enviar mais EBs no ar. Depois de algum tempo o nó se desassocia da rede e depois de receber outro EB repete o processo acima.

Verifiquei o código e vi que a única maneira de os arquivos TSCH analisarem dados é quando há algo no buffer de anel de recebimento que é verificado na função "tsch_rx_process_pending()"
ou quando "tsch_scan" é chamado.
tsch_scan é chamado apenas por um nó e o buffer de anel parece ser preenchido apenas se a função tech_rx_slot() for gerada pelo tsch_slot_operation(). tsch_slot_operation está sendo agendado apenas usando um rtimer para um slot tx.

Pergunta - Não tenho certeza de como fazer o coordenador processar esta mensagem unicast do nó. Eu apenas codifico nos arquivos de driver de rádio para preencher o buffer de anel ou há algo a ser adicionado aos arquivos tsch. Ou estou perdendo alguma coisa aqui?

última pergunta - Este é o processo normal de junção de um nó ao coordenador? Uma vez que o coordenador processa a mensagem unicast, ele enviará novamente outra mensagem unicast para o nó com um agendamento e slots nos quais ele deve se comunicar?

Eu olhei para esta página da web https://tools.ietf.org para obter informações sobre a operação do TSCH.

Eu apreciaria qualquer informação para obter alguma visão aqui.
Obrigado

Fonte

ragbagger16

Todos 10 comentários

Alguns comentários aqui :-

Nem o ST nem a comunidade implementaram suporte para TSCH na plataforma spirit1.
A ST atualizou seu design de referência baseado em Cube em seu site com suporte S2LP, mas ainda não suporta TSCH, nem eles enviaram as atualizações de volta para o GitHub.
A maior parte da comunidade mudou-se para o Contiki-NG, que abandonou completamente o suporte à plataforma ST.

Você terá dificuldade em encontrar suporte para isso, mas talvez @atiselsts possa ter algo a dizer em geral sobre o processo de associação/junção do TSCH.

firmwareguru em 1 nov. 2018

Em relação à sincronização de tempo no TSCH:

Um nó envia uma mensagem KA (keep alive) para sua fonte de tempo (pai RPL) sempre que:
- Junta-se ao DODAG
- Ele muda seu pai preferido
- Após um tempo limite (4 segundos por padrão)
A mensagem KA na verdade é um pacote de dados IEEE 802.15.4 (23 bytes de cabeçalho + 0 bytes de carga útil), quando o nó fonte de tempo recebe um KA de seu filho, ele responde um ACK. O nó filho recebe ACK, calcula o timestamp recebido e ressincroniza com sua fonte de tempo. Este processo é a sincronização adaptativa.

p/s: lembre-se de que o TSCH usa vários canais, portanto, alguma ferramenta de análise pode ser configurada para capturar em um único canal, portanto, não funciona.

hieunq95 em 22 nov. 2018

Está linha:

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

sinaliza que há um problema com o tempo. Você está perdendo a transmissão por 944 - 100 = 844 ticks. A menos que os tiques do rtimer sejam muito curtos, isso é muito tempo. Pode ser após o término do intervalo de tempo quando o pacote é finalmente enviado. Se você estiver imprimindo o pacote inteiro antes de enviá-lo, não é surpresa. O TSCH é sensível ao tempo e o UART é lento - imprimir coisas enquanto / antes de fazer a operação do TSCH interferirá em seus horários.

atiselsts em 29 nov. 2018

👍1

Em relação à sincronização de tempo no TSCH:
Um nó envia uma mensagem KA (keep alive) para sua fonte de tempo (pai RPL) sempre que:
Junta-se ao DODAG
Ele muda seu pai preferido
Após um tempo limite (4 segundos por padrão)
A mensagem KA na verdade é um pacote de dados IEEE 802.15.4 (23 bytes de cabeçalho + 0 bytes de carga útil), quando o nó fonte de tempo recebe um KA de seu filho, ele responde um ACK. O nó filho recebe ACK, calcula o timestamp recebido e ressincroniza com sua fonte de tempo. Este processo é a sincronização adaptativa.
p/s: lembre-se de que o TSCH usa vários canais, portanto, alguma ferramenta de análise pode ser configurada para capturar em um único canal, portanto, não funciona.

Olá Hieu Nguyen,
Eu sou um novato e estava tentando entender como o timestamp é calculado. Por favor, ajude-me de você pode responder algumas perguntas sobre timestamp e pacote ieee 802.15.4.

O cabeçalho do pacote de origem de tempo ieee 802.15.4 contém o timestamp quando envia o ACK?
Se sim, então o que o carimbo de data/hora representa? início do pacote etc?
Acho que o timestamp do quadro transmitido está sendo usado aqui, certo?
Existe uma maneira de adicionar este carimbo de data/hora do quadro transmitido ao meu pacote transmitido se o rádio não suportar isso?

TayyabaZainab0807 em 6 fev. 2019

@TayyabaZainab0807 O cabeçalho IEEE 802.15.4 não contém as informações de timestamp, o timestamp é calculado localmente em cada nó usando seu próprio timer. Você pode encontrar a referência em documentos padrão IEEE.

ieee-standard-for-local-and-metropolitan-area-networkspart-154-l.pdf

hieunq95 em 6 fev. 2019

👍1

@TayyabaZainab0807 você pode executar o TSCH no Cooja e extrair todos os pacotes para o arquivo pcap, então você pode usar o Wireshark para ver a estrutura de cada pacote

hieunq95 em 6 fev. 2019

Então o timestamp no nó filho contém quando o pacote foi recebido neste lado filho? E é calculado localmente?

TayyabaZainab0807 em 6 fev. 2019

@TayyabaZainab0807 sim, é.

hieunq95 em 6 fev. 2019

Na verdade, estou confuso sobre a sincronização de tempo ... se o carimbo de data/hora no nó filho capturar a hora em que um pacote é recebido na fila rx .. e se a fonte de tempo não anexar seu carimbo de data/hora ao pacote, então como o nó filho obtém sua sincronização de relógio em relação ao nó pai usando apenas sua hora local?

TayyabaZainab0807 em 6 fev. 2019

@TayyabaZainab0807
Desculpe a resposta errada à sua pergunta, revisei o documento e encontrei isso, você pode encontrá-lo na seção "5.1.4.2a.2 Sincronização de nós" no documento que enviei acima.