CCS/CC2652R: [RTLS]sometimes channel hopping discontinuity

attachment

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/01_5F00_22_5F00_2021_5F00_18_5F00_39_5F00_58_5F00_rtls_5F00_raw_5F00_iq_5F00_samples.7z

Hi,

Thank you for your inquiry. I notified one of my colleagues and he will respond as soon as possible.

Best regards,

Rafael

Hi Valery,

Thank you for all the investigation you have done.

To complete your observations, could you specify which SDK version you are using? Are you using unmodified rtls_master and rtls_passive?
In your measurements, can you confirm that 58:93:D8:6A:A9:5F is the passive device and 58:93:D8:6A:A9:6F is the master?

For your reference, "Master have talk to Slave to ignore some hopping channel" is call "Channel Map Update". You may want to verify in the sniffer logs to see if any channel map update is requested by one of the devices. In addition, you could verify the sequence of the channels used by the peripheral (rtls_slave).

For the moment I wonder if the computer could drop a few UART frames every time in a while. I say this because it does not make sense the passive can keep track of the connection even if it loses 18 successive packets. All these additional questions will confirm or not this theory :)

Best regards,

Hi again,

Would you also agree to share the BLE sniffer logs with us?

Best regards,

I use SDK4.3 and 58:93:D8:6A:A9:5F is the passive device ,58:93:D8:6A:A9:6F is the master

What condition will cause channel map update, because i didn't find this problem on conductive mode

It doesn't make sense the passive can keep track of the connection even if it loses 18 successive packets

==>Looks like Passive allow 30 consecutive missed pkts

// Threshold for consecutive missed packets in monitor session before terminated link
#define BLE_CONSECUTIVE_MISSED_CONN_EVT_THRES       30

Passive catch consecutive pkt which didn't be transmitted, but lost consecutive pkt which be transmitted. and both pkt numbers are same. I think Passive have a bug

about sniffer log.

tool is too big, so i just can provide the download linkhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/2021_5F00_1_5F00_22_5F00_AOA_5F00_frame_5F00_drop_5F00_test.7z

Hi Valery,

Thank you for the traces provided. I had a look at them.

I noticed that the peripheral appends CTE to every second packet. Is it expected behavior from your side? Is it the way you configure it?

Best regards,

Is it expected behavior from your side? Is it the way you configure it?

no, i didn't configure it. Is that default behavior?

Originally, I thought the Slave keep sending CTEs and the Master return ACK to confirm every CTE be received.

Did you see channel map update between chan11 and chan27?

Hi Valery,

I haven't yet found the issue, but let me summarize the findings:

• As mentioned before, I see that only every second packet is appended with a CTE. This behavior is not the one we typically expect.
• In this specific case, the channel hop increment is 8. As CTE are received only every second packet, it looks like the channel increment is 16 (cf. your xlsx document).
• There is absolutely no channel update.
• There is absolutely no error in the channel hops (it is always 8).  
• At some points the rtls_slave may not transmit the CTE three times in a row. So the channel increment looks like 3x8=24. I don't know yet why the device does this.

Now I would like to understand:

• why is there only one CTE every second BLE packet
• why the rtls_passive and the rtls_master do not report the exact same channel at the same time

To do so, I am going to run the same tests as you.
It would help if you could do the following:

• provide the python script used to control the rtls_master and rtls_passive
• give details on all the modifications made in the rtls_master, rtls_passive, rtls_slave projects

Best regards,

I just modify theses item in Master and Passive

1.ANT switch table

2.combine all IQ data to one packet(32 reference +192 sampling IQ data) from UART to PC

3.use pkt count to replace handle

4.show BT MAC address of IQ data provider and slave BT MAC

I didn't change code of Slave besides some shared files between Master and Slave,

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/rtls_5F00_aoa_5F00_iq_5F00_with_5F00_rtls_5F00_util_5F00_export_5F00_into_5F00_csv_5F00_valery.7z

Master + Slave (All are original SDK4.3) still have only one CTE every second BLE packet

Hi Valery,

I confirm it is expected behavior for the rtls_slave to send only one CTE every second connection event. In order to finish one CTE procedure it should take 2 connection events – in the first connection event we send the CTE request, in the second we receive the CTE response and in the third we send again the CTE request.

At one point, you may see a different hop increment due to a packet loss. Typically, if the rtls_master sends the CTE request (LL_CTE_REQ) an this request is not received by the rtls_slave, then the rtls_slave won't append the CTE to the next connection packet.

Best regards,

thx Clément

I have more questions

1. why the rtls_passive and the rtls_master do not report the exact same channel at the same time. and how to sync channel with Master after 18~19 packets?

2. Passive often loses consecutive 18~19 packets,have any discard window even Passive just lost small amount of packets

