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]

Are the two failing phones running the same version of iOS, and are they both of the same model? In any case,  I think a bug on the iPhone side must be what's causing this. A custom BLE device should never appear as an Apple watch. Or I guess it could be possible if the devices were specifically programmed to advertise the same data as a watch would.  You may try to inspect the advertisement data with a different phone to verify that your service UUID is still being advertised. 

Caching may explain why the problem persists across connections, but not why this happens in the first place.

[GusOP]

Hi Vidar,

As we mentioned in the beginning, we have been using the app nRF Connect in cases when our app doesn't see a reader. And I understand that nRF Connect app is a Nordic Semiconductor app, your app. Am I right?

Therefore could be very helpful for us, if you know how or if you can ask how/where the nRF app gets the information that displays "Apple Watch"? What specific information is it using that would cause that display?

Please see the images attached below:

[Vidar Berg]

The app should simply display the adv data it gets from the Bluetooth stack, and "Apple watch" is what seems to be the reported device name in this case. You can try another third-party app such as Lightblue and see if you get the same result. 

[samy]

Hi Vidar Berg, I was investigating one of the phones with this issue. nRF Connect only showed "Apple Watch" on one phone (which was having the issue of not connecting via our app) while my own iPhone did show the advertisement name properly. That's why we're trying to figure out why the specific phone would think it's an Apple Watch, and trying to understand how the Nordic Connect app pulls that name. I assure you our firmware never ever advertises the words "Apple Watch" or anything similar :) 

I agree it sounds like a cache, but what's odd is two phones, neither of which have ever used or connected to an Apple Watch, both thought the nRF chip was an Apple Watch and no one else's phones have that issue. We're using the nRF chip for access control and there are at least a dozen people in each location without the issue, while only one user in each location had the issue.

Thanks!

[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.