CC1352P7: WISUN Stack PA & Discovery

Hi Bhautik,

1. The 15.4 MAC APIs are not intended to be used here, but theoretically, the Wi-SUN nodes, do send out PAN Advertisements and Pan control messages, so it is aware of MAC level neighbours. But at this stage, using MAC APIs has not been looked into yet.

2. Unfortunately, we do not have simulation tool available.

3. Will consult HW apps and get back to you.

4. CC1310 + CC1190 setup in Smart RF studio, today allows as setting of up to 26dbm , if that is what you are looking for.

5. This is from the Wi-SUN specification. Please refer to the Wi-sun specification document provided by Wi-SUN alliance for these parameters. There are fixed Phys that are supported by the spec. Thus when you select the Phy id, the Phy properties are auto populated.

6. Yes, you need to select the channels that you want to have. (Deselect the last two channels in SysConfig. 

7. SmartRF studio in continuous RX mode can be used for this.

The Wi-SUN OAD application can be used as a reference for this. The MTU of Wi-SUN is 1576 bytes. But in Wi-SUN OAD, block sizes of up to 1024 bytes has been tested.

https://dev.ti.com/tirex/explore/node?node=A__AA5buegAW2cisulIU2.tTg__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK_WISUNFAN_MODULE__BSEc4rl__LATEST

9. If you are asking for compression algorithms, we do not have any example in the SDK.

10. We do not currently have DLMS client support on the roadmap for CC13xx devices.

Regards,
Sid

Hi Sid,

     Please find my in-lined further queries.

1. It is crucial needs for us, to have the neighbor discovery while we do the deployment, can there be any reference/example set (without the release) with which we can have a work-around? and is there any roadmap on this to support it with WiSUN?
2. is there any plan to support on such tools? which can help in deployment or simulation or visualization or optimization of network?

    
    Additionality can we know the future roadmap of TI with respect to the WISUN solution. (ex. above kind of features/tools etc. made available?) 

Hi Bhautik,

I am curious, at what stage do you need the neighbor information? When you deploy the nodes and they form a network, there is a way to get the neighbor information.

Please check the ns_coap_node example, you can see the fetch_neighbor_details() function as a reference.

I see you have raised an issue with wfantund in another thread. So I assume you have evaluated the wisun web app. There you can

1. View the network topology,

2. Health of each link,

3. Test latencies between Border Router and deployed nodes with Pings.

4. Send CoAP requests to the deployed nodes. 

What other features were you looking for specifically?

Ideally, the Wi-SUN stack itself takes care of the network optimization by finding the best routes to the border router. So, I want to know what specific features you are interested in.

We are improving the user experience of our Wi-SUN stack and developing new features, it would be interesting to know what tools you are referring to.  

Regards,
Sid

HI Sid,

     For Ex. We are starting the deployment in field. And consider that there is no BR in field. And BR will be installed in later stage. (After all the RF are installed in field).

    Now let's say RN1 we installed, then when we install RN2, at that time we want to know that RN1 & RN2 both are able to detect themselves or not. similarly we will expand the field deployment by checking that currently installed RN is able to detect the nearby RN.

    If we will be having an info above at application layer then it will be smooth deployment for us.

    For the Other tools, we raised that thread with TI's indian support/sales team to discuss it with BU team.

    (Yes we have evaluated the current webapp, but it handles the one BR only).  What i think is network simulator, joining time simulator etc those kind of tools can be very handy. As in scenario of bootstrapping of mbed tls, when at power reboot of GRID all the node will join the network at a time and at that time we might feels that because of too many transaction (mbed/tls) it might take significant time or crash.(if we consider 1:250 or 1:300 ratio).



Regards,
TheMat

Hi Sid,

 On top of above.

Just want your confirmation on the understanding of the muxing for the PA use.

Simply we just need to use the

GPIO_setMux(DIO_LNA, IOC_PORT_RFC_GPO0)
GPIO_setMux(DIO_PA, IOC_PORT_RFC_GPO1).

is that right understanding?

Hi Bhautik,

Yes, the GPIO_setMux APIs are correct to route the PA, LNA signals to GPIO.

With the following, feature. I want to understand it better. During deployment, you want two specific router nodes to talk or any router nodes in the area? 

Should the message transfer be MAC address based (since you won't have IP till the wisun network is formed). Or do you want to do a simple Packet TX Packet RX between two deployed nodes?

Bhautik Ramoliya said:

  Now let's say RN1 we installed, then when we install RN2, at that time we want to know that RN1 & RN2 both are able to detect themselves or not. similarly we will expand the field deployment by checking that currently installed RN is able to detect the nearby RN.

Regards,

Sid

Hi Sid,

 1) For PA/LNA, i see that there are total RFC GPO, [RFC_GPO0,RFC_GPO1,RFC_GPO2,RFC_GPO3],  may be because of subGHZ & 2.4GHz both? . So how i can know which RFC GPO mapped to subGHz lines?

 2) Neighbor Discovery :-
  - During deployment or so , we ideally do not want both the RN to talk each other or needs to have the IPv6 or So. Our Aim is to know that currently installed RN is able to detect "any" nearby RN or not. (we just want detection only, that's it). As it eases our deployment process and the team can have the checklist that during installation there are any blank spot or not. (If currently being installed RN is not able to detect any other nearby RN then simply we are considering that as a blank spot). And in this practice there is high chance that there won't be BR installed at the time of installation of RN.

  Please let me know if any more query/doubt/suggestions on above.

regards

Hi Bhautik,

This is the section of the User's guide that is relevant to you. 

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_10_02_23/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/signal-routing.html

The GPO0 and GPO1 are the signals that have the LNA and PA signals. This works for the Sub1/2.4 TX. 

GPO3 and GPO3's default mapping and additional conditions can be found in that section of the user guide mentioned in the link.

2. If you just need the discovery like the way you mentioned it, it must be possible to implement a packet TX, packet RX routine based on the rfPacketTx and rfPacketRx examples we have, possibly the wi-sun network name could be transmitted and received by other nodes. 

dev.ti.com/.../node

Regards,

Sid

Hi Sid,

  1) Ok, i got it.

  2)  Do you mean that rfpacketTx & rfPacketRx will work along with the WISUN RN firmware? (as i said we need discovery of the RN, I meant "WiSUN RN Node"). Basically how we can achieve discovery in the current given WISUN RN examples. (as we want to have the discovery feature in the WISUN RN), so that we don't required to have 2 firmware.

regards

Hi Bhautik,

Bhautik Ramoliya said:

2)  Do you mean that rfpacketTx & rfPacketRx will work along with the WISUN RN firmware? (as i said we need discovery of the RN, I meant "WiSUN RN Node"). Basically how we can achieve discovery in the current given WISUN RN examples.

A simple radio TX and RX should be possible on the application layer which runs without bringing up the wisun stack. The feature does not exist in the default WiSUN RN that is available in the SDK, but it should be possible to implement another thread.

Regards,

Sid