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.

CC2650RC: With RemoTI stack on CC2650, PA/LNP are not being asserted when sending ACKs

Part Number: CC2650RC
Other Parts Discussed in Thread: CC2650, REMOTI, CC2592, SMARTRFTM-STUDIO, LAUNCHXL-CC2650

We are using RemoTI v2.0.1 with a CC2650 and have the RNP stack/application working on the CC2650 Launchpads, and are able to bind/pair and send/receive data.  However, the PA signal does not get asserted (and LNA de-asserted) when sending an acknowledgement (ACK) after receiving data on the target/recipient (see attached waveforms showing DATA_REQ from both the target and contoller).  Therefore, when testing on a custom board with a CC2592 range extender, the controller/originator sending the data does not receive the ACK and continually resends the packet until it times out.  Note that the behavior of the PA/LNA signals does look correct on the device sending the data request, and during the bind/pair process.  It also works correctly for the ACKs on the controller/originator version of the stack.  Can someone confirm if this is a bug in the stack code (assuming in rcnsuper-cc2620.a), or if something else needs to be configured differently?

rnp_app and rnp_stack examples from rti_sdk_2_00_01_15 using RTI interface.

Built with MODULE_CC26XX_5X5 and PA_LNA_CC2592 defined.  Configured IO pins 7 and 13 for GPO0 and GPO1 functionality.

Seeing same behavior on CC2650 Launchpad and on custom board with CC2650F128RHBT and CC2592 range extender.

Target sending a DATA_REQ to Controller and seeing an ACT from the Controller

Controller Sending a DATA_REQ and not seeing an ACK from the Target

  • Hi Henry,

    Just to be clear, you do not see any issues when using LAUNCHXL-CC2650 boards?  Can you confirm with SMARTRFTM-STUDIO or a spectrum analyzer that the CC2592 front end is properly driving a high TX output?  Maybe a sniffer would be able to provide more clues in regards to the RSSI and signal strength.  The PA settings should only modify pin and RF table functionality, I would not expect the MAC ACK of a particular command to be affected.  Please be advised that the REMOTI RF4CE solutions, although active, have not been modified since 2016 and there are no resources available for further maintenance or development.

    Regards,
    Ryan

  • Hi Ryan,

    With the Launchpads, communication and ACKs work correctly, as without the CC2592 range extender, the PA/LNA are not connected to anything.  When testing on custom hardware with the CC2592, I'm assuming the ACKs are being sent, but without the PA/LNA being toggled this get blocked and not transmitted by the CC2592.  It very much appears to be an issue in the software in the RemoTI stack.

    We had previously tested this hardware using the EasyLink examples (and with SmartRF Studio) and toggling the PA/LNA signals with callback functions and everything appeared to work correctly.  However, the customer wants to use the RF4CE stack to have the pairing, security, channel agility, and other functionality available with it.

  • Thanks for clarifying Henry, I've sent you an E2E friend request so that we can continue this conversation through private messaging.

    Edit: Also, have you tried to see what happens if POWER_SAVING is not defined?  I also recommend trying HAL_PA_LNA/HAL_PA_LNA_CC2592

    Regards,
    Ryan