<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>I've tested your patches, and your work looks great!</div></div></div></blockquote><div><br></div><div><div>Hi Rick,</div><div><br></div><div>First of all, thanks a lot for your help! It helps me a lot to know that </div><div>it worked for a device that I didn't have the chance to test personally. </div><div>It gives me hope that I am on the right track.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div>To test a bit more, I unpaired my dive computer through the KDE Bluetooth system tray thing, and tried to pair it again through the Bluetooth dialog in Subsurface.  I have to admit that right-clicking and choosing pair seemed less than intuitive, but it worked flawlessly.  I did not need to use bluetoothctl.  Downloading dives again 'worked', except there were no new dives after downloading everything previously, so nothing was downloaded.</div></div></div></div></blockquote><div><br></div><div>To be honest I don't have too much experience with the UI/UX. I though </div><div>that usually when an user wants to execute an action on a specific item, </div><div>he just uses the right button click and he selects the action from a </div><div>context menu. If you have other suggestions, please let me know.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Can you do a similar query through qtbluetooth?  Or perhaps try channel zero first (should work for OSTC computers, Shearwater Predator and Petrel v1), if that fails, try channel 5.  I'm only aware of dive computers using those two channels, but you could try brute force after that.<br></div></div></div></blockquote><div><br></div><div><div>I suspect that this is caused by the timer which after 5 seconds </div><div>without a feedback will stop the connecting process. This is just a </div><div>speculation but I believe that the device starts to interrogate each </div><div>channel (incrementally) and searches for the UUID of the required </div><div>service. It is possible that if the Serial Port Profile is available on </div><div>channel 5, the connection needs more time to succeeds.</div><div>Therefore, do you think that you can apply the attached patch and </div><div>try again? First remove the patch number 5 and then apply this one. </div><div>This patch increases the timeout from 5 seconds to 20. If the timeout </div><div>signal is raised and the device is in lookup service state, then it waits </div><div>another 30 seconds. I just want to eliminate this possibility. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>As further testing, I also tried using the Bluetooth dongle that came with the Petrel 2.  The dialog in Subsurface only recognized the onboard Bluetooth device, i.e. hci0, even when I used hciconfig to turn hci0 off and hci1 on.  I'm guessing you know this.</div></div></div></blockquote><div><br></div><div>Yes, I am aware of this. The thing is that your onboard Bluetooth </div><div>device is set as default. If you set the Bluetooth dongle as default, </div><div>then it will be used in the Subsurface dialog. I will make a drop-down </div><div>list where the user can select which local Bluetooth device he </div><div>wants to use. </div><div><br></div><div>Best wishes,</div><div>Claudiu</div></div><br></div></div>