Device Discovery using "Read By Group Type Request"?

[laran]

I am trying to make a service discovery on a peripheral device using a nrf52-DK (pca10040). I built my project around the multi-discovery example from SDK 15.3.

When performing a service discovery using nRFConnect on an Android tablet, I manage to get the complete service list according to this Wireshark log:

nRFConnectAndroid_POS5802DD.pcapng

However, when trying to do service discovery using the nRF52-DK using the nrfSDK I get the following:

MultiLink_POS5802DD.pcapng

For some reason the peripheral device does not respond to the "Find By Type Value Request". Is it possible o configure the Device Discovery module in nRF SDK to make a "Read By Group Type Request" instead? Also, is this an expected behavior from a peripheral, or should all be able to respond to the "Find By Type...." request?

[Hung Bui]

Hi Lars, 

Which peripheral you are using for testing ? I assume it's a 3rd party product ? 

Any device that pass Bluetooth qualification should response correctly to all ATT opcode. 

Regarding your question, yes you can do a full service discovery, similar to what the Android phone did. 

You can follow this message sequence chart on how to do a "full" service discovery.

Our db_discovery library currently only does service/characteristic discovery for predefined characteristics.

[laran]

Hi Hung,

The device is a Bluetooth thermal printer (POS-5802DD) and if I interpret the log properly it looks like a Qualcomm chip. Are you suggesting that the peripheral I am using is not following the standard, since it does not answer to the "Find By Type Value Request"?

I will look into your message sequence, and see if I manage to get a full discovery working, thanks.

[Hung Bui]

Hi Lars, 

Yes unless the attribute table doesn't have that attribute with such UUID it should return with the correct location (handle) of the attribute. 

Have you tried using nRFConnect to connect to the device and check if you can see the battery service ? 

[laran]

Yes this is exactly what I did, I used nRFConnect on Android tablet for connecting to the device, the Wireshark log is attached above. All the services are discovered properly and I can see the battery service in nRFConnect.

[Hung Bui]

Hi Lars, 

I got an update from our R&D. It could be related to an old Qualcomm issue dating 5-10 years back. I'm not sure it's the case with your printer, but would it be possible to update the stack on the printer? 

If that's not possible, you may need to stick with the "generic" service discovery.