Reply by Arlet Ottens April 25, 20142014-04-25
On 04/22/2014 06:43 PM, Tim Wescott wrote:

>> The first idea that came to my mind was to introduce a random value >> generated by both devices, which comparision (higher/lower) determines >> which device will be the connector and which one the connectee. >> >> Another is to implement the old ALOHA method: detect a failure in >> connection and than wait a random time before attempting to make another >> connection -- but listen for an attempted connnection while waiting. > > Coming up with a random delay can be problematic in identical units that > get powered up at the same time, but shouldn't each Bluetooth device have > a unique MAC? You could use that to seed your random number generator. >
In two truly unique devices without a serial number, a useful trick is to calculate a checksum over the memory/register contents before they are initialized.
Reply by John Speth April 24, 20142014-04-24
> I have a Bluetooth inquiry/response connection problem for which I > suspect there is a classic solution. I just can't seem to find the > answer so I hope somebody here can offer a solution. The problem domain > is Bluetooth but I don't think that should be a limiter in finding the > solution.
Thanks to everyone with the useful discussion. The excellent and simple suggestion to use the 48 bit Bluetooth address as a comparison to determine who shall be connector and connectee works perfectly. It works well in the BT domain because BT address is one of a few items that is shared over air during scanning prior to connection. John Speth
Reply by R.Wieser April 22, 20142014-04-22
Tim,

> but shouldn't each Bluetooth device have a unique MAC? > You could use that to seed your random number generator.
If that MAC value is unique (which is not a given!), why use it as a seed at all ? Just comparing it (in accordance with my first suggestion) would than be enough. But you're right. The ALOHA method needs a well seeded and working random generator. Otherwise the not unthinkable situation of synchronized random values could occur .... Regards, Rudy Wieser P.s.
> (top posting fixed)
bottom posting fixed. (A passive-agressive response to a passive-agressive remark) -- Origional message: Tim Wescott <tim@seemywebsite.really> schreef in berichtnieuws XdWdnbLgAoCCAcvOnZ2dnUVZ5oWdnZ2d@giganews.com...
> On Tue, 22 Apr 2014 13:55:23 +0200, R.Wieser wrote: > (top posting fixed) > > > > -- Origional message: > > John Speth <johnspeth@yahoo.com> schreef in berichtnieuws > > lj4i1f$6kr$1@speranza.aioe.org... > >> Hi Folks- > >> > >> I have a Bluetooth inquiry/response connection problem for which I > >> suspect there is a classic solution. I just can't seem to find the > >> answer so I hope somebody here can offer a solution. The problem > >> domain is Bluetooth but I don't think that should be a limiter in > >> finding the solution. > >> > >> Device A and B are Bluetooth devices that must find each other but only > >> one can be the "connector" and hence the other must be the "connectee". > >> The problem is that both A and B must advertize as peers before they > >> connect (same advertizement IDs) and when one finds the other it > >> attempts to connect to the other. Usually the situation works > >> (connector finishes connecting to the connectee and then the connectee > >> stops advertizing). The bad situation happens when both devices > >> attempt to operate as connectors (not connectees) because they both > >> found each other at nearly the same time. > >> > >> It's like a bunch of devices trying to join a party but each are > >> obligated to conform to an invite / accept protocol. Failing that > >> protocol represents a broken design. > >> > >> Can someone offer how systems like this would solve this problem? Even > >> offering some useful engineering vocabulary so that I can search the > >> web would be helpful. > >> > >> I hope I gave a clear explanation of my needs. Thanks for helping. > > > Hello John, > > > >> Can someone offer how systems like this would solve this problem? > > > > The first idea that came to my mind was to introduce a random value > > generated by both devices, which comparision (higher/lower) determines > > which device will be the connector and which one the connectee. > > > > Another is to implement the old ALOHA method: detect a failure in > > connection and than wait a random time before attempting to make another > > connection -- but listen for an attempted connnection while waiting. > > Coming up with a random delay can be problematic in identical units that > get powered up at the same time, but shouldn't each Bluetooth device have > a unique MAC? You could use that to seed your random number generator. > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com >
Reply by April 22, 20142014-04-22
On 22.04.2014 03:52, John Speth wrote:

