The mandatory services 0x1800 & 0x1801

[Anthony Ch.]

Good day, support!

I have a couple of questions regarding the mandatory services of the nRF52840 dongle.

1) How to add characteristics to the mandatory services 0x1800 and 0x1801?

2) How to read the content and handles of the mandatory services on my dongle?

3) Is it possible to track access to these services?

Looking forward to your reply.

Best regards,

Anthony.

[Hung Bui]

Hi Anton, 

Which characteristics do you plan to add into 0x1800 and 0x1801. These are 2 system service that's not available to application for modification, at least on our softdevice ( I don't know if you are using our softdevice or use other platform). 

You only have the flexibility to choose adding "Service Changed" characteristic to the service 0x1801 (Generic Attribute). 

You can read the content and handles using nRF Connect (on Android or PC) or any central code ( except on iOS). 

[Anthony Ch.]

Hi Hung,

I am using the SoftDevice 6.1.1.

When I am in the server role, I need to register access to existing services on the device and write them to the log. When I add a new service, I save the nested characteristics, their values, etc. to the structure. When a client accesses the characteristics, I save this event to the log. But what about preinstalled (mandatory) services? They are not in my structure. I can really read the contents and handles using nRF Connect (Windows PC and Android), but how can I do this in code using the SoftDevice?

[Anthony Ch.]

Hi Hung,

Sure, I will try to clarify. To debug the application, there is a need to log for any action on my characteristics. I want to see when another device read the name of the device or when it read the appearance. I will explain why this is necessary. When Our other device is connected to the sensor, it reads sensor characteristics and checks them. For example, the device checks the Appearance that the type of device is really a sensor, else - disconnect.

So: suppose we made a mistake and indicate the incorrect value of the characteristic, and the connection with this other device was not established. And we, from the sensor side, will not even know what went wrong. Therefore, I would like to control the reading of these characteristics.

Thanks!

[Hung Bui]

For that purpose, I would suggest to use a sniffer to track all the BLE communication. You can use any nRF52 DK as the sniffer. Download it from here.

[Anthony Ch.]

Okay, I'll take a look now.

[Anthony Ch.]

Hi Hung,

Hung Bui said:

For that purpose, I would suggest to use a sniffer to track all the BLE communication. You can use any nRF52 DK as the sniffer. Download it from here.

I tried to apply the proposed solution. There was a slight misunderstanding. This is my fault, I did not indicate that I was using nRF52840 Dongle, and not nRF52840 Development Kit. This is our hardware: https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52840-Dongle

"To use the nRF Sniffer for Bluetooth LE you need either the nRF52840 DK, nRF52 DK, nRF51 DK or the nRF51 Dongle." That was a quote. Is there a similar solution for our hardware?

[Hung Bui]

Hi Anton, 

You still can use the nRF52840 dongle as the device under test. You just need to have a nRF52840 development kit, or nRF52832 development kit in addition to use as the sniffer to sniff the communication.

But note that this is only for development and testing (to sniff the communication), if you plan to have a solution as end product I don't think there is an easy way to do.