Mindboards

I'll admit right up front - this has been stated previously. However, now that I actually need it, I can't find it.

What is the longest string that can be sent over Bluetooth using SendRemoteString (or SendResponseString)?

The BT buffers are 64 bytes (as are the USB buffers). I guess the longest would probably be 63 characters plus the NULL terminator.

If you are using mailboxes then the longest you can send is 59 bytes (not counting the null) due to the overhead of the MessageWrite direct command. The longest you can read using MessageRead is 58 bytes (not counting the null) due to the overhead of the MessageRead direct command. This is documented in the Bluetooth SDK direct command protocol PDF.

The bluetooth input and output buffers are actually 128 bytes long. The hispeed input and output buffers are also 128 bytes long. The usb input, output, and poll buffers are only 64 bytes long.

http://mindboards.svn.sourceforge.net/v ... iew=markup

John Hansen

Okay, I just learned something.

If the BT buffers are 128 bytes, does that mean there are 68 to 69 bytes over-head? That sounds a bit (* >= 480) insane to me.

afanofosc wrote:If you are using mailboxes then the longest you can send is 59 bytes (not counting the null) due to the overhead of the MessageWrite direct command. The longest you can read using MessageRead is 58 bytes (not counting the null) due to the overhead of the MessageRead direct command.

(I am using mailboxes.) I was doing all right until I hit the "not counting the null".

If I do a strlen(outboundstring), the result should be <= 58, because there is a terminating null and it needs to be readable on the other end. Right?

Above edited to clarify based on John's following post.

There are mailbox-specific restrictions I forgot to take into account:
http://mindboards.svn.sourceforge.net/v ... iew=markup

So both directions a mailbox will only hold 58+null=59 bytes.

If you do not deal with mailboxes or the direct command protocol then you can send and receive bluetooth messages of up to 128 bytes in length due to the size of the input and output buffers. As users of bluetooth GPS devices know, receiving a message that does not follow the direct or system command protocol is a little tricky. But it is doable and you can use all 128 bytes of the BT buffers.

John Hansen

Just to have a little clue: not using direct/system commands, only requires to avoid the possible combinations of chars in the beginning of the buffer that would be interpreted by the FW as something else, right?

I mean, I have tried this before (I actually just tested it again) and it seems to work. In the 3rd byte of the BT buffer, instead of a command byte, I send "0xFE". Just one option that is not contemplated in the direct commands protocol. But I'm afraid that it just works with some chance. Maybe some exception can happen that I am not taking into account.