best way to retrieve latest used BLE bonding infos using SDK16 peer manager library

[astella]

To the kind attention of Nordic support team,

I was reading in peer_manager library that when a ble connection is established, using the connection handler as a parameter should be possible to retrieve the index in the peer database
where those connections infos are stored (pm_peer_id_get). I suppose we can manually save that 'last valid connection index'.

After that, when we want to advertise again (and make a decision about the type of advertising) we could call pm_peer_count to see if there are valid peers. In that case we could retrieve that saved 'last valid connection index' and use it as a parameter to call pm_peer_data_bonding_load.

In case latest valid ble connection has got a long term key (LTK) saved, it makes sense to try a directed advertising, I think (could you please confirm?).
What it is not clear to me, if we have to manually save that last valid connection index.
Probably there is a peer_manager routine that is doing that, so that I can retrieve bonding infos of latest used connection by only calling a suitable library routine. 

Also in case of directed advertising, we should be sure that it times out, or at least that we can advertise for other host to scan, in case the directed adv. host is missing.

When doing directed advertising yesterday I noticed that over about 20 tries, the internal prototype  experienced a couple of resets. I don't know if it is a software issue or an energetic one (could you briefly argument something about that please).

So my question: is there a peer manager library routine so to retrieve latest used bonding infos related to latest connection? Should I save 'manually' that index I was talking about?

Thank you very much for your precious help

Best regards

[Vidar Berg]

Hello,

Directed advertising is usually targeted towards the last connected GAP central, so all you really need to keep track of is one peer id. The ble_app_hids_* examples in SDK 17 demonstrates how this adv. mode can be implemented.

When doing directed advertising yesterday I noticed that over about 20 tries, the internal prototype  experienced a couple of resets. I don't know if it is a software issue or an energetic one (could you briefly argument something about that please).

 The most common reason for sudden resets are code assertions. I suggest you build the project with the "DEBUG" flag to trap all errors instead of letting the Error module reset the device. Do you have debug logging enabled to see if any errors are reported?

Best regards,

Vidar

[astella]

Thank you Vidar Berg very much, now it is much more clear to me:

In sdk16 we had to keep track of latest pm_peer_id (pm_peer_id_get after a new connection) save in flash using fds and use it as a parameter to pm_peer_data_bonding_load when starting a new directed advertisement.

Please note that when inserting a passkey, pm_peer_id is invalid, but with very little of magic using Nordic pm_peer_count it is very simple to sort everything out.

Thank you

[astella]

But this is the very best solution: 

pm_peer_ranks_get(&m_peer_id, NULL, NULL, NULL);