• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 56 subscribers
  • Views 1219 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.

RTOS/LAUNCHXL-CC26X2R1: CC2652 as end node of Xbee 802.15.4 coordinator

Vicente Gavara
Prodigy 30 points
Part Number: LAUNCHXL-CC26X2R1

Tool/software: TI-RTOS

Hi all. After three days fighting to allow a CC2652 joining to a 802.15.4 network coordinated by a Digi Xbee S1 Pro 802.15.4 module, I surrender. I would like to share my tests and configurations in order to help other people that tried a similar approach, maybe they were more lucky.

First, I took as base the 802.15.4 sensor example that comes with the SDK (2.30.00.34, the latest version supported by my launchpad). In the config.h I modify:

  • CONFIG_SECURE = false to disable encryption

  • CONFIG_PAN_ID = 0x0001 to match with the PAN ID of the coordinator

  • CONFIG_CHANNEL_MASK to match with the channels in witch the coordinator tries to create a network. I've tested several values here, but in order to generalize, the value 0xF0 in the second byte (channels 12 to 15) and 0xFF in the third byte (channels 16 to 23) covers all the range of a Xbee S1 Pro 802.15.4 (it doesn't operate on channels 11 and 24-26).

On the Xbee S1 Pro side, with Coordinator firmware, the configuration is this (just relevant parameters documented):

  • Coordinator association (A2) mask set to 0x6, indicating that the coordinator will establish the network in the best of the enabled channels (read on) and that the coordinator allow association of end nodes
  • Coordinator enable (CE) set to 1 : Module working as coordinator
  • Encryption enable (EE) set to 0: Encryption disabled
  • Mac Mode (MM) set to 2: Module working on legacy 802.15.4 with ACKs enabled
  • Network address (MY) set to 0: The coordinator address will be the address 0
  • PAN identifier (ID) set to 0x0001
  • Scan channels (SC) set to 0x200, meaning that the coordinator will try to establish the network only on channel 20. Several combinations have been tested here in order to allow more channels, though, but this channel seems to be free since the coordinator tends to select it.

Behavior of the modules has been different, depending on I don't know what:

  • The first time I tried, the CC6252 joined the network, after a while it left and then it never joined again. That means that, in the terminal, the module shows "State changed: 1" (joining, i guess) and it does nothing.
  • When arriving to the previous state, the module never joins to the network. It is necessary loading other programs (examples as the PWM led or the 802.15.4 collector) and then after re-loading the sensor program, the module joins some times (showing the proper messages in the console, reacting properly when the coordinator is powered of... everything normal). But then again, when the module starts to fail joining, it enters in a state of not joining that only can be stopped by reloading other programs (and that approach not always works, to be sincere)
  • Best results were achieved when I limited the module to only work on channel 20, doing the same on the coordinator. In that state, the module worked perfectly during 24 hours, allowing me to receive the periodic reads from the coordinator side.
  • Last tries has been quite dissapoining though: The module says that it is joined but the coordinator does not receive data, neither incrementing the Rx counters nor showing radio signal activity in the channel... something as if the module was saying that it is sending data but it is really not doing it. I've checked that the module tries to send that data to the destination node 0, that is the address of the coordinator

So, as you can see, many tests with disappointing results. The most disgusting is when the module becomes unable to join. Is it possible that some information regarding the last connection was stored on flash and that was the cause of entering on that state?

