Hi Marcel, > The problem here is that we have to make this fly without harming any other user of the system. One peripheral should not block all the rest. And the problem here is really the re-connection time of for example a HID device where low-latency is what counts. Understood. > One solution would be to keep the long timeout with HCI_LE_Create_Connection if we have controllers that allow us to keep scanning. Meaning a combination of Passive Scanning State and Initiating State. This is something we need to find out with trial and error and see if it can be done. > > As a background here. Currently we stop scanning when we see a device we need to connect to, then connect to it. And if there are other devices on the "to be connected" list, we enable scanning after successful or failure of the connection attempt. Presumably this is per controller rather than global across controllers? One thing I forgot to mention is that some of our infrastructure code is capable of using multiple BLE controllers and (I guess due to the above) we usually keep one controller scanning while using the other(s) for connections. (NB I personally didn’t write any of this linux application code - I was merely tasked with investigating the 2s connection attempt termination issue.) > Essentially you want to change this into this: > > a) Found device we want to connect to > b) If more devices are on the auto-connect list, keep scanning, other disable scanning > c) Send connect request and wait for its completion > d) For the first 2 seconds that connect attempt is exclusive > e) After that cancel it if we see another auto-connect device and try that device > f) Start over > > Similar things then apply to when to re-enable scanning after connection termination, but I doubt that will actually have to change. > > What this means in simple term, only disable background scanning when the auto-connect list empty. Otherwise keep it active and let the controller deal with the two instances of state machines by itself. > > Now we need to check if that would work or not. We have quirks like HCI_QUIRK_SIMULTANEOUS_DISCOVERY and this might need another one. Not sure if we want to go with blacklist or whitelist here. I would do blacklist and actually check the supported states. Since this is LE only, the controller should not lie to us. > > If you want to work on this, then try this simple approach: > > a) Read the supported states and extract support for passive scanning + initiating > a) Use a long timeout > b) Only disable scanning when no other device is left on auto-connect list > > If this basically works, then the only other thing we have to do is be smart about concurrent connection. Meaning that a long running one can be cancelled and replaced with something we see in the 2-x second window. As I said above, the 0-2 second window should be exclusive to the first attempt. We can tune these values, it is just the 20 second one is killing low-latency reconnect by HID device. > > However there is one case to be made that we might only consider direct advertising to be able to interrupt it. Which would satisfy the HID requirement with low-latency. The advantage here is that they are high duty cycle and would show up right away. So you are not really losing out on your slow-connection attempt. > > But this idea really stands and falls with the passive scanning + initiating state support in the controller. OK - I’ll investigate the controllers we have (we are using at least two different chipsets I believe, possibly three) and then have a go at this simple test - probably won’t be before next week at the moment (trying to get a new release candidate out at the moment) and it might take me a day or two to re-familiarise myself and get to grips with the code :) Many thanks for your assistance and input so far. Regards Stu -- Stuart Northfield +44 (0) 1223 566728 (Direct), +44 (0) 1223 566727 (Fax) Metanate Limited. Registered in England No 4046086 at: Lincoln House, Station Court, Great Shelford, Cambridge CB22 5NE, UK www.metanate.com (Consultancy) www.schemus.com (Data synchronisation) This e-mail and all attachments it may contain is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are those of the author and do not necessarily represent those of Metanate Ltd. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, printing, forwarding or copying of this e-mail is strictly prohibited. Please contact the sender if you have received this e-mail in error.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
