Closed abqjln closed 2 weeks 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.
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.
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.
`/*** *
HCI Event: Command Complete (0x0e) plen 4
HCI Event: Command Complete (0x0e) plen 4
Status: Success (0x00) / void bt_adapter_start_discovery_nodedup( Adapter adapter ) { char cmd[60], hcx; const char hcx_path;
hcx_path = binc_adapter_get_path( adapter ); hcx = strstr( hcx_path, "hci" );
snprintf( cmd, sizeof(cmd), "sudo hcitool -i %s cmd 0x08 0x000C 0x00 0x00 > /dev/null", hcx ); system( cmd );
snprintf( cmd, sizeof(cmd), "sudo hcitool -i %s cmd 0x08 0x000C 0x01 0x00 > /dev/null", hcx ); system( cmd );
return; } `
Closed.
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 ));
} `
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.