So I'm testing the different ways in which data can be wireless exchanged between the Edisons. Right now, I am transferring files over an RFCOMM connection that is pragmatically established.
- The two devices are paired (as described in the Intel Edison Bluetooth Guide)
- A 1 MByte is being read by client and sent to server in chunks of 1024 bytes. Client and server code are modified versions of the client/server code on this link: http://people.csail.mit.edu/albert/bluez-intro/x502.html.
- The client connects and sends the file then exits, server continues running
- After two seconds, a new client instance (same machine) transmits the same file again
- After each transmission, the server (which has a copy of the file) runs a cmp command and records number of different bytes.
- When the client and the server are both Edisons, out of the 100 transmissions, there is an average of five transmissions which contain a corrupted byte. The number of bytes is not changed, just one is replaced by another.
- When the client and the server are both laptops (with Bluez running same code), there is no error
- When the client is a laptop and server is an Edison, there is average of three transmissions which contain a corrupted byte.
- When the client is an Edison and the server is a laptop there is no error.
According to my understanding of the Bluez stack, RFCOMM is supposed to be reliable because it requests a reliable L2CAP channel. The Baseband does error checking and drops corrupted packets, then L2CAP does not ACK those packets and they're retransmitted until the end of the flash time-out set by the L2CAP implementation. I tried setting the flash time-out to infinity, but nothing changed. So here are my current guesses and I would really appreciate any more thoughts on the matter:
- Is "Error check" done by the baseband and L2CAP on the entire packets, including payload, or just the headers/size/etc..?
- Is the problem with the L2CAP implementation with Bluez over Yocto, which can be fixed/recovered, or is it in the baseband layer? (It does not drop corrupted packets). quest
However, my main question is:
has anyone else faced the same issue? Is there a problem with Bluez's implementation of RFCOMM on Yocto or am I just doing something wrong?
Also: I've been trying to sniff the bluetooth packets to debug this problem, but I'm only seeing the HCI_EVT packets. If anyone has any idea as to why I'm not seeing the RFCOMM packets that will also be very helpful.
Thanks in advance,