• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 55 subscribers
  • Views 689 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.

Original question:

CC1312R: Contiki-NG: Carrier sense implementation

CC1312R: Contiki-NG: Carrier sense implementation

Koichiro Tashiro
Mastermind 22915 points
Part Number: CC1312R

Hi Edvard,

Customer found Carrier sense is already implemented in Contiki-NG source.
They missed that. Sorry about that.

Now customer confirmed Contiki-NG handles CS and if interfering noises exist, CC1312R does not output its RF.
But they found below two issues for their usecase.
a) To meet Japan regulation, CS time needs to be maintained for 5ms (or 128us depends on channel#).
It seems CC1312R starts output as soon as interfering noises are not detected in current implementation.
Please see page#1 of attached slides.
Is it possible to implement CS time?

b) There is timing gap between CS and RF output start timing.
Please see attached slide#2.
As far as customer checked, ~300us delay exist in current implementation.
Customer thought below codes add the timing delay.
If MAX(CLOCK_SECOND / 3125, 1); is shorter, the delay also gets shorter.
Is it OK to modify this parts of the codes?
Customer wants to change it as small as possible.

C:\contiki-ng\os\net\mac\csma\csma-output.c

 

　/*---------------------------------------------------------------------------*/

static clock_time_t

backoff_period(void)

{

#if CONTIKI_TARGET_COOJA

  /* Increase normal value by 20 to compensate for the coarse-grained

  radio medium with Cooja motes */

  return MAX(20 * CLOCK_SECOND / 3125, 1);

#else /* CONTIKI_TARGET_COOJA */

  /* Use the default in IEEE 802.15.4: aUnitBackoffPeriod which is

   * 20 symbols i.e. 320 usec. That is, 1/3125 second. */

  return MAX(CLOCK_SECOND / 3125, 1);

#endif /* CONTIKI_TARGET_COOJA */

}

　/*---------------------------------------------------------------------------*/


Please let me know if you need further information.
Contiki-NG CarrierSense_20181005.pdf
Thanks and regards,
KoT

 

  • 0
    TI__Genius 12415 points
    Hi,

    Edvard is on vacation at the moment, I will try to look into this while he is out. I will let you know as soon as I have an update.

    Regards,
    Hector
  • 0 in reply to Hector_r
    TI__Mastermind 22915 points
    Hi Hector,

    Any updates for this item?

    Thanks and regards,
    KoT
  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 23730 points

    Hi KoT,

    A) You could either
      1. modify the channel_clear() function in prop-mode to poll the cca_request() for some specific time, however, this is not efficient and not very power friendly if that is a requirement.
      2. re-implement the cca_request() function to use CMD_PROP_CS command instead.

    B) If you want to have zero delay between CS and TX then you want to implement the RADIO_TX_MODE_SEND_ON_CCA for prop-mode. That is, if this TX mode is enabled, then every packet transmitted will chain a CS before every TX. This must be done in the transmit() function. It should not be necessary to modify any source code from the os\net module.

  • 0 in reply to Severin Suveren
    TI__Mastermind 22915 points

    Hi Edvard,

    Thanks for your reply.

    Customer will take A-2: re-implement the cca_request() function, but he does not know CMD_PROP_CS usage in details.
    He modified the code anyway;
    C:\contiki-ng\arch\cpu\simplelink-cc13xx-cc26xx\rf\sched.c

    Before modifications:
    ――――――――――――――――――――――――――ー

    cca_request(void)

    {

      const int8_t rssi = get_rssi();

     

      if(rssi == RF_GET_RSSI_ERROR_VAL) {

        return CCA_STATE_INVALID;

      }

     

      return (rssi < prop_radio.rssi_threshold)

             ? CCA_STATE_IDLE

             : CCA_STATE_BUSY;

    }

    ―――――――――――――――――――――――――――


    After modifications:
    ――――――――――――――――――――――――――ー

    cca_request(void)

    {

         Tim = 0;

         Do {

          sched_params.endTime = Tim;

          RF_scheduleCmd(CMD_PROP_CS);

          Sts = RF_pendCmd();

          Tim += 5000;

         } while(sts != CCA_STATE_IDLE)

          return ( sts ) ;

    }

    ―――――――――――――――――――――――――――


    Are these changes align with what you mentioned?

    Thanks and regards,
    KoT

  • 0 in reply to Koichiro Tashiro
    TI__Mastermind 23730 points
    I recommend reading up on the CMD_PROP_CS command in the TRM. CMD_PROP_CS has an argument for which you can specify how long the carrier sense operation should be running.

    In addition, simply scheduling the command will probably not work. Check out the sched.c file. That is the RF scheduler which ensures access to the radio is done properly with multiple scheduled commands. Essentially, you need to make sure any on-going RX command is stopped before scheduling CMD_PROP_CS, run CMD_PROP_CS, then subsequently reschedule the RX command if it were running before.
  • 0 in reply to Severin Suveren
    TI__Mastermind 22915 points
    Customer is trying to implement your recommended method. Please wait for a while.