Its all configurable. The latency of the connection depends on how often device sends advertisements on one side and scans on the other. For example if both sides know that connection needs to be established and sends advertisement every 20 msec and scan all the time, the latency would be around 20 msec. But that would eat too much of the battery. There is some discussion about that in the How to Write Application document. Very similar for the data, disconnection there is a connection inteval. If this is set to minimum (7.5 msec) the latency will be short. But that would take too much of the energy. So connection iterval is is set based on the latency requirements of the application.
Cool. Can you point to some sample code in the SDK or the documentation where these numbers are configurable? There are a lot of timing configuration options...
Look at the configuration parameters in the sample app for example
const BLE_PROFILE_CFG hello_sensor_cfg =
If your application is sending undirected connectable advertisements by calling
The interval between packets is configured using
/*.high_undirect_adv_interval =*/ 32, // slots
Slot is 0.625 milliseconds. So your device will send advertisement packets every 20 milliseconds. It is recommended that you do not do advertisements that often for a long time. How long to stay in that state is configured by
/*.high_undirect_adv_duration =*/ 30, // seconds
If your application is doing LOW_UNDIRECTED_DISCOVERABLE, the interval is
/*.low_undirect_adv_interval =*/ 1024, // slots
The rest depends on how often peer device performs the scan (listen). For example if they scan every 1.28 seconds for 12msec the connection could be established on the first advertisement, or second advertisement, or even later. So the connection establishment can take several seconds. If peer scans ever 60 msec for 30 msec. The connection should come up very fast.