Jump to: navigation, search

Phonegap Healthcare Adapter Backlog

172 bytes added, 09:17, 23 July 2013
Summary of Bluetooth communication test between Android and A&D PBT Series devices
** About the issue of "Android Bluetooth server works only after rebooting the Android device". This is a tough issue which costs us weeks to address. Based on the searches on the Internet, we have concluded that the medical devices use the fixed RFCOMM port number - #1 to communicate with Bluetooth servers. But beginning with Android 2.0, Android Bluetooth API uses '''random''' RFCOMM channel/port numbers for SDP process and does not allow developers to set the port number manually any more. This conclusion is "confirmed" by the documentation in the A&D Blackberry code from NexJ, which states that port #1 must be used to build Bluetooth server socket. Eventually, we found the real reason which causes the communication problem. When the Android application exits by clicking the "back" or "home" button, the application becomes inactive but its '''Bluetooth server thread''' keeps receiving signals from medical devices. So newly started applications cannot receive data. Therefore, "A&D PBT devices use fixed port# for SPP communication" could be right for the early products. But current market products of the A&D BTP series (UC-321PBT and UA-767PBT) are SDP conformable and are able to use any RFCOMM port number provided by a Bluetooth server.
** The data transmission process needs to deal with '''invalid data''' generated by medical devices. In the tests, we have found out that the medical devices sometimes send out invalid measurement data. An inappropriate process for these data will cause exceptions and therefore interrupt the Bluetooth communication. As a result, these invalid measurement records are accumulated within the medical device's storage (up to 40 records). Thus, each time a new measurement is made, all the old invalid records will be sent to the Bluetooth server before the new one is sent, causing poor performance and even communication failure. The solution for this issue is that the Bluetooth server accepts these invalid data instead of giving exceptions to interrupt the communication process.
** To make sure get right readings from UA-767PBT devices, one of the success way is to read the bytes from datainputstream one by one until appropriate length is reached.

Navigation menu