CBCentralManager on iOS is not detecting readers of type nRF52840

[GusOP]

We're trying to diagnose an issue that's occurred to at least two of our customers. For some reason, we've found two different iPhones that are seeing our reader (nRF52840) believe it's an Apple Watch. Specifically, the "nRF Connect" app labels it as an Apple Watch, and our own app which looks for the specific service can't find it, even though the details are correct.

Do you have any thoughts or could put us in touch with someone who knows might more, or can tell us how the nRF Connect even gets the name "Apple Watch" since our device would never have sent that?

Txs,

Gus.

[Vidar Berg]

Hi Gus,

It sounds strange. I haven't seen reports of BLE devices being mistaken for Apple watches before. Have these two iPhones been tested with several "readers," or just one each? The only explanation I can think of is that it may be related to caching somehow. You can clear device cache by removing the device(s) in Bluetooth settings, followed by a reboot. 

Best regards,

Vidar

[GusOP]

Those two phones were tested on this precise moment with other readers and the phone saw the other readers without a problem, even more, by the next day the same phone went back to normal and saw the reader as used to see it.

About the cache problem, I don't get how in the first place the reader can advertise that he is an Apple Watch. Is that what you were suggesting?

[Vidar Berg]

Hi,

I believe the problem must be more low level in the iOS stack because the reader is not advertising as "Apple Watch", and nRF connect is merely displaying the device name it receives from the system. I would suggest that you try the Lightblue app if you're still able to replicate this and see if it too thinks the device name is "Apple watch".

Is the device name part of your "connection" filter in your app? Maybe a workaround would be to only filter on the Service UUID (0xFE04)?

 

[GusOP]

Hi,

Our app searches for readers that advertise that service UUID, 0xFE04.  

I had the chance to debug our app when the problem happened because it happened in our office with one co-worker. And our app never saw our reader, but it saw other readers of us. nRF Connect saw all the readers as we mentioned, and the one that we didn't see, saw it under the name Apple Watch. We start writing an app that scans for readers without applying any filter, our intention was to start troubleshooting what is going on, but when we finish writing the app the phone of our co-worker starts seeing the reader that the day before wasn't seeing.

The point is that we don't know if we weren't seeing this reader because we were filtering by Service UUID or because of another configuration. We do not do any special configuration when we start scanning, here is an example of what we do:

  var centralManager = CBCentralManager(delegate: self, queue: nil, options: nil)

  centralManager.scanForPeripherals(  withServices: [CBUUID(string: "fe04"], options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

I wonder if you can check your app and tell us how you guys scan for readers. Could you?

The thing is that doesn't make any sense that our app doesn't see a reader and nRF Connect sees this reader and shows that the service this reader is advertising is the one we filter by. As we mentioned earlier,  this scenario happens barely and seems like it happens for a short period of time, like a day or one night and then our app starts seeing the reader again. So, we can't debug the problem but we rather not wait until this problem happens again. 

Txs!

[Vidar Berg]

Hi,

I 've discussed this with one of our iOS developers now - he confirmed that nRF connect is displaying the device name given to it by the CoreBluetooth stack. And that we're using the code line below to initiate scanning without any filtering.

centralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

GusOP said:

As we mentioned earlier,  this scenario happens barely and seems like it happens for a short period of time,

Device name cache can be cleared by rebooting the phone, toggling Bluetooth enable in settings, or by toggling flight mode enable. Do you know if you may have done any of the above before it started to work again?

[GusOP]

When the issue happened in our office we didn't change any setting in our co-worker phone because were trying to debug the issue. And as far as I know, our co-worker didn't make any change either, and even though, by the next day his our app back to work.

I am not so concern about the name, we mentioned that more as a curiosity or something weird that can be helpful. I am not so concern about the device name because we start scanning for readers filtering by UUID Service, there is no way to start scanning and filter by device name. The no sense here is that nRF Connect shows the same UUID Service that we filter by, and we mentioned the device name in our comments because it is the only hint we have.

Anyway, thank you for the help, we will keep you posted if we have any other hint and please if you think about anything else that can help us we will really appreciate that.

[Vidar Berg]

I agree that it doesn't make much sense if you are only filtering on the Service UUID. I will let you know if I find more information that may be relevant. I haven't seen other reports of this issue thus far.. Let us hope it's not a recurring problem.