nRF52832 question

RE: nRF52832 question

Kenneth — Wed, 22 Jan 2020 09:19:57 GMT

I don't think the app is the problem here no. I think it is mainly how the master device handle multiple peripherals that want to connect simultaneously.

Best regards,
Kenneth

RE: nRF52832 question

Pawel Godlewski — Tue, 21 Jan 2020 18:57:47 GMT

So the issue more likely may be caused by how the android OS interprets master device requests or master device handles multiple peripherals rather than the app itself?

RE: nRF52832 question

Kenneth — Tue, 21 Jan 2020 17:40:48 GMT

It's difficult to give an short answer here, since it would require on-air sniffer logs to understand what procedures from the peer that may require one link to temporary have higher priority, but if you follow my suggestion I think that is the most fail-safe (independent of what procedures the peer may be doing).

Best regards,
Kenneth

RE: nRF52832 question

Pawel Godlewski — Tue, 21 Jan 2020 17:33:16 GMT

Thank you. Can I assume that unstable connections/disconnects can happen during connection process (with parallel connections) and that it cannot be prevented? Or maybe do you know of any solution that would help me fix that issue?

RE: nRF52832 question

Kenneth — Tue, 21 Jan 2020 14:39:09 GMT

You can find details here:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/priorities_and_events_intro.html

My suggestion is to setup each link one at a time, e.g.:

1. start advertising
2. wait for connection
3. wait for all exchanges (e.g. MTU / DLE) completes
4. wait for updated connection parameters (e.g. 30ms, slave latency 10)
5. wait for bonding and encryption if that is required
6. repeat from 1

Typically step 3-5 may just be replaced with a few seconds timeout between 2->1 again.

Best regards,
Kenneth