Advertisement packet missed for a while from ble tag

[paul0208]

Hi,

I am testing the advertisement packet scanner based from nRF5_SDK_17.0.2_d674dde\examples\ble_central\ble_app_uart_c.

At current stage, I can receive the advertisement packets from BLE peripherals including my BLE tag.

I found that the advertisement packet from my BLE tag are not received at BLE_GAP_EVT_ADV_REPORT event for a while(about 50 sec) and  after that adv packet are received about 50 secs and then no adv... from my tag while other adv packet received well.

At this time, my cellphone appl. made by Nordic receives the all adv packets which are lost at my scanner.

My tag sends adv packet every 5 secs. 

Scanner scanner is set to scan interval == scan window.

What is the problem?

BR

Paul

[paul0208]

scan interval and scan window are set to 625msec

[Kenneth]

Have you tried to change scan window and scan interval? What timeout have you set when scanning? For instance you can set timeout to 0 to scan infinitely. Do you have other BLE channels while scanning here?

Best regards,
Kenneth

[paul0208]

I did not try to change window and interval. most thread say small window and interval is better to scan.

timeout is set to 0.

Many BLE adv are scanned while my BLE tag adv packet are missing.

Other peripheral are sending adv packet very frequently.

when receive adv packet report, compare a parts of uuid field

case BLE_GAP_EVT_ADV_REPORT:
  {
  //printf ("BLE_GAP_EVT_ADV_REPORT\r\n");
  int i, found = 1;
  for (i = 0; i < 10; i ++)
    {
    if (memcmp (&m_scan.scan_buffer.p_data[9], tag_uuid_postfix, 10))
      {
      found = 0;
      break;
      }
   }

  if (found)
    {
    for (i = 0; i < 0x10 /*m_scan.scan_buffer.len */; i ++)
      {
      printf ("%02x,", m_scan.scan_buffer.p_data[i + 9]);
      }
    printf ("%d\r\n", p_gap_evt->params.adv_report.rssi);
    }
  else
    {
    printf (".\r\n");
   }
}
break;

BR

Paul

[Kenneth]

Hi Paul.

You are right that small scan window and intervals are preferred if you already have active BLE connections that you need to maintain, however if you are only scanning (no other BLE connections), then you may as well use 5seconds window=interval. So you may try that for test. I assume you are only scanning and not doing any advertisement and/or connection with another peer while scanning?

What hardware is used by the scanner? Is it an nRF52-DK or your own custom PCB?

Have you measured the time handling the BLE_GAP_EVT_ADV_REPORT event? Just want to see if it take a long time, and if it may somehow block other devices. What is the distance between the scanner and tag? Can you reduce the distance in case the problem may be related to noise.

Kenneth

[paul0208]

Hi, Kenneth.

Yes, I am just scanning.

Same results with my custom board and nRF52-DK. I will test 5sec window and interval and let you know.

I cannot block other devices I don't know which device send the adv packets, TV and ... 

I put LED blink in BLE_GAP_EVT_ADV_REPORT event state, I can see many LED blinking while my tag beacon are missing.

If I set window and interval to 5sec, is any problem to scan 3 broadcasting channels? Because my scanner has to scan a bunch of my ble tag(has unique UUID, 5sec broadcasting) simultaneously.

BR

Paul 

[paul0208]

Hi, Kenneth.

It was from my mistake.

SCAN_WINDOW define was a half of INTERVAL.

sdk_config.h file's location was wrong.

No missing adv packet from my BLE tag.

BR

Paul

[Kenneth]

Hi Paul,

There isn't much magic here, in general the softdevice will scan as configured (in other words it will scan one frequency for the configured window size, and then scan the next frequency (out of the 3) on next scan interval). The "dead" spots here will be if you have any other BLE activity also on-going that may interfere with this operation, flash erase or write operations, and/or if you are doing active scanning with many peers in the area, since active scanning will request scan response packets from the individual peers (indirectly blocking other devices during this operation (typically ~1ms).

Best regards,
Kenneth