View source for Manually using Bluetooth
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Templates used on this page:
Return to Manually using Bluetooth.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Templates used on this page:
Return to Manually using Bluetooth.
In progress: This article or section documents one or more features whose implementation are in progress. |
Bluetooth is one of the core functions of the Neo1973, however it is basically unimplemented on the software side at the moment. Hardware problems in the P1 phone mean that the CPU has to be active in order to wake on external bluetooth events, which will reduce the battery life to some 2 days at best in standby.
This page details how to use bluetooth from the command line. We have quite a lot of plans about what exactly Bluetooth should be used for.
Bluetooth may not be powered up.
Power up the adapter:
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on
If that doesn't do it, power up and reset the adapter one after the other:
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on ; echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/reset ; echo "0" > /sys/bus/platform/devices/gta01-pm-bt.0/reset
hciconfig should print information about the adapter if it powered up properly:
hciconfig
(If you have an older rootfs, you may need to modprobe gta01-pm-bt or even hci_usb but these are built in/loaded automatically currently.) The devices should show as UP. If not you can use
hciconfig <device> up
in file /etc/bluetooth/hcid.conf you should change the passkey from BlueZ to something numeric. For testing you may use "0000". Also, you can set the name to "Neo (%d)".
hcitool scan
This will list the addresses of any discoverable bluetooth devices in the vicinity
There should be a passkey agent built into openmoko, but for now you can start up the example passkey agent and set the pin code there. This will allow for new pairings to be made when you attempt a connection.
passkey-agent --default 0000 &
Note: the passkey-agent is not required in OpenMoko 2007.2 with kernel 2.6.21.6 as of at least since August 27 (maybe earlier).
We want to be able to use a bluetooth keyboard to type into the various applications of our Neo1973. To use a Bluetooth Keyboard type: (11:22:33:44:55:66 is the Address of your BT-Keyboard)
hidd --connect 11:22:33:44:55:66
and press "Connect" on your BT-KB
Tested on:
We want to be able to use the Neo1973 as a HID device, being able to use it as controller for presentations.
Here's how to connect to an external Bluetooth GPS and read NMEA data (Tested with a Holux GPSSlim236).
First, switch on the GPS and identify the BT address:
hcitool scan
Then, edit /etc/bluetooth/rfcomm, which by default has all settings commented out, to something like this:
rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:11:22:33:44:55; # RFCOMM channel for the connection (check your GPS docs for details) channel 1; # Description of the connection comment "Bluetooth GPS"; }
Restart the BT services:
root@neo:~$ /etc/init.d/bluetooth stop root@neo:~$ /etc/init.d/bluetooth start
You should now be able to bind the GPS to /dev/rfcomm0, like this:
root@neo:~$ rfcomm bind 0
Confirm the connect:
root@neo:~$ rfcomm rfcomm0: 00:11:22:33:44:55 channel 1 clean
... and watch the NMEA strings coming from your GPS:
root@neo:~$ cat /dev/rfcomm0 $GPGGA,111748.000,5907.6964,N,01121.1787,E,1,06,1.2,57.7,M,40.1,M,,0000*6F $GPRMC,111748.000,A,5907.6964,N,01121.1787,E,0.00,94.94,160807,,,A*50 $GPVTG,94.94,T,,M,0.00,N,0.0,K,A*3D
If you have nothing better to do, you can now pinpoint my office :-).
Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.
On the laptop:
elara /home/alphaone # /etc/init.d/bluetooth start
elara /home/alphaone # pand -s
elara /home/alphaone # ip a add 10.0.0.1/24 dev bnep0 elara /home/alphaone # ip l set bnep0 up
On the phone:
root@fic-gta01:~$ hcitool scan Scanning ... 00:0E:6D:C0:0l:6A Sho 00:20:E0:5A:FE:C8 BlueZ (0)
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8
while this should work, I needed this command to get a PAN to a SE K610i up and running:
pand -r PANU -d NAP -A -E -S -c <bt_address_of_K610i> -e bnep0
if you want to see if pand is doing fine, start it with '-n' to see status messages.
ip a add 10.0.0.2/24 dev bnep0 ip r add default via 10.0.0.1
root@fic-gta01:~$ wget http://www-public.tu-bs.de:8080/~y0019680/tmp/thereisnophone.mp3 Connecting to www-public.tu-bs.de[134.169.9.108]:8080 thereisnophone.mp3 100****************************************************| 266 KB 00:00:00 ETA root@fic-gta01:~$ madplay thereisnophone.mp3 MPEG Audio Decoder 0.15.2 (beta) - Copyright (C) 2000-2004 Robert Leslie et al. 630 frames decoded (0:00:22.6), -0.9 dB peak amplitude, 0 clipped samples
If you are unable to use the 'BNEP' method described above, you may be able to use a dialup-networking emulation mode. On the Neo:
RFCOMM_ENABLE=true DUND_ENABLE=true DUND_OPTIONS="--listen --persist call dun"
115200 192.168.2.202:192.168.2.200 passive local noipdefault noauth nodefaultroute
To connect from a MacOS 10.3 client:
The A2DP codec, SBC, runs pretty well now in 32-bit fixed-point math. It's been successfully tested on a faster ARM but not yet on neo. There is test code in the bluetooth-alsa.sf.net plugz module for using alsa plugins to send A2DP audio out and it's starting to be reimplemented "properly" in the bluez core.
Bluez has an audio daemon for headset audio that should work to set up the control connection to the headset. It will need hooks in the openmoko gui.
Neo1973_Audio_Subsystem has more detail about what magic needs to happen with the Wolfson codec so system audio can be switched to use the bluetooth audio channel and later back to the speaker/earpiece/wired headset. There seems to be a proposal for audio scenario management there but no detail about whether that is how things are done currently. How should audio management work when eg plugging in/unplugging the wired headset?
If the codec audio management is worked out, then all we need are hooks to make the kind of dbus api calls that are in the python examples at http://wiki.bluez.org/wiki/HOWTO/AudioDevices (need to ipkg install python-dbus and python-xml). The play method *does* need to be called; it's automatic only when using an alsa plugin which is not how it works on neo.
http://www.holtmann.org/papers/bluetooth/ols2006_slides.pdf http://wiki.bluez.org/wiki/Audio#org.bluez.AudioBluetooth