Best starting point to minimize BLE delays

[brian239955_stm1]

I need to develop an STM32WB55-based BLE system that consists of 2 parts. Each part will have a button on it as well as a sensor. When a button is pressed on one device, it needs to inform the other device, as well as communicate its sensor value. Both devices are identical. I need to communicate information between the devices upon a button press as quickly as possible, and I also need to preserve battery life. Here are my thoughts on this so far -

• Both devices are configured as peripherals.
• Both devices advertise periodically
• When a button is pressed on Device 1, it switches its role to central (is this possible?)
• Device 1 scans for a peripheral, sees Device 2 and connects to it.
• Device 1 sends its button and sensor data to Device 2
• The devices disconnect and both devices go back to peripheral mode and advertising.

Several questions -

• Is the scenario described above feasible?
• If so, should I use a standard profile or a proprietary profile? Is there a performance penalty using one of these compared to another?
• Is there a good example program to start with that would minimize the new code development required?

I have played with the BLE_p2pServer and BLE_p2pClient programs on the WB55 Nucleo boards. I'm seeing a connection time of 10-12 seconds using this code, although much of this appears to be in the discovery phase. Is this typical for establishing a connection between 2 devices? What can I do to reduce this time?

I'm hoping for a time of around 300 ms from the time a button is pressed, until the time the other device is notified of this event. This 300 ms needs to cover both the time to connect the devices as well as the data transfer.

Is this possible using BLE on the WB55 hardware?

Thanks...

Brian

[AME MCU Support Center JT]

Is the scenario described above feasible?  

>>Yes, technically, this scheme is possible but why do you want both devices to be peripherals? Why not have these two devices be a Central and a Peripheral, respectively, and remain connected (with a connection interval < 300ms). 

If so, should I use a standard profile or a proprietary profile? Is there a performance penalty using one of these compared to another? 

>> You can do with with a proprietary profile made up of a couple of custom characteristics to carry the button press and sensor information. 

Is there a good example program to start with that would minimize the new code development required?

>> The P2PServer/Client example is probably the best example you can start with. This example implements a couple of custom characteristics to carry button control and LED information. The custom characteristics are defined in P2PS_STM_Init() routine, so you can customize these characteristics for your needs. Then you can see how the button data is sent to the remote device by updating the characteristic in P2PS_Send_Notification(). 

I have played with the BLE_p2pServer and BLE_p2pClient programs on the WB55 Nucleo boards. I'm seeing a connection time of 10-12 seconds using this code, although much of this appears to be in the discovery phase. Is this typical for establishing a connection between 2 devices? What can I do to reduce this time?

>> I have noticed that the discovery phase and connection can be lengthy, this is why I suggested to consider keeping your two devices connected. I'm checking if something could be done to reduce this time. 

[brian239955_stm1]

Hi Joe - thanks for the quick response!

The reason I don't want one device to always be a central is that there is another use case involved here that I did not describe. There may be a phone that needs to talk to both devices as well. In this case, I want the devices to be peripherals and the phone to be central. But there are cases where the phone is not involved, and the devices need to communicate with each other. This is why I was thinking that the device would need to switch roles from peripheral to central if its' button is pressed. Is there an example or a description of the steps to take to switch roles like this? How hard would it be to modify either the p2pClient or p2pServer examples to also handle the other role - something like switching roles on a button press?

I do not want to leave the devices connected at all times, as this would drain my battery too quickly. I'm hoping to go into a low power mode when the devices are idle.

Does pairing the devices help to reduce any of the discovery time? Each device will ever only be communicating with one other device.

Thanks...

Brian

[AME MCU Support Center JT]

​Hi Brian,

You can look at the BLE_p2pRouteur example, which demonstrates the capability to connect to a master and multiple slaves on the same device, so this device is able to advertise as a peripheral and scan as a master for peripherals.  You can tailor this example as you wish to advertise or scan when desired (button press).

Regards 

[brian239955_stm1]

Hi Joe,

I've played with the p2pRouteur example, but have gone back to the p2pClient and p2pServer examples. Since I don't have a phone as a central in my system, these seemed to be closer to what I need. I'm still struggling with trying to reduce the time it takes the central and the peripheral to connect once I hit the button on the central. Again, I'm seeing 10-12 seconds here. During this time, the central is continuously outputting the same 2 lines to the debug port -

--- ST MANUFACTURER ID ---

-- SERVER DETECTED -- VIA MAN ID

I can see that this is coming from the advertising report received by the client. During a connection cycle, this pair of lines repeats 37 times and is responsible for most of the 10 second delay I'm seeing.

I have tried a variety of both scan interval and scan window settings on the client, as well as advertising intervals on the peripheral.

Several questions -

• Is there anything that can be configured differently in either the client or server to reduce this delay?
• Why does this event repeat that many times?
• Since I know what device I want to connect to, as well as its' capabilities, can I avoid some or all of the discovery process that is used in this example?

Thanks...

Brian