Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I own a Logitech M555b mouse for use with my HP Elitebook 8570w laptop running Kubuntu 12.04. Works fine right after connecting using the KDE Bluetooth control module.

However, after some time (seemingly random), it starts to lag. Movements are being delayed for roughly 500ms for a short period of time. Usually it recovers after some time too, but it can take minutes. All actions are being delayed: movements, click, scrolls. Additionally, the movements can be choppy during these times.

A workaround that always works for the same short period of time is to disconnect an re-connect the mouse. This can be done using the same KDE Bluetooth control module.

What did I try already?

  • Running this at boot time:

    echo on > `readlink -f /sys/class/bluetooth/hci0`/../../../power/level
    

    To disable any power saving features on the Bluetooth hci0 device.

  • Check the mouse's batteries (it's just a week old, other new batteries: same result)

  • Checking logs and kernel messages about Bluetooth-related entries: none aside the expected messages on connect time.
  • I'm running kernel 3.5.0-13-generic as provided in the xorg-edgers PPA. Booting the regular 3.2 Precise kernel results in the same behaviour.

Some other information that may help:

  • It happens when no other Bluetooth connections are active on the machine.
  • Similar symptoms also occur on my Bluetooth stereo (A2DP) headset, but then it's audio lagging and skipping. Swapping Bluetooth profiles as described here then helps. Conclusion: it's not the mouse that's faulty.
  • The headset always worked fine using my now dead Thinkpad T61p with built-in Bluetooth.
  • The bluetooth module in my laptop is connected via USB and shows up as

    0a5c:21e1 Broadcom Corp. 
    
  • Turning the built-in Bluetooth adapter off and using another one works fine, without lag.

    0a5c:2046 Broadcom Corp. Bluetooth Device
    

I'm mobile and several people around me are using Bluetooth at work (A2DP mostly). It also occurs at home, where my neighbours are probably using Bluetooth as well. It could just be radio interference, but I think Bluetooth connections should just hop to another channel. And, moreover, it just works properly instantly when re-connecting.

Therefore I think it's a software driver issue and I'd like to debug it. Is there any way to get more verbose logging on the Bluetooth(-hid) modules?

share|improve this question
    
Until I replaced by motherboard, I had a bad USB port on my computer. Have you tried using a diferent one for plugging in your bluetooth module? You might also try taking your computer for a ride to the country, turn off your car and cell phone, and see if it is still a problem in the absense of RF interference. –  John S Gruber Sep 25 '12 at 16:33
    
I've found an older Bluetooth 2.0 USB dongle and this one works like a charm. Seems like a specific 0a5c:21e1 Broadcom Corp. problem in Linux. –  gertvdijk Nov 15 '12 at 12:09
    
Another update about the original issue. Ever since I'm on Linux kernel 3.7.x this seems vanished on the internal adapter as well - all works very well. Probably hit a bug here now fixed. Once I have time to figure out some more details I'll report this as a bug. –  gertvdijk Jan 31 '13 at 23:45

2 Answers 2

up vote 4 down vote accepted
+100

You could try using the hcidump utility from the package bluez-hcidump to monitor your bluetooth devices and gain in-depth information:

sudo apt-get install bluez-hcidump

In the package description, it is noted that:

The hcidump utility allows the monitoring of Bluetooth activity. It provides a disassembly of the Bluetooth traffic and can display packets from higher level protocols such as RFCOMM, SDP and BNEP.

You can use the utility to log the output from your device to screen or file; where hciX is your own bluetooth device (hci0 is the default and used if you don't specify anything with -i), you can run:

sudo hcidump -x -i hciX

You can save the dump to file by appending to the command -w ~/output, and if you specifically want to know about the audio data you can use the -A switch and thereby extract SCO audio data, although in this case you must always specify an output file:

sudo hcidump -x -A -i hciX -w ~/output

You can view a saved dump file by using

sudo hcidump -r ~/output

There are a lot more specific options that you might want to investigate; you can filter by packet type if you want, as by default all packets are dumped. Please see man hcidump or the Ubuntu manpages online for more information.

The only other option is to install wireshark and see if it can detect your devices; if it can, it will be able to analyse usb and bluetooth traffic, as noted here, but hcidump should give better results.

share|improve this answer
    
Thanks! Peculiar about this is that the while running the hcidump the issue does not appear. Also, the moment I start running it, the issue vanishes immediately. This debugging probe seems to make in irreproducible. –  gertvdijk Sep 26 '12 at 10:56

I've had some luck using USB tracing to solve strange audio problems. Sometimes you can determine something from the content, or the timing of packets. In my case it was an occasional change in the packet length corresponding to noise I was hearing.

Here's a page from Wireshark that provides some information.

You can get a trace simply by doing the following:

  1. sudo modprobe usmon
  2. cd /sys/kernel/debug/usb/usbmon
  3. sudo cat 0u | tee ~/myusbtrace > /dev/null
  4. run your test
  5. kill the process from step 3

Here is information from the linux project about this, including how to narrow down what you are tracing.

The second column appears to contain the time, so you should keep a careful watch on how it increments. If it starts smooth and later gets jumpy the problem may be in the bluetooth section.

If the trace shows irregular packets when there is a problem that could be either USB or bluetooth, but the direction of the irregular packets may indicate whether it is the kernel or driver rather than something on the other side of the USB bus.

share|improve this answer
    
Very helpful, thanks. Would have offered a small bounty if that would be possible. :) –  gertvdijk Sep 26 '12 at 11:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.