• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 513 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-CC1312R1: Coordinator Realignment in non-beacon mode

Joe Alemanni
Prodigy 80 points
Part Number: LAUNCHXL-CC1312R1

CC1312R1 Launchpad

Coprocessor firmware from simplelink_cc13x2_sdk_2_10_00_48

TI Sniffer 2 used to monitor all 4 active channels in my configuration

My apps (device and coordinator) use non-beacon mode only and 4 active channels in APIMAC_STD_US_915_PHY_1. I'm trying to flesh out my device app orphan notification scan confirmation callback handler. Everything is working as described in the TI Stack Users Guide in that my orphan notifications get transmitted on each channel with a scan duration of 5 and my coordinator app detects it (gets the orphan indication callback) and acknowledges recognizing the device by issuing a coordinator realignment which aborts the orphan scan (whatever their shared current logical channel might be).

The problem is there's no way to determine from the contents of the ApiMac_mlmeScanCnf_t receive from the scan callback that a coordinator realignment was received. Whether I receive it or not (I tested blocking the coordinator app from issuing the ApiMac_MlmeOrphanRsp call) status is always ApiMac_status_success and scan_Type ApiMac_scantype_orphan. ApiMac_status_t has a member ApiMac_status_realignment but it, apparently, isn't used. I can't use the unscanned channels list as a clue because I might only be using one or the last one (clue being that the scan aborted) . 

What I'm doing now (and what is working) is to clear the coordinator short address in the device before issuing the orphan scan and then checking it on the scan callback to see if the received coordinator realignment sets it. If so I then read all the updated coordinator parameters from the stack. It would be much simpler to just know the coordinator realignment was received with a status of  ApiMac_status_realignment .

Am I missing something in my understanding here?

P.S. Saw nothing in the latest SimpleLink library release 2_20_00_71 that would change this behavior.

  • 0
    TI__Genius 12415 points
    receiving ApiMac_status_success in scanCnfCb should be only when you receive a coordinator realignment. Are you saying that even if you don't receive a response for the orphan notification you still see ApiMac_status_success in the scanCnfCb in the sensor side?
    If this is the case, have you confirmed using a sniffer that the collector is not sending the coordinator realignment?
  • 0 in reply to Hector_r
    Prodigy 80 points
    Hi Hector.

    "Whether I receive it or not (I tested blocking the coordinator app from issuing the ApiMac_MlmeOrphanRsp call) status is always ApiMac_status_success and scan_Type ApiMac_scantype_orphan." So yes.

    "TI Sniffer 2 used to monitor all 4 active channels in my configuration" So yes.

    The real question: "The problem is there's no way to determine from the contents of the ApiMac_mlmeScanCnf_t receive from the scan callback that a coordinator realignment was received."
  • 0 in reply to Joe Alemanni
    Prodigy 80 points

    You guys are usually pretty responsive. I hope this is not where questions go to die.

  • 0 in reply to Joe Alemanni
    TI__Genius 12415 points
    Hi,

    I tested this and if the collector does not send a coordinator realignment I get ApiMac_status_noBeacon. Yes I agree with you that there is no information embedded in ApiMac_mlmeScanCnf_t that indicates whether there was a coordinator realignment or not but the reason for this is that if the scan type is ApiMac_scantype_orphan and the status of the scan in the scanCf callback is ApiMac_status_success then this means that you received a coordinator realignment. Otherwise you will receive the status of ApiMac_status_noBeacon if there was no coordinator realignment.
  • 0 in reply to Hector_r
    Prodigy 80 points

    Thanks Hector. I confirm your result (not sure why I wasn't seeing the ApiMac_status_noBeacon in my earlier test). I think my mind was looking for a positive re-enforcement of an event (coordinator realignment results in a ApiMac_status_realignment) as opposed to a negative one (ApiMac_status_noBeacon when there is a beacon but no response to the beacon).

    Since I'm now ranting, it would also be helpful if the TI-15.4-STACK-CoP Interface Guide in it's description of MAC_SCAN_CNF (3.4.10) enumerated the Statuses specific to a MAC_SCAN_CNF instead of referring the reader to a list of status values in a section (6.1) that, apparently, does not exist. Yeah, I can look at the header file but no reference I can find relates the specific status for a data structure returned from a callback.

    Thanks again for your advice.