Question about BLE extension reading a value

Hi there, i have a BLE device and i succesfully connect it with my app. When i push a button, the device send a hex value of two bytes (0xFF01). When i try to read the value from my app using the ReadIntValue with intOffset 0 and 1 i get the correct values 255 and 1 but when i try to read the value with the ReadStringValue and offset 0 i get a strange symbol. I attach 3 images showing the values in the top right corner.

I really appreciate any help you can provide.

--

Please take a look at the bottom of this thread: Problem: DataTyp Convert with BLE


--

Hello Ghica, thanks for your response. I already seen this solution but i can't find this character in the table.

-- 

I print the value that the BLE extension reads into a textbox then i copy and paste it into a comparison box and it works but i don't understand why it reads the value with this way.

-- 

Do you know what your BLE device is sending? And in what format?

-- 

Interpreting what you read in the BLE extension can be difficult and (forgive me @Ghica) sometimes impossible.

The normal, printable ASCII character set runs from 32 (space) to 126 (~). From 128 to 254 are a range of special printable characters see here:

 http://www.theasciicode.com.ar/ 

As you can see ASCII value 255 (Hex FF) is defined as a "non-breaking space". I don't know what that means!!!!! But AppInventor is printing the strange symbol you have shown in your previous posts. It's an unfortunate coincidence that you are sending Hex FF

However, if you can read the input correctly as an Integer, why not continue to do that?

If you are in control of what your device sends to AppInventor, then you can send what you like: If you want to read and interpret a string, then send a readable string!

How about "On" and "Off" ?

Hope this helps

-- 

I analyse with wireshark the bluettoth packets that the device send and recieve. And as i can see it is in hexadecimal format.

-- 

Unfortunately Neil i can't change the value that my device sends. In this specific situation i can do my job reading only one byte but maybe another time i will need all the information.

--

So the device output is fixed; OK.

I may be wrong about this, but I doubt that your device sends in Hex - it almost certainly sends in Binary. Hex is merely a convenient way for Wireshark, nRF Connect and other systems to display a binary value, since each Hex character represents 4 bits.

On the question of Wireshark, did you implement on an android device? If not, how did you capture the BLE packet.

-- 

Yes the device is fixed. It's an activity tracker (smart watch). From a rooted android device i capture the packets and analyze the log file with wireshark. The activity tracker has an option that i can take remote pictures from the camera. I found the value that i must send from the app to enable this option and when i push the button from the tracker i open and close my BeeWi bulb which is also connected to my app. It works fine if I use the character that i posted later. So do you think that if i convert it to binary it'll work also?

--

You don't need to change it to binary - one of your images shows it seeing the value 255 so why can't you use that?

-- 

This is only the half of the information. Another device might send a value of 5-6 bytes. I need to read all the information at once.

-- 

It is possible, using repeated Integer reads at offset 0, 1,2,3,4,5 etc, I have done it, but it is very complex and also VERY VERY slow.

I think you will have to be patient - the BLE extension is still experimental and is known to have a number of shortcomings.

I understand that a new version is expected in a couple of months and, hopefully, should make it much easier to do what you want to do.

-- 

Thank you Neil. I also read about the new version of the extension. I will wait to see the new features...!!!

-- 

As far as the micro:bit is concerned, I am wondering how you can get useful values by repeatedly reading ints. The next time you get the value, it has changed, so you cannot really combine them.
I tried to read accelerometer values as a string, but from there my attempts fail. The profile says:

Accelerometer Data : Contains accelerometer measurements for X, Y and Z axes as 3 unsigned 16 bit values in that order and in little endian format. Data can be read on demand or notified periodically. Values are in the range +/-1000 and in milli-newtons.

I used Italo's asc function to get values out, byte by byte, but I found that bytes 2 and 3 are always 0 and the others have values between 0 and 128, roughly.
B.t.w. I wonder how unsigned numbers can be negative?

-- 

Ghica - my solution  serves to illustrate a number of things:

1. The mismatch in the BLE readInteger means you see 6 separate 8 bit integers, instead of 3 separate 16 bit integers

