Receiving data from bluetooth module hc-06

Hi, I am currently working on a FPGA project and I need to receive data from FPGA through a bluetooth module. When i received 00000001 from FPGA, the mobile phone should vibrate and evacuation notice pops out. However, the code is not working.

For some reason, when i added a label1 and the corresponding code, the code works, the mobile phone successfully received data and vibrates.

But i would really like to remove the label1 as it is not needed for my project to see the received data.

Thank you.

Please post the transmitting code, so we can see the data format.

Also post a screen shot of the Label showing the arrived data.

I don't expect that ReceiveUnsigned1ByteNumber to ever return a value, because the ReceiveUnsignedBytes block just emptied out the BlueTooth input buffer.

By the way, that ReceiveUnsignedBytes block returns a list.

Now would be a good time to learn how to work with lists.

Dear @H20_z welcome to the Community.

I see that @ABG has already answered you while I was writing my answer, anyway, you can also try the following:

In my understanding your blocks are very different each other. I mean: the second picture shows that your code waits until the receiving BT buffer has been filled up, before loading its contents into a variable (Received_data).
My suggestion is just do the same thing but without displaying the Received_data into the label.

EDIT : this works only if your device is transmitting only one unsigned byte whose content is 01. So please carefully evaluate what @ABG said, if my suggestion does not work....

By transmitting code, do you mean the code that produces the 00000001 input from fpga to mit apps?

This is when the apps receives data.

What do you mean by 'ReceiveUnsignedBytes block just emptied out the BlueTooth input buffer'?

I actually don understand how they are different.

'your code waits until the receiving BT buffer has been filled up, before loading its contents into a variable (Received_data)', what code causes this to happen?

Dear @H20_z ,
if you read tha "hundreth" of posts relevant to the BT comm's, you'll find that the most used way to namage it is to use the receive and transmit Text toward a server (assuming that the app is the client).
To this purpose the block that allows a complete reception is

The negative number (-1) instructs the app to receive the incoming bytes (characters) into a buffer, and to waiit until a delimiter that closes the transmission, has been received. Typically the delimiter is the ASCII character "linefeed" or LF, in decimal the number 10 or in hexadecimal 0x0A.
To comply with this method, the transmitting device shall terminate the sending with a linefeed. If you use an Arduino, this means that your last transmission shall be done by using a BTserial.println('1'),
On app side this becomes:
and on the designer page, in the Bluetooth Client parameters settings, you shall set this:

That said, your question was in what the two blocks differ: well, the "working" version uses the block:
and this block is the one that waits until characters are being received. If the sending device stops sending for a while, the app does non wait any longer and exits., but at least has tried to receive as many characters as it is possible until a timeout. In your case, this allows anyway the app to wait sufficiently to receive the byte '1'. The first version (the not working one) just verifies if there is something in the receiving buffer, then tries to read just 1 unsigned byte:

I hope this is a bit clearer. If you want to deepen all the stuff relevant to the BT comm's you can have a look to the web sites of other AI2 power users like (@Juan_Antonio ) and (@ChrisWard ). Or the AI2 FAQ managed by @ABG .

i read abt the delimiter stuff before and i don really understand, but now i understand them after your explanation, thank you for answering my questions and i have successfully created the apps i desired, thanks again

thank you @ABG

Happy of that !!!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.