Packet Format

Messages on the proprietary PHY layer always have the following structure:

Preamble:A series of alternating 0 and 1, used for automatic gain control. Sync Word:Determines the actual start of the message. Header:May contain length and address information for the receiver (optional). Payload:The message data. CRC:Verifier for message integrity (optional).

The below image shows an example for a proprietary packet with a 2-byte sync word and 2 bytes payload. The binary modulator signal represents either a positive or a negative frequency deviation from the chosen center frequency, because we are using a binary FSK modulation.

The RF core contains a flexible packet engine that can process two customizable packet formats:

1. A simple packet format
2. An advanced packet format

Table Table 9. compares both variants. The advanced packet format is a superset of the simple one: all features of the simple format are available and it is possible to achieve the same configuration, but the corresponding advanced radio operation commands are larger and can be more time-consuming to configure. SmartRF Studio exports only RF operations for the simple packet format.

Table 9. Comparison of the simple and advanced packet format.

Feature	Simple packet format	Advanced packet format
Compatible radio operation commands	CMD_PROP_TX CMD_PROP_RX CMD_PROP_RX_SNIFF	CMD_PROP_TX_ADV CMD_PROP_RX_ADV CMD_PROP_RX_ADV_SNIFF
Preamble	1 bit, 4 bits or 1 .. 30 bytes	1 bit, 4 bits or 1 .. 30 bytes
Sync word	8 .. 32 bits	8 .. 32 bits up to two sync words for CMD_PROP_RX_ADV
Header	optional may contain either length, address or both in fixed order cannot contain unused entries	optional may contain either length, address or both in arbitrary order size can be 0..32 bits may contain unused data
Length information	is part of the header is always 8 bits long if enabled	is part of the header can be 1..16 bits long if enabled
Address information	is part of the header size is fixed to 1 byte filter for up to 2 addresses	location is either in or after the header size is variable, up to 8 bytes filter for up to 32 addresses
Payload	fixed or variable length, up to 255 bytes unlimited length possible	fixed or variable length, up to 65535 bytes unlimited length possible
CRC	optional calculated over payload and header if header is enabled	optional calculated over payload, header (optional) and sync word (optional)

Preamble

The preamble in the proprietary PHY consists of an alternating bit pattern 0101... and is used to determine the amplifier gain. Unlike in some older TI devices, it is not needed for bit synchronization.

The preamble configuration is done in the setup command and is used for both TX and RX operations. The length can be set between 1 and 30 bytes using the nPreamBytes field. Additionally, 1 bit can be programmed by nPreamBytes = 0 and 4 bits can be programmed by nPreamBytes = 31. The preamMode field controls the preamble pattern. Either 0101.. or 1010.. is possible:

rfc_CMD_PROP_RADIO_DIV_SETUP_t RF_cmdPropRadioDivSetup =
{
    // ...
    .preamConf.nPreamBytes = 4, // 4 bytes
    .preamConf.preamMode = 0,   // 0101...
    // ...
};

Sync Word

The sync word is used by the packet engine to detect the packet start. For best performance, it must satisfy multiple criteria:

• Its auto-correlation must have one high peak and only flat side lobes.
• It must be long enough to be unique. 4 bytes are recommended.

Figure 27. compares the auto correlation of the default TI sync word 0x930B51DE and the bad sync word 0xAAAAAAAA.

Figure 27. Auto correlation of the sync word 0x930B51DE which is the default sync word for TI devices since CC1101.

Reducing the sync word length to less than 4 bytes and choosing a bad sync word will likely have a negative impact on the packet error rate. It should be only changed for a good reason and with the above correlation analysis.

CRC Calculation

When transmitting a packet, a checksum of the header and payload is appended to each packet. The receiver then calculates its own checksum and compares it to the received one. When both match, the packet was received correctly. Otherwise, it must have been corrupted during transmission. The CC13x2 and CC26x2 family implements a checksum based on CRC. Whether the packet header shall be considered for CRC calculation, can be specified for each TX and RX command.

The default CRC configuration on the CC13x2 and CC26x2 family in proprietary mode is similar to older devices in the CC1xxxx family:

• CRC-16
• Polynom : x16 + x15 + x2 + 1 (0x8005)
• Initialization: 0xFFFF
• no input byte reversal
• no output byte reversal
• no XOR

An equivalent implementation in C can be found in the design note DN502

#define CRC16_POLY 0x8005
UINT16 culCalcCRC(BYTE crcData, UINT16 crcReg) {
    UINT8 i;
    for (i = 0; i < 8; i++) {
        if (((crcReg & 0x8000) >> 8) ^ (crcData & 0x80)) {
            crcReg = (crcReg << 1) ^ CRC16_POLY;
        } else {
          crcReg = (crcReg << 1);
        }
        crcData <<= 1;
    }
    return crcReg;
}// culCalcCRC


//----------------------------------------------------------------
// Example of Usage

#define CRC_INIT 0xFFFF
UINT8 txBuffer = {0, 1, 2, 3, 4, 5};
UINT16 checksum;
UINT8 i;

checksum = CRC_INIT; // Init value for CRC calculation

for (i = 0; i < sizeof(txBuffer); i++) {
  checksum = culCalcCRC(txBuffer[i], checksum);
}

If necessary, it is possible to configure new CRC settings via the RF setup override list. The following code sets the CRC polynom to 0x1021:

static uint32_t overrides[] =
{
    // ...
    // Configure new CRC16 polynom
    HW32_ARRAY_OVERRIDE(0x2004, 1),
    // The CRC16 polynome: CRC-16-CCITT normal form, 0x1021 is x^16 + x^15 + x^5 + 1
    0x10210000,
    // ...
};

The following override programs the init value to 0x4711:

static uint32_t overrides[] =
{
    // ...
    // Configure new CRC init value
    0xC0040051,
    // The new init value
    0x47110000,
    // ...
};

Input and output byte reversal are not supported for CRC calculation.