2. You have to know they are supposed to be 16 bit, signed AND little endian to make sense - In fact, you have to know the answer in advance to set up the algorithms to get the correct answer - see below.

3. I can, with extreme difficulty correctly read the values from a STATIC micro:bit, where the values are NOT changing

4. I can convert the values into X,Y and Z coordinates which are CORRECT.

5. As a method of reading changing Accelerometer coordinates, my solution has NO practical value!! Hopefully, the eagerly awaited new version of BLE will solve the problem.......

This is what I did:

1. Lock the mocro:bit down on my desk.

2. Use the micro:bit Blue App to read the accelerometer data and to set the refresh period to 640 mS - maximum.

3. Wait for the values to stabilise and write them down

4. Disconnect from micro:bit Blue and connect AI Companion to develop and run my very tortuous App

5. I can calculate the same coordinates as I read in micro:bit Blue App

There is a misprint in the micro:bit Bluetooth profile at:

https://lancaster-university.github.io/microbit-docs/resources/bluetooth/bluetooth_profile.html

In the Accelerometer Service it says "Value contains fields which represent 3 separate accelerometer measurements for X, Y and Z axes as 3 unsigned 16 bit values in that order and in little endian format." --- WRONG

and in the Accelerometer Characteristic it says "Contains accelerometer measurements for X, Y and Z axes as 3 signed 16 bit values in that order and in little endian format. X, Y and Z values should be divided by 1000 "

And, indeed, depending on how you position the micro:bit, you do get 2s complement negative values, especially on the Z Axis - micro:bit Blue proves this!

I have tried to use the string method, with the weird characters for ASCII values below 32 in another situation, but I couldn't get it to work at all. I ended up using my own method, again based on repeated readInteger.

-- 

I will speak openly.

Don't waste your time with App Inventor,  it is VERY BAD for ble. If you want to wait for new version App Inventor, it can take few years ;-)

I wasted 8 weeks with App Inventor for to READ and NOTIFY ble app.

App Inventor works for only WRITE function,  it doesn't READ and NOTIFY.

 As i said before, don't waste your time with App Inventor ble, learn Android Studio. Search "BluetoothLeGatt" in internet.

I found a code, after the few weeks, i learned to add some code in it.  My app is working now for READ and NOTIFY now (Android Studio)

-- 

This is not true. If your BLE device has notification turned on for a certain characteristic, the values for this characteristic will be received by App Inventor just fine in the ChangedStringValue or ChangedIntValue event blocks. I agree that there are many restrictions currently, but I hope and expect that there will be a much improved extension or maybe even a component anytime soon.

-- 

I would add to what @Ghica said: using AppInventor and using Android Studio are worlds apart..........a very big learning curve in Android Studio!!

-- 

%90 Bloutooth Low Energy MODULES are Notification turned OFF in the market. %10 is Arduino 101 and others.

So, can you give me an idea about READ without NOTIFY first?

Do you have a Notify ON example for BLE with App Inventor?

We can play with Arduino 101 and App Inventor Ble together, but you can't use Arduino 101 in serious BLE project.

For me, AI2  BLE works for write only, if you have ONLY ONE NOTIFY SAMPLE in your hand, i will say "YOU ARE RIGHT"

-- 

To me, being right is very unimportant. What matters to me, is to be able to tell the folks at MIT what exactly the BLE implementation should be able to do, and what it cannot do now.
Yes, as already said many times, the current BLE extension is very experimental and it lacks a lot of functionality. Yet, it is fun to play around with. And, why not write your own extension if you are already skillen in Java and the Android SDK?

I am wondering about your read without notify. Does it mean you want to read some characteristic once and only when requested, via ReadIntValue for example?
Do you have a sketch for the Arduino 101 that asks for this functionality?

B.t.w. I was looking at examples for the Arduino 101 this morning and they all seem to encapsulate the BLE stuff in a way it looks like an old fashioned Arduino sketch, which the App Inventor BLE extension certainly cannot handle.

--