EB synchronization process questions on STM32-S2LP

[ragbagger16]

Hello
I am working on TSCH for STM32-S2LP radio. S2LP is the latest version of Spirit1 which is on contiki code base.
I'm having some issues with the node synchronizing with the co-ordinator. I have the coordinator sending EBs every 35 seconds (a random pick). I get to a point where the node receives and parses the EB from the co-ordinator. Below is the log file from the node. I added a debug printout for the payload so see what is being transmitted.

payload is 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: association: received packet (37 bytes) on channel 0
TSCH: parse_eb: no schedule, setting up minimal schedule
TSCH-schedule: add_slotframe 0 300
TSCH-schedule: add_link 0 15 1 0 0 255
TSCH: update time source: 0 -> 89
TSCH: association done, sec 0, PAN ID abcd, asn-0.258, jp 1, timeslot id 0, hopping id 0, slotframe len 0 with 0 links, from 0c:00:f3:ff:ef:a6:10:59

Question- I assume there is no schedule in the EB because the coordinator still does not know if there are any nodes in the area. Am I correct here?

After association, I see the following in the node log

TSCH-queue: packet is added put_index=0, packet=0x20002d04
TSCH: send packet to 89 with seqno 1, queue 0 1, len 21 21
TSCH: sending KA to 89

Question- What is a keep alive signal because I do not see anything on my spectrum analyzer when this comes up. Is this sent with UC broadcast to the coordinator?

Continuing with the log file, I see the following for the node. Again I added some debug for the payload.

payload just before xmission is 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: prep 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

So here I guess, it has missed a few transmit slots but finally successfully sends a Unicast message to 89 (coordinator).

Now when the UC message is sent, I see the following in the log file of the coordinator

Receiver listening for messages.
SYNC
RECEIVED
Spirit1: polled
READ IN
EB payload right after receiving is 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:
READ OUT

Unfortunately after this, the coordinator does not seem to be using this data in any sense. It ignores the message and resumes to send more EBs in the air. After sometime the node disassociates to the network and then after receiving another EB repeats the above process.

I checked the code and saw that the only way TSCH files can parse data is when there is any thing in the receive ring buffer which is checked in the function "tsch_rx_process_pending()"
or when "tsch_scan" is called.
tsch_scan is called only by a node and the ring buffer seems to be populated only if tech_rx_slot() function is spawned by the tsch_slot_operation(). tsch_slot_operation is only being scheduled using an rtimer for a tx slot.

Question - I am not sure how to make the co-ordinator process this unicast message from the node. Do I just hard code it in the radio driver files to fill in the ring buffer or is there something to be added to the tsch files. Or am I missing something else here?

last question - Is this the normal join process of a node to the coordinator? Once the coordinator processes the unicast message, it will again send another unicast message to the node with a schedule and slots in which it is supposed to communicate?

I looked into this webpage https://tools.ietf.org to get information about TSCH operation.

I would appreciate any information to gain some insight here.
Thanks

[firmwareguru]

A few comments here :-

1. Neither ST nor the community implemented support for TSCH in the spirit1 platform.
2. ST did update their Cube-based reference design from their website with S2LP support, but it still does not support TSCH, nor did they push the updates back to GitHub.
3. Most of the community has moved to Contiki-NG, which has dropped ST platform support altogether.

You'll be hard-pressed finding support for this, but perhaps @atiselsts might have something to say in general about the TSCH association/join process.

[hieunq95]

Regarding the time synchronization in TSCH:

1. A node sends a KA (keep alive) message to its time source (RPL parent) whenever:

• It joins the DODAG
• It switches its preferred parent
• After a timeout (4 seconds by default)

2. KA message actually is IEEE 802.15.4 Data packet (23 header bytes + 0 bytes payload), when time source node receives a KA from its child, it replies back an ACK. The child node receives ACK, calculates the received timestamp and re-synchronize with its time source. This process is adaptive synchronization.

p/s: keep in mind that TSCH using multiple channels so some analyzer tool just might be set up to capture on a single channel, thus it doesn't work.

[atiselsts]

This line:

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

signals that there's a problem with the timing. You missing the transmission by 944 - 100 = 844 ticks. Unless the rtimer ticks are very short, that is a lot of time. It might be after the end of the timeslot when the packet is finally sent. If you're printing the whole packet before sending it it's no surprise. TSCH is time sensitive and UART is slow - printing stuff while / before doing TSCH operation will interfere with their timings.

[TayyabaZainab0807]

Regarding the time synchronization in TSCH:

1. A node sends a KA (keep alive) message to its time source (RPL parent) whenever:

• It joins the DODAG
• It switches its preferred parent
• After a timeout (4 seconds by default)

1. KA message actually is IEEE 802.15.4 Data packet (23 header bytes + 0 bytes payload), when time source node receives a KA from its child, it replies back an ACK. The child node receives ACK, calculates the received timestamp and re-synchronize with its time source. This process is adaptive synchronization.

p/s: keep in mind that TSCH using multiple channels so some analyzer tool just might be set up to capture on a single channel, thus it doesn't work.

Hi Hieu Nguyen,
I am a newbie and I was trying to understand how timestamp is calculate. Kindly help me out of you can answer few questions regarding timestamp and ieee 802.15.4 packet.

• Does the ieee 802.15.4 time source packet header contains the timestamp when it sends the ACK?
• If yes then what does the timestamp represent? start of the packet etc?
• I guess Timestamp of transmitted frame is being used here, right?
  Is there a way that I can add this Timestamp of transmitted frame to my transmitted packet if the radio doesn't support this?

[hieunq95]

@TayyabaZainab0807 The IEEE 802.15.4 header does not contain the timestamp information, the timestamp is computed locally in each nodes by using their own timer. You can find the reference in IEEE standard documents.

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

[hieunq95]

@TayyabaZainab0807 you can run TSCH on Cooja and extract all packets to pcap file, then you can use Wireshark to see each packets' structure

[TayyabaZainab0807]

So timestamp at child node contains when the packet was recieved at this child side? And is calculated locally?

[hieunq95]

@TayyabaZainab0807 yes, it is.

[TayyabaZainab0807]

I am actually confused about the time synchronization...if timestamp at child node capture the time at which a packet is received in rx queue..and if time source does not attach it's timestamp to the packet then how child node get its clock sync with respect to parent node by only using its local time?

[hieunq95]

@TayyabaZainab0807
Very sorry for the wrong answer to your question, I've revised the document and found this, you can find it in section "5.1.4.2a.2 Node synchronization" in the document I'd sent you above.