Possible causes of GATT 133 (0x85)?

[Lionel Sacks]

Hi, I'm really struggling and the Android side (I guess?)

I have a nRF51 app based on the UART initially, with my own services added. etc.

On the Windows MCP it behaves exactly as expected, advertise, connect service discover. On a little Samsung YoungII, also perfect behaviour.

However, on my Moto G (and, indeed a Nexus 7) I have less luck.

• it adverts who up very slowly.
• but when I connect, from the MCP App, I get GATT 133 error, pretty consistently... and in my app also.

I have tried removing my services - and have just the bas_ service right out of the SDK. Same problem. I have the 'recommended' (as per example app) min/max conn intervals (20/75ms).

And I turn the BLE interface on/off whenever I change anything to avoid caching etc.

I'm pretty stuck!

Any ideas welcome.

cheers.

[Torsten Robitzki]

Maybe this helps: www.wireshark.org/.../ChIOSaveSection.html

[Lionel Sacks]

Sure, just took me a moment to figure in Wirshark...

seq1.txt

seq2.txt

any good? And here (should be) a normal connection setup from the Samsung...

seq-normal.txt

[Torsten Robitzki]

The seq1 and seq2 seams identical to me. In both files the master requests a hop value of 21. According to 2.3.3.1 the hop value should be in the range 5 to 16. In addition, is the "next expected sequence number" field set to 1. I think it should be set to 0. So to me it looks like the stack on your Moto G seems to be broken.

[Lionel Sacks]

yes... also, I captured a hop request of 20 from the Nexus 7 (Android 5.1.1). whereas the Samsung asks for 4.

seems a pretty poor situation! Is this common?

[Torsten Robitzki]

Maybe it's an issue that is fixed in latter versions of android? If not, maybe http://bluekitchen-gmbh.com/ can help you, getting a proper version with your application shiped. Good Luck! ;-)