Number of connections to peripherals as a central

[szyglowicz]

Is there a limit to the number of peripherals that can be connected at once using the library? It seems like the second call to Dial, it blocks forever but the peripherals are alive and can be connected to. I tested it with the shell and they all connect. When I use my own program it blocks on the second call to Dial after the first one is successfully connected,

[roylee17]

The number of concurrent connections depends on the chip/device.

For example, with a BCM20702A0 USB dongle, I can, as a central, Dial into two different devices concurrently. But, as a peripheral, I can only accept one connection. Trying Dial or Accept over the maximum of connections supported usually results a HCI error:
ErrDisallowed ErrCommand = 0x0C // Command Disallowed

And "we" should retry upon any of current connection disconnects. I was pondering if the library or user should do it, and not sure which one I ended with last time. I'm heading out now, we check and will get back with more detail. In the mean time, see if disconnecting existing connection unblocks the second Dial. (And/or watching the hcidump for the LECreatingCommand, and see if it gets error 0x0C)

[szyglowicz]

For a go library, we dont want magic. Either retry should be stated as a parameter or user can handle.

[roylee17]

It should return error instead of stuck there. I just updated the blesh to work with multiple connections.

Attach the hcidump log while trying the following commands, or your program (doing the second Dial).

blesh > c -addr DEVICE1
blesh > c -addr DEVICE2

An possibility is that you're dialing into a device which advertising Random Address. In this case, you need to pass hci.RandomAddress.

// RandomAddress is a Random Device Address. In this case
type RandomAddress struct {
    ble.Addr
}

A ble.Addr returned by a Scan() result could be a Public or Random Address depends on the advertisement. Dial() does type assertion to figure out which is the case, and issue HCI command accordingly.

[deadprogram]

I have a similar problem, possibly due to the first device starting to WriteCharacteristics and receive notifications while the second device is in the process of doing the ble.Connect() and client.DiscoverProfile().

[deadprogram]

This is my HCIDUMP output file. hcidump-ollies.txt

[deadprogram]

This problem appears to be the same as #34 and #36 so if we can find the solution it would fix all of these.