You need more instrumentation to see what's arriving.
I added a log() procedure to add a log of incoming data to the Elements of a little magenta List Picker
Just click the List Picker to see what arrived (if anything.)
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
This might be from:
Typo in the characteristics causing if/then tests to fail
Label visibility
Wrong label
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.
I am lost in a maze with no exit.
Thanks for the support.
I try someting else.
(Canned Reply: ABG- Export & Upload .aia)
Export your .aia file and upload it here.
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.
In case you don't know yet, BLE data arrives in lists, so you have to select item 1 from the list to get a value without markup.
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.
Show the log capture of all the floats , not just the second one.
More diagnostic data is needed here.
The CSV row From List block is good for list to text conversion, as is Join With Separator ','
Also, there are different flavors of float.
Revisit the upstream data type and the BLE block tool tip to look for a mismatch.
P.S. You have a LOT of characteristics. Check if you got them crossed.
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.
That's handy, but it is not the same as what is coming out of the AI2 BLE component, as fed into my log procedure.
You have not shown that.
I am quite surprised by the little endian DCBA 32 bit float result.
That is hard to match to the IEEE 754 standard.
Also, I don't have access to the data types in the sketch implied from the BLE characteristic declarations. Those must be somewhere in the header files.
If it were me, I would stick to all text and a single text characteristic, with little YAML labels for each datum.
Hello ABG
this is what is coming out of your log.
I don't know how to copy from phone to the pc, so i typed them. Only the 2 floats.
10:30:12
serviceUUID:
19b10010-e8f2-537e-4f6c-d104768a1214
chracteristicUUID:
19b10017-e8f2-537e-4f6c-d104768a1214
type:
Float
values:
(0.0 4080000.0)
10:30:12
serviceUUID:
19b10010-e8f2-537e-4f6c-d104768a1214
chracteristicUUID:
19b10018-e8f2-537e-4f6c-d104768a1214
type:
Float
values:
(-1.64E-6 4080000.0)
So apperently 4080000 is the correct data (~19 degree celcius)
Notice how the values list has exactly two items in it?
That suggests is sketch is sending 64 bits instead of the expected 32 bits.
There is a 64 bit float format.
Maybe the sketch is sending 64 bit floats?
By now you should be able to decode and encode those at the bit level.
I might have posted an IEEE754.aia toolbox on this board to do step by step conversion
Ok ABG,
thanks for the support sofar.
I will study the float road and the text road.
The last one is used in most tutorials and maybe we know now the reason.
CeeBee
There is another path available to you too.
The BLE extension could be told to expect bytes (0-255) and you could take the incoming 8 bytes and interpret them against the 64 bit float format.
