Bluetooth

https://sites.google.com/site/bifferboard/Home/desktop-linux-distributions/slackware/bluetooth

"You are in a maze of twisty little kernel and userland components, all remarkably..."  
    --- Colossal Cave

Introduction

So, you want to communicate with your Bifferboard via Bluetooth for remote control or whatever. Unfortunately it's not quite as simple as plugging in a cable.  This guide only scratches the surface of Bluetooth, but it's hopefully enough to give you some inspiration about what you might achieve with your Bifferboard.

Extra packages

First, you are going to need some extra packages:

root@darkstar:~# slapt-get -i dbus
root@darkstar:~# slapt-get -i bluez-utils
root@darkstar:~# slapt-get -i bluez-libs
root@darkstar:~# slapt-get -i which

Missing kernel modules

Depending on which version of the slackware rootfs you're using, you may already have these.  If not, download them from this page and load them:

root@darkstar:~/bt# insmod bluetooth.ko
root@darkstar:~/bt# insmod btusb.ko
root@darkstar:~/bt# insmod hci_uart.ko
root@darkstar:~/bt# insmod l2cap.ko
root@darkstar:~/bt# insmod rfcomm.ko

Services

Next up, you need to run some services to manage the bluetooth kernel stack.  First dbus (messagebus) and then the various bluetooth services which run ontop of it::

root@darkstar:~# chmod 755 /etc/rc.d/rc.messagebus
root@darkstar:~# chmod 755 /etc/rc.d/rc.bluetooth
root@darkstar:~# /etc/rc.d/rc.messagebus start
Starting system message bus:  /usr/bin/dbus-uuidgen --ensure ; /usr/bin/dbus-daemon --system
root@darkstar:~# /etc/rc.d/rc.bluetooth start
Starting Bluetooth subsystem:  hcid sdp rfcomm passkeys.

Note that changing the permissions on these startup scripts will mean they get run on the next boot as well. Change them back to 644 if you don't want that.

Now the Dongle!

Now it's time to plug in your USB dongle.  Assuming 'dmesg' says that it's been plugged in and recognised, hciconfig is the equivalent of ifconfig for the ethernet world:

root@darkstar:/etc/rc.d# hciconfig hci0
hci0:   Type: USB
        BD Address: 00:15:83:B3:D0:B6 ACL MTU: 384:8 SCO MTU: 64:8
        UP RUNNING
        RX bytes:348 acl:0 sco:0 events:11 errors:0
        TX bytes:38 acl:0 sco:0 commands:11 errors:0     

If you see the 'BD' address as all zeros then it's likely hcid isn't running.  Go back and try to figure why that might not have happened.

Now we're getting somewhere - it seems like we're talking to the hardware.

But how to make it actually do something?  Well, you can always start by having a look if your neighbour has their mobile switched on:

root@darkstar:/etc/rc.d# hcitool scan
Scanning ...
        00:24:EF:55:A7:2D       Mac+211

But this isn't too interesting.

Point-to-point Link

You can use the rfcomm utility to get a connection between the Bifferboard and a nearby PC (assuming you have two dongles).  Of course the 'nearby PC' is also running Slackware 13.0 to make this guide a bit simpler, however most modern Linux systems should recognize your dongle and connect something to it when you plug it in.

P-to-P Communication is via 'rfcomm' devices, that's why you loaded the kernel module above.  The bluetooth standard defines a serial port profile, and in that profile 30 channels that you can use for point-to-point communication.  You must designate one side to be the server, in other words waiting for a connection.  You do that with the 'rfcomm' utility:

# rfcomm listen rfcomm0 <channel>

example:

# rfcomm listen rfcomm0 1
Waiting for connection on channel 1

Next, you can connect from the other machine, also using the rfcomm utility:

# rfcomm connect rfcomm0 <bt address> <channel>

example:

# rfcomm connect rfcomm0 00:15:83:B3:D2:DD 1
Connected /dev/rfcomm0 to 00:15:83:B3:D2:DD on channel 1
Press CTRL-C for hangup

That's right, you need both the channel and the 'bt' address, which you can get from running hcitool on the first machine.  Now you may be wondering about that 'rfcomm0' parameter.  That's the name of a special device file that gets created under /dev when the connection is established, e.g. /dev/rfcomm0.  You can now write programs that read/write from these devices in much the same way as you'd read/write /dev/ttyS0 or /dev/ttyUSB0.   

If you want a quick test, on one machine type:

# cat /dev/rfcomm0

Then on the other type:

# echo "Boo hoo" > /dev/rfcomm0

You should see the characters printed on the first machine.

Summary

I'm afraid that's as simple as it gets when it comes to Bluetooth communication. Hopefully someone will be able to use this to come up with some neat project involving wireless, e.g. remote control cars, and so on.  Happy hacking!