CCS/CC2652R: [RTLS]Master report time is not synchronized with Passive

update picture 

Even change CTE interval to 2s, Master/Passive still report different channel in the same time

Hi Clément,

Even if I adjust the CTE interval to 10s, Master/Passive report channel are still difference in the same time

Are you sure you can get the same channel in the same time?

In your picture, have 2 types report. with CTE and w/o CTE, Do you know what API will send report w/o CTE

Hi Valery,

Valery Wu said:

Even if I adjust the CTE interval to 10s, Master/Passive report channel are still difference in the same time. Are you sure you can get the same channel in the same time?

Do you have some logic analyzer traces of the UART communication you can share here?

Valery Wu said:

In your picture, have 2 types report. with CTE and w/o CTE, Do you know what API will send report w/o CTE

Actually the two reports are made by the same API. The report without CTE are generated after a connection event where no CTE has been sampled.

Regards,

Do you have some logic analyzer traces of the UART communication you can share here?

  ==>No, i don't have logic analyzer, but Can you get the same channel from Master/Passive in your side? if yes, I will go to borrow one

Actually the two reports are made by the same API. The report without CTE are generated after a connection event where no CTE has been sampled.

  ==>Do you mean sometimes device can't sampled CTE but can decode header?

Hi,

Valery Wu said:

i don't have logic analyzer, but Can you get the same channel from Master/Passive in your side? if yes, I will go to borrow one

Yes, I am getting the same channels from master and passive. As you will see in the attached screenshot, the channels reported are identical for the passive and the master.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/master_5F00_passive_5F00_CTE.logicdata

Valery Wu said:

Do you mean sometimes device can't sampled CTE but can decode header?

No. As we discussed in a different thread, the CTE are sent every second connection event. It is then expected to not get CTE report every second connection event.

Regards,

Hi Clément,

the channel num of Master and Passive are not match

below is our data type and channel num is byte 16

check the 2nd data of Passive

aoa_channel.zip

Hi Valery,

The traces you have provided seem different than the ones we can expect with the out-of-the-box software. The reports look longer and you seem to receive only connection events with a CTE.

On the attached image, I have written the channels number stated in each report. It appears the very first one is identical (0x1E). Then the channel is incremented by 10 on the master side, while incremented by 15 on the passive side. After this, the increments seem to be correct i.e. the channel delta remains the same.

I don't think the passive is listening on the wrong channel if not it would lose track of the connection after 30 events missed and would not report IQ data. I am rather considering an error in the channel reported. We could confirm this hypothesis by collecting at the same time the BLE traces and the UART traces (some Ellisys analyzers are able to do this).

Have you modified something on the rtls_passive code? Could you remind me which SDK version you are using?

Best regards,

I am using SDK4.3

I just add MAC address of tag in Passive packet.

Do you have any idea of Passive channel num is not sync with Master, if sniffer log just show the channel num of Master (like our another discussion thread)

I will be on vacation until 2/17, and will update new LA log after that.

Hi Valery,

May I ask you to slightly modify the function ubCM_setupNextCMEvent() in the file Application/micro_ble_cm.c?

You should find the following piece of code:

  // The CM endTime is a bit different than a standard slave. We only want to keep Rx on
  // long enough to receive 2 packets at each AP, one Master and one Slave if present.
  // Therefore we only need to at most remain active for the full timeoutTime + the duration
  // it takes to receive to max size packets + 300 us or 2*T_IFS for the min inter frame timing.
  // 1515 us is based on the time it takes to receive 2 packets with ~160 byte payloads + headers.
  scanDuration += (BLE_RAT_IN_1515US + 2 * BLE_RAT_IN_150US);
  connInfo->scanDuration = (scanDuration / BLE_TO_RAT) + 1;
#if 0 // issue on multi channel, will be fixed on next releases
  // next channel should always be calculated by adding only 1 hop (not numEvents)
  // on indicationCB() - set timeStamp of last data time from master/slave
  // on completeCB - calculate of numEvents of missing indications to set the new start time for the scan
  // but the next channel to scan should not use the num of missing indications it always increment by 1 hop
  // !!! do it only after first scan complete
  {
    static int entryCount = 0;
    if (entryCount++ >= 1)
    {
      numEvents = 1;
    }
  }
