Having problems getting Weight Data with Android from a BLE Scale - java

I'm currently developing an android app for a weight scale I received that transmits data through bluetooth low energy.
I was looking at documentation and if I got the information correctly, there are specific UUIDs for data. I received a BLE scale with a Chinese protocol document found here: http://www.anj.fyi/protocol.pdf
I found and was able to get a functioning scanner working that lists the device name and the UUIDs it broadcasts.
Lets say I want just the weight data to show up in the UI, nothing else and nothing more.
I don't know what UUID they used for the weight data, and there are a lot of UUIDs. Probably 20+. I checked a UUID compilation and the usual weight data UUID does not show up.
How do I get the data from those UUIDs?
I'm thinking it might be the ones that are notifications, indications or read properties.
Looking at the UUID for example, f000ffc2.
How would I get data from that characteristic? Would anyone have an example code to grab the data from those UUIDs, or tutorials because I'm terribly lost right now.
I really appreciate it.

There are no weight information on the document you list http://www.anj.fyi/protocol.pdf, it is only shows the BLE module hardware interface spec, i.e. it does not specify the detailed service and characteristic.(I an a native Chinese speaker).
Regarding to the UUID you want to know which is the one to represent the weight, yes you are right it should be the read/notification feature without write permission. Can you use the apps e.g. lightblue on iOS to receive the notification(meanwhile change the value on your device) to test it? this will help you to understand which characteristic is the one you want.

Related

SensorExtension Raw HRM data to BPM

I've been looking to build a very simple heart rate monitor as a project to experiment with the sensors on the Samsung Note 4, in particular the heart rate sensor under the camera. I've been granted the SensorExtension sdk by Samsung and have run their sample activity that will display the raw data of the sensor.
I was wondering if someone can give me a nudge in the right direction as to how to convert the raw data into meaningful beats per minute data. I know it involves a lot of signal processing but any help would be appreciated as i'd rather not rely on Samsung Digital Health sdk.
Thanks in advance.
If you add a time stamp to the data you can count the peaks and troughs per second. I show this using an excel spreadsheet below. The same method could be easily translated to your Android code.
I also found this information on whats hidden within that Data:
PPG Signal
In the mentioned link they describe exactly what is hidden within the data shown in this image
I hope this helps.

How to obtain sent SMS price

Is there way on Android to obtain cost of SMS after sending it programmaticaly?
It would be really nice to know.
Thing is that for example my carrier always sends notification back with remaining credit, but I cannot rely on that every carrier does the same, and parsing it wouldn't be good idea anyway, as there are many different languages in world and text might be formatted differently depending on carrier.
Unfortunately there's no way to determine that as it's all handled on the network side.
There is impossible to determine pricing on subscriber site using standard android SDK API, price known only on operator's side inside its billing system. But, maybe your mobile operator provides an API for receiving bills and only then you it will be possible to define price you charged.
Also, if it is possible to check your balance using USSD or SMS, you may try requesting balance before sending SMS and after.

Receive and read GATT notifications on Android

So right now, I'm currently using the TI SensorTag and edited it such that it will send a GATT notification with some data every time I press one of the switches on the device and followed this code where moisture is the data I'm trying to send.
static void sendData(void )
{
int length=0;
while(moisture[length] != NULL)
{
length++;
}
attHandleValueNoti_t nData;
nData.len = length;
nData.handle = length;
osal_memcpy( &nData.value, &moisture, length );
// Send the Notification
GATT_Notification( 0, &nData, FALSE );
}
Now on the Java side, TI provided the SensorTag app source code so I'm editing that to receive the data and save it into a .txt file for later retrieval. I was able to get the app to create a new directory on startup if it does not exist and create the .txt file and populate it with random strings with the same button press as the one used to send the data. A quick question I had about this is should this be done or should I use separate buttons?
What I'm having a huge issue even understanding is how to read the incoming notification or data. From what I understand so far, you need to know the characteristic or something of the incoming notification to read it? I do have notifications enabled on my central device so I know that I have at least that covered. For this kind of data transfer, I don't need to use any UUID things, correct? And if I do, would I be able to piggyback on one of the existing sensor services to do so? Or perhaps use the test service?
I've read a decent amount on BLE communications but I just can't seem to get it. How do I read the incoming notification or data I sent from the SensorTag through BLE?
A quick question I had about this is should this be done or should I
use separate buttons?
It's totally your call. If I were you, I would stick on to one button since BLE devices are better if designed the most simplest way. KISS.
From what I understand so far, you need to know the characteristic or something of the incoming notification to read it?
Yes, you need the same profile running on both the peripheral and the central to enable notifications. In Bluez for example, run the bluetoothd daemon with all experimental profiles to communicate with a TI Sensor tag like this: bluetoothd -E . The same logic applies for a central running on Java. Reference: http://www.amazon.com/Inside-Bluetooth-Communications-Sensing-Library/dp/1608075796
For this kind of data transfer, I don't need to use any UUID things, correct?
No, you don't have to since you aren't creating a new service but rather using the moisture sensor service already available on the device.
I've read a decent amount on BLE communications but I just can't seem to get it.
To know more about Bluetooth terminology such as profiles, services, characteristics, asymmetric architecture, etc, please read the following references to understand the theory behind what's taking place:
http://www.amazon.com/Inside-Bluetooth-Communications-Sensing-Library/dp/1608075796 (use this if you are already into the technical details of the project)
http://www.amazon.com/Bluetooth-Low-Energy-Developers-Handbook/dp/013288836X/ref=pd_sim_14_1?ie=UTF8&refRID=13KZ3RZ0VW93CK91RCM3 (this gives a more general picture of the BLE)

