Turn off bluetooth once the launch handshake is complete #18
Conversation
|
I'm building and I will test this today... anyway I will test this pr today anyway, |
We do enable bluetooth as part of the connect call while reconnecting in case if some failure in the proxy. Though, as a side note, tcp failures are not handled very well so far. But it does reconnect well if the usb fails.
Yes, that's the idea. More precisely, the bluetooth will now only be turned on while trying to connect to a phone once the headunit sends start accessory request. |
| @@ -166,6 +167,8 @@ void AAWirelessProfile::NewConnection(DBus::Path path, std::shared_ptr<DBus::Fil | |||
|
|
|||
| AAWirelessLauncher(fd->descriptor()).launch(); | |||
| Logger::instance()->info("Bluetooth launch sequence completed\n"); | |||
|
|
|||
| BluetoothHandler::instance().powerOff(); | |||
There was a problem hiding this comment.
Please dismiss me if I'm in error... but how about disconnecting here: https://github.com/nisargjhaveri/AAWirelessDongle/blob/1552ae61391b51b78f0d2d8523cc784b657ec80a/aa_wireless_dongle/package/aawg/src/bluetoothProfiles.cpp#L63 that we still have the file descriptor?
There was a problem hiding this comment.
Sorry, could you please explain some more. How would it make a difference?
There was a problem hiding this comment.
Nono, just thinking out loud, I don´t know if it would do a difference, of if it actually done here... but here that we still have the bluetooth device, we could just terminate any connection with it, instead of just powering off all bluetooth...
There was a problem hiding this comment.
Ah, right. I did try simply disconnecting the device instead of powering off. Though, seems like the device automatically reconnects the AA profile anyway, which triggers another "handshake".
We might be able to remove the AA profile and then disconnect the device if this is causing any issues, to prevent reconnect. Thought we can just power off, which can maybe also help free up the shared antenna for WiFi even more.
|
Hi folks! I began testing this firmware today (I will do until Friday, I still didn't tried BT calls yet), but what I immediately noticed, is trouble with pairing. Due to the fact that it disconnected the device after sending request to connect via RFCOMM failed, I couldn't connect again, so it took me few RPi resets to properly pair and successfully connect to the headunit. The solution for this would be, that app checks if there is active proxy between phone and headunit, and if not, periodically try to request connection to phone, so even this fails, RPi will try to connect to phone and engage connection. |
|
Past few days, BT calls were rock solid, so I guess this solved my issue, and it's OK to merge. Great job folks! |
|
Thanks @gamelaster for testing this out!
Could you explain this more, is this new with these changes? We don't power off unless the AA "handshake" completes. |
@nisargjhaveri Oh, sorry, I didn't checked out how exactly it works. Although, I just had quite issues after I updated the firmware, to pair it again, and actually trigger the connection mechanism, I needed to re-plug RPi like 3 times to get it working at all. Could be related to #23 , as if my connection dropped during session, only way to reconnect was to replug RPi. Also, I don't think this behavior is caused by this PR, so I guess it's OK to merge it, and continue discussion in #23 |
Fix #17