Comments for Android App developers (based in experience):
Mentioned already, BLE supports max. 4 Notifications (where we can subscribe to). Here, the WICED Sense uses just two Notifications (see the document "Sensor Data Format").
(OK, maybe reasonable to do because so we can get all 6 sensor values with just two Notifications. If we would have for every sensor an own Notification (which is actually the standard way to do) - we would have a limitation to decide which maximal four).
It results in following:
a) Even BLE supports well-known UUIDs for Temperature, Pressure characteristics etc. - they are not used here. All sensor values are encoded as proprietary data format. Therefore, you cannot use any BLE data types, e.g. FLOAT, SFLOAT etc. You have to decode all sensor values by your own. (BLE supports a nice FLOAT format where even degC or degF can be encoded - not used here, it makes it harder and losing flexibility).
b) Also not using the UUID for a temperature characteristic results in "Unknown Service" and "Unknow Characteristic",
What the "Sensor Data Format" doc does not tell you:
I) The bytes come as Big Endian! So, a Notification as Java byte[] value comes as: 0x34 0xXX 0xXX (Hum) 0xXX 0xXX (Pressure) 0x09 0x01 (Temp)
II) The value (example) 0x0901 is d'2305
III) I think it should mean: 2 bytes BigEndian degC * 100 (we have two factional digits, not just one with *10).
Therefore, if you convert Temp value into floating decimal - divide by 100, not 10, and watch out for the big endian when doing on
a little endian platform (Android ARM CPU for instance where your app is running)
The "Code Snippet" there with the struct I do not understand completely. What are all these bits?
Is my interpretation right?:
1) The first byte in the Characterstic value (sent via Notification) is a bit encoded field which tells us if a sensor value is present or not (6 or 2 byte fields have valid data or not, but they are always transmitted).
2) Does it mean we can have all combinations, not just starting with 0x0B or 0x34? It can be also 0x01, 0x3F?
3) 0x3F we might not see because all the sensor datas are always split into two Notifications?
4) Is the set of values always constant, what is inside 1st and 2nd Notification?
Means: Humidity, Pressur and Temp. come always in 2nd Indication, not in first, but the first byte bit field gives us indication
which values are valid inside packet?
OK, this might make sense, e.g. if we disable a sensor in WICED Sense device and related value is transmitted as 0 (or garbage).
So, it means, we have to decode first byte always because a sensor value can be missing on Notification data packet.
victorz fredc
