Size limit on bluetooth packets

[Jannick]

Hi

Im fooling around with some nxt->pc communication in order to get a grip on the concepts. My goal is to use bluetooth to send some sensor readings and such back to a pc for a high level action planning. I can see that the current implementation sends each byte in a seperate BT packet, which gives me some concern for what kind of execution time you will se when you try to send a "large" byte array. I havnt gotten around to test on this yet, but do any of you have experience in this regard?

I did instead play a bit with sending up to 254 bytes packets by bypassing the outputstreams, which seems to work fine. The problem arrises when I want to receive it on the pc, with NXTCommBluecove performing this check:

Code: Select all

       if (lsb != 1 || msb != 0) throw new IOException("Packet more than 1 byte"); 

Is there any reason that this limit is here? Is it because of umimplemented code, or are there some hardware/protocol limit to force this? And lastly, have anyone had success with sending larger packets from the nxt, and how did you accomplish that?

Thanks in advance

[CoBB]

There’s certainly nothing in the way of it if you’re using a low-level API. I wrote my own PC client (using bluez though, since it’s for Linux), and it works without a hitch. If you don’t need the abstraction that those streams provide and are willing to process the raw packets yourself, you can definitely do it.

[lawrie]

There is nothing in the hardware that imposes any limits.

The implementation of streams is very primitive at the moment. The NXT sends in 1-byte packets, and the PC only sends anything when you call flush().

The low-level Bluetooth API on the NXT has deficiencies as well. It follows the Lego convention of using 2-byte headers for Bluetooth (but not for USB), but does not need to. Also, it currently ignores the MSB of the 2-byte header, limiting packets to 254 bytes.

I would like to remove the 2-byte headers for Java streams, as there is no need to split the stream into packets.

In release 0.3, data coming back to the PC did not use 2-byte headers, but when I implemented NXT to NXT comms, I add the headers as they are currently needed on a receiving NXT. The check for 1-byte packets was added at that time. It would be fairly easy to change the NXTCommBlueCove (and NXTCommBluez) code to allow packets of more than 1 byte.

[Jannick]

Thanks for both answers. I've made what basicly amount to a BufferedOutputStream on the nxt, and patched the BTOutputStream with a byte array write method that only kicks in when the len < 254. Will try to modify NXTCommBluecove as suggested.