Bluetooth Problems
From MoDe
The command to check if the bluetooth receiver is working is as follows:
root@h3900:~# hciconfig -a
But most people get the following output:
hci0: Type: UART BD Address: 08:00:17:1B:0A:21 ACL MTU: 339:4 SCO MTU: 60:9 UP RUNNING PSCAN ISCAN RX bytes:363 acl:0 sco:0 events:13 errors:0 TX bytes:310 acl:0 sco:0 commands:13 errors:0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DH1 HV1 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Can't read local name on hci0. Connection timed out(110)
Skip this portion and try the method posted by Jasper below. If using the shell script (see below for details) does not work then you may be come back here.
In most cases this is not a hardware problem and has something to do with the bluez dbus package not working properly. Try downgrading the dbus to a nodbus and it should work. First issue the following command:
root@h3900:~# ipkg -force-depends remove bluez-utils-dbus
Then download an earlier version of nodbus here bluez-utils-nodbus (http://familiar.handhelds.org/releases/v0.8.0/base/bluez-utils-nodbus_2.11-r1_arm.ipk). Now type the following the command:
root@h3900:~# ipkg install bluez-utils-nodbus_2.11-r1_arm.ipk Installing bluez-utils-nodbus (2.11-r1) to root... Configuring bluez-utils-nodbus Adding system startup for /etc/init.d/bluetooth ... /etc/rc2.d/S20bluetooth -> ../init.d/bluetooth /etc/rc3.d/S20bluetooth -> ../init.d/bluetooth /etc/rc4.d/S20bluetooth -> ../init.d/bluetooth /etc/rc5.d/S20bluetooth -> ../init.d/bluetooth Starting Bluetooth subsystem: hcid sdpdCan't open HIDP control socket: Invalid argument hidd rfcomm. /etc/rc0.d/K20bluetooth -> ../init.d/bluetooth /etc/rc1.d/K20bluetooth -> ../init.d/bluetooth /etc/rc6.d/K20bluetooth -> ../init.d/bluetooth
(ignore the Invalid argument message)
Make sure your bluetooth radio is switched on and the blue light is blinking and then check if receiver is working using the following commands:
root@h3900:~# hciconfig hci0 up
root@h3900:~# hciconfig -a
hci0: Type: UART
BD Address: 08:00:17:1D:D3:16 ACL MTU: 339:4 SCO MTU: 60:9
UP RUNNING PSCAN ISCAN
RX bytes:630 acl:0 sco:0 events:13 errors:0
TX bytes:58 acl:0 sco:0 commands:13 errors:0
Features: 0xff 0x3b 0x05 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'POCKET_PC'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x180 LMP Ver: 1.1 (0x1) LMP Subver: 0x180
Manufacturer: RTX Telecom A/S (21)
If you see the portion in blue then your bluetooth receiver is working fine.
If this method this does not work please report to Zahoor Zafrulla (mailto:zahoor.zafrulla@nus.edu.sg)
I hear the above fix does not work all the time and I have witnessed this myself once. If it works for you great but if not or if you would rather keep dbus functionality then read on. Turns out the "Connection timed out(110)" problem is not caused by dbus necessarily but the order in which hciattach, hciconfig up, and hcid are executed and the delicate timings between each one. As far as I can tell there is a certain probability for the above error to happen on any iPaq but some iPaqs appear more prone than others. Through lots of experimentation I have found a sequence that appears to work with high probability on all iPaqs and if it doesn't work the first time the process can be repeated. I wrote a script bluetooth-up.sh (http://web.mit.edu/jasperln/web_scripts/download/bluetooth-up.sh) that takes care of all this. The script is quite agressive so it'll keep trying if necessary but I have never seen it go past the third iteration. Here is how to install (as root):
1) Revert back to bluez-utils-dbus if you changed to nodbus 2) wget http://web.mit.edu/jasperln/web_scripts/download/bluetooth-up.sh 3) chmod +x bluetooth-up.sh 4) ./bluetooth-up.sh
That's all there is to it. Let me know if it takes quite a few iterations for it to work. If you find it helpful you can cp the script to a global location like /sbin. And also since you may want to turn off bluetooth here's the accompanying off script bluetooth-down.sh (http://web.mit.edu/jasperln/web_scripts/download/bluetooth-down.sh).
Other problems:
- "Resource temporarily unavailable" or "Device unavailable". Running bluetooth-up.sh seems to make the problem go away for me (there is a built-in bluetooth shutdown). I also got this with Famliliar v0.8.2 a lot so if you are running that, unfortunately, it might be time to upgrade.
- "Permission denied" or something similar. Make sure you have entered the pin to talk to the gps receiver. You pretty much only need to do this once since it is remembered.
- "Connection refused". The gps receivers seem to only want to listen on port 1. This is annoying if more than one person wants to listen to the gps receiver at once. Let me know if there is a better workaround than writing code that just duplicates the data for both listeners. Also is there a more proper way of discovering the receivers are listening to port 1?
Getting bluetooth to work on the iPaqs sometimes requires a little blackmagic so if you have run into a problem and found a fix please do add! I hope that bluetooth-up.sh (http://web.mit.edu/jasperln/web_scripts/download/bluetooth-up.sh) gets rid of one of the most annoying problems I have seen so far.
--jasperln (mailto:jasperln@mit.edu)
Interesting find Jasper - you might want to consider filing a bug report of some kind with the Familiar people regarding this issue. Bluetooth support in Familiar is still pretty unstable at best.
Another thing to keep in mind is since wifi's spectrum overlaps with bluetooth, they can interfere with each other and cause you to lose your bluetooth connection (this was mentioned in lecture). One way to get around this problem is to turn off wifi temporarily with the "ifdown" shell command from within python - use os.system("command"), then bring it back up when you need it. There may be other/better solutions out there, so if you find them, post them here.
--Ning (mailto:nsong@mit.edu)
