I've been attempting to do some hacking on the Bluez stack. The starting
point was to initiate an SPP link to my Nokia 6300 mobile phone. I can
establish the link, but when I attempt to send characters to it (through
several different methods), the phone will announce it is disconnecting.
The python I use is at the bottom of this email.
I have already set up a serial connection using a UART to bluetooth
module (a module based on the LMX9830) in conjunction with a
USB->serial->UART piece of hardware. In this configuration, I can
initiate a connection to the phone and write and receive bytes from it
no problem.
My questions are as follows:
1) Am I missing something important with how I am using the Bluez stack?
2) Is this a known issue or is it a previous known issue? I am still
using the version of Bluez that comes with shipped with Ubuntu 9.04
which is 4.39.
3) Are there any caveats with how devices implement the serial port
profile?
I'm keen to sort this problem out and would appreciate any assistance.
Many thanks,
Henry Gomersall
The code used:
import dbus
bus = dbus.SystemBus();
manager = dbus.Interface(bus.get_object('org.bluez', '/'),
'org.bluez.Manager')
obj = bus.get_object('org.bluez', manager.DefaultAdapter())
adapter = dbus.Interface(obj, 'org.bluez.Adapter')
phone = dbus.Interface(bus.get_object('org.bluez',
adapter.ListDevices()[0]), 'org.bluez.Device')
phone_serial = dbus.Interface(phone, 'org.bluez.Serial')
phone_serial.Connect('spp')
At this stage, I have the device /dev/rfcomm0, but I cannot write data
to it without breaking the link.
On Tue, 2009-07-21 at 12:51 +0100, Henry Gomersall wrote:
> I've tried doing the same thing using the rfcomm program. This allows
> me
> to set up a stable connection using:
> rfcomm connect /dev/rfcomm0 'XX:XX:XX:XX:XX:XX'
I've done a little more investigation.
(please correct me if I am wrong) The rfcomm app speaks directly to the
kernel bluetooth interface. It works fine.
The sample test-serial program works through the dbus interface to the
bluetooth daemon and has exactly the same problem as my test program -
namely the serial link is dropped as soon as I attempt to write data to
it.
The problem I have is the large overhead to understanding the source
tree, with the wiki being pretty out of date. I'm keen to sort this
problem.
Cheers,
Henry
On Tue, 2009-07-21 at 13:02 +0300, Johan Hedberg wrote:
> > phone = dbus.Interface(bus.get_object('org.bluez',
> > adapter.ListDevices()[0]), 'org.bluez.Device')
> >
> > phone_serial = dbus.Interface(phone, 'org.bluez.Serial')
> > phone_serial.Connect('spp')
>
> That looks fine to me, though you might want to use FindDevice with
> the
> address of your phone in case you at some point configure more than
> one
> device.
>
yeah, it was a quick and dirty method to get it connected - I couldn't
work out the string format for the bluetooth address (its obvious
now!) ;)
> > At this stage, I have the device /dev/rfcomm0, but I cannot write
> data
> > to it without breaking the link.
>
> Do you open the device node and try to write to it from the same
> python
> script that you created the connection with? At the very least the
> process
> that calls Serial.Connect() needs to stay alive for the duration of
> the
> connection.
Well, this is all being handled inside an ipython session (which I do
not exit)
>
> Another potential issue that comes to mind is that the protocol you're
> supposed to speak to the phone could be binary in which case you'll
> need
> to set the tty into raw mode before doing anything with it (in C you'd
> use
> cfmakeraw and tcsetattr for that and python probably provides
> something
> similar).
I've tried doing the same thing using the rfcomm program. This allows me
to set up a stable connection using:
rfcomm connect /dev/rfcomm0 'XX:XX:XX:XX:XX:XX'
I can then write AT commands to it as expected.
I'll take a look at the rfcomm source and see what its doing differently
from me (unless someone knows the answer ;)
Thanks,
Henry
Hi Henry,
On Tue, Jul 21, 2009, Henry Gomersall wrote:
> import dbus
>
> bus = dbus.SystemBus();
> manager = dbus.Interface(bus.get_object('org.bluez', '/'),
> 'org.bluez.Manager')
> obj = bus.get_object('org.bluez', manager.DefaultAdapter())
> adapter = dbus.Interface(obj, 'org.bluez.Adapter')
>
> phone = dbus.Interface(bus.get_object('org.bluez',
> adapter.ListDevices()[0]), 'org.bluez.Device')
>
> phone_serial = dbus.Interface(phone, 'org.bluez.Serial')
> phone_serial.Connect('spp')
That looks fine to me, though you might want to use FindDevice with the
address of your phone in case you at some point configure more than one
device.
> At this stage, I have the device /dev/rfcomm0, but I cannot write data
> to it without breaking the link.
Do you open the device node and try to write to it from the same python
script that you created the connection with? At the very least the process
that calls Serial.Connect() needs to stay alive for the duration of the
connection. This is because bluetoothd will track the D-Bus client and
automatically disconnect if the client disconnects (e.g. when your script
exits).
Another potential issue that comes to mind is that the protocol you're
supposed to speak to the phone could be binary in which case you'll need
to set the tty into raw mode before doing anything with it (in C you'd use
cfmakeraw and tcsetattr for that and python probably provides something
similar).
Johan