• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 479 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352P: how to setup channel mask after integrating WB-DSSS into 802.15.4 collector/sensor based projects?

Zhiyong Li (FT)
Expert 2920 points
Part Number: CC1352P
Other Parts Discussed in Thread: CC1310, , CC1312R

Hi,

I am trying to get WB-DSSS to work with 15.4 stack based projects. So far I was able to integrate radio configurations from SmartRF Studio, and collect/sensor nodes can communicate with each other. I have two questions going forward:

1) Is there a way to sniff WB-DSSS packets? I have tried to use CC1310/1352P launchpads with the latest version of packet sniffer (v1.9), WB-DSSS doesn't seem to be listed as an option in Device Configuration in Sniff Agent. I suppose we can use SmartRF Studio and set it in continuous Packet RX mode. I was able to see quite a few packets this way, but they always have CRC error.

2) How do we setup channel mask? The default 15.4 stack settings uses narrow band, and each channel is only 200KHz apart from adjacent channels.WB-DSSS spreads much wider. Can we continue to use the same scheme for narrow band channels? Or the channel will always be fixed by the radio configurations exported from SmartRF Studio?

Please advise, thanks.

ZL

  • +1
    TI__Mastermind 20412 points

    Hi Zhiyong,

    Unfortunately, we do not have support for WB-DSSS on 15.4 stack. 

    1. We do not have a sniffer for it. Using smart RF studio to capture the raw data is probably the only way to sniff. 

    2. The issue is, the mac library has some timing calculations depending on the phy used. These calculations and code is provided as a library. Thus cannot be modified by the customer. So, unfortunately, the WB-DSSS Phy cannot be supported in the current sensor collector example. but supporting this phy is on the roadmap for the stack. Unfortunately, I cannot provide timelines for this.

    Regards,

    Sid

  • 0 in reply to Sid
    Expert 2920 points

    Hi Sid,

    Thanks for your reply.

    There are a handful of posts on this forum stating that we can manually import radio configurations from SmartRF Studio, one of them listed below.

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1029001/cc1352r-fcc-compliant-option-for-ti-15-4-stack

    The guy who did it in that post seems able to get WB-DSSS to work in 15.4 stack. My own experience so far is, 15.4 collect/sensor with modified phy from WB-DSSS can form network and communicate with each other. I assume the frequency will stay at the initial value set in the radio_config.c file. Are there any issues because of timing calculations you mentioned?

    It seems WB-DSSS support in 15.4 stack has been discussed as far as 5 years back. So I will assume it probably won't be officially available any time soon. Mybe we can hack together a version as a stopgap.

    Best,

    ZL

  • 0 in reply to Zhiyong Li (FT)
    TI__Mastermind 20412 points

    Hi Zhiyong,

    If you have got it to work with imported settings, that is really good.

    I haven't dug deep into this , but the timing in the lower MAC is calculated on the data rate of the Phy. For example, the wait before you expect an acknowledge etc.  

    Are you able to set the reporting, polling intervals etc and are able to get packet transmission without issues? If this is the case, it is worth testing this hack of importing just the settings and using the 50kbps Phy. 

    Zhiyong Li (FT) said:
    Are there any issues because of timing calculations you mentioned?

    Regards,

    Sid

  • 0 in reply to Sid
    Expert 2920 points

    Hi Sid,

    Again thanks for your response.

    Sid said:
    but the timing in the lower MAC is calculated on the data rate of the Phy. For example, the wait before you expect an acknowledge etc.  

    I would say everything works for all practical purposes except that, occasionally a node would join a network but unable to send or receive data to/from collector. When this happens, a restart of the sensor node usually gets data sending/receiving to work. The status codes from callback sometimes are 0xE9 which may be related to the timing calculation you mentioned, but sometimes the status codes are just 0x00(success). Because I only observed this with customized CC1312R boards while the collector is based on CC1352P. I tend to think this is more likely a problem of CC1312R boards themselves. We will have a larger batch of CC1352P boards coming in soon, and will see how they work.

    I am trying to use WB-DSSS 1:1 240kbps because when background noise is factored in, the increased sensitivity of DSSS=1:8 or Long-Range-Mode doesn't really help much at all. Since the timing calculation in MAC is based on data rate of phy, should I switch from 50kbps to 200kbps, because 200kbps is closer to the 240kbps in WB-DSSS=1:1?

    Best,

    ZL

  • +1 in reply to Zhiyong Li (FT)
    TI__Mastermind 20412 points

    HI Zhiyong,

    Increasing the data rate to 200 should improve the performance with respect to the timing calculations and also the channel BW.

    Since this is a configuration that we have not provided in the SDK, these need to be tested heavily. 

    Regards,

    Sid

  • 0 in reply to Sid
    Expert 2920 points

    Hi Sid,

    I agree with you this needs to heavily tested. So far there are indeed a few issues, at least when 50kbps is selected in syscfg. I will see if 200kbps will mitigate/fix those issues.

    Best,

    ZL

  • 0 in reply to Sid
    Expert 2920 points

    With two CC1352P-launchpad only feet away and TX power set at 20dBm, 4 -10% packets fail to send from sensor to collector when WB-DSSS phy is used for 2-GFSK-200kbps in 15.4 stack. When LRM or FH mode is used, the failure rate is less than 1 in 10K packets.

    I guess we will have to wait until official support for WB-DSSS in 15.4 stack. Hopefully that will be available soon.