CC1352P: interoperability of 802.15.4 Stack radios built with SDK v7.x and CC1310 radios built with SDK v4.x

Hi Mr. Lange,

Thanks for your reply and sorry for getting back to you late.

We were able to track down the problem, we introduced some bug when porting some feature back to SDK v4 based sensor radios.

I did try SDK v8.30 right after it was released. I was hoping to see complete support for WB-DSSS and 900MHz for ZStack. I guess we will have to wait a little longer.

Best,

ZL

Hi ZL, 

There swill unfortunately not be any Sub-Ghz Zigbee support included with future Z-Stack development as part of the SimpleLink F2 SDK.

Regards,
Ryan

Hi Mr. Brown,

Thanks for the update. Any ETA on full support of WB-DSSS in 15.4 stack? For all practical purpose, WB-DSSS already works well for our application (with some work around). Just curious.

On a side note, do you guys have any benchmark on network stability of 15.4 stack radios in frequency hopping mode between SDK v4, v7 and v8? When we started with v4 SDK and CC1310 radios. sensor nodes drop off network once in a few days. After replacing CC1310 collector radio with CC13x2/SDK v7.41, those same set of CC1310 radios only drop off once in a few weeks. So quite some improvement. I am not quite sure whether such improvement is attributed to SDK itself, the revisions we made to application firmware, or the extra RAM on CC13x2 radios.

Over the years, I stumbled onto several posts reporting sensor nodes in FH mode drop off network randomly. I am curious if you guys have some internal data on this.

Best,

ZL

Hi ZL,

the TI15.4 Stack supports WB-DSSS as custom PHY. That means we have not verified it individually but you can use it.
You can explore this using SysConfig -> TI 15.4 Stack -> Radio -> Custom Phy -> then select in Custom PHY Radio Configuration one of the WB-DSSS options.

We have tested the 15.4 Stack in a Large Network setup but all devices were running the same SDK. You can find the data here: https://www.ti.com/lit/swra782

In general what you describe might be related to any kind of clock offset especially when using sleepy nodes. 
If you have more detailed data on what operations the sensors perform and how communication happens we could look for optimization points.
One for example would be to turn off the broadcasting if it is not used by your application which eliminates one wake-up slot.

Kind regards,
Theo

Hi Mr. Lange,

Thanks for the pointer to swra782, I haven't read that one before. I briefly went through it and don't see any mention about sensor nodes dropping off network over long period of time, particularly in FH mode. Did I miss it?

Sensor nodes dropping off network was our primary concern when we started with CC1310/90 + SDK v4. Because once a sensor node drops off network, it will need to consume considerable amount of power to rejoin network. If it happens too often, then the battery life will be reduced significantly. We are still testing CC13x2 based radios, but so far the results are very encouraging.

We use CC13XX radios both as network processors(based on collector/sensor example with customized AT command system) and standalone application processor. We have already turned off broadcasting by setting broadcasting dwell time to 0 in FH mode. All sensor nodes are configured as sleepy devices and wakes every 60 seconds to poll for data, wake up to send data as needed. Is there other parameters that we can tweak to improve stability (in the sense that sensor nodes don't drop off network)?

Motivated by the above issue in FH mode, we actually started to explore WB-DSSS mode before SDK v7.4 which started to support WB-DSSS in 15.4 stack as customized phy. We hacked settings exported from RF studio into ti_radio_config.c and got some quite good results.

Best,

ZL

Hi ZL,

we haven't experienced this in the test setup but you can see numbers for expected package loss for different network setups.

There is a few things to explore for improving stability. 
1. When the sensor wakes up to send data as needed
      - Does this happen using the reporting interval? 
      - Do you send the message as confirmable message?

2. Do you have more information which communication leads to the nodes dropping the network? Is it resending or acknowledgement timeout?

Modifying the ti_radio_config.c to use WB-DSSS is basically the same as SysConfig does. Only that the settings that you select with custom PHY WB-DSSS are the ones our radio team specified.

Kind regards,
Theo

Hi Mr. Lange,

To answer your questions:

1) When sensor node works as network processor, when to send out message to collector is decided by external MCU. If sensor node succeeds in sending message, it will send out a confirmation to external MCU. In this sense, the messages are confirmable.

2) Sensor nodes dropping off network is determined by either an orphan state is detected or failure to receive application layer heartbeat messages from collector node for extended period of time (3X expected interval). This seems completely random. I don't think it is caused by sending out messages to collector.

Best,

ZL

Hi ZL,

thank you for the additional details.

The sensor will enter orphan state when it does not receive an acknowledgement of the message by the collector.
This is why I asked if the message is sent as  confirmable message from sensor to collector.
If you send a message do you set: dataReq.txOptions.ack = true; ?
If yes you can check which not received acknowledge causes the transition to orphan state and check if you can see a pattern after it happened multiple times.

When you say that an external MCU communicates to the radio MCU. Cam you explain me how this communication is implemented? How do you send data out from the CC1352/CC1310?
I would like to ensure that the implementation does not interfere with the TI15.4 Stack scheduling.

What do you mean by the heartbeat message? Can you explain me how you use it?

Kind regards,
Theo