How should I manage Bluetooth connections in Android?

Q. What are your best practices in managing bluetooth connectivity?
I've read the android bluetooth guide & many bluetooth connectivity tutorials. Not helpful with encapsulation-design nor best practices.
When should I open/close the connection?
Is the "connection" with a single bluetooth device called a "socket" connection?
Can a single connection send data while listening? (...or between listening states).
I've never coded connectivity with external devices before. It took two weeks for me to wrap my head around the code that scans for near-by bluetooth devices and throw them into a ListView. Listeners, Broadcasts, and Adapters!
My project will be printing 1-40 receipts every 15 minutes on a bluetooth receipt printer. At the moment, security is not an issue. On the same connection, it will also be receiving data (sending & receiving simultaneously does not appear to be necessary but would be useful). I'm not yet sure how the devices are configured on this single dongle device but I would guess the devices are connected via USB controller to the dongle.
So far, I have 1 object to manage a single I/O connection. Staticly I open an activity to select a connection (to later save the label, mac, and pin in the database). Based on tutorials, I have "open", "listen", "send", and "close" methods. What confuses me is "how" to use these functions. Can I leave a connection open all day (10hrs) and use it every 3mins? Should I open/close the connection when sending or requesting data? Where would I detect the need to reconnect?
sorry for the short answer, but from my practice with the Bluetooth API, I have found that this video describe the things very good (totally personal opinion...)
Video 1
In addition this is useful when you do NOT have any previous experience
Tutorial
And as last check out this question in stackoverflow it has a bunch of good references and examples!!
Again sorry for the shortage, but I believe that if you check these out at least most of your questions and concerns will become answered!
:)
EDIT
So, let me be a bit more descriptive and share some of my experience.
I have written an App that communicates with BLE device that has 3 functions
double sided event driven button (push the button on phone -> event is fired to the device; push the button on the BLE device -> event is fired to the phone)
send request from phone -> BLE device answers with current battery percentage
continuously reading strength signal (as aprox. distance) between the phone and the BLE device
So far so good, now the things is that the basic approach is:
Search for BLE devices (bluetooth search or "discovery" of nearby bluetooth devices)
Here you will need android permissions!
Choose the device you want to connect to
To differ the devices (maybe there are a lot around you :) ) you can use BLE device's name or UUID or ... best - use the name ;)
After both devices connect to each other you can then start the Gatt communication. The approach with state machine is a little too much overkill for me. But anyway the communication is done through bytes (in my case...)
In one of the videos/resources there was something specific and VERY HELPFUL at least for me! To be honest I don't remember it exactly, but the idea was that before any communication it's RECOMMENDED to read/get all the options from the BLE device or something similar...
Maybe it was something like discoverOptions() or something like that
Great thing will be to know your device "communication codes" or at least I call them that way.
Check this link for example: Link
** Now you can see there are tables with the USEFUL INFO! E.g. if you want to read the battery level you navigate to this page and find that in order to read the battery, the service name is UUID XXXXX and you need to send 0x01 to the BLE device and it will "answer" to your call with some data which is again in bytes.
I really hope that this is somehow helpful!
PLEASE NOTE
This is strictly coming from my experience and there could be some mismatches or wrong terms, but that's how I personally see the things and because my project was long ago, I don't remember most of the things exactly.
IMPORTANT:
This is only a summery of STUCI's provided links above. He has since updated his answer and I have not updated/edited this summery. Topics in my summery are not explanatory but provided for reference and help in generating specific questions.
Original Post...
Thank you Stuci! Some of that was helpful:- some not. I thought it best to collect my thoughts and see what has been explained and if anything hasn't.
(I can't post this much in a comment tho, sorry)
PLEASE CALL ME ON ANYTHING THAT IS INCORRECT.
Video of Bluetooth LE
(Covers a bunch of random things)
While I "dont-like" videos of code:- I watched it because it was recommended ... and I am glad I did. While not very helpful it did introduce some concepts I was unaware of. Since I am targeting old android devices (v8+) the LE features are inconsequential.
Pushing Data: [Depending on the source feature-set], one does not need to continually pull data (ex. with a temperature sensor) but some devices can "push" it to the device on change. Seems to use the 'advertisement" design concept.
UUIDs define Services and/or Characteristics of the connected device.
Possibility to write configuration on (to) connected devices.
Characteristics which seem to be simply "settings" that can be assigned over bluetooth. Not sure if this (~19mins) applies to non-gatt connectoins but seems similar to the state-machine that controls
Advertisements which seem to be the "metadata" regarding the devices current state or config (~24mins). Again, not sure if this even applies to non LE Bluetooth.
Leaving Connections Open
Bluetooth connections can indeed remain open; starting at the point which the "startActivityForResult(...) method is successfully called.
Two basic things affect whether or not one would want to maintain an open connection:
Understand the power consumption.
Having the adapter active simply consumes additional power. If one can keep the adapter shut-off while it is not "absolutely-needed" will mearly save battery power.
Accidental disconnects are managed.
Other than leaving the connection continually connected, one could disconnect & reconnect regularly at specified intervals to ensure a connection is up.
In the thread(s) used for I/O, one could check for a disconnect and reconnect (possibly starting a new thread).
I/O Streams pr Connection
A single connection can indeed "have" simultaneous Input & Output streams. I
Since it was suggested, I re-read Android's Bluetooth Guide and under "managing a connection" (talking about a single socket) I noticed this...
Get the InputStream and OutputStream that handle transmissions through the socket, via getInputStream() and getOutputStream(), respectively.
Read and write data to the streams with read(byte[]) and write(byte[]).
...but continues with noting that read & write block each other. Something I still need to look further into. It seems like you cant I/O simultaneously on the same socket???
Max Connections
I also looked into the max connection issue Stuci added and found no documentation on the Android-side. It might exist, I cant find it. However, most people seem to agree that there is a limitation (that could be as low as 4) imposed by whatever hardware you are coding for.
Some notable links:
- How many devices we can pair via Bluetooth of BLE to Android?
- How many maximum device can we pair via Bluetooth to android device at a time?
- https://groups.google.com/forum/#!topic/android-developers/adeBD275u30

Android - Adaptive Bit rate streaming. (HLS) Quality of stream

I'm new to adaptive bit rate streaming. Basically I'm trying to write an app that shows information about the quality of the connection on an Android device.
Since HoneyComb(3.0), Android supports adaptive bit rate streaming through HTTP Live Streaming (HLS). It seams like support for helping developers verify the quality of this connection device side is very limited.
What I would like to know is some low level information about the stream. Such as: the number of segments, the segment duration, number of requests to change bit rate, the bit rate the media player sees (to facilitate the change), etc.
I've been able to get some information about stream quality from the MediaPlayer, MediaController, MediaMetaDataRetriever, CamcorderProfile, MediaFormat, MediaExtractor classes. However, the stuff I'm looking for is even lower level. If possible I'd like to be able to actually see how the player is communicating with the server.
I just started looking at the MediaCodec class, however I can't figure out how to get the MediaCodec from a mediaplayer. Or Maybe I just don't know how to use this properly as I cannot find any good documentation and examples.
Does anyone know if it is possible to access the low level information on the Android that I'm looking for? Is the MediaCodec the way to go? If so, does anyone have any working examples of how I could get the currently used MediaCodec and extract the information I'm looking for out of it? (Or at least point me in the right direction)
Really appreciate any help on this one.
Cheers

Categories