Calliope: receive message string issues

[taslior]

Describe the bug

the block "receive message 'String'" seems not to return the documented empty string if no message is inbound.

To Reproduce Run the code below

Expected behavior I am struggling with checking if a message has been received via bluetooth on the Calliope mini. According to the docs, if no message has been received, the block "receive message 'String'" is supposed to return an empty string. If I save the result of the block in a variable and check if that variable != "" I would expect the condition not to be true. Unfortunately this is not working. In the code below the LED shines green all the time. The same code on the same mini just with message = receive message 'number' and testing if message != 0 works as expected (in accordance with the documentation)

Screenshots

Device information

• Type Calliope Mini 1.3

Additional context The "receive message 'Number'" block returns on idle the number 0. It is not totally clear to me how I could distinguish between

• no message transmitted and
• someone is trying to send me the number 0.

[boonto]

Yes this seems to be a problem, there is no real differentiation possible between "0" or empty values and "null" or no values at all. Our documentation is wrong for strings as well, because the empty PacketBuffer returned by the recv (see this) which we wrap in a ManagedString seems to evaluate to something (but not an empty string, null, or similar).

We should probably provide the dataReady method.

To do:

• [x] change documentation for string to be "undefined"
• [ ] implement "is message available" block
• [ ] add "is message available" to wait until

[philippmaurer]

We added a workarround for the problem in our wiki, with which you can work until we fixed the issue. English wiki entry Deutscher Wiki Eintrag

[bjost2s]

This is not a bug, but a "feature" of the firmware. The only way to solve this is to add the "message availabe" block.

[heini208]

dataReady does not work. It uses queueDepth which is not changed when using MicroBitRadioDatagram.

This could be adjusted. MicroBitRadioDatagram::recv and MicroBitRadioDatagram::send should increase the queue depth.