Does someone has a working BluetoothLE combination with the nRF52840 (peripheral) and an Android phone (mine is A55 as central) which is able to load sensordata into the phone by means of FloatsReceived/ IntegersReceived or ShortsReceived?
I use the Arduino environment to control the nRF chip and send data via bluetooth to the phone. (with library #include <Arduino.BLE.h>
Sofar everything works with the exception of reading the sensors.
All the sensordata is correct if I check these with the nRF app. In other words: the arduino software and nRF hardware are working correct.
Using the MIT App Inventor commands “when BluetoothLE1 FloatsReceived” or “when BluetoothLE1 IntegersReceived” or “when BluetoothLE1 ShortsReceived” is without success.
My Blueooth Extension Version for MIT App Inventor is: Extension Version: 20240822 Date Built: 2024-08-22
Hello ABG,
This log helped me.
In the log i see only the 2 floats passing, both with the correct value but this value still doesn't show up in the labels.
So here i can now focus on.
The shorts and the bytes i don't see in the log, so another issue to study on.
Thank you sofar.
CeeBee
I found one wrong block in the bluetooth buttonScan block.
I used the green block BluetoothClient1. enabled which is not a BLE block.
The is no BLE equivalent block so i have to solve that as well.
But with the wrong block I have BT connection. ??
I did not find typo or labeling.
Last sentence should be: I did not find typo or labeling errors.
Replaced the block BluetoothClient1. enabled with block Call BleutoothLE1. connect.
Now i can connect but still no labels etc.
But a new error 3300: Error 9101 in ectension BluetoothLE: Expected device index etc
MIT is nerve-racking stuff.
Good that you want to continue. I have the impression that MIT and BLE is not mature yet. I do not see a lot of projects where i can learn from. It might however have something to do with the Seeed nRF52840.
Your log file proved that the data of the 2 floats are arriving at my phone. (apperently little endian) The nRF app shows that all the 12 charfiles are there with the correct result. (even with an error 3300.
So I would like to focus now on getting something arriving on the 2 floatlabels.
I still do not know if there is some additional calculation is to be done before this float data is put in the label or that all intelligence is somewhere hidden in the used blocks.
CeeBee nRF52840_4_ABG.aia (635.7 KB)
You went to the trouble of defining global constant variables to hold the characteristics you want to test for in the BLE data stream.
Yet you immediately trash them once you get a match, making it impossible for them to be used for more data.
You need to add the letters 'UUID' to the names of the constant UUID characteristics, and set their names all in CAPS, to help remind you that they are meant to stay constant, and you should not change them.
You might also need extra variables for the incoming data (not their characteristics), for debugging.
My results sofar:
Receiving 2 floats but none shorts.
I followed your advice mentioned by you at other posts.
I put a label in the designer.
As first line in the blocks 'when BluetoothLE1 floatsReceived' and 'when BluetoothLE1 shortsReceived' i put a text block 'floats floats'.
This helped to faster find the problem.
I used on the arduino and on the app inventor blocks capital letters for the adresses.
When checking with 3 apps i saw a following;
nRF app: no capital letters
BLE Scanner app: all capital letters
LightBlue app: no capital letters.
??
I decided to change all adresses on the arduino sketch and in the MIT blocks to non capital letters. Result: All the shorts were now coming in.
??
All the labels are filled with data with only minor issues like brackets for the shorts.
The floats need some rework to show the correct result.
I will also follow your mentioned changes for the names to be in capital.
When i finally check the adresses with the 3 apps then i see again capital letters for the BLEScanner app.
I did that for the floates. ( i saw alist of 0, and a big number )
I received eg 00 80 a2 41 which is translated by nRG app to 20.3 degrees which is equal to the arduino serial monitor output.
MIT shows 4190000 which is quite hot, so i need to do a coversion.
I used nRF app to see the following float data (4 bytes)
UUID 7 DS18B20 temp sensor 00-80-a2-41 ~20.3 degree
UUID 8 BME280 temp sensor 52-b8-a2-41 ~20.3 degree.
I used Scacadore Online Hex Converter.
Float - Little Endian (DCBA)
I am not sure whether you mean this data.
