TSCH CC1312 interop with other platforms

[andresblanco06]

While testing interoperability I found that some other vender bit reverse the payload. The CC1312 does not do this at the radio level and was causing problems when trying to communicate between devices.

There is an override that can be added to the radio to do this, and when we do it we can finally sniff the packets as they should be sent.

Problem is that we cannot establish a network connection between platforms.
After applying the override:
CC1312 leaf node no longer joins CC1312 coordinator
Another vendor’s board as leaf node still joins CC1312 coordinator, however, ping from Linux host through slip interface no longer works

When two CC1312 boards try to form a network, the leaf node finds the parent but soon loses it. This repeats indefinitely.

[WARN: RPL       ] just joined, no parent yet, setting timer for leaving
[WARN: RPL       ] found parent: fe80::212:4b00:1e17:7a8f, staying in DAG
[WARN: RPL       ] local repair (DAO max rtx)
[WARN: RPL       ] no parent, scheduling periodic DIS, will leave if no parent is found
[WARN: RPL       ] found parent: fe80::212:4b00:1e17:7a8f, staying in DAG
[WARN: RPL       ] local repair (DAO max rtx)
[WARN: RPL       ] no parent, scheduling periodic DIS, will leave if no parent is found

[atiselsts]

Can you clarify which other vendor you mean?

One of the approaches must be wrong. Standards exist for this reason, and reverse bit ordering means incompatibility with standard. If Contiki-NG Simplelink platform orders the bits incorrectly on CC1312 ships, it should be fixed; otherwise there is little to do.

Other problems may exist, as indicated by the CC1312/CC1312 communication problems. Just to make sure, you are using the right frequency band for the boards you have? (e.g. 868 in Europe, 915 in the States)

[andresblanco06]

I cannot say what other vender it is.

I can push in a fix to the propmode.c overrides to fix the bit reversal to match what the standard says, but this will basically cause this other issue I am talking about.

Until I find a fix and I am able to have a stable connection between same devices and interop between other vendors I will not suggest the fix.

Yes, I am 100% sure that they are in the same band and freq.

[g-oikonomou]

Following a couple of discussions offline:

It appears as though we are transmitting the payload part of .4g PHY packets in the wrong bit order.

According to the spec, the PHR needs transmitted MS bit first, whereas the payload needs to be LS bit first. This means that we need to present the PHR to the radio using the bit order of the system CPU, but we need to invert the bit order of the payload.

This affects:

• CC13x2 radio prop mode in the simplelink port
• CC13x0 radio prop mode in both the cc26x0-cc13x0 and simplelink ports
• I have not checked, but I am almost certain that it also affects our CC1200 radio driver, which I am pretty certain has been interop-tested with the cc26x0-cc13x0 port.

Based on my current (limited) understanding of this topic, what we need to do is,:

• Enable the aforementioned override for cc13x2
• Invert payload bits in s/w for all other drivers/ports

Ping @simonduq for info

[simonduq]

Just adding for reference, this is documented on cc13x2 in the TRM:
https://www.ti.com/lit/ug/swcu185d/swcu185d.pdf?ts=1600702551585&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FCC1352R

Section 25.10.5.2.1 IEEE 802.15.4g Packet Format:
"The IEEE 802.15.4g PHY header must be presented MSB first to the RF Core. In IEEE
802.15.4g specification, the payload part is LSb first, however the payload length info in
physical layer header (PHR) is MSb first. This means that the payload needs to be flipped in
the System CPU. This can be achieved with the System CPU assembly instruction RBIT."

As far as I was able to evaluate, our PHY header is correct, but all the follows (PHY payload) is bit-inverted: all bytes come in the expected order but have their bits swapped from LSb to MSb.

[g-oikonomou]

Perhaps stating the obvious, but my understanding is that we need to change both the TX as well as the RX path.

[OSYSTEMAB]

Any update on this?
It is a show stopper preventing Contiki-NG communication with other 802.15.4 stacks.
/Ola

[joakimeriksson]

Just adding for reference, this is documented on cc13x2 in the TRM: https://www.ti.com/lit/ug/swcu185d/swcu185d.pdf?ts=1600702551585&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FCC1352R

Section 25.10.5.2.1 IEEE 802.15.4g Packet Format: "The IEEE 802.15.4g PHY header must be presented MSB first to the RF Core. In IEEE 802.15.4g specification, the payload part is LSb first, however the payload length info in physical layer header (PHR) is MSb first. This means that the payload needs to be flipped in the System CPU. This can be achieved with the System CPU assembly instruction RBIT."

As far as I was able to evaluate, our PHY header is correct, but all the follows (PHY payload) is bit-inverted: all bytes come in the expected order but have their bits swapped from LSb to MSb.

I guess that means that we should NOT use the built-in feature that will do bit-reverse on the CC13xx? I did look at some other configurations of the radio - and the Wi-Sun config seems to use that bit-reverse feature.

[joakimeriksson]

I did a few tests with bit reverse via the built-in bit-reverse feature of the CC13xx series - but yes - it will also bit reverse the header bytes, which means that we need to bit reverse only all other bytes. I did try that, and the TI Radiosniffer seems to receive the packets again then - with better "data" in the 802.15.4 header (e.g. correct PANID, etc).

[joakimeriksson]

I have a branch here that improves what is coming into TI RF Sniffer software - correct headers, etc. But I will do more testing to confirm that two CC1352R1 also work with both bit-orders (in, for example RPL-UDP or some other simplistic example). https://github.com/joakimeriksson/contiki-ng/tree/bitrev-cc13xx

[OSYSTEMAB]

As far as I can tell from testing with the TI stack, as well as the ported bitreverse for ST Nucleo-boards the bitrev-cc13xx is working. We'll continue integration and testing using the bitrev-cc13xx branch
Thanks for the rapid work!
/Ola

I have a branch here that improves what is coming into TI RF Sniffer software - correct headers, etc. But I will do more testing to confirm that two CC1352R1 also work with both bit-orders (in, for example RPL-UDP or some other simplistic example). https://github.com/joakimeriksson/contiki-ng/tree/bitrev-cc13xx