Fixing (DualShock 3) Bluetooth Lag

[ARoxdale]

@batesman It looks like that, by default, the FC30 requests (or demands) more parameters in its bluetooth connection. Specifically authentication and encryption. Strange since I would have presumed both would lead to more input lag.

I suspect there might be a way of getting the controller to relinquish its demands and revert to slave mode somehow. Probably using hcitool, which has a large amount of (sadly very undocumented) tools and methods for changing bluetooth connections.

What is the output of $hcitool info AA:BB:CC:DD:EE:FF.

For the PS3 controller, this is
BD Address: AA:BB:CC:DD:EE:FF
OUI Company: ALPS Co,. Ltd. (00-06-F7)
Device Name: PLAYSTATION(R)3 Controller
LMP Version: 2.0 (0x3) LMP Subversion: 0x131f
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xfc 0x07 0x82 0x7e 0x08 0x18 0x00 0x80
<encryption> <slot offset> <timing accuracy> <role switch>
<hold mode> <sniff mode> <park state> <RSSI> <channel quality>
<paging scheme> <broadcast encrypt> <EDR ACL 2 Mbps>
<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan>
<interlaced pscan> <inquiry with RSSI> <AFH cap. slave>
<AFH cap. master> <AFH class. master> <extended features>

So encryption is there, but the Dualshock 3 is not requesting it. What is the equivalent feature set of the FC30?

[batesman]

@ARoxdale

BD Address: <Mac address>
Device name: 8bitDO FC30 Pro
LMP Version 3.0 (0x5) LMP Subversion 0xc
Manufacturer: RDA Microelectronics (97)
Features page 0: 0xff 0xff 0x8d 0xf8 0x98 0x1f 0x79 0x83

<3-slot packets> <5 slot-packets> <encryption> <slot offset>
<timing accuracy> < role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <sco link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log>
<CVSD> <power control> <transparent SCO> <broadcast encrypt>
<enhanced iscan> <interlaced iscan> <interlaced pscan> <inquiry with RSSI>
<extended SCO> <AFH cap. slave> <AFH class. slave> <3-slot EDR ACL>
<5-slot EDR ACL> <sniff subrating> <pause encryption>
<AFH cap. aster> <AFH class.master> <extended inquiry>
<simple pairing> <encapsulated PDU> <err.data report> <non -flush flag>
<LSTO> <inquiry TX power> <extended features>

Features page 1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Features page 2: 0xff 0xa7 0xff 0xff 0x00 0x65 0x07 0x01

[Shakz]

This is a great article. Thanks for posting!

[EVEGames]

ARoxdale,
Thank you so much for this thread. Great detailed instructions, no fluff, no filler. So many other threads which discuss the BT lag problem quickly devolve into a conversation about TV picture modes and 16-foot USB controller extensions. THIS is what I have been looking for. I have yet to try your method, but based on your results I am VERY hopeful. As you point out, so many games are all but unplayable when experiencing this lag.
To me it is well worth the effort of manually running Linux commands to rid myself of this pesky lag, but at the same time I would ask you to please consider following through on your script idea. And if you do come up with a script that can become an automated part of the boot sequence, please share it.
Thanks again, and good luck! I'll be watching this thread intently.
-Dave

[ARoxdale]

@batesman Sorry about the delay.

It looks like the FC30 is using a more updated version of the Bluetooth Link management profile. I'm guessing that the authentication and encryption paramethers are interfering with the basic switch role command, but this is only a guess.

Can you try running the following command

$ sudo hciconfig -a hci0 noauth noencrypt

