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-CC26X2R1: rfDriverCallback

Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: SYSCONFIG

Hello,

has anyone successfully used sysconfig to get a callback to void rfDriverCallback(RF_Handle client, RF_GlobalEvent events, void *arg)? How? Changes in the rf section of the sysconfig do not seem to have the expected effect.

Best regards

  • Hi Hermann,

    Could you elaborate on how you set this up in SysConfig. I'm able to get SysConfig to generate the proper attributes where the callback is assigned, is this not what happens for you?

    Or is the issue not that the callback is not passed into "RFCC26XX_hwAttrs" but that it is never called? In this case, which events have you setup in the mask?

  • Hi M-W,

    it is working now. I did not set rfDriverCallback in the sysconfig field "Global Callback Function".

    Is it possible to differentiate between severeal BLE connections in rfDriverCallback? (Like it is done between a sub-1 Ghz and a Ble connection)

    Best regards

  • Hi Hermann,

    Glad you got it working. 

    You can not really differentiate between different connections as there is no information available that could tell you which is doing what. The radio driver only really knows in what mode the radio is currently operating, it do not know about stack specific things such as multiple connections. 

  • Hi M-W,

    are there any plans on implementing such functionality? This is an antenna diversity thing which I am sure others are also concerned about. Do you know how others are approaching this requirement with the options your stack provide?

    Best regards!

  • Hi Hermann,

    Currently there is no such support in the phys them self, in some cases (like IEEE) I would expect this to maybe get out one day.

    For BLE in this case, there is no antenna diversity built into the stack as far as I know and something you could potentially implement in software yourself (with this I mean from BLE application space, not the RF driver callback per say as this does not know about BLE specifics such as which connection is happening etc).