• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 476 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352P: Patch for CC1101 compatible FEC on CC1352

Manny Salazar
Prodigy 290 points
Part Number: CC1352P
Other Parts Discussed in Thread: CC1101, CC1310,

The following link mentioned  that there is a patch for a CC1101 compatible FEC on CC13x2.

https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/4.30.00.54/exports/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf/cc1101-migration.html

A couple of questions I would have about the patch:

1. Is it a Software based solution on the M0 or a hardware solution (for latency)

2. Does it work with the advanced packet mode of the CC1352, or only the 256 byte packet format of the CC1101.

  • 0
    TI__Guru**** 317180 points

    From the migration guide:

    "The patch required for the CC1101 compatible FEC on CC13x2 is not tested. Contact TI if you are interested in using a CC1101 compatible FEC on CC13x2."

    This is a patch that uses the M0. 

    For CC13x0 I only tested the FEC for the default packet format, I have to check if it is possible to use the patch for the advanced packet formats. 

  • 0 in reply to TER
    TI__Guru**** 317180 points

    It should be possible to use the FEC for both packet formats but should be checked. 

  • 0 in reply to TER
    Prodigy 30 points

    Who would I need to talk to at TI in order to obtain the patch for our own internal testing?  We would like to evaluate the performance of the FEC decoding.  

  • 0 in reply to Kevin Whitton1
    TI__Guru**** 317180 points

    The FEC patch that was developed for CC1310 has been ported to the CC13x2 family but no work has been done to check if the porting has been done correctly etc. This has not been done so far since it has not been any customer interest. We have a policy not to send out untested patches since this normally demand a high support load. To verify a patch on request normally demand a potential volume of a few 100 k for the project to justify the time used.

    Could you outline the background for why you are interested in the patch? I want to check if it's possible to solve what you are looking for in other ways. 

  • 0 in reply to TER
    Prodigy 30 points

    In essence we are looking to be able to add any kind forward error correction (preferably performed in the hardware for performance reasons) to the proprietary RF interface.  Something similar to the 1/2 rate convolutional encoding from the CC1101 or the long range waveform of the CC1352.  Bluetooth also looks like it supports 1/3 and 2/3 FEC.  Our goal is to see if any of those error corrections could be available to our proprietary RF format.  Avoiding the need to implement a Viterbi decoder in software would be advantageous for our system.  

  • 0 in reply to Kevin Whitton1
    TI__Guru**** 317180 points

    We are most likely not to do something with the CC1101 FEC for CC1352P short term. 

    What you can look into is LRM or WB DSSS, both of them use a FEC as first stage. Settings for both are available in SmartRF Studio.

    You can find app notes that describe the principle for both in the following app notes: https://www.ti.com/lit/an/swra591/swra591.pdf and https://www.ti.com/lit/an/swra642/swra642.pdf

    The implementation is equal for CC13x0 and CC13x2. Check if you can use one of these. 

     

  • 0 in reply to TER
    Prodigy 30 points

    Thanks for the response!  Somehow we had missed the first of the app notes that you attached.  From the surface it looks like it will meet our needs and we're checking it out now.