Yeah, I'd second that, talking to n>3 devices has been pretty tough for me. With 2.2 I was barely able to get 3 to connect most of the time, extremely difficult, and very unreliable. Pushing it to four was possible perhaps once, though extremely unstable?
As for your rfcomm question, I'm unsure, this is something where I (or you) should go through the source to find out. I feel like it should make a difference, however might not be implemented that way. Anyway, I would say that in general, getting >3 to work was just, pretty much impossible for me, or anyone I've talked to so far. (Alternatively, yes, you heard about the daisy chain thing, right? Perhaps that would be a good idea, however you have to change your distribution model significantly. I read that some company was developing a high level api to do things like this...) Kris On Mon, Sep 12, 2011 at 10:14 PM, gjs <[email protected]> wrote: > Hi, > > I can't confirm it is just 2.2 but I have had similar experiences & I > have not been able to get more than four phones to connect via > bluetooth reliably on any version of Android in a single server many > clients arrangement. I have not tried a daisy chain configuration > where each phone just connects to it neighbour but I suspect this > might work better, maybe up to the magic seven devices ? > > Let me know if you can get more than 4 devices working together. > > I've found the BT implementation / connection reliability varies > wildly across different Android phones & tablet, ranging from good > through bad - Nexus S, Nexus One, Xoom, EVO 3D, Galaxy S2, LG G2X (G2X > only device with Android 2.2). I often find I need to reset the > bluetooth disable/enable on some of the latter to get reliable > connections. > > Regards > > On Sep 13, 1:37 am, novakom <[email protected]> wrote: >> Neil, >> My original implementation used a pool of 7 UUIDs, but since thats a >> nightmare to manage if you don't make activity limiting assumptions, I >> tried re-implementing based on a single UUID. My tests showed that I >> got the same behavior with 1 UUID or 7, so I ripped out the UUID >> management stuff. My theory (detailed >> here:http://stackoverflow.com/questions/7198487/are-connected-bluetoothsoc...) >> is that UUIDs do nothing other than provide a key to a particular SDP >> entry, and that the call to listenUsingRfcommWithServiceRecord() or >> createRfcommSocketToServiceRecord() creates a new socket on an open >> RFCOMM channel, regardless of the UUID used. I have no definitive >> proof but unless I can get a google engineer to answer either this or >> the other question I can't know, so I'm just proceeding this way. >> >> One thing to watch out for is that one time (and one time only) when I >> opened a new connection, the receiving phone prompted me that the >> external connection was trying to connect to my mailbox through BT. I >> don't know a ton about BT but it appears there is a BT channel >> specific to mailboxes that can get mixed up in there. I don't know if >> the 2.2 device was mixed up in there or how; it was 2 weeks ago or so >> and I didn't take notes, and it didn't happen again. >> >> I have no other updates, I'm working on other code right now. >> Unfortunately I am only working data sockets right now so I have no >> insight to share wrt audio sockets. >> >> Good Luck! >> >> On Sep 11, 7:46 pm, Neil <[email protected]> wrote: >> >> >> >> >> >> >> >> > I'm doing the same, extended the Bluetooth Chat example in a similar >> > way to you. >> >> > Not tried with 4 devices yet, your experience is worrying! >> >> > Any updates? >> >> > Are you doleing out from a Collection of 7 UUIDs? >> >> > My Asus EeePad or Nexus One can't sustain a Bluetooth audio stream at >> > the same time as one of my connections, even if there's no data >> > traffic. >> >> > On Aug 31, 9:19 pm,novakom<[email protected]> wrote: >> >> > > I am developing an app which will have multiple phones communicating >> > > together concurrently via bluetooth. To this end, I extended the >> > > BluetoothChat example to support multiple simultaneous connections. >> > > Once I got it working with 3 phones, I ramped up to 4 but have >> > > discovered that it appears that phones running Android 2.2 can only >> > > support 2 simultaneous bluetooth connections, while phones running >> > > 2.3.4 can support 3 (at least, if not more). Can anyone confirm this >> > > as a known bug for 2.2? It would be good to know if this is just a >> > > hard limitation. >> >> > > Phones I am testing with: >> > > HTC Incredible (2.2) >> > > Nexus S (2.3.4) >> > > Nexus 1 (2.3.4) >> > > Nexus 1 (2.3.4) >> >> > > Here's how I determined that there is this hard limit: >> >> > > My code extends the BluetoothChat sample program, as I said. >> > > Unfortunately I cannot share it right now (company legal limitations) >> > > but it's basically the same as the original except that all threads >> > > are not killed when new connections are made, all ConnectThread and >> > > ConnectedThread objects are stored in an array, and I kick off a new >> > > AcceptThread whenever an incoming connection is turned into a >> > > ConnectedThread. >> >> > > After instrumenting my code with lots of debug, what I've found is >> > > that once my 2.2 device (the incredible) has established 2 >> > > connections, it will literally hang at either the accept() in the >> > > AcceptThread or at the connect() in the ConnectThread. This is true >> > > with whichever order of connections are made. For example, if I do >> > > the following: >> > > 1. Incredible > NS >> > > 2. Incredible > N1 (1) >> > > 3. Incredible > N1 (2) >> > > or >> > > 1. Incredible > N1 (1) >> > > 2. Incredible > N1 (2) >> > > 3. Incredible > NS >> > > or >> > > 1. Incredible > N1 (either) >> > > 2. Incredible > NS >> > > 3. Incredible > N1 (either) >> > > or >> > > 1. NS > Incredible >> > > 2. N1 (either) > Incredible >> > > 3. N1 (either) > Incredible >> >> > > In all cases, the Incredible will Always hang on step 3, whether it's >> > > on the connect() in the first 3 cases, or the accept() in the last >> > > case. Debug shows that it hangs specifically on those calls (not the >> > > RFComm socket creation calls or anything else). Now, there are other >> > > potential connection orders but these are the basic ones that need to >> > > work, so I'm not worried about interleaving connects and accepts right >> > > now. >> >> > > The other interesting thing is that I instrumented an end program >> > > method from the menu which calls cancel on all open threads. >> > > According to the SDK, when you call close() on an open hanging socket, >> > > it is supposed to throw an error. Well, if the app has already hung >> > > on either accept() or connect() in any of the scenarios above, then >> > > the close() call hangs as well and I have to forceclose the program. >> >> > > Other info: >> > > - Using another N1 running 2.3.4, I found that I didn't have any >> > > trouble connecting all 4 phones as long as the incredible wasn't in >> > > the mix. >> > > - Also, when a phone running 2.3.4 with 2 active connections tries to >> > > connect to the incredible while the incredible has 2 other active >> > > connections, the phone running 2.3.4 fails to connect and does not >> > > hang, while attempting the connection in reverse has the (now) >> > > expected hang. >> > > - Also tried to connect 4 phones with a Samsung Infuse (2.2) and >> > > another N1 running 2.2. Both cases had similar hangs (cannot >> > > exhaustively check this thanks to limited access to the devices). >> > > - When trying to establish a 3rd connection with a device which is not >> > > there (turned off the bluetooth on one of the N1s), the connect() call >> > > does NOT hang. However, if I then turn on BT on the 3rd phone and try >> > > to reconnect, it's back to hanging at connect(). Therefore there >> > > definitely appears to be some kind of connection management problem >> > > when running 2.2. >> > > - If I make 2 connections on the incredible, then close one, I can >> > > open another. All closing/opening works fine as long as I'm only >> > > trying to manage 2 connections. >> >> > > Anyways, as I said, if anyone can confirm that I simply cannot use my >> > > 2.2. device for testing more than 2 concurrent connections, that would >> > > be very helpful. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
