Return-Path: Message-ID: From: Robert Wlaschin To: "'bluez-users@lists.sourceforge.net'" Subject: [Bluez-users] Trouble communicating to a non-discoverable BT devi ce MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C489.45989B80" Sender: bluez-users-admin@lists.sourceforge.net Errors-To: bluez-users-admin@lists.sourceforge.net Reply-To: bluez-users@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ users List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Sep 2005 17:03:50 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5C489.45989B80 Content-Type: text/plain; charset="ISO-8859-2" I have a slightly different problem than what I've seen posted in the mailing list thus far, please point me in the right direction if I have misspoke. I am attempting to create an Ash script (on Busybox, Arm processor -- uClib cross compile, Deb Kernel 2.6.10) w/ bluez-libs-2.19, and bluez-utils-2.19. The system I am using is semi-embedded and has a limited amount of space for various utilities. My BT device is non-discoverable, I am unable to change this. Therefore, I am forced to wait until I am signaled by the device to attempt a connection. This device is also battery operated and the Manufacturer designed it to conserve power by allowing only a minimal time slice for the device to link with my system. Once I have a connection I have to read the data by sending ACK's back across the device. I was attempting to create a script that watched the system log messages dumped by hcid and sdpd. I was able to create a script using rfcomm's bind and connect, which allowed me to read from /dev/rfcomm0 but I was unable to send without receiving a 'Host is down' error. I did some reading and it was suggested that both the devices were setup as clients and this was why I was receiving this message. Another suggestion was to use rfcomm's listen to setup the device. I have attempted an implementation of that but I receive a Disconnect extremely quickly and I am having difficulty detecting when the listen connects to my device so I can extract the BT address and other pertinent data. First off am I even heading in the correct direction, should I use the rfcomm listen command, instead of the connect? Is there an easier way to do what I need to get done, using already created tools I don't know about? Do I need to run the sdptool and add the SP interface? Where are the doc's that explain how to use the rfcomm and sdptool utils -- the man pages have various information/knowledge gaps? Thanks, Robert ------_=_NextPart_001_01C5C489.45989B80 Content-Type: text/html; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable [Bluez-users] Trouble communicating to a non-discoverable BT = device

I have a slightly different problem than what I've = seen posted in the mailing list thus far, please point me in the right = direction if I have misspoke.  I am attempting to create an Ash = script (on Busybox, Arm processor -- uClib cross compile, Deb Kernel = 2.6.10) w/ bluez-libs-2.19, and bluez-utils-2.19.  The system I am = using is semi-embedded and has a limited amount of space for various = utilities.

My BT device is non-discoverable, I am unable to = change this.  Therefore, I am forced to wait until I am signaled = by the device to attempt a connection.  This device is also = battery operated and the Manufacturer designed it to conserve power by = allowing only a minimal time slice for the device to link with my = system.  Once I have a connection I have to read the data by = sending ACK's back across the device.

I was attempting to create a script that watched the = system log messages dumped by hcid and sdpd.  I was able to create = a script using rfcomm's bind and connect, which allowed me to read from = /dev/rfcomm0 but I was unable to send without receiving a 'Host is = down' error.  I did some reading and it was suggested that both = the devices were setup as clients and this was why I was receiving this = message.  Another suggestion was to use rfcomm's listen to setup = the device.  I have attempted an implementation of that but I = receive a Disconnect extremely quickly and I am having difficulty = detecting when the listen connects to my device so I can extract the BT = address and other pertinent data.

First off am I even heading in the correct direction, = should I use the rfcomm listen command, instead of the connect?  = Is there an easier way to do what I need to get done, using already = created tools I don't know about?  Do I need to run the sdptool = and add the SP interface?  Where are the doc's that explain how to = use the rfcomm and sdptool utils -- the man pages have various = information/knowledge gaps?

Thanks,
Robert

------_=_NextPart_001_01C5C489.45989B80-- ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users