LAUNCHXL-CC26X2R1: Some questions about the periodic advertising process of the RTLS responder

已经收到了您的案例，调查需要些时间，感谢您的耐心等待。

Hi,

If I understand correctly, you're trying to create a RTLS responder from your usrp device, and have a CC26X2R1 be the RTLS coordinator, is that correct ?
The image that you sent is a schema of BLE extended advertising, and not BLE regular advertising. I'm not sure that our example for the RTLS coordinator for the CC26X2R1 supports extended advertising.

In BLE regular advertising, the peripheral (RTLS repsonder in your case) sends 3 ADV_INT packets, one in each of the primary advertisement channels, and does not advertise in the data channels . 

You could try to first have this advertising format to work, and then tackle the more difficult issue of emulating BLE extended advertising on your USRP device and the RTLS coordinator.

Another thing I should mention is that RTLS is not officially supported anymore (it has been removed from SimpleLink Academy), and is mainly being replaced by channel sounding, which provides the same features as RTLS but with better results. You can have a preview of channel sounding in our newest SDK version (9.11), but it is only available for the CC23xx and CC27xx devices.

Hi Links,

Your understand  is correct, i am trying to emulate my usrp device as RTLS responder, and a CC26X2R1 be the RTLS Coordinator, to implement the RTLS iq sampling function and AoA function.

According to what I saw in the Bluetooth manual and the manual you provided，i think the periodic advertising(which is a kind of BLE extended advertising) is necessary for the connectionless AoA process. The Responder need to transmit Constant Tone Extension field in the AUX_SYNC_IND packets, and the Coordinator sampling IQ data based on this field. This process is based on periodic advertising.

After receiving your reply,  i try to capture the packet from my another CC26X2R1 which is a real RTLS Responder with a BLE sniffer. The images are as follows, i think is a complete periodic advertising process(actually There are so many AUX_SYNC_IND packet, I only took a screenshot of one.)

You suggested that I try the simplest ADV_IND packet format, in fact i have made it. And i can also transmit the ADV_EXT_IND packet in the Advertising channel with my usrp(they are all captured with sniffer).

But when i try to implement the AUX_ADV_IND and AUX_SYNC_IND in the data channel, I tried many times but all failed. This confused me because I took the same approach as before and referred to the actual captured packets, and there should be no errors in the packet format and content.  

So I wonder if there is a strict and precise timing relationship between these packets? Or if there is any additional bit process(I used simple BLE 1M PHY no coded) required when sending packets on the data channel?

Looking forward to reply！