weliem / bluez_inc

A C library for Bluez (BLE) that hides all DBus communication. It doesn't get easier than this. This library can also be used in C++.
MIT License
91 stars 23 forks source link

Need to stop discovery before starting for multiple connections? #74

Closed abqjln closed 2 weeks ago

abqjln commented 1 month ago

On my client , I need to continue discovering after the first server connection to find other servers and beacons. I can get this to work only if I first stop discovering and then start discovering in the BINC_CONNECTED part of my callback (below) that prints the entry discovery state:

In my on_client_connection_state_changed_cb ` else if( state == BINC_CONNECTED ){ printf( "Connected: before stopping state is '%s'\n", binc_adapter_get_discovery_state_name( adapter ));

    binc_adapter_stop_discovery( adapter ); // WITHOUT THIS LINE ONLY THE FIRST SERVER CAN CONNECT

    binc_adapter_start_discovery( adapter );
}

} `

The entry state (from printf above) after a connection can either be Connected: before stopping state is 'started' or Connected: before stopping state is 'stopped'

but both work as long as I have the stop discovery statement.

If I don't stop first, the discovery state never gets to "started". It seems like the states are getting jumbled and my workaround of stopping before starting had the effect of resetting them?

Side thought--Would it help to make the discovery state volatile? I compile from source--is my compiler optimizing it out (and maybe doing other odd things)?

Thank you for listening.

weliem commented 1 month ago

starting or stopping discovery are asynchronous functions. So they return immediately and you'll get a callback when it has been completed.

Calling then directly after each other will not have to desired effect. Typically only the first one will be done.

abqjln commented 1 month ago

Understood. I'm still seeing confusing issues here where the callbacks are not responding but it is best to close until I can more crisply characterize the behavior. Thanks.

abqjln commented 2 weeks ago

Commenting after close on this issue as I figured out what was happening. My workaround to start/stop discovery using binc_adapter_start_discovery and connection_state_change_cb only occasionally worked because my wrong non-async approach. But it worked enough to give me clues.

Weeks later I diagnosed the root issue in the de-duplication filter in bluez. If you have a device that is advertising at a rate higher than the discovery scan rate and you are not connected (like a beacon) you lose all but the first advertisement.

The second issue was a long connection time for connectable servers because we had to wait until another scan was performed. I still have not figured out how to control the scan rate in bluez.

This link provided a workaround using hcitool to scan on demand without filtering https://github.com/hbldh/bleak/issues/235. , (Although apparently every 11 seconds MGMT Command: Start Service Discovery gets executed and restores duplicate filtering, this isn't an issue as I am continuously scanning.)

Now scans keep up with my beacons (~3Hz that I do not control) and multiple servers connect rapidly, even after failing with GDBus.Error:org.bluez.Error.Failed: le-connection-abort-by-local (36) (This seems to be either wifi interference or that fact that I have multiple bt adapters running on the same machine)

It may be yucky to call hcitool, but it is working quite well for me. I haven't seen issues with messing up binc discovery state flags--I'd be very interested in any observations about possible issues.

`/*** *

abqjln commented 2 weeks ago

Closed.