#endif

Please change the #if 0 to #if 1 in order to activate this code.

I wish you nice vacation :)

Kind regards,

Hi Clément,

I didn't change the code of micro_ble_cm.c

I get the same result after active the code you mention. (attach the BLE sniffer log/LA log/RAW data )

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

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/50-MHz_2C00_-5-B-Samples-_5B00_10_5D005F00_2021_5F00_0220.7z

Hi Valery,

Valery Wu said:

I didn't change the code of micro_ble_cm.c

I am not sure to well understand. It could be nice to at least try the suggested change.

Regards,

Hi Clément,

about the report without CTE(CTE request frame) can't find in my LA log.

I think that is because CTE request frame be drop in below code

#ifdef RTLS_PASSIVE
void RTLSCtrl_postProcessAoa(uint8_t connHandle, uint8_t resultMode, int8_t rssi, uint8_t channel, uint8_t sampleCtrl)
#else // RTLS_MASTER
void RTLSCtrl_postProcessAoa(rtlsAoaIqEvt_t *pEvt)
#endif
{
  uint8_t antenna;

#ifdef RTLS_PASSIVE

  AOA_postProcess(rssi, channel, samplesBuff);

  // Poll until we have samples to work with
  while(AOA_getSampleState() == SAMPLES_NOT_READY);

  // If samples are not valid, nothing to do here
  if (AOA_getSampleState() == SAMPLES_NOT_VALID)
  {
    return;
  }

Sorry i mean i didn't modify micro_ble_cm.c before you suggestion.

The result have apply your suggestion(change #if 0 to #if 1)

Please help to check why Passive still report wrong channel ID?

I think the mechanism of Passive finding Channel and reporting Channel is very strange

Master frame #159 find invalid CRC and the time interval becomes 150ms
Passive also hopping 150ms at the same time,

Slave only sends one CTE packet at one channel, one time

I think this means that Master/Passive is reporting the same CTE channel at the same time, but Passive's Channel ID is wrong

The code of Passive seems to set the expected channel to BLE stack to catch the CTE and report IQ with this channel, so if the channel IQ report is wrong, it means the expected channel is wrong, but why BLE stack can catch CTE with wrong expected channel?

How do BLE stack know the correct channel? if Yes, Why don't report correct channel to application layer like Master?

P.S. I can reproduce this issue on TI EVB board and use original SDK4.3 without any change.  Did you can get the same channel at the same time for Master and Passive?

Hey Valery,

You may be interesting to use some toggle some pins in the code to have a better picture of what is going on.

I am currently doing this with the IOD6 and 7 (corresponding to the LEDs of the launchpad). Here how to proceed:

- using SysConfig add support for one GPIO (and set it properly)

- In main.c, in function main(), after PIN_init() call add the following:

  GPIO_setConfig(CONFIG_GPIO_LED_0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);
  GPIO_setConfig(CONFIG_GPIO_LED_1, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

- You will require the following includes in main.c:

#include <ti/drivers/GPIO.h>
#include "ti_drivers_config.h"

- in the file you want, add the proper includes (see previous step) and use the GPIO functions you want:

  GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON);
  GPIO_write(CONFIG_GPIO_LED_1, CONFIG_GPIO_LED_ON);

  GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_OFF);
  GPIO_write(CONFIG_GPIO_LED_1, CONFIG_GPIO_LED_OFF);

  GPIO_toggle(CONFIG_GPIO_LED_0);
  GPIO_toggle(CONFIG_GPIO_LED_1);

I am currently using this technique in order to understand the issues we are working on.

Best regards,

Hi Valery,

We are agree if the passive and the master do not report the same channel number for the same connection event, then it means we have a problem.

For the moment I do not manage to reproduce (or at least I am not sure if I reproduce the same thing like you hence the message on our other thread).

Valery Wu said:

Master frame #159 find invalid CRC and the time interval becomes 150ms
Passive also hopping 150ms at the same time,

Actually, I guess the connection interval is 50ms, so having a jump of 2+1 connection intervals on both the master and the passive after a CRC error is a good sign.

As a side note, have you reviewed our latest SDK (4.40). We have released connectionless-AoA. I know this is not totally related to this thread but I think it could be useful for your use-case.

Regards,

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,