Extended advertised Server not recognized by whitelist

[djdehaan]

I find an error in having Extended advertised Servers not being recognized by whitelist.

This is what I test. I have 3 servers and 1 Central. Without filtering on the Central, all devices can and will connect. The central stores the NimBLEAddress from those 3 servers in the whitelist. Then I set the filter to USE_WL (with a Serial command - the Central device keeps running). When powercycling those devices, only the one using normal 1M PHY (and not using extended advertising) is recognized and immediately reconnected. The other 2 are advertising using CODED_PHY and are not recognized by the central - hence do not reconnect. So, when the filter in the central is BLE_HCI_SCAN_FILT_NO_WL the are connected (and the address added to the whitelist), and when the filter is set to BLE_HCI_SCAN_FILT_USE_WL the CODED_PHY ones do not reconnect. The 2 CODED_PHY ones are both an ESP32-S3 and a nRF52840.

The advertisement part of the Servers is as follows:

  /** 
   * Create an advertising instance and add the services to the advertised data 
  */
  NimBLEExtAdvertisement extAdv(primaryPhy, secondaryPhy);
  //NimBLEExtAdvertisement extAdv;
  extAdv.setAnonymous(false);
  sprintf(BLEname, "%s%04d", WHX_PREFIX, Config()->WHX_IDX);
  extAdv.setName(BLEname);
  extAdv.addServiceUUID(BleServiceWhx->getUUID());
  extAdv.setConnectable(true);
  extAdv.setPreferredParams(0x20, 0x40);

  NimBLEExtAdvertising* pAdvertising = NimBLEDevice::getAdvertising();
  log_p(".");

  if (pAdvertising->setInstanceData(0, extAdv)) {
    if (pAdvertising->start(0, 0)) log_p("Advertising Started with id %s\n", BLEname);
    else log_p("Failed to start advertising\n");
  } else log_p("Failed to register advertisement data\n");
}

The Central side scans like this:

void setupBleWhx() 
{
  NimBLEDevice::init("WHX_CENTRAL");
  NimBLEDevice::setPower(8, NimBLETxPowerType::All); // +8dbm

  NimBLEScan* pScan = NimBLEDevice::getScan();

  /** Set the callbacks that the scanner will call on events. */
  pScan->setScanCallbacks(&scanCallbacks);

  /** Use active scanning to obtain scan response data from advertisers */
  //pScan->setActiveScan(true);

  /** Set the initial PHY's to scan on, default is SCAN_ALL */
  pScan->setPhy(scanPhy);

  pScan->setFilterPolicy(BLE_HCI_SCAN_FILT_USE_WL); //BLE_HCI_SCAN_FILT_NO_WL); 

  /** Set scan interval (how often) and window (how long) in milliseconds */
  pScan->setInterval(0x500);
  pScan->setWindow(0x100);

  for (uint8_t i=0; i < maxDevices; i++)
  {
    devices[i].Active = false;
  }

  /** Start scanning for scanTime */
  pScan->start(scanTime, true, true);

  log_p("EndStartBLE\n");
  
}

Note that I start scanning without the whitelist with a Serial command. Addresses found are stored in the whitelist.

Anyone an experience with this? Tips?

[h2zero]

Are you also storing the address type?

[djdehaan]

I get and add the address as follows, and as far as I can see that includes the type (which is 1 with all devices I test with):

NimBLEAddress addr = pClient->getPeerAddress();
NimBLEDevice::whiteListAdd(addr);

This happens right after connection in 'scan' mode. When the server is not using extended advertising & using 1M_PHY it is reconnecting immediatly. When the server is using extended advertising and CODED_PHY it does not reconnect.

[h2zero]

I'm going to guess that the devices on coded phy are generating a new address every time the restart. You may have to either bond with them so the identity address can be used or manually set their addresses.

[djdehaan]

Hi h2zero, that is not the case. When I do not use the whitelist (on the Central) and select on the right service advertised by the Server I see reboot after reboot the same address on my screen (see image).

[h2zero]

What device are you using? I know that the controller in the S3 has some flakey coded phy handling where the devices that use the nimble controller (c6) work perfectly.

[djdehaan]

Hi h2zero, I am using both the EBYTE E73-2G4M08S1CX (based on the nRF52840 chip) and the ESP32 C3 SuperMini . Both chips show the same effect: without extended advertising in CODED_PHY they reconnect when on the whitelist, but when using extended advertising they don't.

[h2zero]

I suspect this is an issue in the controller then, which is not part of this library and is closed source. I'll try to verify this and then raise an issue upstream.

[henkelis]

Probably not related, but I had a similar issue with multiple connects with CODED_PHY and a whitelist, in that I was unable to get multiple server connections from one central to work concurrently.

I'm using v1.4.3, and all my devices are S3.

Whichever server I started first connected immediately, but the others didn't - looking at debug output the central was issuing a connect, but the server was not receiving it so the connection timed out (I couldn't work out why this was the case).

I eventually fixed it by changing the connection params (actually I commented out the ones I took from the example and let the defaults take over).

I tried lots of combinations of 1M vs CODED, but I did manage to get a single CODED connection with a whitelist (it sounds like you can only get a 1M) before I eventually got all 3 working.