• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 730 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: CMD_PROP_RX CMD_PROP_TX lenoffset

Chris Carter
Expert 1030 points
Part Number: CC1310


is it possible to use an override to configure a lenoffset for CMD_PROP_RX and CMD_PROP_TX.

I'm trying to integrate with a transmitter that sends 0 based length's and I can use CMD_PROP_RX_ADV lenoffset to receive fine, but when trying to use SmartRF Studio, or the basic RX/TX commands I get CRC failures

  • 0
    TI__Guru**** 317180 points
    First I would like to understand the system:
    How does the packet format from the transmitter look like? If the first byte after sync word is the length byte and this is zero, how should the receiver know how many bytes it needs to receive?

    If the tx side sends a length byte equal to zero you have to set the receiver up with fixed packet length.
  • 0 in reply to TER
    Expert 1030 points

    First byte is length.  If length is 6, there are 7 bytes then 2 crc bytes.  if length is 9, there are 10 bytes then 2 crc bytes ( and so on).   What I meant by zero based is that the original device starts counting at 0 not 1

  • 0 in reply to Chris Carter
    TI__Guru**** 317180 points
    Not sure if I understand the issue. By "If length is 6, there are 7 bytes then 2 crc bytes" do you mean that you have 7 bytes including the length byte? If yes, this is the same as on CC1310.

    An easy way to test is using SmartRF Studio and set the Rx side to use fixed packet length and compare what you have with the old transmitter and CC1310.
  • 0 in reply to TER
    Expert 1030 points

    Yes that works for receiving all the data, but the crc fails because it includes the length byte in the calculation.

    Consider this packet:

    {Preamble}{Sync}0x06{7 bytes of payload}{CRC}

    With the RX Adv command I can set length offset to 1 and receive the entire packet.

  • 0 in reply to Chris Carter
    TI__Genius 14860 points

    Hi,

    in TI terminology, the packet address and the packet length are called the "packet header". If you do not want to include the packet header into CRC calculation, then you need to use the advanced packet format and the corresponding CMD_PROP_RX_ADV command and set pktConf.bCrcIncHdr = 0. The advanced packet format and CMD_PROP_RX_ADV is described in the Proprietary RF user's guide, but also in the Technical reference manual section 23.7.1, 23.5.7.4.2 and table 23-16.

    I am not sure if I understand the meaning of your length field correctly. Are you saying that your packet contains for instance

    • 1 byte length field (value 6)
    • followed by 7 (6+1) bytes payload
    • followed by 2 bytes CRC, calculated over all 7 bytes payload

    ? The interpretation of the length field by the RF core is "bytes after the header". If in your case the real payload length is one byte longer than the length field says, then you need to work around. You could set hdrConf.numHdrBits to 16 while setting hdrConf.numLenBits to 8 and hdrConf.lenPos 0. This fakes a 2 byte header. But then you have the problem that the CRC would be only calculated over the last 6 payload bytes. So, CRC calculation would have to be done in your application.

  • 0 in reply to Richard W.
    Expert 1030 points
    Thanks Richard.

    Yes you are correct in everything above. My firmware works fine as you described. Though for TX I have to manually configure the packet and calculate the CRC, since CMD_PROP_TX_ADV does not include a length offset.

    What I want to be able to do is use SmartRF studio to test PER and without using CMD_PROP_RX_ADV I cant seem to find a way to do that.

    Maybe an alternative solution would be using RX ADV in Smart RF studio for receiving in the RX packet tab. Is that possible?
  • 0 in reply to Chris Carter
    TI__Genius 14860 points
    SmartRF Studio does not support the advanced packet format. On TX side you could create packets manually, but no chance on RX side.
  • 0 in reply to Richard W.
    Expert 1030 points

    Thats kind of what I thought.

    So what about my original question?  Is it possible to use an override to adjust the packet length in CMD_PROP_RX so CRC works in RF Studio?

  • 0 in reply to Chris Carter
    Expert 1030 points
    Quick update:
    I was able to mix TER's and Richards comments (thanks dudes!) and come up with a working solution:
    I generated a complete packet and CRC to match my expected format. Then switched to fixed length and set the fixed length to be the total length (including my length of packet and CRC). In my case i set it to 16. This causes the transmitter to send extra null bytes by my original receiver gets the expected data and passes CRC.