From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Cc: Steven Singer <steven.singer@csr.com>
Subject: Re: [Bluez-devel] Re: Lower granularity for INQUIRY interval
Date: Fri, 11 Feb 2005 01:16:33 +0100 [thread overview]
Message-ID: <1108080993.21620.36.camel@pegasus> (raw)
In-Reply-To: <Pine.GSO.4.58.0502101727190.7559@qew.cs>
Hi Catalin,
> > > Is there a way to perform INQUIRY for intervals with
> > > a lower granularity than 1.28 seconds? I know the Bluetooth
> > > specification says no.
>
> > To inquire for less than 10.24 seconds is a bad idea. Unless you
> > inquire for a single contiguous block lasting 10.24 seconds you do not
> > have a good probability of picking up all devices.
> >
> > Note that, for example, 8 consecutive 1.28 second inquiries is not
> > guaranteed to work.
>
> Not necessarily a bad idea. In my case, I need to do symmetric Bluetooth
> discovery. There are no predefined roles (master-slave, server-client) for
> the devices which must continually scan their surroundings in order to
> discover other devices. Hence, each device must continously switch between
> the INQUIRY and INQUIRY SCAN states. Since in my setup, the devices will
> be in range for 20-30 seconds (i.e. humans walking past each other), to
> remain for 10.24 seconds in INQUIRY mode might just me too much. Imagine
> that the "phases" of the devices are almost synchronized, then they will
> both be in INQUIRY mode at the same time, then in INQUIRY SCAN mode at the
> same time, and so on, and none of them will discover the other one.
>
> The problem has been studied both theoretically and experimentally (for
> example, see:
> http://web.informatik.uni-bonn.de/IV/Mitarbeiter/scholz/10_Bohman.pdf
>
> The conclusion of the authors of this study was that each a device should
> stay in each of the two states for a random amount of time with a mean
> around 2 to 3 seconds (more details, are in the above paper). Doing this
> yields and average neighbor discovery delay of about 8 seconds.
>
> Now obviously if we can only stay in INQUIRY state mode, for multiples of
> 1.28 seconds, the above scenario will not work. So there are _legitimate_
> uses (i.e. it is not necessarily a bad idea) for my request.
I still don't get why switching inquiry scan on and off should help in
any case. Since inquiry scan defines the discoverable mode and so you
switch devices to unvisible when they inquiry and back to visible when
they don't.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2005-02-11 0:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-10 22:42 [Bluez-devel] Re: Lower granularity for INQUIRY interval Catalin Drula
2005-02-11 0:16 ` Marcel Holtmann [this message]
2005-02-11 15:03 ` Steven Singer
-- strict thread matches above, loose matches on Subject: below --
2005-02-11 17:48 Jean Tourrilhes
2005-02-11 19:01 ` Steven Singer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1108080993.21620.36.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=steven.singer@csr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.