• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 55 subscribers
  • Views 1231 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.

LAUNCHXL-CC1310: 802.15.4 Non-Beacon mode no longer works as of Simplelink SDK 1.00.00.13

Steve Sims
Prodigy 180 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Hello,

We're developing a system whereby the 802.15.4 devices have non-replaceable alkaline batteries and the PAN coordinator will be mains powered. Additionally our sensors will be mobile and only within range of a PAN for around 10 minutes per day. As such, we're trying to use the non-beacon mode of 802.15.4 to maximise the battery life of our sensors. In the previous 802.15.4 stack, we had non-beacon mode working however as we've migrated to the new Simplelink v1 SDK, we can no longer get non-beacon mode to work.

Our sensor is based on the Simplelink V1 sensor example and we have attempted to enable non-beacon mode through the following changes:

config.h:

#define CONFIG_SECURE false        /* So that we can view data messages using the packet sniffer */
#define CONFIG_PAN_ID 0xffff
/* snip */
#define CONFIG_BEACON_ORDER 15
#define CONFIG_SUPERFRAME_ORDER 15
/* snip */
#define CONFIG_CHANNEL_PAGE (APIMAC_CHANNEL_PAGE_9)
#define CONFIG_PHY_ID (APIMAC_STD_ETSI_863_PHY_3)

features.h

#define FEATURE_ALL_MODES

By implementing the ScanCnfCallback, we noted that the first 2 scan results returned a status of ApiMac_status_unsupportedSecurity, the next ~30 returned a status of ApiMac_status_noBeacon and every subsequent scan results in a status of ApiMac_status_noResources.

We've verified that there are no packets being captured on the packet sniffer (that works fine in beacon mode) and the spectrum analyser (albeit with an antenna and not a cable directly in) doesn't appear to be picking anything up either.

Has anybody managed to get the CC1310 Simplelink V1 stack working in non-beacon mode? If so what are we missing from our config?

Thanks,

Steve

  • 0
    TI__Expert 4375 points

    Hey Steve,


    Can you confirm CONFIG_SECURE is false both on the sensor and collector?

    The stack returns ApiMac_status_unsupportedSecurity when a packet's frame control indicates security enabled, but the stack is configured with no security.


    ~Brocklobsta

  • 0 in reply to Brocklobsta
    Prodigy 180 points

    Hi Brocklobsta,

    Thanks for your response, I can confirm that CONFIG_SECURE is false on the sensor and config-secure inside collector.cfg is also set to false.

    On the packet sniffer, we don't actually see any beacon requests being sent by the sensor and consequently no beacons being returned by the collector so I'm not sure where the source of the ApiMac_status_unsupportedSecurity status in the scan callback comes from but due to the lack of beacons I assume that it must be generated internally by the sensor's stack?

    Thanks,

    Steve

  • 0 in reply to Steve Sims
    TI__Expert 4375 points
    if the file nv-simulation.bin is present, then configurations are loaded from that instead of the .cfg. You can confirm if security is enabled or disabled from the web gui.

    ~Brocklobsta
  • 0 in reply to Brocklobsta
    Prodigy 180 points
    We removed the NodeJS application and now drive the linux collector (and launchpad coprocessor) directly through a linux socket in our Python application so we no longer have access to the web console.

    I can see from collector.cfg however that load-nv-sim = true so perhaps it's loading default NV settings with security enabled after all? I'm not at the office now (it's nearly 9pm here in the UK) but I'll check when I'm back in on Monday and try with load-nv-sim = false and config-security = false as well.

    Thanks for your help and enjoy your weekend!

    Steve
  • 0 in reply to Brocklobsta
    TI__Expert 4375 points
    Steve,
    So your saying there is no traffic OTA?
  • 0 in reply to Brocklobsta
    TI__Genius 10650 points
    nv-simulation.bin is not part of the gatway (nodejs) application, it is part of the collector application. So previous network configuration getting loaded may be the case as Brocklobsta suggested. If you want to preserve network information over power cycle, the keep load-nv-sim=true in the .cfg file and delete the nv-simulation.bin file one time before starting the collector application. If not, you can set the load-nv-sim = false.
  • 0 in reply to Brocklobsta
    Prodigy 180 points
    Correct, there's no beacon request from the sensor and, as the collector's also in Non-beacon mode, it's not sending beacons autonomously. In the sensor firmware, the scan callback is invoked with the various statuses mentioned in the first post - most worryingly is that eventually the callback status seems to indicate that the sensor has run out of resources (memory leak somewhere?). The reason it's worrying is that our sensor will be out of range of the collector for most of the day and only back within range for up to 10 minutes.
  • 0 in reply to Suyash Jain
    Prodigy 180 points
    Hi Suyash,

    Thanks, I thought that might be the case - we have it running on a Raspberry Pi back in the office so I'm only looking at source control remotely from home. I'll have a look on Monday and ensure that .bin is gone. I have a feeling that this isn't the problem however as when changing the beacon and superframe order params to put the collector into non-beacon mode, the collector ceases to send beacons so it appears as though collector.cfg is being read. I'll give it a go anyway.

    Thanks,

    Steve
  • 0 in reply to Steve Sims
    Prodigy 180 points

    Hello Brocklobsta and Suyash,

    It's all pretty confusing, the nv-sim switch didn't make any difference except that we then had real difficulty getting a sensor to associate as the collector didn't seem to want to ack any more. We also tried our configuration params (e.g. ETSI PHY) with the stock Sensor example from SDK 1.00.00.13 in non-beacon mode and that works fine. We've diff'd what we think are the important source files between our modified sensor and the working example sensor application and can't see any differences that look to be important (we've mostly just removed some of the higher level protocol parts of Sensor (such as the reporting of stats etc.).

    The only other major difference we spotted was that we've had to switch on optimisation for size in order to fit everything onto the CC1310. Perhaps something in the optimisation has affected an important configuration parameter or piece of code (we've tried different optimisation levels to no avail) or perhaps there's something we've changed elsewhere that's caused it to not send out beacons. Either way, it appears to be unique to our application and not something generic so we'll keep plugging away at it and in parallel look at developing a proprietary MAC using Easylink (or the proprietary RF drivers) that may be more appropriate to our system architecture whereby sensors are out of range for an extended period of time.

    Thank you both for your help,

    Steve