CC1310: Collector kick not active device for new associated devices

Hi Beh,

Did you base your code on one of the SDK examples? If so, what was it?

Thanks,

Arthur

Yes, i am using TI 15.4-Stack Linux Gateway

Hi Beh,

For how long a period does the device need to be inactive for it to be replaced by another?

Regards,
Nikolaj

More than a day, then we try to pair new sensor into the collector, the old device kicked by collector

Hi,

Thanks for the response.

What exactly do you mean by the old device being "kicked" by the collector? Does the collector send a disassociation request? Does the sensor device know that it has been "kicked"?

Are you by any chance using custom IEEE mac addresses stored in CCFG (see section 9.1.1.9 and 9.1.1.10 in the Technical Reference Manual) for the sensor devices? It is important that addresses used are unique for each device. 

Regards,
Nikolaj

Hi,

Being kicked is when the new device associate into network, the device still there, but after calling appsrv_processGetDeviceArrayReq(), the non active device remove/kicked by the network.

I doesnt capture the disassociation request, i will try on that later

For the IEEE mac addresses, we using default CCFG file, so i think all the device using unique mac addresses. Which when i print the extended mac address i can verify for that.

Thanks

Hi Beh,

Can you please confirm which examples you are using for the collector and sensor?

Are you using the prebuilt collector example (prebuilt/bin/host_collector) from the TI 15.4-Stack Linux Gateway?

Which examples are you using for the embedded applications for the the collector side and the sensor side? And which SDK are you using?

Have you modified any of the examples?

Thanks,
Nikolaj

For Collector side the sdk is ti154stack_linux_x64_4_20_00_05, and sensor side is simplelink_cc13x0_sdk_4_20_01_03, and coprocessor is simplelink_cc13x0_sdk_4_10_02_04. 

And the example we used is ti154stack's coprocessor and sensor.

We had modify the dataIndCb, but we doesnt modify any of associate and disassociate things

Thanks

Hi Beh,

I will try and see if I can reproduce this issue. Would the following steps be sufficient?

1. Program coprocessor example to coprocessor device (with "All Unprotected Sectors" erase setting)
2. Program sensor example to sensor device A (with "All Unprotected Sectors" erase setting)
3. Program sensor example to sensor device B (with "All Unprotected Sectors" erase setting)
4. Start collector (and permit sensors to join the network)
5. Associate sensor A to the network. Note down its short address through UART interface to the sensor device.
6. Turn off sensor A (to simulate that it is inactive)
7. Wait for 2 days (you previously wrote "More than a day")
8. Associate sensor B to the network. Note down its short address through UART interface to the sensor device.
9. Compare the short addresses assigned to sensor A and sensor B.

Can you please confirm that you can reproduce your issue using above sequence? Can you also let me know if you experience your issue if you only wait for 1 hour in step 7?

Regards,
Nikolaj 

Also, are you able to reproduce your issue with the out-of-the box examples?

Hi

I will try for that later, thanks for the update

Thanks

Hi,

I executed the test as I described in my previous post. I waited for approximately 45 hours in step 7, and I did not observe the issue your are describing. Sensor A got assigned the short address 0x2 and sensor B got assigned the short address 0x3.

EDIT: I did use a newer version of the TI 15.4-Stack Linux Gateway SDK. I used version 4.40.00.03, but except for that I should be using the same setup as you.

Please let me know of your results.

Regards,
Nikolaj