• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 16 subscribers
  • Views 702 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.

CC1352P7: Changing Custom RF PHY from rfSynchronizedPacket example

Mike Snyder
Intellectual 295 points
Part Number: CC1352P7
Other Parts Discussed in Thread: SYSCONFIG

Hi! 

I notice these examples used a custom setting PHY. I wanted to change that. 
I was able to get it working easily with 250 kpbs, 125 kHz Deviation, 2-GFSK, 471 kHz RX Bandwidth @ 2.440 GHz

When I tried to use 500 kbps, 190 kHz Deviation, 2-GFSK, 622 kHz RX Bandwidth @ 915 MHz,
the receiver notices's some activity, but bails before the data is transmitted. 

Event_PacketReceived does get posted. rxBuffer has some garbage, then all zero's. 


This is during waitingForSyncState().

  • Using the RFC_GPO0 and 1, the waveform shows
    • channel 0 is transmitting from the TX side
    • channel 6 is receiving on the RX side, and stops listening before the transmission is over
      • about ~240 us after 
  • I would think this would only happen if
    • TX and RX are tuned to different frequencies
    • pre-amble or sync word matching issue
    • some driver oversight when changing frequencies and just expecting it to work
  • Some differences to note
    • 500 kbps uses RF_cmdPropTxAdv/RxAdv, 250 kbps uses RF_cmdPropTx/Rx
    • different sized preambles and different sync words at 500 kbps and 250 kpbs 

Any ideas?


Here are my config redirection, the only code change to fresh imported examples:

// TI-RTOS RF Mode object
#define RF_prop                     RF_prop_2gfsk500kbps154g_0

