multiple SCO connections -- how to determine I2S channel

I am using a PAN1315 module.  The goal is to support multiple SCO channels (well, up to the maximum of 2 supported by the chip) over the I2S bus.  There doesn't appear to be any command or event that specifies which I2S channel a particular connection is on.  Therefore, I'm hoping there is a reliable means of determining which channel a connection is on.  How does the chip internally decide which channel to put a connection on, at what point does it decide, and does it remain constant for the lifetime of that SCO connection?



4 Replies

  • Mike:

    Each SCO gets assigned one channel.  The first connection gets the first channel (which stays with it for the remaineder of the connection life time), and the second connection gets the second I2S channel (again, which stays with it for the remainder of the connection time).

    There is not event that will tell you which I2S channel a particular connection has been assigned.


  • In reply to Arild Kolsrud:

    Is it safe then to say that when I get an HCI_Connection_Request_Event of type SCO/eSCO I can count that link as having a channel allocated and when I get a HCI_Disconnection_Complete_Event on that handle the channel allocation is removed?  And there is no possible way I would get interleaved events such that a channel was allocated for one handle but an event sent on another before the event for the allocation occurred (and similar for channel de-allocation)?

  • In reply to Mike Brudevold:

    We've noticed that the connection handle for the first SCO connection is something like 0x0101 and the second SCO connection is like 0x0202 (where the least significant byte corresponds to the device handle, so we could see 0x0101 or 0x0102 depending on which device opens the first SCO).  Is this intentional?  Can we parse the least significant bits of the most significant byte and accurately obtain which I2S channel a particular device is on?

  • In reply to Mike Brudevold:

    The connection handle ordering that you mentioned is true for ACL handles. SCO connections are created on top of ACL connection(radio level). So SCO handle will take on its corresponding ACL handle. So as long each ACL/SCO connections at the radio level is made in order, your parsing should be correct.




    Check out the CC26xx/CC254x BLE Main Wiki page: