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: EasyLink not receiving back to back transmissions

Part Number: CC1352P

Hi,

I'm working on a custom system that is set up with one cc1352 acting as a controller and multiple others acting as sensor nodes (there could be as many as 20 or more when fully deployed). For most of the communication between the controller and the nodes it is a one to one communication. Everything uses the same EasyLink address, but we have unique IDs built into the payload so only the expected sensor acts and responds. This works as expected when we've tested it. All the sensor nodes receive the EasyLink transmission but only one will respond.

We're having an issue however with the couple of commands that will require all of the sensors nodes to respond. We're currently testing with a system with 2 sensor nodes, and the controller is only seeing a single response instead of the two we expect to see. There is a random time delay added before calling the transmit on each sensor node, coupled with using EasyLink_transmitCcaAsync() as the transmit function, so the sensor nodes should not be trying to respond at the same time. Likewise, the tx callback function is consistently called with a status of EasyLink_Status_Success, so it appears the that transmit is happening successfully on both sensor nodes. The controller however is only receiving a single EasyLink packet. This functionality is vital as it is how the controller will initially find sensor nodes. For ease of deployment we need to avoid finding sensor nodes one at a time.

We are at a loss as to why we are seeing this behavior. We've tried multiple different settings for the CCA in the .syscfg but that hasn't seemed to help at all. Our two main questions are:

  1. Why are we seeing this behavior of only one transmission actually being received?
  2. What can we do to solve this issue, or what could we do as a workaround?

This is what we have for our transmit and receive functions. Both the transmit and receive functions are based on the example projects rfEasyLinkTx and rfEasyLinkRx.

int32_t Transmit
(
    uint8_t* payload,   ///< Buffer containing the data to send
    uint8_t length      ///< Number of bytes to send
)
//-----------------------------------------------------------------------------
{
    EasyLink_TxPacket txPacket =  { {0}, 0, 0, {0} };
    int8_t i;
    int32_t returnVal = -1;

    if ((RFEASYLINKTXPAYLOAD_LENGTH < length) || (payload == NULL))
    {
        returnVal = -2;
        return (returnVal);
    }

    /* Set the transmission flag to its default state */
    txDoneFlag = false;

    // Fill the tx payload with the passed in payload
    for (i=0; i<length; i++)
    {
        txPacket.payload[i] = payload[i];
    }
    txPacket.len = length;

    //The payload has the actual destination address
    txPacket.dstAddr[0] = DEST_ADDRESS;
    txPacket.absTime = 0;   //Send the packet immediately

    /*
     * Set the Transmit done flag to false, callback will set it to true
     */
    txDoneFlag = false;

    /* Transmit the packet */
    EasyLink_transmitCcaAsync(&txPacket, TxDoneCb);

    return (returnVal);
}

int32_t Receive
(
    uint8_t* payload,   ///< Buffer to hold the received data
    uint8_t* length     ///< Buffer to hold the number of received bytes
)
//-----------------------------------------------------------------------------
{
    int8_t i;
    int32_t returnVal = -1;

    if ((payload == NULL) || (length == NULL))
    {
        returnVal = -2;

        return (returnVal);
    }

    //Check that we aren't trying to send a command out
    while (true == sendingCommandFlag)
    {
        //wait until the command is sent
        usleep (1000);
    }

    // Set the Receive done flag to false, callback will set it to true
    rxDoneFlag = false;

    // Wait to receive a packet
    while (EasyLink_Status_Success != EasyLink_receiveAsync(RxDoneCb, 0));

    while (rxDoneFlag == false)
    {
        /* Break if timeout flag is set */
        if (rxTimeoutFlag == true)
        {
            /* Reset the timeout flag */
            rxTimeoutFlag = false;

            /* RX timed out, abort */
            if (EasyLink_abort() == EasyLink_Status_Success)
            {
                /* Wait for the abort */
                while (rxDoneFlag == false){};
                returnVal = -2;
            }
            break;
        }
    }
    if (0 < recLen)
    {
        //fill received data and byte count to output parameters
        *length = recLen;
        for (i=0; i<recLen; i++)
        {
            payload[i] = recPayload[i];
        }
        returnVal = 1;
    }

    recLen = 0;
    memset(&recPayload, 0, sizeof(recPayload));

    return (returnVal);
}

Tim

  • Without being able to reproduce your setup here, it is hard to tell why you are not receiving both packets.

    To debug this, I would strongly recommend that you output the LNA and PA signal from the RF Core, to be able to use a logic analyzer to monitor when your devices is in RX (LNA) mode or TX (PA) mode.

    Please take a look here to see how these signal s can be output:

    RF Core — SimpleLinkTm CC13XX/CC26XX SDK Proprietary RF User's Guide 5.10.00 documentation

    Once a packet is received, the RF Core exit RX mode, and it will take some time to enter RX again.

    If looking at the default rfEasyLinkRX and TX example and output the LNA and PA signals, the timing looks like this:

    You will see that there is a delay from the transmitter is done (PA signal de-asserted) until the receiver is entering RX again (LNA signal asserted) of 540 us (which corresponds to 27 bits at 50 kbps). That means that if your second transmitter starts to transmit just when the first transmitter is done, the receiver will barely have entered RX again, and might miss the sync word

    Siri

  • It ended up being an issue with the software bogging down and not calling receive fast enough on the controller. Those signals helped a lot in debugging and it's working now!

  • Glad to hear you were able to get it up and running :-)