Hi,

Valery Wu said:

1. why the rtls_passive and the rtls_master do not report the exact same channel at the same time.

I haven't seen this issue yet. Actually, when a connect a logic analyzer to the the rtls_passive and the rtls_master I see the same channels being reported. The results yield by the python script may let you think the two devices are reporting different channels but this is not the case. This impression may be caused by the passive missing some connection events.

Valery Wu said:

how to sync channel with Master after 18~19 packets?

An idea could be to let the devices toggle a pin every-time they sample a CTE on an arbitrary channel (e.g. channel 10). Then you can have a synchronization.

Valery Wu said:

2. Passive often loses consecutive 18~19 packets,have any discard window even Passive just lost small amount of packets

This is one of the limits of the topology including one master and one (or several) passive(s). The passive devices do not participate in the connection and cannot request a re-transmission when needed. In addition, the passive receives way more data (because it sniffs the RF packet coming from both sides).

Best regards,

I haven't seen this issue yet. Actually, when a connect a logic analyzer to the the rtls_passive and the rtls_master I see the same channels being reported. The results yield by the python script may let you think the two devices are reporting different channels but this is not the case. This impression may be caused by the passive missing some connection events.

[Valery] Can you reproduce that Master or Slave lost packets?

             I have add packet num in report field of passive, the pkt num is consecutive, This has nothing to do with python script.

            What can I do to help accelerate the analysis of this problem?

An idea could be to let the devices toggle a pin every-time they sample a CTE on an arbitrary channel (e.g. channel 10). Then you can have a synchronization.

[Valery]sorry, i means if Passive record wrong channel number, how can it correct to right channel num after 18~19 channel. (Synchronize on Channel 35)

This is one of the limits of the topology including one master and one (or several) passive(s). The passive devices do not participate in the connection and cannot request a re-transmission when needed. In addition, the passive receives way more data (because it sniffs the RF packet coming from both sides).

[Valery] Are there any parameters that can be adjusted? I wish Passive could catch up with the AOA channel sooner.

Hi Valery,

We need a bit of time to work on this issue.

Please allow us a week and expect an answer for February, 8th.

Best regards,

Hi Clément,

I don't know if that are same problem.

but I attach all files in thread.

1. In RAW report, we can find Master lost some packet and shift AOA channel

check the sniffer log. the CRC of channel 1 CTE is error, but why Master still capture this frame and report to user?  Is the IQ information correct?

2. I first assume that the channel of Master and Passive are same at the same time. Passive still catch the non-existent channel CTE.

    and recover the channel ID after 19 frame

   

P.S. I can reproduce this issue on TI EVB board and use original SDK4.3 without any change

Hi,

I want to focus on reproducing the problem. Could you help me to do so?

Valery Wu said:

I can reproduce this issue on TI EVB board and use original SDK4.3 without any change

What is the reproducibility? Are you doing something to jam some packets or are you just running the example freely? What are the parameters sets? Could you provide the python script you use?

Regards,

I tested 3 times, 100%.

running free, didn't change SW and script besides COM port and measurement time.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/rtls_5F00_aoa_5F00_iq_5F00_with_5F00_rtls_5F00_util_5F00_export_5F00_into_5F00_csv.7z

Hi Valery,

I have run the same python script like you.

First time I used embedded code (rtls_master / rtls_passive) from SDK 4.30 (like you), second time I used embedded code from SDK 4.40.

I have attached my results. Could you comment if you can see the problem appearing on both tests or not?

VALERY_SDK_4_30_rtls_aoa_iq_with_rtls_util_export_into_csv_log.zip

VALERY_SDK_4_40_rtls_aoa_iq_with_rtls_util_export_into_csv_log.zip

Hi Valery,

As the thread is reaching the 30 days since its opening, I would recommend you to open a new one - I will pick the thread when you open it.

This is in order to avoid having this thread locked or I lose track of it.

Thanks and regards,

Yes, I see the same problem on both log

Did you have any update about passive's channel report?

Hi,

Have you reviewed the UART traces too? Do you see issues there too?

Could you highlight the problem occurrences in the log I provided?

Thanks and regards,

I just see the same issue like this thread.

Yes, I have checked UART traces

Hi Valery,

Thank you for the confirmation. With all the data I have opened an internal thread to track the issue.

From my observations, I assume the master reports the channel of the previous PDU (i.e. of a PDU without CTE). I do not have a BLE analyzer to confirm that. But could you verify this observation for me? To do so I think we could use the Ellisys to collect at the same time the UART and the BLE signals.

In the meantime, a work around could be to add one hop to the channel reported by the rtls_master. If it was not clear, usually you have two hops between two IQ data reports (because a CTE is appended to every second connection packet).

Best regards,