1

I’m trying to develop an Android application for a medical device using Bluetooth (SPP). I’ve used the BluetoothChat as a starting point (also see earlier post). Now I think I’m facing a weird problem and I’m also having trouble describing it. Testing on a Nexus S.

Upon the completion of measurement the medical device checks its memory for the Bluetooth address and other information about the previously paired device. If found it will try to initiate a connection (while the application on the phone is listening for a connection) and then transfer data and otherwise it starts an inquiry procedure.

The first time it works fine: pairing procedure, establishing connection and transferring data. When the data is received the application replies with an ACK package and the connection is terminated.

The rest of the times it does not work: after a measurement I can see in the LogCat that the phone receives a signal (just like the first time) from the device, so I know the device saved the phones Bluetooth address. It seems like the system ignores the signal (or at least nothing happens), no connection is established and thus no data transferred even though I'm using accept-method of BluetoothServerSocket the same way as when it works. If I remove the pairing record from the phone this signal starts the pairing procedure and the devices get paired again, BUT they still won’t establish a connection nor transfer data. I guess the message about the signal represents a try to establish a connection but something is wrong. The message in the log is the same as when the connection is successful and can be seen in the LogCat:

03-22 14:21:55.335: ERROR/BluetoothEventLoop.cpp(114): event_filter: Received signal org.bluez.Device:PropertyChanged from /org/bluez/4123/hci0/dev_00_A0_96_2D_05_E8

It's rather confusing it's an ERROR message and present in the log when it works as well.

The weird thing is that it works the first time they are successfully paired, but never again afterwards. When the data is transferred and the device receives an ACK it saves the Bluetooth address "and other useful information". The only way I can reproduce the successful ‘first time’ is by pairing the medical device with another device and then afterwards pair it with the application on the phone again.

I’m confused about what is actually causing this problem. Does anyone out there have any clue?

I’m afraid my problem is a bit to specific to be familiar to others if case the problem is caused by the medical device and not the phone. I was thinking it might be related to the Link Key or Channel? But on the other hand, as I said, if I remove the pairing from the phone, I'll get a pairing request again.

The medical device is old, using Bluetooth 1.2. Now it strikes me that I should have a look at if there are any connection-related issues because of this. Could it be that a device using Bluetooth 1.2 have another policy of what information to store when it is paired?

For the moment I feel I'm struggling with a problem I don't fully understand, but if I'll understand later I'll of course get back with my conclusions. I hope I didn't forget important details.

Thanks in advance /F

Community
  • 1
  • 1
Fredricus
  • 273
  • 1
  • 2
  • 9

2 Answers2

1

Hi fredricus My problem is similar to yours i m running a bluetooth service which keeps on listening for data when the bluetooth is on.u have solved the problem of connecting android device to a medical device as u mentioned that u have used reflection.But in case if medical initiates connection will it be able to connect to android device.

Raghu
  • 11
  • 1
  • Well, to be clear: In my case the medical device connects to the Bluetooth service provided by my Android application. I managed to get the medical device to connect to it, and I used reflection to get the port (RFCOMM channel). So if that is your problem, you should try the code for reflection found [here](http://code.google.com/p/android/issues/detail?id=5427). – Fredricus Mar 30 '11 at 07:08
  • Also, if the medical device initiates the connection, notice that you will have to be careful about Service Name and UUID (which is used to set Protocol / Profile) as well, to be sure the device actually tries to connect to your Bluetooth service. You can find the UUID:s for respective Profile/Protocol in [this link](http://bluecove.org/bluecove/apidocs/javax/bluetooth/UUID.html). – Fredricus Mar 30 '11 at 07:23
0

Sounds like the problem is with the medical device, that it is not able to re-establish connection (i.e. re-authenticate) with already paired device. I dont think that being being 1.2 should matter. The procedures are designed to be backward compatible so that all bluetooth versions work with each other. You may have to get a bluetooth sniffer trace to check what might be going on over the air that will validate if the issue is on the medical device side.

Another option is to check if android has any way to turn on more detailed logging of the Bluetooth interactions and enable that. Default log of Android messages are very high level and does not provide much detail

Dennis Mathews
  • 6,897
  • 2
  • 26
  • 39
  • Thank you for that good advice. I didn't think of such a program. I've probably been stairing at the problem for too long period of time and lost the wide sight while trying to dig deeper. I'll try it out and see what I can get out of it and get back with more information about the progress. – Fredricus Mar 23 '11 at 07:56
  • I wasn't able to get a sniffer but I've spoken to the manufacturer and the problem is that the device saves the socket, i.e. the channel, while pairing and using the `listenUsingRfcommWithServiceRecord` means "system will assign an unused RFCOMM channel to listen on". So, I need to either set the channel or close and create a new server socket until I get the right Rfcomm channel. So this is my new problem. I was looking at [this question](http://stackoverflow.com/questions/4887307/android-rfcomm-socket-on-fixed-channel) but still I hope there is a better solution? – Fredricus Mar 28 '11 at 08:46
  • I haven't found this so I guess not, but.. Is it possible to inspect the number of the Rfcomm channel with help from the standard API? – Fredricus Mar 28 '11 at 08:47
  • See if this helps - http://stackoverflow.com/questions/4887307/android-rfcomm-socket-on-fixed-channel – Dennis Mathews Mar 29 '11 at 02:24
  • Thank you, that was actually the link I posted (almost invisibly) in my comment above :-D Anyway, I didn't have to backport to Android 1.5. The solution was to use reflection to get the private variables needed. – Fredricus Mar 29 '11 at 08:25
  • I found code for reflection [here](http://code.google.com/p/android/issues/detail?id=5427). – Fredricus Mar 29 '11 at 08:30