Then, turn the FC30 off and on again. Check if it works(If not you'll have to reset the pi), then run the commands

$ hcitool con

$ sudo hcitool sr AA:BB:CC:DD:EE:FF slave

And finally another l2ping command

@EVEGames I will try to come up with a script file, but it will be very hacky. My intention is to get in contact with the Bluez team on their mailing list to see if they can shed light on a more stable way forward here.

I think it may be possible to adjust the settings of the pi's bluetooth hci0 controller, either by modifying the file /etc/bluetooth/main.conf or the config/settings files in /var/lib/bluetooth/AA:BB:CC:DD:EE:FF . These changes would be permentant, and if implemented in the distribution (I would not recommend doing this without consulting the Bluez team) would change the settings for all RetroPies.

This is all speculation, and really I'm not sure exactly why any of this is really working. But we can but fail.

(Edit: Corrected commands to include hcitool sr command)

[batesman]

Haven't forgotten about this, just haven't had the time. I hope to get to it later this evening.

[batesman]

So I ran hciconfig noauth noencrypt, rebooted the fc30 and tested. Everything still works, however when I run hcitool con afterward it still shows in MASTER AUTH ENCRYPT state. L2ping times were ~36 with spikes up to 80. After running the hciconfig command I still cannot switch roles.

[snckrz]

Im also using a NES30 8Bitdo controller and since I wasnt able to change the BT mode, just like batesman, I wanted to try to turn wifi off. That did not change anything, and the problem is, now I cant turn it on again:
"Error for wireless requess "Set Tx Power (8B27) : GET Failed on device wlan0: input/output error"

Edit: Nevermind, for some reason its working now. (Even without restarting the Pi)

[ARoxdale]

I've been in some contact with the Bluez team, but no luck so far on a more permanent solution though I do have some ideas.

@batesman @snckrz I tried to get a PS4 controller working to see if it could reproduce this FC30 problem. It has most of the same connection paramaters, however (un)fortunately it allows role switching.

Can you try running the following commands and then checking their results using $hcitool con and $sudo l2ping as before

Firstly can you run

$ sudo hcitool enc AA:BB:CC:DD:EE:FF off
$ sudo hcitool sr AA:BB:CC:DD:EE:FF slave

Then test with hcitool con and l2ping. If this one doesn't work, try

$ sudo hciconfig -a hci0 lm accept,master
$ sudo hciconfig -a hci0 lp rswitch,sniff,hold

Then turn off and reconnect the controllers. After this second step, try a few earlier commands as well.

You could also try just
$ sudo hciconfig -a hci0 lp hold
in the above.

You could also try

Let me know how things go. I'll keep looking into things.

[batesman]

@ARoxdale said in Fixing (DualShock 3) Bluetooth Lag:

I've been in some contact with the Bluez team, but no luck so far on a more permanent solution though I do have some ideas.

@batesman @snckrz I tried to get a PS4 controller working to see if it could reproduce this FC30 problem. It has most of the same connection paramaters, however (un)fortunately it allows role switching.

Can you try running the following commands and then checking their results using $hcitool con and $sudo l2ping as before

Firstly can you run

$ sudo hcitool enc AA:BB:CC:DD:EE:FF off
$ sudo hcitool sr AA:BB:CC:DD:EE:FF slave

Then test with hcitool con and l2ping. If this one doesn't work, try

$ sudo hciconfig -a hci0 lm accept,master
$ sudo hciconfig -a hci0 lp rswitch,sniff,hold

Then turn off and reconnect the controllers. After this second step, try a few earlier commands as well.

You could also try just
$ sudo hciconfig -a hci0 lp hold
in the above.

You could also try

Let me know how things go. I'll keep looking into things.

Just to be clear, when you say "reconnect" do you mean disconnect and re-pair or just power off power on?

[snckrz]

@ARoxdale Hey! I tried all your commands, reconnect and even repaired the controller, but it still connects in "MASTER AUTH ENCRYPT" mode, with a ping from 78-85ms.
But thanks for looking into this!

[ARoxdale]

@batesman I meant just to power off and power back on.

@snckrz Sorry these commands don't work for the FC30s. It's a pity.

I attempted to ask on the Bluez mailing list, but there hasn't been much response yet.
http://www.spinics.net/lists/linux-bluetooth/msg69611.html

I'm not longer certain of my original assessment. The switch from master to slave may be a red herring, or maybe the FC30s simply don't accept a role change. I don't know enough about all this. I can report that the PS4 controller I have (which appears to eb a newer firmware model) did accept a role change, but only after encryption was deactivated. Once there, it gives an erratic set of ping times, which can be as low as ~4ms, but spikes to 20-40ms at times. Also, in this mode, similar spikes occure with the PS3 controller. Bluetooth is complicated I suppose.

[ARoxdale]

@batesman @snckrz

A brief update. I've had no luck in finding a fix, but I do have a better tool to measure actual controller latency with.

With the controller off, run the following command
$sudo btmon -S

Then turn the controller on. You should see a lot of output about the initial connection between the controller and the pie. This differs from controller to controller.
After that, you should see a long stream of text similar to the following. (You may need to hold down a button or waggle a stick to see these)

ACL Data RX: Handle 12 flags 0x02 dlen 54 [hci0] 5.571498
Channel: 65 len 50 [PSM 0 mode 0] {chan 0}
a1 01 00 00 00 00 00 80 86 7d 7f 00 00 00 00 00 .........}......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 ................
16 ff d0 00 00 33 3c 77 01 c0 01 fc 02 02 01 86 .....3<w........
01 ee ..

The part you're actually interested in here is the [hci0] 5.571498. This gives the time in seconds after btmon was started when the data packet from the controller was received by the pi (I think).

