0

I am writing an Android App that connects and communicates with a peripheral over BLE. I've been around the bases a few times on BLE development, with iOS and firmware and now android, and the doc always seems to advise you to:

  1. connect
  2. discover services
  3. (on some stacks, not android) a second round of discovery for characteristics within services
  4. save references to the characteristics
  5. read and write to characteristics (or subscribe to notifications) as you wish

In the back of my mind, I've always wondered if one can skip the discovery step? Say if its a situation where you are dead certain what you are talking to, and you know the UUIDs and properties of all services and attributes provided by the peripheral. Can my app just presumptively create my own BluetoothGattCharacteristic objects with UUIDs and properties, and read /write to them, and the stack will just send the corresponding commands, without having gone through that initial interogation?

Then, on this project that thought was forced to the front of my mind, because we are having some mysterious glitch/corruption in the discovery response -- on some phones it would publish services, but no peripherals. It is intermittent and we are sure it is due to some weirdness in the peripheral firmware or configuration, but unfortunately we can't wait for them to fix their problem. So I decided to test out the above theory, with some success:

I built in a secondary path that, in this event, would create BluetoothGattCharacteristic objects with the correct UUIDs and properties and attach them to the received service object. And lo and behold... it worked! Sort of. I could read and write to about 25 of the 28 characteristics... not sure yet what's wrong with the other three. But this seems to me to be a promising result w.r.t. my theory above!

So my question is, is my theory true? Can I skip discovery? If so, is there any sample code or guidance on how to do this, how to correctly set up your presumptive service and characteristic objects outside of the context of a discovery response? (Since I'm obviously close, batting 25/28=0.893, but no cigar.)

Would appreciate any pointers to discussion on this topic, and esp to any sample code, projects, or snippets.

Chris
  • 629
  • 1
  • 10
  • 28
  • Does it work even if you clear the cache for that device? (i.e. by removing bond to that device if it's bonded and restarted Bluetooth to reset cache) – Emil May 15 '16 at 23:17
  • You should check the HCI log to see if you can find your "glitches" in there. – Emil May 15 '16 at 23:19
  • In the end, the stack must know the ATT handles of your characteristic values, since over the air it's the ATT handle and the value that's being sent. The characteristic UUID is irrelevant. – Emil May 15 '16 at 23:22
  • Emil, thanks for the comments. Is it possible to assume the ATT handles, if I inspect them after a valid discovery, or something? Also, how do I check the HCI log. (Forgive the dumb questions.) – Chris May 15 '16 at 23:36
  • I'm trying your suggestion to clear the cache... using this: http://stackoverflow.com/questions/22596951/how-to-programmatically-force-bluetooth-low-energy-service-discovery-on-android – Chris May 16 '16 at 00:48
  • Dang, didn't work... either programmatically or cycling bluetooth. – Chris May 16 '16 at 04:34
  • Do you mean you couldn't clear the cache or do you mean that your approach didn't worked after cleaning the cache? – Emil May 16 '16 at 16:18
  • Still didn't work after clearing the cache. – Chris May 19 '16 at 11:04

0 Answers0