Receiving data from BluetoothLE

MIT App Inventor Help
21

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.

22

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)

23

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

24

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

25

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.

26

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

blocks (2)
blocks (2)1814×2076 464 KB

omma)

27

ShortValues is a list.

Select items by number.

Test list length first.

Then show us your shorts

28

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..

29

I don't have to crack open my eggs before I scramble them, if I like them crunchy.

30

Hello ABG,
what is the hidden wisdom in that last statement.
I want to improve.
regards
CeeBee

31

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.

32

Ok it's done and working.
I will now continue with the alarmblocks.
Writing the times of alarmevents to the phone.
I seems doable to me, but when i stumble i will come back to the community.
Thanks again for the GREAT support.

blocks
blocks1936×1436 355 KB