Ah, I see. You mean just the topology.
no, you only create a scatternet. This means when one device must be member of two different piconets.
Would that solve the problem? Actually, is it a known problem?Is there a way to upgrade it? Are there better dongles the University could buy?You can upgrade the D-Link DBT-120 Rev. B3 with the Apple firmware update package to HCI 18.1.
I'm just testing it with a really simple program. The client (master, no role-switching) connects sequentially to 2 servers (slave) with a really huge delay of 3 seconds. As soon as one server becomes unavailable, it is impossible to connect to the other. This is obviously due to the connection attempts to the unavailable device. Tomorrow I'll try to implement some kind of exponential backoff. Btw, I read something about getting RSSI via Inquiry. Is it possible with BlueZ? This could be used to faster decrease the backoff if the unavailable device is found by inquiry and probably with a good RSSI near 0.Try to introduce some delays between the connections and see if that helps.I'm experimenting with delays and timeouts for three days now. It helps... a bit, but not really good. I just tried to switch master-slave, but it doesn't really help.I think you should avoid the role-switching and keep the listening applications as slaves. In this case the client creates the piconet and can keep both servers in the same piconet.
Yes, but I could disconnect faster on timeout and make L2CAP throw a clean error instead of behaving strange.One year ago, I wrote another Location Awareness App on top of a modified JBlueZ and it just used ACL links to measure RSSI and LQ. It worked. I probably have to take care of the ACLs myself (does L2CAP use existing ACLs?). The only drawback: The App has to run as root :(.The L2CAP creates the same ACL links, so this can't be the problem.