Difference between revisions of "Phonegap Healthcare Adapter Backlog"

From CDOT Wiki
Jump to: navigation, search
(→‎Summary of Bluetooth communication test between Android and A&D BTP devices)
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Admon/obsolete}}
 +
 
[[Category: NexJ_Express]]
 
[[Category: NexJ_Express]]
 
[[category: NexJ Express PhoneGap]]
 
[[category: NexJ Express PhoneGap]]
Line 66: Line 68:
 
*** 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.
 
*** 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 PBT Series devices===
−
==== Summary of Bluetooth communication test between Android and A&D BTP 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.
 
* 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.
 
** 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).
 
** 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 series which are SPP and SDP conformable. We use A&D UC-321PBT(Weight scale) and UA-767PBT (Blood Pressure Monitor).
+
** Medical devices: A&D PBT series which are SPP and SDP conformable. We use A&D UC-321PBT(Weight scale) and UA-767PBT (Blood Pressure Monitor).
−
 
 
 
* Important research findings for building the Bluetooth applications:
 
* Important research findings for building the Bluetooth applications:
 
** Use the right Bluetooth service name and application UUID (00001101-0000-1000-8000-00805f9b34fb).
 
** 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 it should not be necessary for a paired device.
 
** Set the Android device to 'discoverable' state for the first medical measurement even through it should not be necessary for a paired device.
−
** The Android Bluetooth server works only after rebooting the Android device. This is the first issue we met with the tests. After search on the Internet, We condemned the medical devices uses the fixed RFCOMM port number - #1. 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. This conclusion could be right form A&D early products. But the current market products of 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 the Android device" is this: When the application (Android activity) exits by clicking the "back" or "home' button, it 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 devices use fixed Bluetooth port#" is actually not the case.
+
** 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.
−
** Unreadable data from medical devices may affect the Bluetooth communication. In the tests, we found inappropriate process of unreadable data from medical devices will interrupt the Bluetooth communication, leading to these unreadable measurement records accumulated within medical device's memory (up to 40 records). Each time a new measurement is made, unreadable records will be sent to the Bluetooth server first, and these records will cause communication failure. The solution for this issue is that the Bluetooth server accepts these wrong data instead of giving exceptions to interrupt the process. We may let applications to deal with these invalid data.
+
** 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.

Latest revision as of 19:38, 26 January 2014

Important.png
This page may be obsolete.
It contains historical information.

NexJ Medical Peripheral Mobile Adapter Will be designed to enable NexJ's Mobile Healthcare solutions to interact with Bluetooth peripherals.

Main article: Mobile Medical Device Integration

Investigation

IOS

  • Bluetooth can work on simulators.
  • Deploy to devices, requiring enrollment in the developer program.
  • Understand Objective C.
  • Understand iOS best practice development.
  • Understand iOS PhoneGap plugin best practices.

Android

  • Bluetooth does not work on the emulator.
  • Understand ADK best practice development.
  • Understand ADK PhoneGap plugin best practices.

PhoneGap API

  • Design a unified API in JavaScript that will allow the NexJ application to interact with Bluetooth devices.
  • Define a project architecture that facilitates multiple device compatibility.

Blood Pressure Device

IOS

  • Create native Bluetooth adapter for this device.

Android

  • Create native Bluetooth adapter for this device.

Glucose Level Device

IOS

  • Extend native Bluetooth adapter for this device.

Android

  • Extend native Bluetooth adapter for this device.

Weight Scale Device

IOS

  • Extend native Bluetooth adapter for this device.

Android

  • Extend native Bluetooth adapter for this device.

Proof of Concept

Android

  • We've created the Android native code (using Android Bluetooth API) to test the Bluetooth process between Android and medical devices.
    • Settings for connection: For creating the UUID of the Android device, "00001101-0000-1000-8000-00805f9b34fb" is used instead of conforming to the COD filter value on the A&D specs; but the service name and PIN on the specs have to be used.
    • Issues in the test:
      • 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 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 PBT series which are SPP and SDP conformable. We use A&D UC-321PBT(Weight scale) and UA-767PBT (Blood Pressure Monitor).
  • Important 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 it should not be necessary for a paired device.
    • 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.
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Phonegap_Healthcare_Adapter_Backlog&oldid=104085"