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.

  • Resolved

SIMPLELINK-CC13X2-26X2-SDK: simplelink-cc13x2-26x2

Prodigy 190 points

Replies: 8

Views: 77

Part Number: SIMPLELINK-CC13X2-26X2-SDK

I've added a circular list to read multiple messages from the RF core butI only see one message regardless of how many transmitters are operating.
When I turn of either transmitter I get the message from the other meaning both are transmitting but when I loop through the rxQueue there's ever only
one message and it's always from the same source.

I used the circular list implementation from:

--dev.ti.com/.../data-queues.html--

When I walk the list and print all the status I can see all the slots are pending but I expected the read request to copy all available data into the available memory since there are multiple open slots.

I've tried waiting longer to see if the start/end duration wasn't long but that didn't change. below is the code to read from the RF core

/* Start RX command to receive packets. */
    RF_cmdPropRx.startTrigger.triggerType = TRIG_ABSTIME;

    //use the current time as the time to read any pending data
    //According to RF.h if startTime is in the past then we will
    //never fire so use a future time from now.
    RF_cmdPropRx.startTime =
            RF_getCurrentTime() + RF_convertMsToRatTicks(2);

    //set how long to wait before quitting
    RF_cmdPropRx.endTime = RF_convertMsToRatTicks(BEACON_INTERVAL_MS);
    RF_cmdPropRx.endTrigger.triggerType = TRIG_REL_START;

    RF_EventMask result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRx,
                                    RF_PriorityNormal,
                                    &WaitingForSyncState_rxCallback,
                                    RF_EventRxEntryDone);

    if ((result != RF_EventLastCmdDone) || ((volatile RF_Op*)&RF_cmdFs)->status != DONE_OK)
    {
        status1 = ((volatile RF_Op*)&RF_cmdFs)->status;
        status2 = result;

        snprintf((char*)msg.data,sizeof(msg.data),
                 "Failed to send run command. result(0x%X), status(0x%X)\n",
                 status2,status1);

        msg.type = log_error;
        msg.msg_size = strlen((const char*)msg.data);

        display(&msg);
    }

