1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Bluetooth inquiry / response

Discussion in 'Embedded' started by John Speth, Apr 22, 2014.

  1. John Speth

    John Speth Guest

    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

    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 Speth, Apr 22, 2014
    1. Advertisements

  2. John Speth

    R.Wieser Guest

    Hello John,
    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.

    Rudy Wieser

    -- Origional message:
    R.Wieser, Apr 22, 2014
    1. Advertisements

  3. John Speth

    Tim Wescott Guest

    On Tue, 22 Apr 2014 13:55:23 +0200, R.Wieser wrote:
    (top posting fixed)
    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, Apr 22, 2014
  4. 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.
    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.
    Hans-Bernhard Bröker, Apr 22, 2014
  5. John Speth

    R.Wieser Guest

    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 ....

    Rudy Wieser

    bottom posting fixed.

    (A passive-agressive response to a passive-agressive remark)

    -- Origional message:
    R.Wieser, Apr 22, 2014
  6. John Speth

    John Speth Guest

    I have a Bluetooth inquiry/response connection problem for which I
    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
    John Speth, Apr 24, 2014
  7. John Speth

    Arlet Ottens Guest

    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.
    Arlet Ottens, Apr 25, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.