what is Softdevice BLE central/peripheral Link?

[chxt]

Hi,

In SD_S132v7 chapter "Radio Notification", `Link-0 / Link-1 / ...`  are mentioned several times, what's the meaning of that?

I mean, does it refer to a physical link associated with a specific peer, or just a logical concept so we can map several links to 1 physical peer?

currently, I have a multi-central device and several(<=8) 1-peripheral devices, CI(connection interval = 18), CEL(connection event length = 5), what I want to know is how SD schedules every connection?

regards,

chxt

[chxt]

Hi, Terje,

thanks for your reply, I've read SD Scheduling chapter before, but the problem I have is I can not send a packet over BLE within a 1~2 CIs(connection Interval) successfully, result from 1-central(max 8 link) to 1-peripheral with CI=18 (data_payload = 20B) gives about 40-60ms delay from `sd_ble_gatts_hvx` to event `BLE_GATTS_EVT_HVN_TX_COMPLETE`, but the delay I expect is at most 1 CI = 18*1.25ms=22.5ms

regards,

chxt

[tesc]

Hi,

What is the direction of the data? (I.e. what device is GATT server, and what device is GATT client. Notifications are sent from the GATT server. Usually peripheral is GATT server.) I would assume the peripheral is sending notifications to the central, but confirmation of this would be good to avoid any misunderstandings.

You write that the central has maximum eight connections. Does that mean that scanning is enabled concurrently with the peripheral connection, and if so what are the scan parameters? I suspect some of the connection events get dropped on the central side, for it to do scanning. A scanner that has been blocked consecutively for a few times gets higher priority, and so does a connection that is about to time out. With both scanner and connection competing for the same radio time, a usual pattern is that both gets about half of the events they ask for. See SoftDevice timing-activities and priorities for an overview of the scheduling priorities.

Regards,
Terje

[chxt]

Hi,

1. In my test data is sent from GATT server(peripheral) to GATT client(central), after many trials, I found that this delay is mainly caused by the way I used to send packet, I use a timer to send packet periodically in where timer start point may not be aligned with ble timeslot start point, the other reason, as you have said, from continuous scanning.

2. Another question, how can I schedule scanning at specific timeslots, currently I have just use 3-5 of 8 links, besides, data is sent every 100ms, can scanning be scheduled at those unused links timeslot or no data transmission timeslot ?

Currently schedule is as follows,

L0 L1 L2 ... | 0 0 0 ... | L0 L1 L2 ... | 0 0 0 ... | ... (Ln timeslot have data transfer, 0 represents no data transfer, Scanning occurred at random link timeslots since CI is not set large enough)

and what I want is

L0 L1 L2 ... | S ... | L0 L1 L2 ... | S ... | ... (S represents scanning)

regards,

chxt

[tesc]

Hi,

Basically you have two options:

1. Set "connection interval" equal to "scan interval", and larger than "connection event length" * "number of connections" + "scan window". That way, both connection events and scanning gets scheduled one after each other within the set interval, and you should get no collisions.
2. Set a short "scan interval" and the same value for "scan window". That way, (small) connection events will compete with small scan events, and the SoftDevice scheduler will give some events to each of the two.

The full picture is a bit more nuanced, and for a full understanding I am afraid I can only refer to the SoftDevice Specification chapters on Scheduling. Feel free to ask if anything is unclear in the SDS.

If you have a pattern where data is only shared every other connection interval, then I suggest to double the connection interval. If you then choose "scan interval = connection interval", and "scan window = interval - (connection event length * number of connections) - tScanReserved", then you should get what you want. Ref. Primary channel scanner timing. tScanReserved is not defined in the SDS for S132, but for S140 (which should basically be the same) it is stated to be in the range of 760 us.

Regards,
Terje

[chxt]

Hi, Terje

1. option-1 have a larger packet send delay which we are trying to avoid. in option-2 as minimum SI(scan interval) is 20ms, that may cause some links to be scheduled too far(~ 2 * CI), but we want a stable maximum packet send delay time.

2. We do have a fixed pattern, all peripherals send data nearly at the same time with fixed period(~100ms), not every other CI, but every n-th CI where n is constant but not predetermined. we try to schedule scanning at those 'empyt' CIs but can't find a way.

regards,

chxt

[tesc]

Hi,

I think I understand now.

The SoftDevice scheduler schedules radio events based on "type of event", "about to time out" and "blocked consecutively". There is no prioritizing based on "has anything to send", and certainly not on "peer has anything to send" (how would we know?)

Would it be a solution to use longer connection interval, then sync up the measurements (taken on the peripheral side) with when the connection events happen? I have a hard time coming up with other ways to consistently give low latency from measurement on peripheral to data received on central, combined with scanning on the central...

Alternatively, you can try enabling scanning when you get data on the central side, and let it run until it is "about time to get data again". If you are lucky you may be able to squeeze in a scan event or two. (Scan will typically be blocked a few times before getting through, though.)

Regards,
Terje

[chxt]

Hi,

I was thinking to use the strategy of enbaling/disabling scanning when appropriate, but since skipped CI number and active links are not pre-programmed, it seems not a easy task to implement robustly, we consider to set this aside now and return to it later.

thanks for your help!

regards,

chxt

[tesc]

Hi,

You are right this is not an easy task to implement robustly, especially if the timing from the peer is not set in advance. Feel free to return to this thread when you come back to working on it, for continuing the discussion.

Regards,
Terje