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.

CC1312R: Contiki-NG: Carrier sense implementation

Part Number: CC1312R

Hi,

My customer is trying to implement “carrier sense” on CC1312R using Contiki-NG which is available on below GitHub.

https://github.com/contiki-ng/contiki-ng

It seems carrier sense command is implemented in TI driver, but it does not work.
Command: typedef struct __RFC_STRUCT rfc_CMD_PROP_CS_s rfc_CMD_PROP_CS_t
Folder:C:\contiki-ng\arch\cpu\cc13xx-cc26xx\lib\coresdk_cc13xx_cc26xx\source\ti\devices\cc13x2_cc26x2_v2\driverlib\rf_prop_cmd.h

I knew this is still development branch, but is this the reason the command does not work?

Thanks and regards,
KoT

  • Hi KoT,

    The CMD_PROP_CS command must be called with the RF driver. Since the RF driver is integrated into the radio implementation (called prop-mode for Sub-1) of the Contiki-NG platform, then prop-mode should integrate the usage of CMD_PROP_CS.

    Why do you want to use CMD_PROP_CS directly, by the way?
  • Hi Edvard,

    Thanks for your quick reply.
    Could you tell me how to call the CMD_PROP_CS command with the RF driver?

    Customer does not know how to do that, that is why customer tried to call the command directly.
    And it seems customer could not find the command in RF driver.
    folder: C:\contiki-ng\arch\cpu\cc13xx-cc26xx\rf-settings\cc13x2\prop-settings.c/prop-settings.h

    This is another reason customer needed to call the command directly.

    Thanks and regards,
    KoT

  • Could you elaborate why the customer wants to call the command directly?

  • Edvard,

    I am afraid I do not understand your question correctly.
    I am not a radio expert.

    Do you mean it is not normal customer call the carrier sense command?
    You said “The CMD_PROP_CS command must be called with the RF driver.”
    So we thought the command can be called via the RF driver (indirectly).
    This is not what you meant?

    Thanks and regards,
    KoT

  • It is not uncommon to use the carrier sense command, but I am wondering why they want to call the carrier sense command directly? Is there some use case that the Contiki stack does not take into consideration which requires the application layer to call this command directly?
  • Edvard,

    Customer wants to meet Japanese regulation and below carrier senses are required.
    It does not matter the command is called directly or not.

    Carrier sense time: 5ms, 24ch:920.6MHz to 31ch:922.0MHz

    Carrier sense time: 128us, 33ch:922.4MHz to 61ch:928.0MHz

    As far as customer understood by source code and some tests done by themselves,
    Prop mode needs to be used for Sub-1GHz, but it seems carrier sense is not implemented in Prop mode.
    Then they are in trouble.

    Again, it does not matter the command is called directly or not.
    Customer just wants to implement carrier sense in sub-1GHz.

    Thanks and regards,
    KoT

  • KoT,

    I suggest to take a look at the channel_clear() function in prop-mode.c. This is the function called by the Contiki netstack when doing a Clear-Channel Assessment.

    Right now, channel_clear() calls cca_request() which performs a single RSSI measurement and checks it against a configurable RSSI threshold. What you can do is to re-implement the channel_clear() function to instead do a CMD_PROP_CS call with your preferred configuration. The RF driver handle is available in prop_radio.rf_handle, and you can then schedule commands with the RF driver.
  • Hi Edvard,

    Thanks for your suggestion. Customer will try that.
    Let me close this thread for now.
    If they have additional questions, I will open new post.

    Thanks and regards,
    KoT