linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] Slow connect time for devices
Date: Thu, 16 Feb 2006 07:07:21 +0100	[thread overview]
Message-ID: <1140070041.29234.11.camel@localhost> (raw)
In-Reply-To: <bd72c4b0602151628v14d53ae7vab573412bb56d6c@mail.gmail.com>

Hi Gareth,

> I'm working on a project on a Intel XScale processor, connecting to
> bluetooth heart rate monitors and headsets. Connections currently have
> 7 attempts to work, though leaving a debug flag on (which slows the
> handshake down) gets a near-instant connection. I would like to get
> the connections normal without slowing down the BT device after the
> connection is made.
> 
> Any normal connection, regardless of whether there's an authorization
> segment, will fail (errors 104 & 110 - 'Connection timed out' and
> 'Connection reset by peer') 7 times before connecting. It'll usually
> alternate between the two errors, and the 7 is fairly constant.
> 
> I have found that I can get the total connection time by reducing
> these two variables down to 2 seconds each. It still takes seven
> attempts. Once the first device is connected, any others will either
> be instant or have one timeout/reset.
> 
> (rfcomm.h)
> #define RFCOMM_CONN_TIMEOUT (HZ * 2)
> #define RFCOMM_DISC_TIMEOUT (HZ * 2)
> 
> I later found that enabling a debug flag will give me instant
> connections (how I assume things should be), because it is slowing
> down the process. The flag is HCI_CORE_DEBUG in bluetooth.h, which
> affects the fines hci_core.c, hci_conn.c and hci_event.c. I have
> isolated it to the hci_core.c file that needs to be slowed down.
> 
> I can't, however, leave the prints on or a loop to slow it down or
> sleep, as the SCO voice connection becomes unusable with them on once
> it is connected.
> 
> Can someone please suggest an approach to targeting and slowing down
> the handshake and the not the resulting connection?

this looks like a hardware limitation. What kind of dongles/chips are
you using?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

      reply	other threads:[~2006-02-16  6:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-16  0:28 [Bluez-devel] Slow connect time for devices Gareth Bradley
2006-02-16  6:07 ` Marcel Holtmann [this message]

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=1140070041.29234.11.camel@localhost \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).