One thing would be to double-check that the service UUID and the characteristic UUID are correct. Otherwise, you'll end up registering for integers on a service/characteristic that doesn't exist.
UUIDs are correct because I change the same blocks to float and also on the peripheral side and it worked perfectly. It only stop working at when I use Integer.
I have tried RegisterForBytes and RegisterForShorts but it do not register notifications on peripheral side. It only register notifcations on peripheral side if I use RegisterForIntegers but then the IntegersRecived never get executed.
But if I use nrf connect for mobile app it shows that integers are received from peripheral side.
1 Like
Hi, It seems i have the same program, any progress?
Post everything here.
A soon as the connection is made, i try to read the values of all my cractristics.
I used Labels to check if the blocks are used, unfortunately only the block dealing with bytes is triggered.
Every one of the circled if/then tests is wrong.
They all need those green '=' blocks, to compare against something to return a true/false value for the if/then test.
But you actually used a green '=' block in your service UUID test.
You're allowed to pull out more of them.
I think i followed your advice but it seems that the application behaviour hasn't changed.
Did i made another fault?
Okay, I glossed over another problem with your input testing.
byteValues is a LIST, and can not be directly compared against 0.
I don't know what you are fishing for in that data stream, so I will assume you just want to test the first item in that list against 0.
if 0 = (select item 1 from byteValues) then ....
The arduino board send some booleans, the app can't received them in this form. I understood that they are cas into a byte.
i was trying to test their value; 1 = True
By the way i tried to find some answers into the doc at
MIT App Inventor + Internet of Things, but i find it quite incomplete. Do you have a better source?
if 0 < (select item 1 of list byteValues) then
....
else
....
More BLE stuff:
The IntegersRecived block is still not triggered.
When i read the doc, for every Ble.somethingRecived, there is a list of data waiting to be proced.
In a block i specified witch Bytes, integers... i want to get with the UUids (service & Carac), but what's inside this list?
To différenciate witch is witch, i thought i could do some test at the beginning, but it seems that its not the right way to solve this problem.
Since you are still in the first stages of trying to receive data, you need good input stream logging.
In the Designer, add a Debugging Vertical Arrangement with these Labels:
ReceivedServiceUUID
ReceivedCharacteristicUUID
ReceivedByteValues
ReceivedIntValues
At the top of each of your When ... Received events,
fill those Labels from the incoming event variables,
without any attempt to filter them.
When all mysteries are solved, set the Arrangement invisible.
You can do this later, when you know you are fishing in the right stream.
Make sure that your device is also sending a multiple of 4 bytes. The ReadIntegers block attempts to process the BLE payload as a little endian 4 byte wide number. If you only send, e.g., 3 bytes, then it won't work.
An effective work-around is to convert your integers to strings with sprintf() and write to the App with a string Characteristic.
After some test with labels to know witch function is called, the BytesReceived is launch each time a read bytes/integer the app ask for the values.
The right part never triggers!
Perhaps i should only work with integers instead of the two types of var.
I also tested multiple ways to test Uuid, some folks inthe forum compare the uuid directly with the global var (String) while others compare text. Strange!
Expatton, when i check the data send by the arduino with NrfConnect, it seems fine.
There is a Length of List block that can be used to tell you how many bytes are in that incoming byteValues list variable.
You could test if you got 4 bytes, then combine them in a Little Endian manner into an integer.
Hello,
I was involved in the same problem. I solved it by alternatively using the BluetoothLE.BytesReceived event.
Then I got the INTEGER number (name hand in my app) in the following way when BluetoothLE.BytesReceived event,
And I changed from BluetoothLE.RegisterForInteger to BluetoothLE.RegisterForBytes (from unsigned integers to unsigned bytes)
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.