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.
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:
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_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,
if ((result != RF_EventLastCmdDone) || ((volatile RF_Op*)&RF_cmdFs)->status != DONE_OK)
status1 = ((volatile RF_Op*)&RF_cmdFs)->status;
status2 = result;
"Failed to send run command. result(0x%X), status(0x%X)\n",
msg.type = log_error;
msg.msg_size = strlen((const char*)msg.data);
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to 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:
1. setup TX MCU for transmit
2. send N messages
3. wait some time
4. repeat from 2
1. setup RX MCU for reading
2. wait for incoming messages
3. read all messages in the RF core at one go
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
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;
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()).
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
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?
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 messageRF_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
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.