I have successfully modified DSPS 5.150.2 to support multiple peripherals.
But I have a small issue remaining, which I need to understand better.
When I connect to the 1st Peripheral everything is OK. A successful connection is established very fast (likely < 100ms)
When I connect to the 2nd Peripheral, it usually takes several connection attempts before it successfully connects.
I see a connection failure callback in user_on_connect_failed() between subsequent unsuccessful connection attempts
When it does succeed, it typically is several seconds after the last connection attempt was initiated.
My questions relate to recommended Central operations when supporting multiple Peripherals:
-After each successful connection is established, should I re-enable scanning ( user_scan_start ) ?
When the Central sends a connection message, in it's user_central_conf data structure, it has 2 settings ...
/// Scan interval
.scan_interval = 0x180,// Not sure what the units of time are here ... ?
/// Scan window size
.scan_window = 0x160,
-How are these scan settings related to the interval / window user_scan_conf settings referred to in user_scan_start() ?
/// Scan interval
.interval = 10,
/// Scan window size
.window = 5,
- My interval / window settings are just defaults from the original DSPS client application.
-Now that I am supporting multiple simultaneous Peripheral connections, are there more optimal window/interval/... settings I should be using ?
The concern of course, is trying to fix my erratic connection issues when attempting to connect to the second peripheral.
- My application requires sustaining up to 3KB/s peripheral notification throughput per Peripheral connection. Maximum of 2 Peripheral connections.
- Presently I have tested with a 2KB/s rate, and will do more testing to find the upper boundary.
- DSPS default connection interval is 12.5ms
Thanks, Martin
Just aFYI
When a 2nd connection attempt fails, as mentioned. I see a callback on user_on_connect_failed()
If I have a BLE sniffer active, I never see my Central device send out a CONNECT_REQ message.
So it appears there is some problem for the Central in sending out CONNECT_REQ when there is already one connection previously established.
Thanks, Martin
任何对话框专家Central operation out there ?
Thanks, Martin
scan interval/window's units is 625us, which can be referred in Core 4.2 //
7.8.10 LE Set Scan Parameters Command //for scan procedure, determines the scan interval and window
7.8.12 LE Create Connection Command //for connect procedure, master needs to determine the scan interval and window to capture the adv packets from slave
not sure why you sometimes will encounter the failure for the second connection.
I upload a file for your reference.
Hi Gongyu_Dialog,
Thank you for the reply.
OK, I did suspect that the "create connection" settings were for scan settings after a connection has been set up.
My suspicions from a Dialog perspective, is that if an existing connection exists with a short connection interval (12.5ms or less), that the DA14580 is having difficulty scheduling time for a scan operation.
It would be an easy test on your side to verify. Anyone within Dialog that would have more insight into this issue ?
Regards, Martin
Hi MSun,
实际上,当580年在连接和康涅狄格州ection interval is 12.5 or less there is less time for the device to schedule scanning operations. It will try to keep up with the scanning interval but will not succeed every time and offcourse the scanning window is going to be much smaller that the one instructed by the code. You can watch this by using the Power Profiler in Smart Snippets. As you can see from the images attached, the spikes that are a little bit flat on the top is the slot that the device has managed to allocate for the scanning procedure, the length of those scan events is less than 5 ms and even smaller, all the other spikes are the connection intervals. The red line in the image is a scan event that managed to find an advertising string while it was active, notice that all the other scan events are haven't managed to find anything.
So in your case while you have a connection you find a peripheral after a while (since it takes quite sometime to scan it), and you issue a connection command, after the connection command is send to the stack the central will try to find an advertising event on the air in order to send the CONNECT_REQ (since it has to find an open receiver on the advertising side), due to the small connection interval the central has to keep with the other connection, it can schedule only a small scan window in order to find the next advertising event for the second device, and that takes enough time. The reason you get that user_on_connect_failed() is because when sending the connect command to the stack you also start a timer with a 7 seconds delay (i suppose that is DSPS) so if after that 7 seconds the central hasn't managed to schedule the connection event (since it isn't able to find the adv message of the advertising device) the timer just cancels it. Try to increase the time before cancelling the connection event in order to give time to central to establish the connection.
Thanks MT_dialog
Hi MT_dialog,
Thank you for your reply. That sheds some light on how it operates, and I will work to make some adjustments to my interval settings to see if I can give a lot more time to scanning operations.
I'll update with my final progress.
Thanks, Martin