QBluetoothSocket (RFCOMM) sending data only in small bursts (1024 bytes) on N950
-
Hi all,
I have an app (on N950) that basically needs to send over bluetooth large amounts of data continuously (as much data as bluetooth can physically allow). So I have packages of around 7 KB that I will send continuously over RFCOMM bluetooth sockets. I connected to the @QBluetoothSocket::bytesWritten(qint64 bytes)@ signal and much to my surprise I see the signal being emitted with parameter bytes having a value of 1024 (except of course for the last part in the packet, in which case bytes is smaller thatn 1024). This is obviously too small. Instead of sending my 7KB packets each in on go, the bluetooth implementation sends my packet in 7-8 steps: this is clearly slowing down the transfer.
See below some qDebug output:(SmartCam) BtCommHandler::send(): bufferLen= 4912
(SmartCam) AppEngine::frameAvailable() sent frame SUCCESS
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 3888 ; bytesToWrite= 3888
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 2864 ; bytesToWrite= 2864
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 1840 ; bytesToWrite= 1840
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 816 ; bytesToWrite= 816
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 816 ; left2send= 0 ; bytesToWrite= 0
(SmartCam) BtCommHandler::send(): bufferLen= 4863
(SmartCam) AppEngine::frameAvailable() sent frame SUCCESS
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 3839 ; bytesToWrite= 3839
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 2815 ; bytesToWrite= 2815
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 1791 ; bytesToWrite= 1791
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 1024 ; left2send= 767 ; bytesToWrite= 767
(SmartCam) BtCommHandler::onBtSocketBytesWritten(): bytesWritten= 767 ; left2send= 0 ; bytesToWrite= 0
What is it with this 1024 max size? Is it specific to N950 only? Maybe on N9 there is no such limitation ....?
Is there any way I can change this default 1024 max size to make it bigger? I've looked over the APIs but couldn't find anything helpful. Any other ideas/hints are very welcome and appreciated.Thanks & regards,
Ionut Dediu -
Hmm, looks like your problem is related to the bluetooth settings MTU which is probably set so something around 1k.
Try to change your MTU settings:
This is my n950's default:
@
~ # hciconfig
hci0: Type: BR/EDR Bus: UART
BD Address: B4:EE:D4:91:79:50 ACL MTU: 1021:4 SCO MTU: 180:4
UP RUNNING PSCAN
RX bytes:3384381 acl:82636 sco:0 events:45662 errors:0
TX bytes:757476 acl:44933 sco:0 commands:193 errors:0
@You can change it like this:
@
~ # hciconfig hciX aclmtu 2048:4
~ # hciconfig
hci0: Type: BR/EDR Bus: UART
BD Address: B4:EE:D4:91:79:50 ACL MTU: 2048:4 SCO MTU: 180:4
UP RUNNING PSCAN
RX bytes:3384381 acl:82636 sco:0 events:45662 errors:0
TX bytes:757476 acl:44933 sco:0 commands:193 errors:0~ # hciconfig hciX scomtu 2048:4
~ # hciconfig
hci0: Type: BR/EDR Bus: UART
BD Address: B4:EE:D4:91:79:50 ACL MTU: 2048:4 SCO MTU: 2048:4
UP RUNNING PSCAN
RX bytes:3384381 acl:82636 sco:0 events:45662 errors:0
TX bytes:757476 acl:44933 sco:0 commands:193 errors:0@
Does this solve your problem? I know it's not via software but if that solves it you know that all you have to do is access those settings via sw.
good luck!
-
Hi cpscotti,
Thanks for your reply.
I did what you suggested:@RM680-22-6_PR_RM680:~# hciconfig
hci0: Type: BR/EDR Bus: UART
BD Address: B4:EE:D4:E5:D1:F3 ACL MTU: 1021:4 SCO MTU: 180:4
UP RUNNING PSCAN ISCAN
RX bytes:208637 acl:6234 sco:0 events:13436 errors:0
TX bytes:12526546 acl:24424 sco:0 commands:87 errors:0RM680-22-6_PR_RM680:~# hciconfig hciX aclmtu 2048:4
RM680-22-6_PR_RM680:~# hciconfig
hci0: Type: BR/EDR Bus: UART
BD Address: B4:EE:D4:E5:D1:F3 ACL MTU: 2048:4 SCO MTU: 180:4
UP RUNNING PSCAN ISCAN
RX bytes:208637 acl:6234 sco:0 events:13436 errors:0
TX bytes:12526546 acl:24424 sco:0 commands:87 errors:0@I guess the command hciconfig hciX aclmtu 2048:4 sets the MTU to 2KB;
However this does not solve the issue, I am still getting the same qDebug() output as before.
I tried another way, using a TCP socket (QTcpSocket) over the usb connection to my PC. In this case all my packages are sent in one go, no more 1024 fragmentation; plus the transfer rate is huge;
I am porting SmartCam (http://sourceforge.net/projects/smartcam) to MeeGo;
Before trying the TCP socket I was suspecting I was doing some other processing that was slowing down the overall FPS; however on TCP the FPS on the server app on the PC is 29 (close to native n950 camera FPS), so the slowdown in case of bluetooth connection is related entirelly to bluetooth.
Now I understand that bluetooth is not nearly as fast as USB networking, however I easilly get a 25 FPS using bluetooth on a Samsung Wave 723 which does not have 1GHz processor...Currently the FPS on bluetooth using N950 is 12-13 ... really feature phone like ...
Thanks again for your help,
Ionut -
hmmm.. weird.
One thing you can try is to lower the video resolution. I'm pretty sure that the resolution you were using in the Samsung Wave is smaller than the one you're using the n950 with. That might explain the difference. More data per frame/ less frames per sec!
Makes any sense?
-
I am hardcoding the resolution to 320x240 on N950; and I know on Samsung Wave 723 I can get 25 FPS on bluetooth with the same resolution (320x240):
http://www.youtube.com/watch?v=sZMqFr_82hMThanks,
Ionut -
The fundamental problem is link bandwidth. Assuming the connection is Bt 2+EDR its nominal bw is about 3mbit/s in ideal conditions. Assuming no overhead:
320x240x32bppx25fps is ~7.5mbit/s.
320x240x8bpp it's a more reasonable ~2mbit/sec.
Bluetooth 1.x is 721kbit. The problem is, most systems don't operate in ideal conditions either. Wireless networks also share bandwidth and generally don't get maximum throughput consistently either.
Usb 2.0 operates at 480mbit, with a possible throughput in the 30Mbyte/sec range. Not exactly a fair comparison.
Packet fragmentation is going to get you a few % change, but hardly enough to double your throughput.
As an aside: TCP by default has an MTU of 1500 bytes.
-
Hi,
Thanks for the reply.
I am compressing each frame using MJPEG so each frame is in average 5-7 KB in size.
56 Kb x 30 ~ 1.8 MbsBluetooth v2.x has 2.1 Mbs, so it should be enough even for 30 FPS.
I think there is clearly something wrong with the Qt mobility bluetooth implementation.
Is there any way that I can access directly the bluez APIs using only Qt SDK (that is without installing scratchbox on a Linux machine)?
Thanks & regards,
Ionut