The specifics of our wireless protocols require that we run CC1310 in the Proprietary Radio mode of operation.
All our tests at the moment are done on SmartRf evaluation boards and mostly based on the rfPacketRx_CC1310DK_7XD_TI_CC1310F128 and rfPacketTx_CC1310DK_7XD_TI_CC1310F128 reference projects.
Receive mode.
We need to use the Partial Read RX Entry and we need to be able to stop reception once we determine that we reached the end of packet.
Since we don’t know the length of the received data until we get the END OF PACKET marker we use a receive data queue with data entries in a circular buffer like in the rfPacketsRx reference design except we use Partial Read RX entries.
Once the reception is started the only viable way for us to stop it is by sending the CMD_ABORT. We use the RF_cancelCmd with the “abrupt end” parameter.
Here is what we observed and need help understanding/using:
- When the RF_cancelCmd function is executed, the call back function is called with the zero value in the RF_EventMask e variable. It is not documented anywhere and we would like to know if it is an anomaly and if we can use it as an indicator to the callback function that the abort command was executed.
- The Output structure is not updated when receive mode is terminated by either CMD_ABORT or CMD_STOP. This behaviour is not documented. We would like to use this structure.
- The RSSI value when requested by setting RF_cmdPropRx.rxConf.bAppendRssi = 0x1 is appended to the packet but is always set to 0x80. Note that the time stamp is appended properly. We need the RSSI.
I would like to add another question for the receive mode.
We found that the receiver generates call backs with the RF_EventRxEntryDone event at a rate that differs from what is actually received from the air by exactly one byte.
For example the size of each partial read entry in the receive queue is configured to be 11. 4 bytes of it are for the pktStatus and nextIndex fields, and the remaining 7 bytes are for user data. We confirmed, by examining the nextIndex after reception, that the radio puts exactly 7 bytes into each entry – nextIndex = 7.
But the interrupts come at a rate as if 8 bytes are received from the air.
With the link rate of 50 kbps each byte should take 160us, and one complete data entry – 7 * 0.16 = 1.12ms. In the actual test we see the ISR runs every 1.28ms, which translates to 8 bytes.
Can you tell us what is happening?
I should also add that as the entry size goes down, the interrupt behavior becomes pretty much chaotic. I may see a gap of a millisecond, followed by three interrupts in a span of 40 microseconds. Eventually the system hangs at a random time.
It is very important for us to use short entries, because we need to have low latency between the actual end of a packet and the moment we detect it.
Thanks!