CC1312R7: Silicon X Texas WiSUN BZ phy config interoperability problems

Hi Thiago,

We also noticed this and will fix it in the next SDK.

In the mean while you can change the sysconfig files in the following way to allo the channel map up to 129 channels. (This is based on SimpleLink F2 SDK version 7.41.)

--- a/source/ti/ti_wisunfan/.meta/rf_config/ti_wisunfan_rf_config_common.js
+++ b/source/ti/ti_wisunfan/.meta/rf_config/ti_wisunfan_rf_config_common.js
@@ -630,7 +630,7 @@ const phyMap_updated2 = {
             "2": {
                 ChanPlanID: {
                     "1": {
-                        TotalNumChan: 90,
+                        TotalNumChan: 129,
                         ChanPlanName: "902_928_200",
                         ChanCenterFreq0: 902.2,
                         ChanSpacing: 200,
@@ -643,7 +643,7 @@ const phyMap_updated2 = {
             "3": {
                 ChanPlanID: {
                     "1": {
-                        TotalNumChan: 90,
+                        TotalNumChan: 129,
                         ChanPlanName: "902_928_200",
                         ChanCenterFreq0: 902.2,
                         ChanSpacing: 200,
@@ -656,7 +656,7 @@ const phyMap_updated2 = {
             "5": {
                 ChanPlanID: {
                     "2": {
-                        TotalNumChan: 43,
+                        TotalNumChan: 64,
                         ChanPlanName: "902_928_400",
                         ChanCenterFreq0: 902.4,
                         ChanSpacing: 400,
@@ -669,7 +669,7 @@ const phyMap_updated2 = {
             "6": {
                 ChanPlanID: {
                     "2": {
-                        TotalNumChan: 43,
+                        TotalNumChan: 64,
                         ChanPlanName: "902_928_400",
                         ChanCenterFreq0: 902.4,
                         ChanSpacing: 400,
@@ -682,7 +682,7 @@ const phyMap_updated2 = {
             "8": {
                 ChanPlanID: {
                     "3": {
-                        TotalNumChan: 28,
+                        TotalNumChan: 42,
                         ChanPlanName: "902_928_600",
                         ChanCenterFreq0: 902.6,
                         ChanSpacing: 600,
@@ -695,7 +695,7 @@ const phyMap_updated2 = {
             "Custom": {
                 ChanPlanID: {
                     "Custom": {
-                        TotalNumChan: 90,
+                        TotalNumChan: 129,
                         ChanPlanName: "902_928_200",
                         ChanCenterFreq0: 902.2,
                         ChanSpacing: 200,

Cheers,

Marie

Hi Marie,
Changing the total number of channels indeed makes the phy use the rest of the spectrum, however, the interoperability performance issues still remain for some reason.

Here is a sample of the packet capture:



The log generated by silicon's BR is the same, it can't continue and keep up with the connection process.

Thanks in advance,
Thiago

Hi Thiago,

1. How are you capturing this sniffer log? Since Wi-SUN is a frequency hopping network, using one device to sniff will only give you what's happening on one channel.

2. If you set the TI device, SiLabs device and sniffer device to all just use one channel (the same channel), are they still not able to connect? Can you post this sniffer log? (Is it a security configuration mismatch, e.g. different certificates?)

3. In the IT Wi-SUN project we have a log that you can enable that would be interesting to take a look at. Please open Project -> Properties -> Build -> ARM Compiler ->Predefined Symbols. Then comment out the "EXCLUDE_TRACE" symbol.

Cheers,

Marie H

Hi Marie,

1. Silicon's RCP daemon configuration file is integrated with wireshark captures, as presented in the image below. I'm using it to sniff packets received by the border router.
(1)




2. I'm having problems setting up Silicon's device to fixed channel mode because the async channel apparently can't be configured to use only the channel of choice (in my case, channel 0). Also, I think because of that, both devices can't connect. Security certificates shouldn't be the problem here, since I configured TI's node to use Silicon's certificates and both devices can form a network in the default NA config for FAN 1.0 (the configuration made for TI's node is presented on images 4-6)

(2)


(3)


(4)


(5)


(6)


3. I commented out the EXCLUDE_TRACE to see TI's Logs, didn't know about that, thanks. I will proceed to make more tests using it

Thanks in advance,
Thiago

Hi Thiago,

Let us know of the results you get with the EXCLUDE_TRACE modification.

Regards,

Arthur

Hi Arthur and Marie,

I've made some initial tests using the EXCLUDE_TRACE modification, and apparently, after some time of both devices trying to form a network, the communication becomes unreliable and the packet transaction is restarted. The problem shouldn't be something about the security certificates because I've made tests with the other 3 phys. Basically, the only ones that work as expected on both ends (TI and SiLabs) without further customization are NA and EU. JP has a problem similar to BZ when ARIB regulation is activated on SiLab's end. Here are some images of the results:

EU:










(Works exactly like  NA)

JP w/ARIB enabled on SiLabs:






(At this point the communication basically restarts, with the device starting to resend PAN Advert Solicits)


The same behavior can be observed on BZ (even with the changes suggested to the syscfg):


JP without ARIB:







I think there is something wrong specifically with the BZ phy that prevents it from performing well with other WiSUN solutions. I'm actually out of ideas of what else I could try, but later I will be sending some  images of SiLabs BZ's RF config, for comparison.

Thanks in advance,
Thiago

Hi Thiago,

Thank you for posting the additional information.

From what you posted it seems like everything is fine as long as you use EU or NA region.

Can you try capturing a sniffer log with the TI packet sniffer? 

https://www.ti.com/tool/PACKET-SNIFFER

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ti_wisunfan/html/wisun-guide/debugging-index.html#packet-sniffer

Cheers,

Marie H

Hi Marie.

I work with Thiago and as mentioned by him in previous messages, setting a the Silicon BR and TI EP to the same fixed channel does not work well, they don't even connect to each other. Thus, we can't really setup the sniffer, because it requires a fixed channel to be set. Any other suggestions based on what was already posted?

Regards,

Mauricio.

Hi Mauricio, Thiago,

Sorry for the delayed response.

Can you capture a PAN Advertisement (PA) or PA Solicit (PAS) packet from the SiLabs device? Then we can cross check with our settings.

Cheers,

Marie H

Hi Marie,

I setup two silabs devices with fan1.0 and BZ region. I was able to capture the BR packets with wsbrd, but it only captured a PAN Configuration Solicit from the silabs node (the one ending with address 235b). The other nodes are ti wisun nodes which should be ignored, as they are using different certificates. Here is the .pcapng capture file: https://drive.google.com/file/d/1QY1NhweVpVYq00z2WsSFsitqwzdOh8MM/view?usp=sharing

Regards,

Mauricio.

Hi Mauricio,

Not sure I understand which packet you mean since I can't see any device with the address you mentioned. The only PAN Configuration Solicit package is this one, is it from the SiLabs device?

Cheers,

Marie H

Hi Marie,

Yes, that is the packet I mentioned. I thought for sure the packet had that address. Sorry for the inconvenience.

Regards,

Mauricio.

Hi Marie.

We have asked Silicon Labs about this in their forums. If anyone else is interested here is the link: https://community.silabs.com/s/question/0D5Vm00000F7HupKAF/problems-observed-with-interoperability-between-sis-wisun-and-texas-instruments-using-bz-phy-config-for-fan-10?language=en_US

Regards,

Maurício.

Hi Marie.

It seems like Silicon Labs does not set the Excluded Channels for BZ in the US-IEs, but TI does set the Excluded channels as [26-64]. And according to Silabs interpretation of US-IEs, 'BZ' mode US-IEs MUST NOT contain 'Excluded Channels [26-64]', because these are already excluded by the selection of the BZ 'Regulatory Domain'. The following figure shows their comment, which is in the link of my previous comment.

Regards,

Mauricio.