-
Notifications
You must be signed in to change notification settings - Fork 26
PPoGATT protocol
The PPoGATT protocol is a layer outside the pebble protocol, used to encapsulate pebble protocol data as atomic chunks that fit within the maximum size of the Bluetooth LE General Attribute (GATT) buffer.
There are two versions of the PPoGATT protocol (0 or 1), where version 1 supports ACK coalescing and negotiation of ACK coalescing windows.
ACK coalescing in PPoGATT is the process of skipping ACKs for a specified number of packets, in order to increase the throughput. On connection, maximum RX and TX (from the watch's perspective) skip counts are negotiated between the phone and watch (AKA window negotiation).
Packets can be one of 4 types:
- Reset
- Used to reset the PPoGATT state machine of the target device back to a known initial state. This is the first packet that's sent and, ideally, should never be sent again but can be if needed.
- This packet also contains the PPoGATT connection version, which is used to decide whether to negotiate windows for ACK coalescing.
- Reset ACK
- Acknowledges a reset request, but also contains information about that device's maximum ACK coalescing windows.
- Data
- Contains Pebble Protocol data, can be multiple packets or a chunk of a single large packet.
- Data ACK
- Used to acknowledge a data packet, contains the data packet's sequence. When ACK coalescing is active, it also acknowledges all sequence values before it.
Every packet contains a sequence value, from 0 to 31 then wrapping around again.
In data/reset packets it is used to indicate the order of those packets and identify them, and in both ACK packets it is used to indicate which data/reset to acknowledge.
- When the watch connects, an initial reset packet is sent to the phone.
- The phone handles this and replies with maximum ACK windows for RX and TX if required via a reset ACK.
- The watch sends an extra reset ACK in reply with the maximum ACK windows it has decided based on what the phone suggested.
A rough state machine of our implementation:
If the received sequence is invalid (not the next sequence), both watch and phone are expected to re-send the ACK of the last correctly received packet to request a soft restart from that point.
If this is not possible, a reset should be sent.