For my PS3 controller, before the role switch to slave, these times increase unsteadily in intervals of about 30ms (0.03s). That's about 2 frames at 60fps. Once the role is switched to slave, the packets begin to arrive at steadier intervals of a consistent 11ms. I believe the PS3 controller is sending a packet every 11ms so I presume this is the maximum input lag as a result, presuming no computation delays within the controller itself. 1 frame is 1/60 of a second or about 16.67ms, so this is a major improvement.

The PS4 controller I have is a more interesting case.
By default, even when in slave mode, the PS4 controller seems to be sending packets of data every ~1.3ms . Even when switched to slave mode, this remains consistent. The ping times improve, but role switch seems to have no effect on the actual rate at which the device is sending packets of data. I think the PS4 controller should produce almost minimal input lag by default. Can anyone confirm this? (Edit: I should add. The PS4 controller tends to introduce a lot of "noise" which cause the PS3 controller to expierience quasi-regular lags.)

I'm curious as to what the delay times are for the FC30 controllers. Canyou try running btmon -S for your controllers also. Also, btmon does report more useful information about the connection setup, but I don't know how to use this yet. The Bluez team may know more.

[EVEGames]

Damn good stuff, @ARoxdale .
So it sounds like the role switch to slave yields a measurable improvement. From your original thread, you give the command: sudo hcitool sr AA:BB:CC:DD:EE:FF slave , of course, filling in the variables per your instructions. And you say that the command needs to be executed every time the controller is re-connected. I take it that means, every time the Pi is shut down and turned back on? If so, I know there are "runbefore" options available at boot time, seems that command could simply be added there? But the question is, does the device's address change from boot to boot?
I'm without a PS3 controller temporarily to test this out myself...

[PET2001]

@ARoxdale

There is another factor to be taken into consideration: The difference in latency with the Dualshock 3 controller between master and slave mode probably exist only with the Bluetooth chip of the Raspberry Pi. I am using a Cambridge Silicon Radio Bluetooth USB dongle with my Pi and see absolutely no difference in latency between the DS3 in master or slave mode.

I don't think the Pi's Bluetooth is working well with the DS3 because I've seen lots of problems: connection failures, latency, high system load with the sixaxis driver, system log filled with Bluetooth errors etc. I'd recommend to buy a cheap compatible Bluetooth dongle (my recommendation goes to the CSR one) if one wants to use the DS3 instead of going off to a wild goose chase in the depths of Linux Bluetooth configuration.

[Rion]

@PET2001 @ARoxdale

After some reading using this as a reference.
Best Bluetooth Adapters 2017 : Complete Guide

Plugable USB Bluetooth 4.0

RPi USB Bluetooth adapters

Looks like it's compatible out of the box with Raspian.

I wonder if going for this one might solve the lag with the built-in BT.

[PET2001]

@Rion

I especially like the quote from elinux.org (your second link): "The best solution for these devices seems to be to return them or throw them away, and go with the ones with a genuine Cambridge Silicon Radio chipset."

Problem is: many Bluetooth adapters are sold by diffrend brands and seldom the original manufacturer of the Bluetooth chip used is named (and brands may change OEMs while still selling their product under the same name). My DS3 controllers work very well with CSR chips, other Bluetooth devices have no problems with the pi's builtin chip, so lag and other problems might be compatibility issues between the pi chipset/driver and Sony's DS3/4 controller.

[Rion]

@PET2001 So in other words go for a Bluetooth 4.0 CSR Dongel?

Do you know any good legit 4.0 csr dongels?

[PET2001]

@Rion

I bought some of these devices for my RetroPies: Amazon.de link (obviously a link to the german Amazon site).

Searching for "usb bluetooth csr" however should lead to multiple devices using the CSR chipset (at least it does for me).

[rsn8887]

I just tried turning wifi off in an attempt to reduce lag with my PS4 controller, however the monitor shows dropouts every half second or so of 40 ms or more inbetween many fast receipts with delays of 2 ms or so.

Since turning off wifi is not helping with the lag, I am trying to turn wifi back on.

However the recommended command
sudo iwconfig wlan0 txpower on
does result in an input/output error. Replacing "on" with "Auto" doesn't work either
The command
sudo iwconfig wlan0 txpower 31dbm
Works. But which is the default power? Is 31dbm correct?

EDIT: I found it you have to enter "sudo iwconfig wlan0 txpower auto" TWO TIMES one after the other to turn wifi back on. The first time there's an input/output error response, but the second time it works.

EDIT2: I found the proper way to turn off wifi is to add the line dtoverlay=pi3-disable-wifi to /boot/config.txt . Disabling wifi this way reduced to ping round trip times for my DS4 controller from an average of around 40 ms with some high spikes >100 ms, to an average of around 10 ms. There's still an occasional spike to >40 ms which is very annoying. But this is definitely an improvement.