BlueToe
an alternative GATT/BLE implementation
Loading...
Searching...
No Matches
Classes | Typedefs | Enumerations
peripheral_latency.hpp File Reference
#include <bluetoe/ll_meta_types.hpp>
#include <bluetoe/connection_events.hpp>

Go to the source code of this file.

Classes

struct  bluetoe::link_layer::peripheral_latency_configuration< Options >
 defines a peripheral configuration to be used by the link layer More...
 
class  bluetoe::link_layer::peripheral_latency_configuration_set< Configurations >
 allows the peripheral latency configuration to be changed at runtime between a given set of configurations. More...
 

Typedefs

using bluetoe::link_layer::peripheral_latency_ignored = peripheral_latency_configuration< peripheral_latency::listen_always >
 Instructs the link layer to ignore peripheral latency.
 
using bluetoe::link_layer::peripheral_latency_strict = peripheral_latency_configuration< peripheral_latency::listen_if_pending_transmit_data, peripheral_latency::listen_if_last_received_had_more_data >
 Configure the link layer to only listen every configured connection event.
 
using bluetoe::link_layer::peripheral_latency_strict_plus = peripheral_latency_configuration< peripheral_latency::listen_if_last_received_not_empty, peripheral_latency::listen_if_last_received_had_more_data >
 Configure the link layer to just listen every configured connection event and on the next connection events if the previous connection event contained data from the central.
 
using bluetoe::link_layer::periperal_latency_default_configuration = peripheral_latency_configuration< peripheral_latency::listen_if_pending_transmit_data, peripheral_latency::listen_if_unacknowledged_data, peripheral_latency::listen_if_last_received_not_empty, peripheral_latency::listen_if_last_transmitted_not_empty, peripheral_latency::listen_if_last_received_had_more_data >
 Default peripheral latency configuration.
 

Enumerations

enum class  bluetoe::link_layer::peripheral_latency {
  listen_if_pending_transmit_data , listen_if_unacknowledged_data , listen_if_last_received_not_empty , listen_if_last_transmitted_not_empty ,
  listen_if_last_received_had_more_data , listen_always
}
 detailed options for the peripheral latency behavior More...
 

Detailed Description

This file provides several options, that allow users to configure Bluetoe's support for peripheral latency. Peripheral latency allows a link layer peripheral to ignore some connection events (do not respond to the central) to conserve power.

Each option is a compromise between latency and power consumption.

See also
bluetoe::link_layer::peripheral_latency_ignored
...

Typedef Documentation

◆ periperal_latency_default_configuration

using bluetoe::link_layer::periperal_latency_default_configuration = typedef peripheral_latency_configuration< peripheral_latency::listen_if_pending_transmit_data, peripheral_latency::listen_if_unacknowledged_data, peripheral_latency::listen_if_last_received_not_empty, peripheral_latency::listen_if_last_transmitted_not_empty, peripheral_latency::listen_if_last_received_had_more_data >

◆ peripheral_latency_ignored

using bluetoe::link_layer::peripheral_latency_ignored = typedef peripheral_latency_configuration< peripheral_latency::listen_always >

Instructs the link layer to ignore peripheral latency.

The link layer will listen at every connection event and will respond at every connection event.

This option will provide lowest latency without any chance to conserve power.

See also
bluetoe::link_layer::peripheral_latency_configuration

◆ peripheral_latency_strict

using bluetoe::link_layer::peripheral_latency_strict = typedef peripheral_latency_configuration< peripheral_latency::listen_if_pending_transmit_data, peripheral_latency::listen_if_last_received_had_more_data >

Configure the link layer to only listen every configured connection event.

The link layer will only listen to the central every "peripheral latency" + 1 connection events. If for example, the peripheral latency of the current connection is 4, the link layer will just listen to every 5th connection event.

If there is pending, outgoing data, the link layer will start to listen on the next possible connection event to be able to reply with the pending data. Also, if a received PDU has the more data (MD) flag beeing set, the link layer will start listening at the next connection event and transmit the pending data.

This option provided lowest power consumption while providing better transmitting latency compared to having a connection interval equal to peripheral latency + 1 * interval.

See also
bluetoe::link_layer::peripheral_latency_always_listening

◆ peripheral_latency_strict_plus

using bluetoe::link_layer::peripheral_latency_strict_plus = typedef peripheral_latency_configuration< peripheral_latency::listen_if_last_received_not_empty, peripheral_latency::listen_if_last_received_had_more_data >

Configure the link layer to just listen every configured connection event and on the next connection events if the previous connection event contained data from the central.

This option extends the peripheral_latency_strict option by listening on subsequent events, if there was data received at the previous event.

This option provided lowest power consumption while providing better transmitting latency compared to having a connection interval equal to peripheral latency + 1 * interval. Compared to peripheral_latency_strict, this might increase the receiving bandwidth.

See also
bluetoe::link_layer::peripheral_latency_always_listening
bluetoe::link_layer::peripheral_latency_strict

Enumeration Type Documentation

◆ peripheral_latency

detailed options for the peripheral latency behavior

Every option defines a set of events / circumstances under which the link layer should listen at the very next connection event. Regardless of the selected options, the link layer always listens for incoming PDU at each peripheral latency anchor points, which were negotiated as part of the current connection parameters.

Note
in combination, there are some options that make no sense. For example, using listen_always with some of the other listen_* options is pointless and will result in failure to compile.
Enumerator
listen_if_pending_transmit_data 

listen at the very next connection event if bluetoe has an available PDU for sending.

This reduces the latency of any available payload. If outgoing payload becomes available while the next connection event was planned to utilize peripheral latency, the library tries to reschedule the next connection event to happen earlier.

listen_if_unacknowledged_data 

listen if the link layer contains unacknowledged data.

If a PDU was sent, but no acknowledgement has been received, the link layer will listen at the next connection event.

This might be interesting, if the sending queue is very small because Bluetoe has to keep a copy of a transmitted PDU, as long as that PDU is not acknowledged.

listen_if_last_received_not_empty 

listen to the next connection event, if the last received PDU was not empty.

listen_if_last_transmitted_not_empty 

listen to the next connection event, if the last transmitted PDU was not empty.

listen_if_last_received_had_more_data 

listen to the next connection event, if the last received PDU had the more data (MD) flag set.

With the MD flag, the central (and the peripheral) can indicate, that there is more data to be sent. Usually this data is then transmitted during the same connection event. If there is no support for handling more data in the same connection event either by the peripheral or by the central, then this option may help reducing the latency of the pending data.

listen_always 

listen at all connection events, despite the negotiated peripheral latency value of the current connection.