English is currently available.
Bluetooth & BLE DISCUSSION
My ESP32 peripheral sends a 60-byte sensor record through a notify characteristic, but the Android app only ever receives the first 20 bytes. Writes from the phone are cut at 20 bytes as well. Nothing reports an error on either side.
Where does the 20-byte limit come from, and what is the correct way to move larger records: raise the MTU, or split the data myself?
The limit comes from the default ATT MTU of 23 bytes, which every BLE device must support. A notification or a write uses 3 of those bytes for the ATT header (1 byte opcode and 2 bytes attribute handle), which leaves 23 - 3 = 20 bytes for your data. A notification is never fragmented at the ATT level, so the stack sends the first 20 bytes and drops the rest without an error.
The MTU is negotiated per connection, and both sides stay at 23 if nobody asks for more.
On Android call requestMtu(247) once the connection is up and wait for onMtuChanged before doing anything else. The value reported there is the one actually agreed, which is the smaller of what the two sides support; Android accepts requests up to 517. iOS has no request call: it negotiates by itself shortly after connecting, and the app reads the usable size with maximumWriteValueLength.
The peripheral's stack must allow the larger value too, so check its configured maximum MTU. With an agreed MTU of 247 each notification can carry 244 bytes and your 60-byte record fits in one packet.
MTU is only half of the picture. Below ATT, the link layer carries 27 bytes of payload per packet in Bluetooth 4.0 and 4.1, so a 247-byte ATT packet is split into several radio packets and reassembled at the other end. Bluetooth 4.2 added Data Length Extension, which raises the link-layer payload to 251 bytes. That is why 247 is a popular MTU: 247 bytes of ATT plus the 4-byte L2CAP header is exactly 251, so one notification fits in one radio packet.
Both controllers must support the extension. If one does not, the larger MTU still works, only with more packets on air.
Do not rely on the MTU being large. Some phones agree to less than you ask for, so the firmware should read the negotiated value and send at most MTU - 3 bytes per notification. For records longer than that, add a small header of your own, for example one byte holding a sequence number and a last-fragment flag, and reassemble in the app.
For phone-to-device data there is also the long write procedure (prepare write followed by execute write), which most phone stacks use automatically when a write with response is longer than the MTU allows. It handles values up to 512 bytes but needs a round trip per fragment, so it is slow compared with a larger MTU.
If the goal is throughput rather than one larger record, the numbers that matter are the connection interval and the packets sent per connection event. With 20-byte notifications and a 30 ms interval, a stack that sends four packets per event moves about 4 × 20 / 0.03 = 2.7 kB/s. With 244-byte payloads and the same four packets per event it is about 32 kB/s.
Request a short connection interval from the peripheral (the phone decides whether to accept it) and consider the 2M PHY of Bluetooth 5 if both ends support it. Notifications are also faster than indications, because each indication waits for a confirmation before the next one can go.
