PDA

View Full Version : QSerialPort Bluetooth SPP Slow Response



BrianNorman
22nd January 2016, 16:24
Hi,

I send an 11 byte message to a device and it responds with 75 bytes of data. On USB Serial ports the response comes in 10-15 msec. On Bluetooth SPP connections it takes 60-70 msec. That is all normal.

My problem is on a Mac with a Bluetooth SPP the first response is normal but if I then send another message straight away the response comes back a little slower. Each subsequent message comes back slower and slower until I am waiting 250 msec for a response. If I then slow down my message sending to once per second after a few message the response time comes back down to 60-70 msec.

This effect does not happen on Windows.

I have no concerns about the device I am talking to as I have used it with Bluetooth SPP under Windows using a Visual Studio app without problems.

Are there any buffer or similar settings that I can adjust that might effect this? Either via Qt or via Mac settings?

I think it is not related but I have noticed that CTS is not set for Mac Bluetooth SPP connections whereas in all other cases it is.

Thanks

Brian

BrianNorman
25th January 2016, 10:40
Update to my previous post.

Using qInstallMessageHandler(loggerOutput) I can record accurate timings from my application. Using XCode PacketLogger I can get accurate timings from Bluetooth.

Under normal conditions where I send one message per second the timings are like this.

Application log
08:52:51:556 DBG Sending 0xAC 0x41 0x44 0x45 0xB8 0x0 0x0 0x0 0x0 0x0 0x54 , Length 11
08:52:51:556 DBG Sent 11 bytes

08:52:51:614 DBG 57: Read() read 3 bytes
08:52:51:615 DBG 58: Read() read 9 bytes

PacketLogger log
[Jan 25 08:52:51.561] [RFCOMM SEND] UIH 11 bytes of data for channel 0x01 [¬ADE¸T]
[Jan 25 08:52:51.561] [KERNEL DEBUG] **** [IOBluetoothHostController][TransferACLPacketToHW] -- Connection Handle 0x000C -- SendACLData() success -- incremented -- Devices: low (1), mid (0), high (0) -- ACL Packets in Queue: low (0), mid (0), high (0) -- Outstanding ACL Packets: low (1), mid (0), high (0) -- controller = 0xffffff802eb5c000 ****

[Jan 25 08:52:51.613] [RFCOMM RECEIVE] UIH 0 bytes of data for channel 0x01 [credit frame with 1 credits] []
[Jan 25 08:52:51.614] [RFCOMM RECEIVE] UIH 3 bytes of data for channel 0x01 [¬AD]
[Jan 25 08:52:51.615] [RFCOMM RECEIVE] UIH 9 bytes of data for channel 0x01 [E¸W]

So I send data at 51.556 using 'bytesSent = serialport->write(data,len)'
At 51.556 I get 11 bytes confirmed from 'serialport->waitForBytesWritten(50)'
PacketExplorer tells me that it sent data at 51.561. Packet explorer sees the first 3 bytes at 51.614 followed by 9 bytes at 51.615.
My application is waiting for 'serialport->waitForReadyRead(10)' and is notified at 51.614.

That is a 5ms delay from application send to Bluetooth send. 52ms response from my device.

If I then repeat the test but as soon as I have received data I immediately send a new packet I get a delay.

First packet
32.575 My App send
32.589 Bluetooth send (Delay 14ms)
32.652 Bluetooth receive (Response 63ms)
32.652 My app receive

Second packet
32.653 My App send
32.837 Bluetooth send (Delay 184ms)
32.894 Bluetooth receive (Response 55ms)
32.894 My app receive

It appears to be a delay between Qt send and Bluetooth send. Where do I look now?

BrianNorman
29th January 2016, 09:55
Spent some time reviewing this with Denis (I think the author of QSerialPort) and the conclusion is that it is a Bluetooth stack issue. There appears to be nothing that can be done from the Qt side.