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.
Tool/software:
Hello my friends,
I was wondering if there is any example on how to implement a custom FEC scheme using the proprietary RF?
My main question revolves around the fact that at the Tx side the FEC should be over the entire payload plus the CRC. In this context, I was wondering if there is a way to get the generated CRC for a specific payload and then feed the entire thing to a simple encoder like a linear 3/4 block code?
Also, the biggest question is how to perform the FEC decoding at the RX and then CRC check? Is there a way to see the raw air packet in the Rx mode and using the proprietary RF? Further, if there is any API to calculate the CRC checksum or we should write a simple code to do the computations for the CRC.
Any help or suggestions will be much appreciated.
Thanks.
Hi Omid,
if you want to review the data to/from the modem, you can have a look at the available debug signals here: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/signal-routing.html
You can implement the crc according to you needs. If you chose to use our crc you can configure it to your needs (bytes length, polynomial, init value, if it is calculated with or without sync word (bCrcIncSw) and with or without header (bCrcIncHdr) etc.). You can review the packet format here: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf/packet-format.html?highlight=crc#crc-calculation
You can also turn off our crc calculation and calculate a complete custom crc and build the packet as you need. If you are implementing a custom sw fec you should use fixed packet length so that the packet is interpreted correctly.
Kind regards,
Theo
Thanks for your reply Theo,
It is nice that we can access the CPE signals and even tie them to the GPIOs for "outward" access and callbacks.
However, the real question is how to access the data? For example can I do the following:
1. waiting for the CPE signal showing that the signal passed the demodulator at the RX, then access the location of the packet pointer.
2. Perform signal processing on the content of the populated memory address for FEC.
3. calculate the CRC?
I mean the question really boils down to the fact that if the packet pointer location is populated in real time and the demodulated data is available to access right after the CPE signal says that?
Also, is there repo or piece of code to exemplify this?
Thanks
What you ask for is not possible.
You need to take the data you want to transmit, perform your SW FEC, calculate the CRC, and then write your data to the "buffer" the RF_cmdPropTx.pPktis pointing to.
Similarly, on the RX side, you need to receive all data in a data entry, then perform any decoding, crc calculation etc on the received data.
BR
Siri
Thanks for the clarification, but is there a way to access the raw data?
I mean, I thought the buffer is getting populated if the CRC is passed or the callback is triggered if the CRC check passes. ( I mean the CRC that is applied to both sides automaticallty by the TI stack)
If you can access the raw data, in what type of RX callback I have to access the buffer to make sure it was populated correctly?
The only access to the raw data is via the Debug signals that can be output to a pin, as I referred to in my first respond:
You can look at the MCE_GPO0, which shows the Binary data signal that goes to the modulator when sending
There are no place where you can check what CRC has been calculated etc.
what about the data which are after the preamble and/or the synchword, I believe I could disable the TI stack's CRC, get the payload-buffer in the application and perform FEC and CRC. Is that right? My concern is that the TI stack would not populate the buffer if the CRC fails. So, I believe I have to disable the CRC but I am not sure how the buffer will be populated upon reception and when I have to access the payload for processing.
Which TI stack are you referring to?
You should not use any stack when transmitting/receiving something proprietary as you explain you want to.
You should use the prop API (CMD_PROP_TX or CMD_PROP_TX_ADV) and send the commands using the RF Driver directly.
In the commands you have full control to turn off CRC, not insert length info, not adding length info etc.
You can also configure what the preamble should be and the sync word.
There is nothing else added to the packets, and what you configure in the API is what you send.
For example, if you want to transmit the following packet:
0x55 0x55 0x55 (preamble)
0x93 0x0B 0x51 0xDE (sync)
0x01 0x02, 0x03, 0x04, 0x05, 0x06 (payload)
0xXX 0xYY (crc)
Then you configure the TX command and setup command like this (just showing fields relevant for the format)
RF_cmdPropRadioDivSetup.preamConf.nPreamBytes = 0x4; // 4 bytes preamble RF_cmdPropRadioDivSetup.preamConf.preamMode = 0x0; // Send 0 as the first preamble bit RF_cmdPropRadioDivSetup.formatConf.nSwBits = 0x20; // 32 bites sync RF_cmdPropTx.syncWord = 0x930B51DE; RF_cmdPropTx.pktConf.bUseCrc = 0x0; // Turn off CRC RF_cmdPropTx.pktConf.bVarLen = 0x0; Use fixed packet length RF_cmdPropTx.pktLen = 0x08; // Transmit 6 payload bytes and 2 CRC bytes RF_cmdPropTx.pPkt = packet; // The packet you want to send (packet[] = {0x01 0x02, 0x03, 0x04, 0x05, 0x06, 0xXX, 0xYY}
Thanks, I meant the proprietary stack. I see what you are saying. So, in the rx side, the buffer will always be populated and it can be access through the callback, right?
On the RX side, you need to use fixed packet length and set the packet length long enough for the longest packets you are transmitting (including the CRC).
Since you are encong your data manually, the receiver is not able to figure out the length atomatically from the data that is put in the data entry.
Siri