• State Resolved
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 56 subscribers
  • Views 227 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

Original question:

CC2652P: Low temperature test problem

CC2340R5: could you proived a zigbee RF test example ?

senjin
Prodigy 200 points
Part Number: CC2340R5
Other Parts Discussed in Thread: CC1352P, , SYSCONFIG

Tool/software:

I found this example for CC13XX in the following path.

ti\simplelink_cc13xx_cc26xx_sdk_7_41_00_17\examples\rtos\CC1352P_2_LAUNCHXL\prop_rf\rfDiagnostics

For the CC2340R5 chip, the related example I found in the prop_rf folder are all used for Bluetooth RF testing, but not related to zigbee. Can you provide this example

  • 0
    TI__Guru**** 211947 points

    Hi Senjin,

    There is no similar rfDiagnostics project currently available in the F3 SDK.  Are you able to use rfPacketTx/Rx projects where the SysConfig -> RF STACKS -> Custom module is changed from BLE to IEEE?  With a SWD connection you can also consider using Smart RF Studio 8.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 200 points

    Hi Ryan,

    We need a UART port, so that in production testing, it is more convenient to configure the transmission power, switch channels, and so on. RF STUDIO is not suitable for this application scenario. I think it may be more appropriate for me to modify based on rfPacketTx project, of course, better if you can provide similar rfDiagnostics project .

  • +1 in reply to senjin
    TI__Guru**** 211947 points

    Hi Senjin,

    It is entirely possible to add UART to the rfPacketTx/Rx projects to meet your configuration requirements.  There is a uart_rfCarrierWave example which supports UART commands for changing PHY, frequency, and TX power when executing the carrier wave test.  The only caveat is that it does not currently have the IEEE PHY as a selectable PHY.  You will therefore need to add  "rcl_settings_ieee.c/h" files to the setup folder (these will either be "Code Export" from Smart RF Studio 8 or copied from F3 SDK's propRF SysConfig-generated ti_radio_config.c/h files for the IEEE PHY) and modify uart_rfCarrierWave.c to add the new PHY or replace an existing one.  Then you can modify the example to support prop RF modes outside of Carrier Wave (Packet TX/RX, etc).

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 200 points

    I tesetd rfPacketTx/Rx projects, encounted compile problems, when I changed RF configuration from BLE to IEEE 802.15.4 250kbps. It seems that the current project cannot support 802.15.4. 

    For  rfPacketRx project, it shows unresolved symbol rclPacketRxCmdGenericRx.

    For  rfPacketTx project, it shows use of undeclared identifier 'RCL_REGISTER_FIELD_PBE_GENERIC_RAM_LENCFG_LENPOS' 

  • 0 in reply to Ryan Brown1
    Prodigy 200 points

    Sorry, I accidentally clicked on the resolved button.

    I still don't know how to add zigbee PHY to BLE project, can you provide a source code, thanks.

  • 0 in reply to senjin
    TI__Guru**** 211947 points

    Hi Senjin,

    For the rfPacketTx project, you can add these definitions to your project directly.

    Fullscreen
    1
    2
    #define RCL_REGISTER_FIELD_PBE_GENERIC_RAM_LENCFG_LENPOS 0x08
    #define RCL_REGISTER_FIELD_PBE_GENERIC_RAM_LENCFG_NUMLENBITS 0x08
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     

    For both projects, you need to use the "Generic 250 kbps, O-QPSK" IEEE 802.15.4 option.  Otherwise you won't be able to use the existing Generic RCL commands and further project migration will be required.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 200 points

    Hi Ryan, 

    My rfPacketTx projedt compiled success when I use  "Generic 250 kbps, O-QPSK" IEEE 802.15.4, thanks. Now I am tring to migragte zigbee tx function to rfCarrierWave  project.

    I found that the construct type used by rfPacketTx project is RCL_CmdGenericTx, while the construct type used in uart _ rfCarrierWave project is RCL _ CmdGenericTxTest.
    Where, the construct type RCL_ mdGenericTx, containing the variable txBuffers, can set the data to be sent, but not the variable txPower.
    The structure type RCL_CmdGenericTxTest, which contains the variable txPower, supports setting the transmit power, but has no variable txBuffers. And I need both functions.

    For the variable txPower, which now includes LRF_TxPower_Use_Max，LRF_TxPower_Use_Min，LRF_TxPower_Use_Raw options, what should I do if I need to set the transmit power to 10 dbm.

  • 0 in reply to senjin
    TI__Guru**** 211947 points

    Both of the structures you provided contain a RCL_Command_TxPower txPower field.  In the rfPacketTx example you would typically set the TX power by modifying rclPacketTxCmdGenericTx.txPower.dBm before calling RCL_Command_submit.  The carrier wave is in of itself a test wave which does not include a modifiable buffer.  The maximum CC2340R5 TX power is 8 dBm.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    // LRF_TxPowerTable data structure
    const LRF_TxPowerTable LRF_txPowerTable = {
    .numEntries = 0x0000000E,
    .powerTable = {
    { .power = { .fraction = 0, .dBm = -20 }, .tempCoeff = 0, .value = { .reserved = 0, .ib = 18, .gain = 0, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = -16 }, .tempCoeff = 0, .value = { .reserved = 0, .ib = 25, .gain = 0, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = -12 }, .tempCoeff = 5, .value = { .reserved = 0, .ib = 29, .gain = 1, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = -8 }, .tempCoeff = 18, .value = { .reserved = 0, .ib = 44, .gain = 1, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = -4 }, .tempCoeff = 28, .value = { .reserved = 0, .ib = 40, .gain = 3, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 0 }, .tempCoeff = 40, .value = { .reserved = 0, .ib = 21, .gain = 6, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 1 }, .tempCoeff = 65, .value = { .reserved = 0, .ib = 30, .gain = 6, .mode = 0, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 2 }, .tempCoeff = 41, .value = { .reserved = 0, .ib = 39, .gain = 4, .mode = 1, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 3 }, .tempCoeff = 43, .value = { .reserved = 0, .ib = 31, .gain = 5, .mode = 1, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 4 }, .tempCoeff = 50, .value = { .reserved = 0, .ib = 37, .gain = 5, .mode = 1, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 5 }, .tempCoeff = 55, .value = { .reserved = 0, .ib = 27, .gain = 6, .mode = 1, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 6 }, .tempCoeff = 75, .value = { .reserved = 0, .ib = 38, .gain = 6, .mode = 1, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 7 }, .tempCoeff = 80, .value = { .reserved = 0, .ib = 25, .gain = 7, .mode = 1, .noIfampRfLdoBypass = 0 } },
    { .power = { .fraction = 0, .dBm = 8 }, .tempCoeff = 180, .value = { .reserved = 0, .ib = 63, .gain = 7, .mode = 1, .noIfampRfLdoBypass = 0 } }
    }
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 200 points

    Hi Ryan,

    Thank you for your reply, I still have a few questions.

    1, I found the macro NUM_DATA_ENTRIES in rfPacketTx project is set to 5, does that mean sending 5 packets at a time? If I want to enter continuous sending mode, can I set NUM _ DATA _ ENTRIES to the maximum value. 

    2, For rfPacketRx project, I found the macro NUM_DATA_ENTRIES  is set to 2, what should I do if I want to go into continuous receive mode? 

    3, For rfPacketRx project, I want to get the PER results, what should I do?

  • 0 in reply to senjin
    TI__Guru**** 211947 points

    1. It will not since the code is essentially only using one of the two TX buffers established.  Please reference the Buffer Management explanation for more details.  What you should do instead is determine your transmit interval based on the PACKET_INTERVAL which determines the sleep time in between packets.

    2. The rfPacketRx is already continuously in receive mode, serving the defaultCallback to toggle the LED whenever a packet is received.  The  rclPacketRxCmdGenericRx command is in repeat mode and is never cancelled from within this project's default operation.

    3. You would have an agreed upon transaction sequence between the TX and RX devices.  For example, the rfPacketTx would populate the packet data with an incrementing packet count and have the rfPacketRx read this value for every packet reception.  If sequence numbers are missing or do not arrive within the expected time then this would indicate to the rfPacketRx code that packets are missing and thus contribute to the total PER.  You can also take inspiration from the rfPacketErrorRate example.

    Regards,
    Ryan