I hope that this information was useful for people trying to follow my approach, or even if somebody has any suggestion about how to proceed it will be really welcome.

  • 0
    TI__Mastermind 22916 points

    Hello Vicente,

    I am not sure how this Xbee coordinator is implemented, but lets walk through this and try to fix your problem.

    • The first time I tried, the CC6252 joined the network, after a while it left and then it never joined again. That means that, in the terminal, the module shows "State changed: 1" (joining, i guess) and it does nothing.

      This looks like the sensor found a coordinator to connect to and sent a request to join but has not heard back from the coordinator. By any chance, does this coordinator switch channels? Or does it stay in one channel listening?

    • When arriving to the previous state, the module never joins to the network. It is necessary loading other programs (examples as the PWM led or the 802.15.4 collector) and then after re-loading the sensor program, the module joins some times (showing the proper messages in the console, reacting properly when the coordinator is powered of... everything normal). But then again, when the module starts to fail joining, it enters in a state of not joining that only can be stopped by reloading other programs (and that approach not always works, to be sincere)

      This is because once the sensor finds a coordinator device it saves this information to rejoin later. You have two options here

      1. press and hold Btn-2 as you reset the sensor, this will delete the NVM and let you join a new network.

      2. you can reflash  the sensor image, but you need to change the flash settings in the project properties to rewrite all unprotected pages 

    • Best results were achieved when I limited the module to only work on channel 20, doing the same on the coordinator. In that state, the module worked perfectly during 24 hours, allowing me to receive the periodic reads from the coordinator side.

      This indicates to me that the coordinator is jumping around channels, and if this is the case our out of the box sensor does not support switching channels on demand. We do offer a frequency hopping mode (FH MODE) but it is based on the Wisun spec, you need to check this spec to see if it matches with what the coordinator does.

    • Last tries has been quite dissapoining though: The module says that it is joined but the coordinator does not receive data, neither incrementing the Rx counters nor showing radio signal activity in the channel... something as if the module was saying that it is sending data but it is really not doing it. I've checked that the module tries to send that data to the destination node 0, that is the address of the coordinator

    Your best option here is to packet sniff using our packet sniffer (file:///C:/Program%20Files%20(x86)/Texas%20Instruments/SmartRF%20Tools/SmartRF%20Packet%20Sniffer%202/docs/user_guide/html/users_guide.html#installation)

    This will allow you to see everything going on in the network and make sure that packets are actually being sent.

  • 0 in reply to AB
    Prodigy 30 points

    Hello AB:

    First, thanks (thanks thanks) for your reply, I thought nobody would face a so long post. During these three days I've followed some of the approaches you talk about (reflashing all unprotected areas, restarting with Btn 2 held) with different results, sometimes it worked but other times it didn't. 100% agree that I'm working blind without a sniffer, but this is a personal diy project with reduced budget so getting one, though feasible, is considered just in case I was fully blocked.

    I lied to myself and, instead of surrender, I spent some time last night on this matter. Right now it is working for about 12 hours after reflashing the CC2652 with minimal changes on the sensor SDK example (no encryption, search the coordinator in all the Xbee Pro available channels). Yesterday I tested restarting several times, and in different ways, both launchpad and coordinator getting excellent results: the CC2652 always joined the network and, in those times that it didn't, I tried resetting the board while holding Button2 with 100% of success.

    So at this point I can state that there is compatibility between TI CC2652 as end node and Digi Xbee Pro S1 802.15.4 as coordinator. At least under certain circunstrances, and defining these circunstances is the next milestone:

    • Is the Xbee hopping channels as AB suggests? It shouldn't, but it must be clearly set (to do)
    • Is the unstability coming from the Xbee module? It could, these devices has been tricky during years (I've suffered them so much...) and yesterday I detected that the Xbee locked if no processs opened its serial port. This could be the reason of the CC2652 stopping working after a few cycles: The Xbee becomes locked, there's no active coordinator on the net and the CC2652 gets orphan. If you are not checking the CC2652 terminal to know its exact state, the board will stop working without resetting the leds (red led is on, green led can be on or off) and the external sensation is that the CC2652 is locked.
    • Is something wrong after rebuilding the sensor SDK example and reflashing the module several times? It was my opinion yesterday, but I will work on it to state clear results.
    • If finally (and hopefully) there is full compatibility between XBee S1 Coordinator and CC2652, does Xbee S2C (newer module version, the S1 is end-of-life) or even XBee S3 (newest module) keep compatibility?

    Again, thanks AB for your support. I hope that all these questions, tests and findings were not offtopic (my apologies if they are) and that they were useful for other users.

  • 0 in reply to Vicente Gavara
    TI__Mastermind 22916 points
    Hello Vicente,

    Do not worry about, that is why we are here for.

    You can use our sniffer, As long as you have a CC265X or a CC135X you should be able to our packet sniffer firmaware.

    This firmware lets you connect a launchpad to your pc and sniff the environment and get the results on Wireshark.

    Follow these link:

    Product: www.ti.com/.../PACKET-SNIFFER

    User Guide: file:///C:/Program%20Files%20(x86)/Texas%20Instruments/SmartRF%20Tools/SmartRF%20Packet%20Sniffer%202/docs/user_guide/html/users_guide.html#installation

    Regards,
    AB
  • 0 in reply to AB
    Prodigy 30 points
    Thanks again for the info AB. As feedback and after days using the Launchpad with the 802.15.4 "sensor" example paired with a Xbee coordinator, I can say that NO problem has been suffered.

    I guess that my very first problems came from two sources: Not initializing properly the launchpad after a coordinator configuration change (it is crucial performing a Button2-press, reset-press, reset-release, Button2-release in that order) and some firmware bug problem on the Xbee coordinator side.

    So, overall, for those reaching this post I can say that integrating the CC26x2 as 802.15.4 end node with a Digi Xbee (S1) coordinator has been done and therefore is feasible.