> The bad situation happens when both devices attempt > to operate as connectors (not connectees) because they both found each > other at nearly the same time.
That's a well-known complication which became somewhat notorious in the early days of Auto-MDI-X in 10/100BaseT Ethernet. Things would work just fine almost all the time, _except_ in some strange cases, when you tried to connect two devices using the exact same implementation, particularly if they were turned on synchronously. They could never agree which of the two should cross/not cross the lines, because they would both flip their own state at the exact same time, every time, ad nauseam. In effect they would fail to establish a link although there was really not the slightest thing wrong with the cabling.
> It's like a bunch of devices trying to join a party but each are > obligated to conform to an invite / accept protocol.
Actually, it's more like the age-old problem of two people walking directly towards each other in the street. Usually one of them will dodge to one side just as the other dodges to the other, or one reacts correctly to a barely perceived dodge of the other, and they'll just pass each other by uneventfully. And yet, every once in a while two people actually run headlong into each other, or avoid it only by an emergency full stop. When that happens it's because they both picked the exact same evasive manoeuvre, at the exact same time, every time. The same pattern can emerge when two people of equal upbringing try to pass the same narrow doorway simultaneously. They may be stuck there for an improbably long time without either making it through, either in an endless loop of mutually asserting: "Ah but I could not possibly impose! Please: after _you_, sir!", or repeatedly trying to pass in the exact same moment, bodily blocking each other's passage. This failure mechanism of collision avoidance can't be avoided by any rigid protocol. You really have to inject _some_ kind of difference between participants into the mix, to break out of the symmetry trap. As Tim and Rudy already indicated, the two primary sources of such difference are device IDs (MAC, ...) and true random numbers.
Reply by Tim Wescott April 22, 20142014-04-22
On Tue, 22 Apr 2014 13:55:23 +0200, R.Wieser wrote:
(top posting fixed)
> > -- Origional message: > John Speth <johnspeth@yahoo.com> schreef in berichtnieuws > lj4i1f$6kr$1@speranza.aioe.org... >> Hi Folks- >> >> I have a Bluetooth inquiry/response connection problem for which I >> suspect there is a classic solution. I just can't seem to find the >> answer so I hope somebody here can offer a solution. The problem >> domain is Bluetooth but I don't think that should be a limiter in >> finding the solution. >> >> Device A and B are Bluetooth devices that must find each other but only >> one can be the "connector" and hence the other must be the "connectee". >> The problem is that both A and B must advertize as peers before they >> connect (same advertizement IDs) and when one finds the other it >> attempts to connect to the other. Usually the situation works >> (connector finishes connecting to the connectee and then the connectee >> stops advertizing). The bad situation happens when both devices >> attempt to operate as connectors (not connectees) because they both >> found each other at nearly the same time. >> >> It's like a bunch of devices trying to join a party but each are >> obligated to conform to an invite / accept protocol. Failing that >> protocol represents a broken design. >> >> Can someone offer how systems like this would solve this problem? Even >> offering some useful engineering vocabulary so that I can search the >> web would be helpful. >> >> I hope I gave a clear explanation of my needs. Thanks for helping.
> Hello John, > >> Can someone offer how systems like this would solve this problem? > > The first idea that came to my mind was to introduce a random value > generated by both devices, which comparision (higher/lower) determines > which device will be the connector and which one the connectee. > > Another is to implement the old ALOHA method: detect a failure in > connection and than wait a random time before attempting to make another > connection -- but listen for an attempted connnection while waiting.
Coming up with a random delay can be problematic in identical units that get powered up at the same time, but shouldn't each Bluetooth device have a unique MAC? You could use that to seed your random number generator. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by R.Wieser April 22, 20142014-04-22
Hello John,

> Can someone offer how systems like this would solve this problem?
The first idea that came to my mind was to introduce a random value generated by both devices, which comparision (higher/lower) determines which device will be the connector and which one the connectee. Another is to implement the old ALOHA method: detect a failure in connection and than wait a random time before attempting to make another connection -- but listen for an attempted connnection while waiting. Regards, Rudy Wieser -- Origional message: John Speth <johnspeth@yahoo.com> schreef in berichtnieuws lj4i1f$6kr$1@speranza.aioe.org...
> Hi Folks- > > I have a Bluetooth inquiry/response connection problem for which I > suspect there is a classic solution. I just can't seem to find the > answer so I hope somebody here can offer a solution. The problem domain > is Bluetooth but I don't think that should be a limiter in finding the > solution. > > Device A and B are Bluetooth devices that must find each other but only > one can be the "connector" and hence the other must be the "connectee". > The problem is that both A and B must advertize as peers before they > connect (same advertizement IDs) and when one finds the other it > attempts to connect to the other. Usually the situation works > (connector finishes connecting to the connectee and then the connectee > stops advertizing). The bad situation happens when both devices attempt > to operate as connectors (not connectees) because they both found each > other at nearly the same time. > > It's like a bunch of devices trying to join a party but each are > obligated to conform to an invite / accept protocol. Failing that > protocol represents a broken design. > > Can someone offer how systems like this would solve this problem? Even > offering some useful engineering vocabulary so that I can search the web > would be helpful. > > I hope I gave a clear explanation of my needs. Thanks for helping. > > John
Reply by John Speth April 21, 20142014-04-21
Hi Folks-

I have a Bluetooth inquiry/response connection problem for which I 
suspect there is a classic solution.  I just can't seem to find the 
answer so I hope somebody here can offer a solution.  The problem domain 
is Bluetooth but I don't think that should be a limiter in finding the 
solution.

Device A and B are Bluetooth devices that must find each other but only 
one can be the "connector" and hence the other must be the "connectee". 
  The problem is that both A and B must advertize as peers before they 
connect (same advertizement IDs) and when one finds the other it 
attempts to connect to the other.  Usually the situation works 
(connector finishes connecting to the connectee and then the connectee 
stops advertizing).  The bad situation happens when both devices attempt 
to operate as connectors (not connectees) because they both found each 
other at nearly the same time.

It's like a bunch of devices trying to join a party but each are 
obligated to conform to an invite / accept protocol.  Failing that 
protocol represents a broken design.

Can someone offer how systems like this would solve this problem?  Even 
offering some useful engineering vocabulary so that I can search the web 
would be helpful.

I hope I gave a clear explanation of my needs.  Thanks for helping.

John