BATT service (0x180F) does not work as expected

[Fengy Zhang]

Hi Folks, 

My cellphone  is able to connect with server (peripherals) which supported Battery service. Then I added button to read "battery level" by using ReadIntValue with providing service_uuid  and characterstic_uuid and intOffset. however, server can receive it as battery service, but NOT interpret it as "read battery level" somehow. I used other apk "BLE scanner" from google play store, which can read "battery level" correctly from server. So I am just wondering if anyone has same experience as I met. 

I have double checked the uuid are correct, as the server can receive it as battery service read request. One more question is that actually I am not clear about what exactly the offset means, anyway, I tried to set offset to 0~4, none of them causes difference. Is the offset of raw data buffer? Can someone explain a little more for me?

thanks in advance!

Z

 

[Evan Patton]

The BLE extension only supports 128-bit UUIDs, so you will need to provide the long form UUID for the battery service and not the short form.

The long form should be 0000180F-0000-1000-8000-00805F9B34FB.

Evan

[Ghica]

Try to use when BluetoothLE.IntValueChanged to read these values.
Cheers, Ghica.

[Fengy Zhang]

Thanks both Evan and Ghica's response and sorry about my late response (out of town in past week). 

@Evan, Actually I do use 128 bit uuid as well as characteristic id as below, and I can this request is delivered to server/peripherals, but somehow it was interpreted as different request.  

0000180F-0000-1000-8000-00805F9B34FB

00002A19-0000-1000-8000-00805F9B34FB

@Ghica, I think the problem is more on the service request cannot be recognized on server side instead of reading value back. In case, I am trying to read battery level, so I sent above request with uuid and char id, then do read, but the problem happens when server cannot interpret this request. 

I am purchasing a BLE sniffer right now and once I get it, I can see what the difference in term of packet between "BLE scanner" and "my app based on AI2". 

any more idea? 

thanks

Qiuyu

[Ghica]

Well, If the server cannot recognize the request, maybe you are able to see what the server gets?
What is your BLE device?
Most BLE examples I have seen so far for AI are either battery service or heart rate monitor (which is battery service in disguise), so it must be possible to use it.
Cheers, Ghica

[Fengy Zhang]

My BLE device (center) is Samsung S7, but server is development kit from 3rd party which supported BAS service. the packet is recognized by server/3rd party dev kit as read configuration request instead of read battery level. 

Firstly I doubt it is 3rd party dev kit issue, but I used another apk released on google play "BLE scanner" which can read battery level correctly from 3rd party dev kit.  I will keep debugging to see what is the difference between raw packets of AI2 and BLE scanner. 

thanks

[Ghica]

i am not interested in your Samsum S7, I am interested in your BLE (server) device. Is it an Arduino 101?, an Arduino with HC-10 shield? an Adafruit? a Micro:bit? All work
fine with AI (with some limitations which are currently addressed, but not about the battery service).
So, maybe you could post your AI blocks, for us to look at?
Cheers, Ghica.

[Fengy Zhang]

Hi Ghica, 

thanks for your comments!!!

BLE service is development kit which is like "Bluefruit LE friend". After debugging this, here is what I found out and I understood partial root cause now. 

Basically for Battery Service of GATT (please refer to : https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.battery_service.xml), there could have three properties (READ, NOTIFY, WRITE), but only READ is mandatory based on above link. For my case, the BLE server device supported two properties, one is READ, the other is NOTIFY. see attached snapshot (Battery_service.png).  If I use AI2 blocks (see blocks snapshot: read_battery_blocks.jpg), the request was treated as the type of NOTIFY properties always, instead of READ. For AI2 blocks, as I mentioned before, when using ReadIntValue blocks, there are 3 parameters, service_uuid, characteristic_uuid and intOffset, I filled out these two uuid based on spec, but not sure what the meaning of IntOffset? anyway, it seems that there is no way to differentiate "properties (read/notify) if based on two uuid parameters. 

READ: for me, it means the server should return battery level once READ request is received.  

NOTIFY:  it means the client is registered as listener of Battery service on server, but there is no immediate return required, server will send NOTIFICATION i.e. when battery level is changed. 

P.S: I used attached blocks and can register client (S7) as listener to receive battery level notification from server. But cannot read it immediately, which is my question. 

Thanks again!

Z

[Ghica]

So, you found out that you should use intValueChanged. Which I told you in my first reply ;-(

As for intOffset, it has to do something with the integer representation in you specific BLE device (the famous little Endian and big Endian representation). It has been asked here before, but I did not see a clear answer.

Did you notice that there is a batteryValue block? I never tried it, but maybe it works for you.

Also remember that the BLE extension is very experimental. If something works, be happy, and if not, wait for the improved version, which will come out sometime...
Cheers, Ghica.

[Fengy Zhang]

Thanks Ghcia for your kind help again!

Yes, the block intValueChanged you told me is working when battery level is change. it is great help!!! it is used currently as workaround since immediate reading does not work so far. 

For batteryValue block, I tried it before which always returns "cannot read battery level" regardless if BLE is connected or not.  

I totally understood BLE is extension and super appreciate whoever created it. Just want to provide my feedback if there is something which could be improved, also try to confirm if I did something wrong or not. 

Thanks

Z

[Ghica]

Hi Fengy,
Surely your feedback is indeed very much appreciated.
I do not want to beat this subject to death, but I think part of the confusion comes from the awkward naming of intValueChanged. intValueReceived or similar would be better, because you will always get a value, changed or not, at intervals determined by the notification setting in the BLE device.
Cheers, Ghica.