• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 418 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.

CC1310: CC1310 packet CRC-16-CCITT size

Archil Pirmisashvili
Prodigy 90 points
Part Number: CC1310

Hello,

We have following issue with the packet configuration:

in smartrf_settings file we have following overrides in order to enable CRC-16-CCITT:

// Overrides for CMD_PROP_RADIO_DIV_SETUP
static uint32_t pOverrides[] =
{
// override_use_patch_prop_genfsk.xml
// PHY: Use MCE ROM bank 4, RFE RAM patch
MCE_RFE_OVERRIDE(0,4,0,1,0,0),
// override_synth_prop_430_510_div10.xml
// Synth: Set recommended RTRIM to 7
HW_REG_OVERRIDE(0x4038,0x0037),
// Synth: Set Fref to 4 MHz
(uint32_t)0x000684A3,
// Synth: Configure fine calibration setting
HW_REG_OVERRIDE(0x4020,0x7F00),
// Synth: Configure fine calibration setting
HW_REG_OVERRIDE(0x4064,0x0040),
// Synth: Configure fine calibration setting
(uint32_t)0xB1070503,
// Synth: Configure fine calibration setting
(uint32_t)0x05330523,
// Synth: Set loop bandwidth after lock to 20 kHz
(uint32_t)0x0A480583,
// Synth: Set loop bandwidth after lock to 20 kHz
(uint32_t)0x7AB80603,
// Synth: Configure VCO LDO (in ADI1, set VCOLDOCFG=0x9F to use voltage input reference)
ADI_REG_OVERRIDE(1,4,0x9F),
// Synth: Configure synth LDO (in ADI1, set SLDOCTL0.COMP_CAP=1)
ADI_HALFREG_OVERRIDE(1,7,0x4,0x4),
// Synth: Use 24 MHz XOSC as synth clock, enable extra PLL filtering
(uint32_t)0x02010403,
// Synth: Configure extra PLL filtering
(uint32_t)0x00108463,
// Synth: Increase synth programming timeout (0x04B0 RAT ticks = 300 us)
(uint32_t)0x04B00243,
// override_synth_disable_bias_div10.xml
// Synth: Set divider bias to disabled
HW32_ARRAY_OVERRIDE(0x405C,1),
// Synth: Set divider bias to disabled (specific for loDivider=10)
(uint32_t)0x18000280,
// override_phy_rx_aaf_bw_0xd.xml
// Rx: Set anti-aliasing filter bandwidth to 0xD (in ADI0, set IFAMPCTL3[7:4]=0xD)
ADI_HALFREG_OVERRIDE(0,61,0xF,0xD),
// override_phy_gfsk_rx.xml
// Rx: Set LNA bias current trim offset to 3
(uint32_t)0x00038883,
// Rx: Freeze RSSI on sync found event
HW_REG_OVERRIDE(0x6084,0x35F1),
// override_phy_gfsk_pa_ramp_agc_reflevel_0x1a.xml
// Tx: Configure PA ramping setting (0x41). Rx: Set AGC reference level to 0x1A.
HW_REG_OVERRIDE(0x6088,0x411A),
// Tx: Configure PA ramping setting
HW_REG_OVERRIDE(0x608C,0x8213),
// override_phy_rx_rssi_offset_neg2db.xml
// Rx: Set RSSI offset to adjust reported RSSI by -2 dB
(uint32_t)0x000288A3,
// TX power override
// Tx: Set PA trim to max (in ADI0, set PACTL0=0xF8)
ADI_REG_OVERRIDE(0,12,0xF8),
//Enabling syncword detection
(uint32_t)0x008F88B3,
//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,
// Configure new CRC init value
0xC0040051,
// The new init value
0x00000000,
// Set the SYSGPOCTL register
HW_REG_OVERRIDE(0x1110, RFC_DBELL_SYSGPOCTL_GPOCTL0_RATGPO1 | RFC_DBELL_SYSGPOCTL_GPOCTL1_MCEGPO0),
(uint32_t)0xFFFFFFFF,

};

We expect to have CRC of length 2 bytes at the end of the transmitted packet, but according packet sent time we have additional 2 bytes transmitted, which means that the actual transferred CRC size is 4 bytes instead of 2.

How we can set CRC size to be 2 bytes long instead of 4???

Thx

  • 0
    TI__Guru**** 317180 points

    It looks like you use the transmit time to check how long packet you have (and hence checking the CRC length).

    If you use SmartRF Studio on the RX side, use fixed packet length with a value to some byte more than you believe is needed. How does the received data look like (and compared to the payload you know you are sending)?

    802.15.4g phys can use 4 byte CRC, have you for some reason selected one of these? 

  • 0 in reply to TER
    Prodigy 90 points

    Actually we had a problem with acknowledge reception. Sometimes we got an acknowledge and sometimes not. Basically we have two modules that exchange messages (fixed size) between them. Each message is acknowledged (fixed size). So we have dedicated time window for each message based on the message size + acknowledge size. We checked with the sniffer (third module that only sniffs messages in the air and prints them out with the received timestamp taken from the CC1310 radio module). If we take a look on the timestamp of the message and acknowledge we see that there is additional ~2ms (baudrate we use is 9600 bit/s, which mean that each bytes are transmitted in 833 us). Acknowledge is sent as soon as the message receive and this operation takes less than a millisecond. As a result we can conclude that there are additional 2bytes transferred, which can be only if transmitted CRC is 4 bytes long and not 2 and we want to change it to 2 bytes in order to save power.
    Important to add: after we change our calculations to have CRC 4bytes long. All messages are sent as expected.

  • 0 in reply to Archil Pirmisashvili
    TI__Guru**** 317180 points

    I would advice to do the test I suggested to go low level to get a better picture of what is going on. Look both at the message and the ack.