About whitelist storage area and data

[sdi_kei]

Hello.

I am developing using nrf52832 (S132 v7.0.1, SDK v16.0.0) as a central and Android device (Bluetooth 4.2) as an advertisement.

During development, I was wondering about the whitelist storage area.

1. When bonding with an Android device, it seems that the data will be written to the Whitelist via the peer manager. Is it possible to specify the area to be written?
2. Is the only data written to the whitelist the address and IRK? If other data is written, is there a setting?

I would like to know if there are any materials written about each.

Please let us know if you have any questions.

Thank you. 

[tesc]

Hi,

The peer manager uses the Flash Data Storage library (FDS) of the SDK for storing data. The way FDS works is that data is stored and labeled as "records" that can be read back, but it is not put at a fixed position in flash. This is due to how flash works, e.g. that only full flash pages can be erased, maximum number of read/erase cycles before you risk flash wear, etc.

The size of the flash area used by Flash Data Storage is configurable, but the location of a given record will vary depending on where free space is available. It is a bit similar to creating new files on a PC; the location (address) on the hard drive is selected when you save the file, and you retrieve the file by name (not by address).

Only the address information (including IRK if appropriate for the type of address) is relevant for the purpose of whitelists, but the Peer manager does store other information about the peer as well.

Regards,
Terje

[sdi_kei]

Thank you for your answer.

What is the other information about the peer?

I want to know other information because I want to check how many bytes of data are saved in FDS when one bonding is performed.

If you have any other materials, please let me know.

Thank you. 

[tesc]

Hi,

The amount of data depends on several factors. For instance, it can store CCCD values, which depend on how many characteristics there are, and service changed information, if present, etc. We do not have a full overview of flash usage per peer, but in practice the 3 flash pages used by FDS in the default configuration is usually more than enough. We have only one example in the SDK with a higher value (the eddystone example).

Note that FDS is shared between peer manager and other flash usage by the application, so often if the rest of the application needs a lot of data storage you will find that you have to increase the number of pages used by FDS. If you see that you run out of space and/or want the exact numbers for your particular use case, then I recommend that you do some testing using fds_stat() to probe the amount of data used.

Regards,
Terje

[sdi_kei]

thank you for your answer.

After bonding with the Android device and disconnecting, the data in the FDS area is confirmed. At that time, I was able to confirm the address and IRK data that seemed to be saved by whitelist, but I do not know about the other 72 bytes of data.

You mentioned that the data stored will change depending on the factors. Is there any material about the factors and data?

Thank you.

[tesc]

Hi,

In FDS, each flash page has a 8 byte header, and each piece of data has a 12 byte header. Was the 72 bytes of data in addition to that?

The data stored by Peer Manager is typically:

• Bonding data (role, Bluetooth address, IRK, LTKs, master IDs.)
• Whether a service changed is pending.
• GATT data (including state of CCCD, which depend on how many CCCDs there are in the GATT table.)
• A 32 bit value for ranking peers (providing a sorted list of when different peers were last connected to.)
• Data for central address resolution (a 32 bit value).

In addition it is possible to use Peer Manager for storing application data, but this is not, to my knowledge, used in our SDK examples.

In order to investigate further what you see in your flash, you can find the data IDs for the various types of data in peer_manager_types.h, with comments describing what data types hold the related data.

Data IDs used in Peer Manager map to Record Key in Peer Manager, by adding 0xC000 to the data ID. E.g. data ID 7 for PM_PEER_DATA_ID_BONDING corresponds to an FDS record with Record Key 0xC007. From what I understand the data is typically put into FDS records directly from the representation of the corresponding data type or struct.

Regards,
Terje

[sdi_kei]

thank you for your answer.
Sorry for the late reply.

It was 76 bytes instead of 72 bytes, excluding the 8-byte header of the flash page and the 12-byte header of each data.

It was confirmed that the first 18 bytes of the 76 bytes contained the IRK, followed by the 6-byte MAC address.
It was followed by 28 bytes of unknown data, with a 12-byte header and a 4-byte peer rank.

I still don't know about 28 bytes of data.

We will continue to investigate.

Thank you.