Changes

Jump to: navigation, search

Phonegap Healthcare Adapter Backlog

515 bytes added, 20:38, 26 January 2014
no edit summary
{{Admon/obsolete}}
 
[[Category: NexJ_Express]]
[[category: NexJ Express PhoneGap]]
*** For the blood pressure meter, pairing can be set but data transmission is unstable. The reason could be: The A&D medical device always forces one to use RFCOMM port/channel 1 for the connection; but the Android device will choose the next available channel.
 ==== Summary of Bluetooth communication test between Android and A&D BTP PBT Series devices ====
* After the research efforts of many weeks, we have successfully built Bluetooth communication test programs: one is an Android native application; the other is based on PhoneGap (plugin on Android) framework.
** The two versions of the testing code, through Android Bluetooth APIs, make the Android devices work as Bluetooth server and perform SPP communication of Bluetooth.
** Android devices: The minimum version of Android is targeted at Android 2.2 and the test devices are HTC Desire (Android 2.3.3) and MOTOROLA XT885 (Android 4.04).
** Medical devices: A&D BTP PBT series which are SPP and SDP conformable. We use A&D UC-321PBT(Weight scale) and UA-767PBT (Blood Pressure Monitor). * Important points research findings for building the Bluetooth applications:
** Use the right Bluetooth service name and application UUID (00001101-0000-1000-8000-00805f9b34fb).
** Set the Android device to 'discoverable' state for the first medical measurement even through for paired device it should not be necessaryfor a paired device.** The About the issue of "Android Bluetooth server work works only after rebooting the Android device". This is the first a tough issue we met which costs us weeks to address. Based on the tests. After search searches on the Internet, We condemned we have concluded that the medical devices uses use the fixed RFCOMM port number - #1to 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 was 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. This conclusion could be right form A&D early products. But the current market products of Eventually, we found the A&D BTP series (at least UC-321PBT and UA-767PBT) are DSP conformable and are able to use any RFCOMM port number provided by Bluetooth server. The real reason that "Android Bluetooth server works only after rebooting which causes the Android device" is this: communication problem. When the Android application (Android activity) exits by clicking the "back" or "home' " button, it the application becomes inactive but its '''Bluetooth server thread ''' keeps receiving signals from the medical devices. So the newly started applications cannot not receive data. Therefore, the issue of "A&D medical PBT devices use fixed Bluetooth port#for SPP communication" is actually not could be right for the caseearly 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.** Unreadable The data from transmission process needs to deal with '''invalid data''' generated by medical devices may affect the Bluetooth communication. In the tests, we have found out that the medical devices sometimes send out invalid measurement data. An inappropriate process of unreadable for these data from medical devices will cause exceptions and therefore interrupt the Bluetooth communication. As a result, leading to these unreadable invalid measurement records are accumulated within the medical device's memory storage (up to 40 records). Each Thus, each time a new measurement is made, unreadable all the old invalid records will be sent to the Bluetooth server firstbefore the new one is sent, causing poor performance and these records will cause even communication failure. The solution for this issue is that the Bluetooth server accepts these wrong invalid data instead of giving exceptions to interrupt the communication process. We may let applications ** To make sure get right readings from UA-767PBT devices, one of the success way is to deal with these invalid dataread the bytes from datainputstream one by one until appropriate length is reached.

Navigation menu