setConnectionParams info

[johntaves]

I have a bunch of questions that I hope you can answer.

Can you provide a more complete explanation of the settings passed to setConnectionParams?
[in] | minInterval | The minimum connection interval in 1.25ms units.
[in] | maxInterval | The maximum connection interval in 1.25ms units.
[in] | latency | The number of packets allowed to skip (extends max interval).
[in] | timeout | The timeout time in 10ms units before disconnecting.
[in] | scanInterval | The scan interval to use when attempting to connect in 0.625ms units.
[in] | scanWindow | The scan window to use when attempting to connect in 0.625ms units.

I am using NimBLE on both the server and the client. There will be 8 servers to the client. The client will also be a web page server via wifi. Each server needs to send a few bytes of data every few seconds. My goal is to minimize power and free up the radio for wifi. The client wants to know if any of the servers die.

The settings above seem somewhat redundant. I expect the min and maxInterval is how often it will send a ping to ensure the connection is still alive, but then why both min and max? Is the timeout the max time allowed with no response from the other end before declaring the connection lost, how is that different from maxInterval? What is latency? I mean what is skipping a packet?

Do the ping's get sent only if no other writeValue or notify happens? For example, can I set the minInterval to say 4 seconds and have the server do notify() every 2 seconds so that all will be quiet on the radios except when that notify happens?

How does all this relate to putting the ESP32 to sleep? I am thinking that if I set these values properly, I can then put the chip to sleep for say 2 seconds and have the timer wake it before the BLE would have timed out.

I apologize for failing to find this info, and appreciate any info you can provide.

[h2zero]

Hi @johntaves, I will do my best to explain.

[in] | minInterval | The minimum connection interval in 1.25ms units.
[in] | maxInterval | The maximum connection interval in 1.25ms units.

These determine how often the devices will "ping-pong" each other and also when they will send any data required. So if you set the value to something like 20, that would mean packets are sent every 25ms, which will obviously consume more power than say a value of 80 (100ms). The reason for the min max values is so the devices can negotiate a compromise for the best possible communication, you can set these to the same value if you prefer.

[in] | latency | The number of packets allowed to skip (extends max interval).

This is how many "ping-pong" (connection interval) events the slave(server) device is allowed to skip without the client device considering the connection terminated. So if you had a 25ms connection interval and you wanted to sleep for 1 second you could set this value to 40 and the client would consider the connection active for up to 40 skipped intervals.

[in] | timeout | The timeout time in 10ms units before disconnecting.

This is the absolute (disconnection) timeout, if no packets are received by either device within this time the connection is considered terminated.

All of these factors combined allow the flexibility of fast data transfer on demand with low connection intervals but also a long sleep time when no data is available, through the latency parameter, while maintaining a connection.

If you are using light sleep on the ESP32 it should wake up and do what it needs at the connection interval event, though I have not tested this so I could be wrong. In deep sleep BLE is disabled so you would need to reconnect to it on wakeup.

[johntaves]

Thanks for that info.

If we assume a sleep of 1s then:

Why would I set the minInterval to 25ms and latency of 40 instead of say 1250ms and 1?

Also, if I have the client tell the server when to sleep, then have the client do a read at say 1.1 sec, will the ping-pong ever occur? (This is assuming a minInterval of 1250ms). I am assuming the ping-pong is just a zero byte transfer, and that any data transfer confirms the connection. Is this true, and therefore there is no benefit to the ping-pong in my case where I will be sending 1x per second?

Regarding the min max, is there any negotiation when the two sides are both NimBLE on ESP32? I don't see where I would set that on the server side, so I assume the server will just agree to the min, or does it agree with the max?

[h2zero]

Why would I set the minInterval to 25ms and latency of 40 instead of say 1250ms and 1?

The shorter interval = faster response time/more data throughput. It's up to you how you want it to work and that is the reason for the parameters. You can absolutely use those settings if you prefer.

Also, if I have the client tell the server when to sleep, then have the client do a read at say 1.1 sec, will the ping-pong ever occur? (This is assuming a minInterval of 1250ms). I am assuming the ping-pong is just a zero byte transfer, and that any data transfer confirms the connection. Is this true, and therefore there is no benefit to the ping-pong in my case where I will be sending 1x per second?

The server will be idle until it needs to communicate, the "ping-pong" is the connection interval event which is when the read will actually be transmitted, the client would hang and wait for the response or disconnection at that point. If no command is requested the event will be as you said, a zero byte (actually a few header bytes) which maintains the connection.

Regarding the min max, is there any negotiation when the two sides are both NimBLE on ESP32? I don't see where I would set that on the server side, so I assume the server will just agree to the min, or does it agree with the max?

The client device is always in control of the connection parameters, the server can request it's own preference but the client can reject them and enforce it's own, the server can only disconnect at that point if it does not agree.

[johntaves]

Oh, I see. You are saying that data is only transmitted during the ping-pong event. The call to notify() or writeValue just queues it for the next interval. Now it is making sense.

However, I am striking out. The following does not work, but when I comment out the setConnectionParams it does connect.
NimBLEClient* pC = NimBLEDevice::createClient();

pC->setClientCallbacks(new MyClientCallback(i),true);
pC->setConnectionParams(80,120,60,600);
if (!pC->connect(BLEAddress(cellSets.addrs[i]),true))
Serial.println("fail");

I am not doing any sleeping at this point. The client won't connect to the server.

EDIT: further experimenting shows that the latency at 5 works, but at 20 it fails.

This doesn't make sense to me. Why would the latency have any effect on connecting?

[h2zero]

pC->setConnectionParams(80,120,60,600);

This may be the reason for the failure, if the max interval is used with that latency you would have 9000ms worth of latency with a 6000ms timeout. Try changing the time out to 900 or the latency to 40.

Internally the process would look like if(maxinterval *latency > timeout) {return invalidParams;)

[h2zero]

@johntaves have you been able to get this working?

[johntaves]

I apologize for not replying sooner. Yes, I got it to work, thanks.

Why there is a timeout separate from the latency, and why there is a max parameter?

I am now working on getting it to light sleep, and reconnect quickly on wake up. It takes several seconds to reconnect, which is unacceptable. My understanding is that I need the external 32khz crystal to achieve a fast reconnect. I am waiting for a new build to test that.

[h2zero]

Glad to hear it.

Why there is a timeout separate from the latency, and why there is a max parameter?

Because the slave latency is optional, this allows for more flexibility to control the connection parameters to maximize battery life. The supervision timeout must always be there as a backstop to detect a disconnection if it doesn't receive a message in the time allowed.

I am now working on getting it to light sleep, and reconnect quickly on wake up. It takes several seconds to reconnect, which is unacceptable.

There are many factors that can influence the performance of this operation; distance, advertising interval, scan interval and transmission power. The 32khz crystal will allow for a lower power sleep mode, I'm not sure about the faster reconnect as I have not tried it. TBH the esp32 is not ideal for this. I use nRF devices for my battery powered devices (they last for months on a CR2032).