// RF Core API commands
#define RF_cmdPropRadioDivSetup  RF_cmdPropRadioDivSetup_2gfsk500kbps154g_0
#define RF_cmdFs                             RF_cmdFs_2gfsk500kbps154g_0
#define RF_cmdPropTxAdv               RF_cmdPropTxAdv_2gfsk500kbps154g_0
#define RF_cmdPropRxAdv               RF_cmdPropRxAdv_2gfsk500kbps154g_0


  • 0
    Intellectual 295 points

    under TI Devices -> Device Configuration -> Force VDDR has also been enabled as advised by syscfg.

    Forgot to mention that. 

  • 0
    Intellectual 295 points

    I verified the transmitter is firing at 915 MHz with a spectrum analyzer. 

  • +1 in reply to Mike Snyder
    TI__Guru* 86831 points

    The rfSynchronizedPacket example uses the RF_cmdPropTx and RF_cmdPropRx commands, and a totally different packet format than what is exported for the 500 kbps settings. This format is IEEE 802.15.4g compliant, have a 2 bytes header after sync including an 11 bits length field.

    You cannot use this packet format in the rfSynchronizedPacket example without re-writing the application. The easiest would be to change the advanced RX and TX commands to transmit the "standard" packet format used by most of our examples (Sync word is followed by a length byte).

    If you look at the rfDiagnostics example, it shows how you can alter the 802.15.4g compliant packets to use the "standard" packet format.

    In radio.c, look for the following:

    //----------------------------------------------------------------------------------------------------------------------------
    // PhySettings_API_PROP + PhySettings_CMD_ADVANCED + PhySettings_TEST_RF_PERF
    //
    // Advanced TX command for Proprietary Phy's used for RF performance testing.
    // The packet format is altered compared to what is imported from sysConfig,
    // to utilize "standard" packet format with an 8 bits length field following
    // the sync word
    //----------------------------------------------------------------------------------------------------------------------------

    I recommend that you take the rfPacketRX and rfPacketTX examples (our easiest examples) and try to get these up and running with the modifications implemented in rfDiagnostics. When you have the 500 kbps PHY up and running with standard packet format, you can try these settings int other examples as well

  • 0 in reply to Siri
    Intellectual 295 points

    yes! thank you. Very helpful.

  • 0 in reply to Siri
    Intellectual 295 points

    So I actually had some interesting progress with a slightly different approach

    • use the rfPacketRx/Tx examples
    • selected 1 Mbps, 350 kHz Deviation, 2-GFSK
      • changed kbaud to 500
    • rfPacket examples worked immediately
    • my application worked immediately

    I can probably dial down some more of the PHY properties because we probably don't need that kind of deviation at half the baud rate. 

    I did mess around with the rfDiagnostics recommended approach. 
    When it didn't work fairly quickly I tried the other approach. 

  • 0 in reply to Siri
    Intellectual 295 points

    Hi Siri. I've recently come back to figure this out. 
    I wanted to clarify the steps because this is not yet working. 

    From radio.c in rfDiagnostics, it looks like these are the receiver modifications that are different than the ones I've been using.
    I assumed these were matching the TX settings for // PhySettings_API_PROP + PhySettings_CMD_ADVANCED + PhySettings_TEST_RF_PERF

                        RF_cmdPropRxAdv.pktConf.filterOp = 0;
                        // Addition settings for PhySettings_TEST_RF_PERF
                        if(PhySettings_supportedPhys[currentPhyNumber].PhySettings_testType == PhySettings_TEST_RF_PERF)
                        {
                            //---------------------------------------------------------------------------
                            // PhySettings_API_PROP + PhySettings_CMD_ADVANCED + PhySettings_TEST_RF_PERF
                            //---------------------------------------------------------------------------
                            RF_cmdPropRxAdv.pktConf.bCrcIncHdr = 1;
                            RF_cmdPropRxAdv.hdrConf.numHdrBits = 8;
                            RF_cmdPropRxAdv.hdrConf.numLenBits = 8;
                            RF_cmdPropRxAdv.lenOffset = 0;
                        }

    The confusing part is that the RX side is using 

    • RF_cmdPropRxAdv.hdrConf.numHdrBits = 8;

    • RF_cmdPropRxAdv.hdrConf.numLenBits = 8;

    when the TX side is using 

    • RF_cmdPropTxAdv.numHdrBits = 0;

    It feels like I'm looking in the wrong place.

    Also, bCrcIncHdr is 0 on both projects, and if we're going with numHdrBits=0, this is also weird. 

    Also worth noting, we allocate pktLen + 1 for the tx buffer to prepend 1 byte of length on the payload, as shown above

    • RF_cmdPropTxAdv.pktLen = ((uint8_t)(*pktLen)) + 1; 

    • in the payload ->  packet[0] = PAYLOAD_LENGTH;


    I can visualize the154g compliant payload

    | sync | 16 bit header including 11 bits of length | payload |

    And I think I can visualize the standard packet (no header) 

    | sync | payload[0] aka length | payload[1..n] | 

    Just a little confused. Thanks! 

  • +1 in reply to Mike Snyder
    Intellectual 295 points

    I had to ditch the appended bytes to get this to work. 
    Oddly it didn't work with CRC+RSSI+timestamp appended despite adjusting my buffers. 

    on the receiver, this finally worked

        RF_cmdPropRxAdv_2gfsk500kbps154g_1.pktConf.filterOp = 0;
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.pktConf.bCrcIncHdr = 1;
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.hdrConf.numHdrBits = 8;
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.hdrConf.numLenBits = 8;
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.lenOffset = 0;
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.rxConf.bIncludeCrc = 0x0,
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.rxConf.bAppendRssi = 0x0,
        RF_cmdPropRxAdv_2gfsk500kbps154g_1.rxConf.bAppendTimestamp = 0x0,

    on the transmitter, this worked

        RF_cmdPropTxAdv_2gfsk500kbps154g_1.numHdrBits = 0;
        RF_cmdPropTxAdv_2gfsk500kbps154g_1.pktLen = PAYLOAD_LENGTH + 1;

            packet[0] = PAYLOAD_LENGTH;
            packet[1] = (uint8_t)(seqNumber >> 8);
            packet[2] = (uint8_t)(seqNumber++);
            uint8_t i;
            for (i = 3; i < PAYLOAD_LENGTH; i++)
            {
                packet[i] = rand();
            }

  • 0 in reply to Siri
    Intellectual 295 points

    Siri!
    Here is where things get tricky, when moving from rfPacketRx to rfSynchronizedPacketRx. 

    • appending timestamp rfSynchronizedPacketRx
      • NUM_APPENDED_BYTES is 5 in this project, with status, header (length) byte, and timestamp
        • I would think that would be 6
      • In rfPacketRx, NUM_APPENDED_BYTES is 2, which is status and header (length) byte
    • rfPacketRx uses RF_runCmd, rfSynchronizedPacketRx uses RF_postCmd and StateMachine_pendEvents
      • the value of RF_cmdPropRxAdv.status is completely different.
        • Getting 0x2000 instead of PROP_DONE_OK
    • rxQueue and dataQueue are defined completely different. 
      • dataQueue uses RFQueue_defineQueue

    This is all worth mentioning because it came down to getting everything sized correctly down to the byte. 

    Once I can get this working, integrating into my app should be a breeze. 

  • 0 in reply to Mike Snyder
    Intellectual 295 points

    I changed it NUM_APPENDED_BYTES to 6 and it sync'd.
    I think this thread has served its purpose. Thanks again.