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.

cc1310 SYNC word external signaling and Node Synchronization



HI, I am using the following configuration to configure the RARGPO1 to indicate the sync word reception:

Output sync found signal on RATGPO1

static uint32_t pOverrides[] =
{

........
(uint32_t)0x008F88B3,

HW_REG_OVERRIDE(0x1110, RFC_DBELL_SYSGPOCTL_GPOCTL0_CPEGPO0 | //RFC_GPO0 //LNA enable
RFC_DBELL_SYSGPOCTL_GPOCTL1_CPEGPO1 | //RFC_GPO1 //PA enable - we don't need it
RFC_DBELL_SYSGPOCTL_GPOCTL2_RATGPO1 | // RFC_GPO2 (sync found) //RFC_GPO2 //sync found
RFC_DBELL_SYSGPOCTL_GPOCTL3_RATGPO0), //RFC_GPO3 //TX start - we don't need it



(uint32_t)0xFFFFFFFF,

}

In application:

#define  DEFINE_LED_FOR_SYNC_ACTIVITY_MONITORING(led) PINCC26XX_setMux(ledPinHandle, led, PINCC26XX_MUX_RFC_GPO2);

Here the results:

EVB_SND                     – PA is enabled ( packet transmit indication)

EVB_LNA                     -  LNA enabled  ( receive indication)

  EVB_SYNC                   – high when sync is found in the receiver, and low when the  packet is     received or   reception aborted)

Packet parameters:

Preamble length:8

Sync     length:2

Length field length:1

Data length:17

CRC length :2

Total:  30 byte

Datarate:50000

We see that :EVB_SYNC duration is 3.28 msec (20byte)

EVB_SYNC goes low 340mcs after end of packet transmission. 

So transmission duration 30*8/50000=4.8 msec

We see that EVB_SND duration is 5 msec.

Q1: How can we estimate start of preamble transmission ?

Q2: When SYNC was found?

Q3: Why  packet transmition duration is more than packet length?(transition to TX mode duration was included?)

 

Another problem:
Actually I tried to synchronize  Rx and TX as following(sorry for long explanation).

1. Tx send beacon (see Packet parameters earlier) every TbeaconPeriod (TBD)

2. Init state: RX command send and application  waits for beacon Twait2beacon>T beacon.If beacon was received , Packet Time Stamp is updated and  state

      equal to Sync state.

3. Sync state: When beacon was received, Radio is switched off, Application goes to sleep for Tsleep(standby) period..

    After sleep  RX command send and application  waits for beacon Twait2beacon  timeout.

I am using rfEasyLinkRx example for implementation.

Every Rx command configured as following:

EasyLink_cmdPropRxAdv.startTrigger.triggerType = TRIG_NOW;
EasyLink_cmdPropRxAdv.startTrigger.pastTrig = 1;
EasyLink_cmdPropRxAdv.startTime = 0;

EasyLink_cmdPropRxAdv.endTrigger.triggerType = TRIG_ABSTIME;
//EasyLink_cmdPropRxAdv.endTime = RF_getCurrentTime() + asyncRxTimeOut;

//asyncRxTimeOut contained RF timer current time
EasyLink_cmdPropRxAdv.endTime = asyncRxTimeOut;  

For every Rx command the following parameters calculated in RF timer ticks:

 EasyLink_cmdPropRxAdv.endTime   - Time Stamp, should take into account Start of packet Time stamp plus   Preamble and Sync word duration to ensure end of Rx in the case of failure

 rxEndPacket                                      Time stamp for  end  of packet reception, used for  Twait2beacon calculation. Should take into account   Start of packet

                                                          Time stamp and Packet duration.

//here the code

while(1) 

{

//calculate asyncRxTimeOut,rxEndPacket, end  Tsleep.                                   


if(SyncData.beaconInterval2Sleep)
{

Task_sleep(SyncData.beaconInterval2Sleep);

}
else
{

          //it's Init state, immediately start RX, all parameters actually offset from the Start of Packet Time Stamp

UInt32 ts = RF_getCurrentTime();
.rxEndTime += ts;
rxEndPacket += ts;

}


//set asyncRxTimeOut
EasyLink_setCtrl(EasyLink_Ctrl_AsyncRx_TimeOut,rxEndTime);

//start receive

EasyLink_receiveAsync(rxDoneCb, 0);

//calculate Twait2beacon   
ts = RF_getCurrentTime();
timeoutRfTick = calculateInterval( .rxEndPacket, ts);
Twait2beacon  = ((timeoutRfTick)/(4*Clock_tickPeriod));

if(Semaphore_pend(rxDoneSem, Twait2beacon  ) == FALSE)
{
....
}
else

{

update Start of packet Time Stamp with rxStatistics.timeStamp taken in rxDoneCallback(), see Easy_Link.c 

}

//here I want to close the radio to ensure the standby mode

}

When I  calculate the asyncRxTimeOut,rxEndPacket, end  Tsleep parameters on the base of rxStatistics.timeStamp, packet parameters(length), datarate 

I see (with the scope) that  calculation is wrong so I need to add some magic number to the data.

Start of packet Time Stamp                - rxStatistics.timeStamp plus TbeaconPeriod 

EasyLink_cmdPropRxAdv.endTime   - should take into account Start of packet Time stamp plus   Preamble and Sync word duration to ensure end of Rx in the case of failure

 rxEndPacket                                      Time stamp for  end  of packet reception, used for  Twait2beacon calculation. Should take into account   Start of packet

                                                          Time stamp and Packet duration.

Q4: how to calculate the asyncRxTimeOut,rxEndPacket, end  Tsleep parameters on the base of rxStatistics.timeStamp, packet parameters(length), datarate?

      Which internal RF driver process duration to take into account?

Q5: how to close the Radio(  EasyLink_init(EasyLink_Phy_Custom),EasyLink_abort())?

BR

Leonid


  • these are a lot of questions. I think I can answer most of them, but I'll take me some time.

    Leonid A. said:
    Q1: How can we estimate start of preamble transmission ?

    The first preamble bit should on the air 384 RAT ticks (96 us) after the startTrigger fired. If you use absolute triggers, you should be able to estimate it precisely. Please also consider to use the modulator data output to analyse the transmission process.

    Leonid A. said:
    Q2: When SYNC was found?

    The "sync found" event is not highly accurate. It happens a bit after the sync word was received because of internal processing. I suggest to use the RX timestamp appended to the packet, because the RF core firmware calculates the correct packet start and compensates for the mentioned processing delay. If you want to have the time of the "sync found", then you need to add the duration of the preamble and the syncword to that timestamp.

     

    Leonid A. said:
    Q3: Why  packet transmition duration is more than packet length?(transition to TX mode duration was included?)

    If you measure the "packet transmission duration" from EVB_SND 0/1 until EVB_SND 1/0 (PA signal), then keep in mind that this also contains the PA ramp-up time and some time after transmission has completed. I suggest to use the signal MCE_GPO0 if you want to know how the other signals relate to the packet timing. The following timing diagram shows the PA signal and TX data. It has been measured with the packet setup from above.

    • A: Enable PA (0)
    • B: First preamble bit starts (~15µs)
    • C: Last CRC bit finishes (4.815ms)
    • D: Disable PA (4.815ms + 185ms = 5ms)

    I'll leave the other questions up to an EasyLink expert.

  • Hi Richard.

    It will be great.

    TI Support is extremely important to our project.

    BR

    Leonid

  • Hi Richard,

    packet transmition duration is duration  from EVB_SND 0/1 until EVB_SND 1/0

    BR

    Leonid

  • Leonid A. said:
    Q4: how to calculate the asyncRxTimeOut,rxEndPacket, end  Tsleep parameters on the base of rxStatistics.timeStamp, packet parameters(length), datarate?

    In this situation it may be easier to use a relative time instead of absolute:

    EasyLink_cmdPropRxAdv.endTrigger.triggerType = TRIG_REL_START;

    However I am not sure how the datarate is related, by default once the Rx starts it will continue regardless of the timeout. If this behavior not desired then you can set the .pktConf.endType and the RX will timeout regardless of the RX starting.

    Leonid A. said:
    Q5: how to close the Radio(  EasyLink_init(EasyLink_Phy_Custom),EasyLink_abort())?

    Currently there is no EasyLink_close API implemented. This could be implemented and should call RF_close, as well as deleting the semaphores and freeing any memory.

    Regards, TC.

  • Hi TopCat,

    thanks for answer.

    As far as I know TI RTOS does not make possible CPU sleep (Idle) mode   when Trigger type is different from TRIG_ABSTIME.

    For our project it is an issue.

    BR Leonid

  • Lenoid,

    while waiting for a command to start, the CPU can go into IDLE mode, but not STANDBY in general. IDLE is the deepest sleep mode where the RF core is still awake. Only for absolute start triggers, the RF driver allows STANDBY, because the RF core is powered down.

  • Hi Richard,
    thanks for explanation.
    BR
    Leonid
  • Lenoid, please consider to mark the given answers as accepted. Thanks.