SuperZaxxon v1.73 breaks bluetooth GPS connection


Further BT issues taken out of the OS release thread, as this one has more to do with BT troubleshooting. My pebble issues are not 1.73 specific, however.

I have further related investigation to do in order to determine why auto PIN generation does not work when paring with the Pebble watch.

Specifically:

I just had someone confirm to me that they are able to pair their Pebble watch using bluez4 by setting pin to "auto", which is the most common way to pair. This would suggest we should be able to do it on Pandora as well, but it has never worked for me, so this is not a recent issue. In order to pair my watch on Slackware or SuperZaxxon I need to specify PIN "9999". This method only works with older watch firmware for some reason (v2.9.1 and below from what I can tell.)

On the very, very bright side, I did in fact get music control working from my Pebble watch by using the app pebble-linux-remote and downgrading to watch firmware v2.9.1.

This is something I've been wanting ever since I got my Pebble, as music control while biking is difficult with the Pandora (best so far has been BlindPlayer). It also seems like libpebble2 is working fine on the Pandora. There has been some unofficial Sailfish support developed using libpebble and I plan to emulate it if I can. I am looking forward to working on an app or two in preparation for syncing a Pebble to the Pyra. I think combining, Pyra, Pebble, and heaphones/headset will make the perfect combo to replace my phone.

Sorry for getting further and further OT. I'll move to another topic for the Pebble stuff. I pretty much have everything I need to package up a PND of pebble-linux-remote if anyone is interested.

EDIT: @notaz, I will try the socket modification first. After that: https://wiki.gentoo.org/wiki/Bluetooth_Headset

If those two don't work, I'll try to post some dmesg output and .out files from deadbeef.

LAST EDIT: @notaz, you are really good. It was the socket issue. Looking at the deadbeef output confirmed it matched an error in the link you gave. To fix, simply make sure /etc/bluetooth/audio.conf has the socket line in the general section:

Code:
[General]
Enable=Socket
 
Last edited:
LAST EDIT: @notaz, you are really good. It was the socket issue. Looking at the deadbeef output confirmed it matched an error in the link you gave. To fix, simply make sure /etc/bluetooth/audio.conf has the socket line in the general section:

Code:
[General]
Enable=Socket
Hmm I wonder if this has any downsides, i.e. if it's worth to enable it by default.
Let's see if this solves it for @Eight Bit too.
 
Awesome. Thanks, notaz. There is a script out there that someone wrote to switch asound.conf files back and forth between normal output and bluetooth. That could be modified to also enable/disable this. It could then be given a keyboard shortcut rather than having it on by default.

Or maybe I can just combine all this and put a tutorial on the wiki...
 
@notaz, you are a god among men. Just that one line made it work flawlesly.
In that same file I also noticed an auto reconnect option which I uncommented. Awesome!
Only thing I had to do to make it work was switch on BT on my Pandora and switch on my BT speakers. I already had them paired. It auto connected straight away et voila. Sound from Audacious after I set the audio output to bluetooth.

For anyone trying this with speakers that do not have a volume control (like my Teufels), remember to switch soft-vol on and turn the software volume control down a bit otherwise your ears might start to bleed ;)

*Happy*
 
Last edited:
I'm not sure if it's related, but after some search the only thing I found is this

Extra (unnecessary) processing of HCI events

When there’s one or more raw HCI sockets in user space a special promisc flag is set for the corresponding adapter on the kernel side. When this flag is set the kernel needs to do extra processing to figure out whether an HCI event packet needs to be forwarded to user space or not.

from http://www.bluez.org/the-management-interface/
 
But is there any reason to ever disable it ("Enable=Socket" I mean)?

I can guess it was enabled by default by the old bluez and that's what caused the regression, although who knows...

I guess it couldn't hurt. From how i understand it, you enable the socket to play sound through an external speaker. You disable the socket to make the Pandora act like a bluetooth speaker and play sound from other devices.

At least that is what I got from reading: http://www.lightofdawn.org/blog/?viewDetailed=00031

However it was late so I may have misunderstood.
 
Damn. Updated my Pandora again, and it wiped out my rfcomm.conf file.
I recreated it and "sudo rfcomm connect 0" connects to the GPS and works, but when I run ConBTGPS I get the error "No appropriate MAC address found in /etc/bluetooth/rfcomm.conf!"
Any suggestions?
 
I have it working again.
First, I changed the comment in rfcomm.conf to match the wiki "GPS". It seems the ConBTGPS is looking for this string.
The error message changed to something like "The MAC address is in the wrong format". Well, my string looked exactly like the comment above, but I decided to copy the numbers from my string to the comment, then uncomment the comment, and comment my string. Now it works, even though there is no visible difference between the two.
I think I will need to open the file in a hex editor to see if I can find the difference.

edit: I opened the file in a hex editor, and did not find any difference between the two lines. I have no idea why ConBTGPS was complaining.
 
Last edited:
Back
Top