Dear All,
I have a real quick question on a periodic inquiry mode defined in
Bluetooth spec. as of 1.1 standard. It's also called a symmetric
discovery procedure and we could initiate this by feeding feed min and
max values for inquiry intervals as well as # of inquiries to be
performed. However, it's only defined in HCI and I realized that it's
pretty tough to use it in the application layer (since we're using a
high level programming using sockets). We recently wrote a paper on
P2P file sharing using bluetooth and there, we used application layer
emulation for this periodic inquiry mode; specifically, we used
HCI_inquiry to discover nodes, but we simply used a socket to listen
to a port to make a node available for discovery (i.e., implicitly in
inquiry/page scan mode). Is there any better way that we could
actually exploit this, yet exploiting high-level programming features
of Bluez?
Thank you.
--
Uichin (Eugene) Lee
Ph.D. Student UCLA CS Dept.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Uichin,
> I have a real quick question on a periodic inquiry mode defined in
> Bluetooth spec. as of 1.1 standard. It's also called a symmetric
> discovery procedure and we could initiate this by feeding feed min and
> max values for inquiry intervals as well as # of inquiries to be
> performed. However, it's only defined in HCI and I realized that it's
> pretty tough to use it in the application layer (since we're using a
> high level programming using sockets). We recently wrote a paper on
> P2P file sharing using bluetooth and there, we used application layer
> emulation for this periodic inquiry mode; specifically, we used
> HCI_inquiry to discover nodes, but we simply used a socket to listen
> to a port to make a node available for discovery (i.e., implicitly in
> inquiry/page scan mode). Is there any better way that we could
> actually exploit this, yet exploiting high-level programming features
> of Bluez?
the periodic inquiry is exposed of our new D-Bus based API and really
simple to use. You only have to set the adapter into periodic inquiry
mode and then you will receive RemoteDeviceFound and RemoteNameUpdated
signals over D-Bus. Check the dbus-api.txt documentation and the
bluez-gnome package for an example.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Uichin,
> I need some more helps/comments with periodic inquiry mode. As Marcel
> told, I checked the D-Bus based API, which is assumed to be defined in
> HCID. I mainly want to use this for P2P applications, i.e., for
> content sharing/advertisement application, and thus minimizing peer
> discovery latency (or, symmetric discovery latency) is the key issue.
>
> It seems like the actual configuration in HCID is a bit absurd. It
> uses inquiry window length of 8, and min and max were set to 16 and 24
> respectively; i.e., by multiplying 1.28s, they are 20.48s and 30.72s.
> We need to WAIT8*1.28=10.24s to get a response.
>
> It seems like nobody has been working on optimizing the periodic
> inquiry mode. I saw a number of papers, but they misunderstood the
> units of various parameters, and thus proposed their own schemes,
> which are yet another version of this "periodic inquiry mode." Some
> analysis work simplified the mode too much, thus failing to reflect
> the reality. (I tried, but it seems like it's non-trivial to exactly
> model the overall system).
>
> I'm actually working on optimizing the parameter configuration for
> "symmetric" peer discovery. What I found is that unless we're using
> Bluetooth v1.1, we need inquiry window size at most 2, and the min and
> max are set to [0, 2*1.28] (assuming that inquiry scan is adjusted
> accordingly). When I tested it with Bluetooth 2.0 (Broadcom chipset),
> the latency was less than 3 seconds, which is a pretty well match with
> simulation.
nobody said that our values are perfect, but we need to simply pick some
to get this going. If you gonna propose different values, then I am fine
with that and would like to simply change it. You can have a different
set of parameters for each Bluetooth version, because hcid knows the
version of the chip and its manufacturer. So if a Bluetooth 1.1 behaves
different from a 2.0 and a Broadcom chip behaves different from a CSR
chip, then we simply include a table of parameters and pick the best one
at runtime.
One extra thing you should keep in mind is however power consumption. It
is not possible to always assume unlimited power.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users