(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.
I used yet another appraoch.
I wanted the inside and outside temperature with one digit, so I started to use floats.
Thats was too difficult at the end.
Now a multiply the temperature reading of the arduine sketch by 10 and define it is short.
In the MIT app i divide it by 10 and get my 1 decimal back.
Herer are my 5 blocks of shorts. ( 2 with 1 decimal behind the c
omma)
ShortValues is a list.
Select items by number.
Test list length first.
Then show us your shorts
I used your logfile for the 5 shorts.
UUID17 (198)
UUID18 (199)
UUID19 (43)
UUID1A (997)
UUID1B (27)
So all my shorts have a list of 1 only item, meaning i do not have to select out of a list..
I don't have to crack open my eggs before I scramble them, if I like them crunchy.
Hello ABG,
what is the hidden wisdom in that last statement.
I want to improve.
regards
CeeBee
Those [...] wrappers you found are AI2's JSON markup that it uses to show the structure of a list that it has been asked to render as text.
They are like the shell of an egg, there only for transport, and not to be eaten.
Selecting item 1 from a list is like cracking the egg to get only its contents and leave behind the eggshell.
Falling back on AI2's default text conversion is sloppy programming practice, and leaves you open to failure if the default setting in Project Properties of showing lists as JSON is ever changed.
It also requires two text replacements for the brackets, and possible more if there are text items in the incoming list, which would arrive with "x" markup. (Okay, these are shorts, but it's good practice.)
A more concise code would have been
set Luchtdruk.Text to JOIN((select item 1 from shortValues), ' hPa')
for example.
It's more to the point, and avoids the round trip of list to text wrapping and unwrapping.