Thanks

  • Guru 53320 points

    Hi Jonathan

    Unfortunately it is not clear to me what exactly you are trying to accomplish and what is failing.

    From the code I see that you use both start trigger and endtrigger for the RX command, meaning that you are not cont. in RX.

    How are you making sure that you are in sync with your transmitters, and how do you make sure that your transmitters does not transmit at the same time.

    I would strongly recommend that you start with our rfPacketRX and rfPacketTX example from the latest SDK and make sure that you are receiving packets from both of the transmitters with that code. There you will also see how to setup a queue.

    BR

    Siri

     

     

  • In reply to Siri:

    Hi Siri,

    1. The original code was the rfPacketRX/rfPacketTx code from the TI sources.

    The code works as long as I'm sending only one packet.

    2. To rule out multiple transmission at the same time I used only one transmitter

    but send 4 packets and I increased the window I'm waiting for packets x 10. Only

    one packet is read.

    This effectively means I'm not doing something that the RF core needs to read multiple

    packets besides creating a list big enough to hold multiple messages.

    To reiterate, the intent is to read however many messages are in the RF core at one

    swoop but it doesn't look like creating a buffer big enough with the queue setup

    example in the documentation is working.

    Is there anything else that needs to be done besides setting up a large buffer in order

    for all messages that will fit in the buffer to be read?

    I'm adding pseudo code for tx/rx in case it helps:

    TX:

    1. setup  TX MCU for transmit

    2. send N messages

    3. wait some time

    4. repeat from 2

    RX:

    1. setup RX MCU for reading

    2. wait for incoming messages

    3. read all messages in the RF core at one go

    4. repeat from 2

    At the moment the issue is step 3 on the RX side because only 1

    message out of N will be read regardless of the time wait or the buffer

    size that can fit the messages

    Thanks

  • In reply to jonathan bondzie61:

    I also wanted to share the current RX settings. I've tried playing around with them but to no avail. See if I need to make any other mods.

    /* Modify CMD_PROP_RX command for application needs */
        RF_cmdPropRx.pQueue = &rxQueue;                /* Set the Data Entity queue for received data */
        RF_cmdPropRx.rxConf.bAutoFlushIgnored = false;  /* Discard ignored packets from Rx queue */
        RF_cmdPropRx.rxConf.bAutoFlushCrcErr = true;   /* Discard packets with CRC error from Rx queue */
        RF_cmdPropRx.rxConf.bIncludeHdr = true;        /* Put length field in front of queue entries. */
        RF_cmdPropRx.rxConf.bAppendTimestamp = true;   /* Append RX time stamp to the packet payload */
        RF_cmdPropRx.maxPktLen = sizeof(BeaconPacket); /* Implement packet length filtering to avoid PROP_ERROR_RXBUF */
        RF_cmdPropRx.pktConf.bRepeatOk = false;        /* Stop after receiving a single valid packet */
        RF_cmdPropRx.pktConf.bRepeatNok = true;

  • Guru 53320 points

    In reply to jonathan bondzie61:

    In the rfPacketRX example you have a queue with 2 data entries. Even if you set MAX_LENGHT to 255, once you have received a packet, even if it is only 10 bytes long, the status of the data entry is set to DATA_ENTRY_FINISHED, and this data entry cannot be used again before the application set it to DATA_ENTRY_PENDING.

    That means that as soon as you receive a packet (RF_EventRxEntryDone), the application need to process the data entry that holds the packet. While the application is doing this, the radio can receive another packet in the available data entry. Hopefully, when also this packet is received, the application are done processing the first packet and has made that data entry available for the next packet (RFQueue_nextEntry()).

    Siri

     

     

  • In reply to Siri:

    Hi Siri,

    from what you're saying it sounds like it doesn't matter how many queue entries you have

    available with the status set to DATA_ENTRY_PENDING, because the RF core will not

    automatically move to the next available entry to copy data. So are you suggesting

    to use a while loop with the radio core still in receive mode and as soon as the current

    entry is set to DATA_ENTRY_FINISHED you advance the buffer to the next one with

    DATA_ENTRY_PENDING?

  • In reply to jonathan bondzie61:

    I tried leaving the following:

    1. leaving the radio on

    2. manually advancing the queue to the next empty entry by setting

    rxQueue.pCurrEntry = (uint8_t*)ptr->pNextEntry;

    This has the status set to 0

    I don't see any extra data besides the single entry. The tx side isn't reporting any

    errors so I assume all the sends are valid (I'm using 4 sends). Do you have any

    suggestions or any code that successfully reads multiple data entries from the RF_CORE?

    Thanks

  • In reply to jonathan bondzie61:

    I've made some progress. I've been able to get all 4 messages sent by the sender, but only 1 of the messages is valid. I was able to see all 4 by setting the following RX options

    RF_cmdPropRx.maxPktLen - I set to more than 1 message
    RF_cmdPropRx.pktConf.bRepeatOk - true

    It has some other side effects but what I've seen so far is that the message header size is correct for all 4 but the data following is incorrect for 3 of them consistently.

    If you can think up any clues, it would be greatly appreciated. I'll set the buffers to some known values to see what is put in there, just in case the RF_CORE is just setting the status to 3 but not copying anything into the first 3

  • Guru 53320 points

    In reply to jonathan bondzie61:

    You can have several data entries, but it is you in your application that needs to set up the pointers correctly. If you have done so, and for example have set up a queue with 4 data entries, the radio can receive 4 packets (one in each data entry), before you read out the 4 packets. It is also the application that needs to make sure to access the correct entries when trying to read the data in the data entry. In the rfPacketRXexample, this is done by calling RFQueue_nextEntry();

    In the default rfPacket RX example, there are two data entries in the queue, meaning that you can receive two packets (on in each entry) without doing anything in the application.

    Please understand that that if you have x data entries, and wait until you have received x packets before starting to process them, you will not have an available data entry for your x+1 packet (given that you are still in RX).

    Not sure what you are trying to accomplish by changing RF_cmdPropRx.maxPktLen.

    maxPktLen has nothing to do with the data entries, it is simply used for length filtering in RX. If maxPktLen = 40, and the RF Core receives a length byte greater than 40, the packet will be discarded.

    Also, I am still confused as to why you need to change the rfPacketRX code at all. It is not a problem to use this code to receive packets from multiple receivers. The radio can only receive packets from one sender at the time, and if your senders transmit at the same time, the packets will most likely interfere with each other and none of them will be received.

    The rfPacketRX is handling the queue correctly and are showing you how this should be done. After a packet is received, it processes the packet and makes the data entry available again for the RF Core, while the next packet is received in the second data entry. When this entry is being handled, the RF Core will receive the 3rd packet in the first entry, and so on.

    Siri

     

     

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.