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/CC1310: Multiple collectors are not working at the same time

Part Number: CC1310

Tool/software: TI-RTOS

Hello,

         We are using 15.4 stack and running collector- sensor example. We wanted to use multiple collectors (C0x01,C0x02) and multiple sensors (S0x01, S0x02,S0x03,S0x04).We want C0x01 should form the network with the sensors S0x01, S0x03. and C0x02 should form the network with the sensors S0x02 , S0x04. For this We have added a condition in assocIndCb(). So, If we use One collector i.e either C0x01 or C0x02 at a time appropriate sensors are  joining in the network and working fine but If we turn on both the Collectors(C0x01 , C0x02) at the same time then the sensors are not joining into the network at all. So, Is there any modifications we need to do to use multiple collectors at the same time? Following settings we are using

      - PAN_ID is same for All the modules i.e sensors and collectors(We have tried different PAN_ID for Individual networks as well).

     -Frequency Hopping disable.

     -Non-beacon mode.

Can anybody help us How to get out of this issue?

Regards,

Harsha

  • Hello Harsha,

    Can you tell me your beacon orders on your devices?
    Can you try to power them on at different times to avoid having collisions between beacons .
    The correct way of going at this is by having different PAN IDs for each network and change the coord_Short ADDR of each collector.

    Please try these changes and it should work.

    Regards,
    AB
  • Hello AB,

                Even though we powered ON at different times, We are facing the issues like one of them hanging or other one not joining into the network or some times both are hanging. and we were maintaining different PAN_ID 's only. 

    We are going with FH_MODE disable(CONFIG_FH_ENABLE-->false). so, Is it required to maintained different coord_short ADDR of each collector. because In Sensor Project--->config.h, we found like FH_COORD_SHORT_ADDR--->0xAABB, This means It's applicable only when FH Enable right? 

        Thanks in Advance

    Regards,

    Harsha

  • Hello,

            We have maintained different Coord_short ADDR, also we are maintaining different PAN_ID's and We are making Sensor PAN_ID's are open(0xFFFF). We are not able to form a proper communication with multiple collectors. Can anybody help us out, How can we do?

    Regards,

    Harsha

  • Hello Harsha,

    I am looking into this.

    Regards,
    AB
  • Thank you.... We will be waiting for your response

    Regards,
    Harsha
  • Hello,
    Any updates regarding this issue?

    Regards,
    Harsha
  • Harsha,

    Sorry for the delay, I am trying to re create the same scenario in my setup.

    Can you provide me with additional information.

    Are you using beacon mode? (Beacon order and superframe order less than 14)

    If not can you try and make those number 8, and see if this works?

    polling and reporting intervals in both collector and sensors? Make sure they match, because the collector will override these values once the sensor connects

  • Hello,

           We were using non-beacon mode earlier. then after your suggestion we changed to beacon mode by changing beacon order and superframe order to 8. but none of the sensor joined into any of the network. 

    We will explain our requirement once again that,

     We wanted to use multiple collectors (C0x01,C0x02) and multiple sensors (S0x01, S0x02,S0x03,S0x04).We want C0x01 should form the network with the sensors S0x01, S0x03. and C0x02 should form the network with the sensors S0x02 , S0x04. For this We have added a condition in assocIndCb(), so that even other network sensor sends association request collector just ignores and it joins only appropriate sensors into network.

    For this we are maintaining different coord_shortAddr and PAN_ID for collectors and sensor's PAN_ID's we are making it open network i.e 0xFFFF. Here, the issue is which ever the collector permitJoin-ON first, all the sensors are copying it's PAN_ID and keeps sending association request to that collector even the sensor is not belongs to that network. so that even other collector permitJoin-ON later, no sensor is free to join into it(because all the sensors copied first collector PAN_ID to it's own).

     For Example: First If you PermitJoin-ON the colletcor(C0x01), because all the sensor's PAN_ID's are open(0xFFFF), all sensor's copies C0x01 pan_id to it's own and all sensors sends association request to C0x01. but we allows S0x01 and S0x03 only to join(For this we have written logic assocIndCb()).Other two sensors keeps sending assoc_request to C0x01.So, Now even if you permitJoin-ON the second colletcor(C0x02) there is no use at all and nothing to join in this because S0x02 and S0x04 are keeps sending request to C0x01.

     For logic i have explained above you can refer in sensorProject-->jdllc.c--->beaconNotifyIndCb()

    How can we solve this issue?

    Regards,

    Harsha

  • We are waiting for your response. Please give us the solution as soon as possible

    Regards,
    Harsha
  • Harsha,

    I need to understand what are you doing at the collector side, specifically inside the assocIndCb(). When this happens, the collector is assigning an address to the sensor device, are you creating only ODD number devices for C0x01 and EVEN for C0x02?

    How are you determining which extended address do you choose for even or odd sensor address?

    Also, if you are going to reject specific PAN then you will need to either:
    1. On collector side reject a specific extended address and send a assocRsp.status == ApiMac_assocStatus_PanAccessDenied.
    2. On the Sensor Side reject the PAN ID in the assocCnfCB()
    3. MAke the PAN_ID fixed on the Sensor side, instead of open 0xFFFF

    It would be easier to debug if you use Packet Sniffer 2 and we can actually see the traffic. But the problem I see here is that you are not handling the PANID rejection and looking for a new one from the Sensor example.

    But from the looks of this, you are accepting all PANIDs from the Sensor side and you are also accepting all extendded addresses from the collector side. Which is causing all of these problems.

    Regards,
    AB