[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] # of ttyBT device files
> > I believe a Bluetooth transceiver can only have 7 active
> connections at a
> > time even though RFCOMM should support 64 connections (6
> bit DLCI), less 4
> > reserved.
> What do you mean by that (less 4 reserved) ?
4 of the DLCI values between 0 and 63 (0,1,62,63) are reserved for other
> I think it is possible that you once connect to a device and
> after that
> you can setup more than one rfcomm connection the the device ! Each
> rfcomm connection should use a seperate ttyBTx. That means that more
> than 7 ttyBTx could be needed if you setup a bunch of rfcomm
> connections, even to different slaves.
> > So, the idea behind the 7 ttyBT* inodes is probably related to
> > this. Just as a side note, the way you use more of the
> RFCOMM connections is
> > by placing the slave in HOLD mode and connecting to an alternate.
> You do this, if you weant to setup RFCOMM conns to other devices !
> Do I think right ?
Yes and no. Each bluetooth transceiver *can* (meaning according to the
bluetooth spec, actual mileage may vary) support up to 7 active connections
simultaneously in either a piconet or scatternet configuration (mine
supports 4 connections and no scattenet). Now suppose you want to connect to
8 devices, are you out of luck? No. This is where HOLD and PARK modes come
in to play. A master can place one (or more) of its slaves in PARK mode (or
ACL connections in HOLD) to free up one of the active connections. Then the
master can connect to another slave. Note that there is a connection timeout
threshold and if set, the master must cycle through all of the slaves in
PARK to prevent them from dropping the connection (or rather, considering
All of this is explained in the Bluetooth Spec v1.0B. I suggest you read
that and not rely on my memory of how things work! :)
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com