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 - use two syncwords

Other Parts Discussed in Thread: CC1310, CC1101

Is it possible to set 2 different Syncwords with the CC1310?

I tried to set syncword0 and syncword1 but it only listens to syncword0. I'm not sure if it is supported or not.


From User Guide: If syncWord1 is nonzero, the receiver also listens for the sync word given in the syncWord1 field
(formatted in the same way) if supported in the MCE.

  • I tested it now with the newest TI-RTOS.

    I used the rf_packetRx with the following in the smartrfsettings file:
    // CMD_PROP_RX_ADV
    rfc_CMD_PROP_RX_ADV_t RF_cmdPropRxAdv =
    {
    .commandNo = 0x3804,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .pktConf.bFsOff = 0x0,
    .pktConf.bRepeatOk = 0x0,
    .pktConf.bRepeatNok = 0x0,
    .pktConf.bUseCrc = 0x1,
    .pktConf.bCrcIncSw = 0x0,
    .pktConf.bCrcIncHdr = 0x1,
    .pktConf.endType = 0x0,
    .pktConf.filterOp = 0x0,
    .rxConf.bAutoFlushIgnored = 0x0,
    .rxConf.bAutoFlushCrcErr = 0x0,
    .rxConf.bIncludeHdr = 0x1,
    .rxConf.bIncludeCrc = 0x0,
    .rxConf.bAppendRssi = 0x0,
    .rxConf.bAppendTimestamp = 0x0,
    .rxConf.bAppendStatus = 0x1,
    .syncWord0 = 0x930b51de,
    .syncWord1 = 0x51de930b,
    .maxPktLen = 0x7D,
    .hdrConf.numHdrBits = 0x8,
    .hdrConf.lenPos = 0x0,
    .hdrConf.numLenBits = 0x8,
    .addrConf.addrType = 0x0,
    .addrConf.addrSize = 0x0,
    .addrConf.addrPos = 0x0,
    .addrConf.numAddr = 0x0,
    .lenOffset = 0x00,
    .endTrigger.triggerType = 0x0,
    .endTrigger.bEnaCmd = 0x0,
    .endTrigger.triggerNo = 0x0,
    .endTrigger.pastTrig = 0x0,
    .endTime = 0x00000000,
    .pAddr = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .pQueue = 0, // INSERT APPLICABLE POINTER: (dataQueue_t*)&xxx
    .pOutput = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    };

    A packet is received if I send either syncword0 or syncword1
  • i tried with

    syncword0 = 0xCE3D

    syncword1 = 0xCE1D

    The Receiver always wakes up with syncword0.

    But only sometimes with syncword1. Maybe 1 out of 10.

  • Have you tried with two very different sync words?

    In your case you have 1 bit difference between the two. In addition they are 16 bit which make false sync more probable. Why are you using two sync words that are close to equal?
  • Because I have to stay compatible with an existing application where we used the CC1101 which had the 15/16 bit match mode.

    There is a base syncword and depeding on the device 1 bit different. And the 15/16 mode is not possible with the CC1310, thats why I tried the two syncword mode.

    Did you try it with your devices to see if you have problems if only 1 bit is different?

  • I think this is the first time someone has used the 15/16 mode in CC1101 like that... The intent (I think) was to allow one bit error in the sync word and still be able to receive the packet.

    Anyway: I sat syncword0 and syncword1 equal to your syncwords and sent first syncword0 and then syncword1 and got the same performance. Since I use the rfpacket examples I don't have a counter showing packets received/ sent but the LEDs on rx/ tx side blink at the same time. For both cases the blinking gets out of sync from time to time, possible do to false syncs.
  • Yes thats why we used it. So we have the possibility to wake up all the devices at once or only specific ones.

    What could be the problem that it misses some syncs?
    A workaround would be to listen 2 times seperatly for each sync but that costs energy.
  • 15/16 byte sync on CC1101 means that you will get a false sync every few minutes. CC1310 is better than CC1101 but still a 16 bit sync word will cause false syncs. To get better performance, use a slightly longer sync word in Rx where the last bits of the preamble is part of the sync.

    The effects of false syncs/ lost packets will be dependent on your system. Is the data critical, is it possible to ask for re-transmits etc.
  • I still dont understand why syncword0 is working fine but syncword1 is failing alot.

    I cannot change the syncword, i have to stay compatible and find a way to receive both syncwords withou using alot of energy.

    How is the 2 syncword detection done?

    BTW: What do you mean i will get false sync every few minutes? I will get more sync errors with a longer sync.

  • With the 15/16 setup on CC1101 it is fairly likely to find a valid sync word in noise within a fairly short period of time.

    The existing CC1101 system sends 0x0101..0101CE3D. If you program CC1310 to look for 0x55CE3D you are still compatible with the existing system (in Tx you send 0xCE3D)

    " I will get more sync errors with a longer sync." Why? It's lower probability to find a long sync word in noise compared to a short one.
  • Ok I tried it ... still the same problem syncword0 good - syncword1 bad
  • Now I tried it with the evaluation board and the rfRXPacket example and it has the same problem.
    It receives 100% of the syncword0
    but <1% of the syncword1
    (if i switch the syncwords its the same 0xCE1D <> 0xCE3D)

    Something is wrong??
  • Could you zip the code so I can see exactly what you are doning in Rx and Tx?
  • Cant send the TX Code but its just [2 Byte Preamble][2 Byte Sync][2 Byte Data] sending all the time (no CRC)
    (19200 bit/s, 20kHz deviation, 868Mhz)

    The RX Code is the rfPacketRx Example from TI-RTOS for CC13xx (the one that blinks if a packet was received)
    with modified RF settings from SmartRF Studio and I use the Advanced RX Mode.

    For Example: if I send 5seconds continous with syncword0 - Rx blinks continous for 5s
    if I send 5seconds with syncword1 - Rx blinks maye once or twice
  • It sounds like you are not using dual sync but it's not possible for me to see what you could possibly done wrong if I don't have the code.
  • I tried to post the code. it doesnt show up.
  • The easiest would be to attach it (select rich text to get the option)

  • /*
     * Copyright (c) 2019, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    
    /***** Includes *****/
    /* Standard C Libraries */
    #include <stdlib.h>
    
    /* TI Drivers */
    #include <ti/drivers/rf/RF.h>
    #include <ti/drivers/PIN.h>
    
    /* Driverlib Header files */
    #include DeviceFamily_constructPath(driverlib/rf_prop_mailbox.h)
    
    /* Board Header files */
    #include "Board.h"
    
    /* Application Header files */
    #include "RFQueue.h"
    #include "smartrf_settings/smartrf_settings.h"
    
    /***** Defines *****/
    
    /* Packet RX Configuration */
    #define DATA_ENTRY_HEADER_SIZE  8  /* Constant header size of a Generic Data Entry */
    #define MAX_LENGTH              300 /* Max length byte the radio will accept */
    #define NUM_DATA_ENTRIES        2  /* NOTE: Only two data entries supported at the moment */
    #define NUM_APPENDED_BYTES      2  /* RF_cmdRxHS.rxConf.bIncludeLen = 1 */
    #define LENGTH_BYTE_SIZE        2
    
    
    /***** Prototypes *****/
    static void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e);
    
    /***** Variable declarations *****/
    static RF_Object rfObject;
    static RF_Handle rfHandle;
    
    /* Pin driver handle */
    static PIN_Handle ledPinHandle;
    static PIN_State ledPinState;
    
    /* Buffer which contains all Data Entries for receiving data.
     * Pragmas are needed to make sure this buffer is 4 byte aligned (requirement from the RF Core) */
    #if defined(__TI_COMPILER_VERSION__)
    #pragma DATA_ALIGN (rxDataEntryBuffer, 4);
    static uint8_t
    rxDataEntryBuffer[RF_QUEUE_DATA_ENTRY_BUFFER_SIZE(NUM_DATA_ENTRIES,
                                                      MAX_LENGTH,
                                                      NUM_APPENDED_BYTES)];
    #elif defined(__IAR_SYSTEMS_ICC__)
    #pragma data_alignment = 4
    static uint8_t
    rxDataEntryBuffer[RF_QUEUE_DATA_ENTRY_BUFFER_SIZE(NUM_DATA_ENTRIES,
                                                      MAX_LENGTH,
                                                      NUM_APPENDED_BYTES)];
    #elif defined(__GNUC__)
    static uint8_t
    rxDataEntryBuffer[RF_QUEUE_DATA_ENTRY_BUFFER_SIZE(NUM_DATA_ENTRIES,
                                                      MAX_LENGTH,
                                                      NUM_APPENDED_BYTES)]
                                                      __attribute__((aligned(4)));
    #else
    #error This compiler is not supported.
    #endif
    
    /* Receive dataQueue for RF Core to fill in data */
    static dataQueue_t dataQueue;
    static rfc_dataEntryGeneral_t* currentDataEntry;
    static uint8_t packetLength;
    static uint8_t* packetDataPointer;
    static rfc_hsRxOutput_t rxStatistics;
    
    
    static uint8_t packet[MAX_LENGTH + NUM_APPENDED_BYTES - LENGTH_BYTE_SIZE]; /* The length info (2 bytes) is stored in a separate variable */
    
    /*
     * Application LED pin configuration table:
     *   - All LEDs board LEDs are off.
     */
    PIN_Config pinTable[] =
    {
        Board_PIN_LED2 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
    	PIN_TERMINATE
    };
    
    /***** Function definitions *****/
    
    void *mainThread(void *arg0)
    {
        RF_Params rfParams;
        RF_Params_init(&rfParams);
    
        /* Open LED pins */
        ledPinHandle = PIN_open(&ledPinState, pinTable);
        if (ledPinHandle == NULL)
        {
            while(1);
        }
    
        if( RFQueue_defineQueue(&dataQueue,
                                rxDataEntryBuffer,
                                sizeof(rxDataEntryBuffer),
                                NUM_DATA_ENTRIES,
                                MAX_LENGTH + NUM_APPENDED_BYTES))
        {
            /* Failed to allocate space for all data entries */
            while(1);
        }
    
        RF_cmdRxHS.pOutput = &rxStatistics;
        RF_cmdRxHS.pQueue = &dataQueue;
        RF_cmdRxHS.rxConf.bAutoFlushCrcErr = 1;
        RF_cmdRxHS.maxPktLen = MAX_LENGTH;
        RF_cmdRxHS.pktConf.bRepeatOk = 1;
        RF_cmdRxHS.pktConf.bRepeatNok = 1;
    
        // Appended bytes
        RF_cmdRxHS.rxConf.bIncludeLen = 1;
        RF_cmdRxHS.rxConf.bIncludeCrc = 0;
        RF_cmdRxHS.rxConf.bAppendStatus = 0;
        RF_cmdRxHS.rxConf.bAppendTimestamp = 0;
    
        /* Request access to the radio */
        rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdRadioSetup, &rfParams);
    
        /* Set the frequency */
        RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);
    
        RF_runCmd(rfHandle, (RF_Op*)&RF_cmdRxHS, RF_PriorityNormal, &callback, RF_EventRxEntryDone);
    
        while(1);
    }
    
    void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
        if (e & RF_EventRxEntryDone)
        {
            /* Toggle pin to indicate RX */
            PIN_setOutputValue(ledPinHandle, Board_PIN_LED2, !PIN_getOutputValue(Board_PIN_LED2));
    
            /* Get current unhandled data entry */
            currentDataEntry = RFQueue_getDataEntry();
    
            /* Handle the packet data, located at &currentDataEntry->data */
            packetLength      = ((*(uint8_t*)(&currentDataEntry->data + 1)) << 8) |
                                 (*(uint8_t*)(&currentDataEntry->data));
            packetDataPointer = (uint8_t*)(&currentDataEntry->data + 2);
    
            /* Copy the payload + optional status byte to the packet variable */
            memcpy(packet, packetDataPointer, (packetLength + NUM_APPENDED_BYTES - LENGTH_BYTE_SIZE));
    
            RFQueue_nextEntry();
        }
    }
    

    #include <ti/devices/DeviceFamily.h>
    #include DeviceFamily_constructPath(driverlib/rf_mailbox.h)
    #include DeviceFamily_constructPath(driverlib/rf_hs_mailbox.h)
    #include DeviceFamily_constructPath(driverlib/rf_common_cmd.h)
    #include DeviceFamily_constructPath(driverlib/rf_hs_cmd.h)
    #include <ti/drivers/rf/RF.h>
    #include DeviceFamily_constructPath(rf_patches/rf_patch_mce_hsp_4mbps.h)
    #include DeviceFamily_constructPath(rf_patches/rf_patch_rfe_hsp_4mbps.h)
    #include "smartrf_settings.h"
    
    RF_Mode RF_prop =
    {
        .rfMode = RF_MODE_PROPRIETARY_SUB_1,
        .cpePatchFxn =  0,
        .mcePatchFxn =  &rf_patch_mce_hsp_4mbps,
        .rfePatchFxn =  &rf_patch_rfe_hsp_4mbps,
    };
    
    // Overrides for CMD_RADIO_SETUP
    uint32_t shapeovr[] = {0x00000000, 0x00000000, 0x00000000, 0x12010000, 0x72685C43, 0x8986817A};
    
    uint32_t pOverrides[] =
    {
        MCE_RFE_OVERRIDE(1,0,0,1,0,0),
        ADI_HALFREG_OVERRIDE(0,61,0xF,0x0),
        ADI_REG_OVERRIDE(1,4,0x9F),
        ADI_HALFREG_OVERRIDE(1,7,0x4,0x4),
        HW_REG_OVERRIDE(0x4038,0x003A),
        HW_REG_OVERRIDE(0x4020,0x7F00),
        HW_REG_OVERRIDE(0x4064,0x0040),
        0x000604A3,
        0xB1070503,
        0x05330523,
        0x0A480583,
        0x7AB80603,
        0x00108463,
        0x02010403,
        0x04B00243,
        0x00038883,
        0xC0040031,
        (uint32_t) &shapeovr[0],
        0xC0040021,
        (uint32_t) (0x00000035),
        0x000388A3,
        HW_REG_OVERRIDE(0x50B4,0x6666),
        HW_REG_OVERRIDE(0x50B8,0x000C),
        (uint32_t)0xFFFFFFFF,
    };
    
    // CMD_RADIO_SETUP
    rfc_CMD_RADIO_SETUP_t RF_cmdRadioSetup =
    {
        .commandNo = CMD_RADIO_SETUP,
        .status = 0x0000,
        .pNextOp = 0x00000000,
        .startTime = 0x00000000,
        .startTrigger.triggerType = 0x0,
        .startTrigger.bEnaCmd = 0x0,
        .startTrigger.triggerNo = 0x0,
        .startTrigger.pastTrig = 0x0,
        .condition.rule = 0x1,
        .condition.nSkip = 0x0,
        .mode = 0x05,
        .loDivider = 5,
        .config.frontEndMode = 0x0,
        .config.biasMode = 0x1,
        .config.bNoFsPowerUp = 0,
        .txPower = 0xA63F,
        .pRegOverride = pOverrides,
    };
    
    // CMD_FS
    rfc_CMD_FS_t RF_cmdFs =
    {
        .commandNo = 0x0803,
        .status = 0x0000,
        .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
        .startTime = 0x00000000,
        .startTrigger.triggerType = 0x0,
        .startTrigger.bEnaCmd = 0x0,
        .startTrigger.triggerNo = 0x0,
        .startTrigger.pastTrig = 0x0,
        .condition.rule = 0x1,
        .condition.nSkip = 0x0,
        .frequency = 0x0364,
        .fractFreq = 0x0000,
        .synthConf.bTxMode = 0x0,
        .synthConf.refFreq = 0x0,
        .__dummy0 = 0x00,
        .__dummy1 = 0x00,
        .__dummy2 = 0x00,
        .__dummy3 = 0x0000,
    };
    
    // CMD_TX_HS
    rfc_CMD_HS_TX_t RF_cmdTxHS =
    {
        .commandNo = 0x3841,
        .status = 0x0000,
        .pNextOp = 0x00000000,
        .startTime = 0x00000000,
        .startTrigger.triggerType = 0x0,
        .startTrigger.bEnaCmd = 0x0,
        .startTrigger.triggerNo = 0x0,
        .startTrigger.pastTrig = 0x0,
        .condition.rule = 0x1,
        .condition.nSkip = 0x0,
        .pktConf.bFsOff = 0x0,
        .pktConf.bUseCrc = 0x1,
        .pktConf.bVarLen = 0x1,
        .pQueue = 0,
    };
    
    // CMD_RX_HS
    rfc_CMD_HS_RX_t RF_cmdRxHS =
    {
        .commandNo = CMD_HS_RX,
        .status = 0x0000,
        .pNextOp = 0x00000000,
        .startTime = 0x00000000,
        .startTrigger.triggerType = 0x0,
        .startTrigger.bEnaCmd = 0x0,
        .startTrigger.triggerNo = 0x0,
        .startTrigger.pastTrig = 0x0,
        .condition.rule = 0x1,
        .condition.nSkip = 0x0,
        .pktConf.bFsOff = 0,
        .pktConf.bUseCrc = 1,
        .pktConf.bVarLen = 1,
        .pktConf.bRepeatOk = 0,
        .pktConf.bRepeatNok = 0,
        .pktConf.addressMode = 0,
        .rxConf.bAutoFlushCrcErr = 0,
        .rxConf.bIncludeLen = 1,
        .rxConf.bIncludeCrc = 0,
        .rxConf.bAppendStatus = 0,
        .rxConf.bAppendTimestamp = 0,
        .maxPktLen = 0,
        .address0 = 0,
        .address1 = 0,
        .__dummy0 = 0,
        .endTrigger.triggerType = 1,
        .endTrigger.bEnaCmd = 0,
        .endTrigger.triggerNo = 0,
        .endTrigger.pastTrig = 0,
        .endTime = 0,
        .pQueue = 0,
        .pOutput = 0,
    };
    

  • Have you tried with the setup for RF_cmdPropRxAdv that I used? (just change sync1 and sync0)
  • I get the same result.

    Can you give me your settings for my sequence [2 Byte Preamble][2 Byte Sync][2 Byte Data]
    With 2 different syncwords 0xCE1D, 0xCE3D. No CRC at the end!
    And does it work for you if you try it?
  • Now I tried it with different syncwords 0xCE1D and 0x5B49 and it works great.

    If i change it to my syncword 0xCE1D and 0xCE3D it doesnt work.

    Atleast now i am sure that i use dualsync mode.

    Is there a way to make it work?
    And why is it not working if only 1 bit is different?
    I am using TI RTOS 2.15.
  • Anything else i could try? Any updates?

  • Sorry, the example I used for testing got corrupted and I needed some time to get it up again. Now I see the same as you and I have to dig some to see if I can find out why.
  • Not entirely sure what happens but I suspect that the sync words are too equal. Internally we have two correlators lokking for a sync word in parallel. What could be the case here is that both correlators think that they have found a valid sync since from a correlation standpoint the two sync words you are using are more or less equal. It seems like the sync found signal from both correlators block each other and result in packet loss dependent of which sync word you actually are sending.

    Will you be able to use one sync word (0x55CE, using part of the preamble as sync) and do filtering in firmware on the last byte (0x1D or 0x3D?)?
  • The problem is every bit of the 0xCE1D could change not only the last byte. I guess i could look only for the preamble as sync but i dont know how reliable it is because we only have 2 byte preamble anyway.

    Do you think it is possible to fix this in the CC1310?

  • I won't have time to test the following before late next week but you can play with it to see if it help:

    Add the following to the override list:

    HW_REG_OVERRIDE(0x5104, 0x2727);

    Where you can try to replace 0x2727 with some higher numbers up to max 0x6363. This basically sets the sync threshold. Increasing this could influence the sensitivity.
  • I tried it with some values up to 0x6363, but it doesnt seem to help. I see no difference.