ForceQuickReconnect can be made quicker and more robust.

tfabris / BlueGigaEmpeg

Arduino module and daughter board to convert the empeg Car MP3 player to Bluetooth output.

GNU General Public License v3.0

0 stars 0 forks source link

ForceQuickReconnect can be made quicker and more robust. #20

Closed tfabris closed 6 years ago

tfabris commented 6 years ago

When I encounter the problem where the host stereo asks me for a PDU Register Notification message that I don't like, I fix the problem by resetting the bluetooth module completely. The reconnect occurs and the second reconnect solves the problem.

This however creates a brief dropout in the audio and the host stereo says "no device connected". This is irritating. See if you can fix this by doing the following:

Store the pair address in a global variable each time you see it (PAIR command for situations when this device initiated pairing, or the RING command for situations when the host stereo initiated pairing).
Issue a disconnect/reconnect command set instead of a full reset of the bluetooth module, using the pair address for the commands.

Double check that you even need the address. Maybe you don't? Check it.

tfabris commented 6 years ago

This is implemented but when running the code it doesn't seem to reconnect as quickly as it did when I was typing the commands on the console directly. Needs more experimentation. Perhaps a slight time delay between the disconnect and reconnect commands would actually be faster? Not sure.

tfabris commented 6 years ago

Added the slight time delay between the disco/reco and that seems to help.

Still need to test make sure that on the car stereo that this actually fixes the "Bad PDU Registration" problem.

tfabris commented 6 years ago

Though the routine seemed to work well on the BT headset, when I brought it into the car and repro'd the issue, the strings got mangled and it's got something to do with the string lengths and the line-by-line logging and something else I'm not quite understanding.

Temporarily reverting to a full reset until I can debug this some more, but it's after 3am and I'm stumped. More later.

tfabris commented 6 years ago

Investigate possible problems with DisplayAndProcessCommands, perhaps there should be no delays.

tfabris commented 6 years ago

After a ton of debugging and code rearranging (some of which was still good and useful) the "speedy" version of the force reconnect ended up not solving the issue that I wanted it to solve. Reconnecting with a close/call pair did indeed result in a very speedy reconnect which... played music without any AVRCP commands working at all.

Closing this as "Cannot Do". Sigh. Stayed up till 4am on this one too.