English is currently available.
Bluetooth & BLE DISCUSSION
My custom peripheral (nRF52 module, own firmware) connects fine from one phone, but on several Android phones onConnectionStateChange reports status 133, either immediately or a few seconds after connecting. Sometimes a retry works. iOS seems more stable but also drops occasionally.
Status 133 appears to be a generic error. How do I find out whether the fault is in the app, the phone or my peripheral, and what are the usual causes on the device side?
133 is 0x85, GATT_ERROR, which Android uses as a catch-all, so the number itself tells you little. The useful information is the HCI disconnect reason, which you can read from the peripheral's stack events or with a sniffer. The common ones: 0x08 connection timeout (packets stopped being heard), 0x3E connection failed to be established (the peripheral never answered the first connection events), 0x13 remote user terminated, 0x16 terminated by local host, and 0x22 link-layer response timeout (a control procedure was not answered in time).
Log that reason in your firmware first. It splits the problem into radio and timing, protocol, or application causes.
Rule out the app-side classics. Android allows only a limited number of GATT client objects, and every connectGatt() needs a matching close(); calling only disconnect() leaks them until new connections fail with 133. Run GATT operations strictly one at a time, waiting for each callback before the next request. For a dual-mode or unknown device pass TRANSPORT_LE to connectGatt(), otherwise some phones try Classic first.
A short delay and one retry after a 133 is normal practice, but if retries are needed often, the cause is below the app.
On the peripheral, timing is the first suspect for 0x3E and 0x08. The link layer wakes for each connection event using the 32.768 kHz sleep clock, and it widens its receive window according to the clock accuracy it has declared. If the firmware declares 20 ppm but the board really runs from an internal RC oscillator, or the crystal's load capacitors are wrong, the peripheral drifts out of the window and the connection dies after a few events, more often at long intervals.
Set the low-frequency clock source and accuracy in the stack configuration to match the hardware, and check the load capacitance: C_load = (C1 × C2) / (C1 + C2) + C_stray. For a 9 pF crystal with about 3 pF of stray capacitance, two 12 pF capacitors give 6 + 3 = 9 pF.
If the failure comes a moment after connecting and the devices were paired before, suspect mismatched bonds. When the peripheral is reflashed or its bond storage erased, the phone still holds the old keys and tries to start encryption with them; the peripheral cannot, and the link is dropped, often with reason 0x3D (MIC failure) or an authentication error. Remove the device in the phone's Bluetooth settings and pair again, and give the peripheral a way to clear its own bonds during development.
Similarly, if the GATT table changes between firmware versions, implement the Service Changed characteristic, otherwise Android keeps using cached handles that no longer match.
Also check the connection parameters your firmware requests. Values outside what phones accept can be rejected, and some stacks are configured to disconnect when the negotiation fails. Keep the supervision timeout comfortably above (1 + latency) × interval × 2: an interval of 30 ms with latency 4 needs more than 300 ms, and a few seconds is a sensible choice.
Finally, test the radio itself. A poorly matched antenna or a board lying on a metal bench gives a marginal signal, which looks exactly like random 133 errors. Compare RSSI against a reference module at the same distance, and capture a failing connection with a BLE sniffer to see which side stops answering.
