I have finally managed to retrieve data from the weight scale again! I don’t know why, but when I unpaired then re-paired my phone to the weight scale, it seemed to fix the connection problem. The thing to note is, I had used the version of Demo MMDI from my very first commit to re-pair to the weight scale. As a test, I unpaired them again then paired from my latest revision and they were successfully paired. On another note, when my phone finished pairing to a new device, Demo MMDI would stay on the second screen and still say “Pairing…”. I fixed this by having the app detect when I’ve paired to a new device after a connect and had it go to the third screen. However, instead of having it display the retrieved data (which there obviously wouldn’t be), I had it say that the pairing is complete.
I immediately restarted the application and the new device did show up in the paired devices list. I also tested if I could still connect to the device as usual, and it was able to connect.
My work of this week is focused on refining the code of bluglu device integration. The purposes of the work are to prepare for pushing the bluglu integration into our project repo and make the bluglu demo ready for the FSOSS demostration. Some detailed work include: added device serial number verification feature for bluglu; updated UI for better demostration; performing tests for both bluglu and A&D devices and fixed bugs; Update project specification (README.md) file.
Here is the notes about some features of bluglu and A&D devices:
- When A&D devices sending data using Bluetooth, they have a discovery process using service name. So, verifying the service name makes sure to find right service, but the discovery process costs time.
- While bluglu device has no such discovery process when sending data using Bluetooth. After Android device pairing with bluglu device, the bulglu device will remember the MAC address of the Android. When sending data to Android, the bluglu device will directly connect to the Android device using Android’s MAC address without discovery process.
- Therefore the bluglu device uses less time in transferring data to Android than A&D devices. However, bluglu device will interfere with other Bluetooth server if the Android is listening to other devices. And in this situation, the bluglu device will enter and error state, which we need to press the reset button to recover it.
- Meanwhile, another device, Polytel, uses the same Bluetooth service name as the A&D devices. Therefore, the Android device’s opening multiple Bluetooth servers at the same to listen different medical devices will cause interference problem for each device type currently we have. So, I set the disconnect / stop_device command to stop the Bluetooth server for all devices rather than a specific server.
This week I continued working on the Pedometer. The day started off slow. Did I say It is FSOSS at Seneca? Me and Wei were talking about the Pedometer and how it needed to measure Speed of the user. The pedometer already counts steps. Definitely adding Speed is a challenge I feel I can do. Wei mentions the one way I was taught in high school to calculate speed: change in distance over time. So a large part of the day was spent doing nano timing of the distance notification method. I thought this was the best way at first. I even went and tried a jQuery timer. So I tested this for a while. Things really got exciting when I paradoxically ran into a wall. I was there for a while trying to find a better way to find speed. All that was left was my location. So finally I realized that GPS might do the trick. After all Apache Cordova’s Geolocation Watch gives the speed. So the next step is to find speed natively in Java. There is also a way to calculate distance based on the starting GPS and etc…GPS cordinates This is adding up to more work that I am glad for and looking forward to trying. You can only go so far with one idea before you need to try something brand new!
My main goal for this week was starting to integrate the pedometer with the Mobile Bluetooth adapter. So I started by importing the project into the bigger picture. I spent some time looking at how to create a separate action in the MedicalDevicePlugin Class. My aim is to create an action that will allow me to launch the Pedometer Activity that starts the Step Service. Definitely this is one way to tackle the problem, and I will need to create other ways of gathering information from the pedometer. Me and Wei actually spent probably an hour talking about how this could work. I look forward to having the final product implemented soon.
The Demo MMDI app is for some reason unable to retrieve data from any medical devices. When I select a medical device to connect to and I press Ready on the next screen, although the button says “Retrieving Data…”, the app does not change anything on the screen even after waiting a few minutes. On some occasions, I am prompted for a PIN and I do enter it, but most of the time I am not even asked for a PIN. Note that there is a test pop-up saying “true” indicating the phone is in discoverable mode. I traced the function called by the Ready button which calls connect() all the way to the Java library and when I used test alerts to see if the passed-in device type, serial number, etc. were not lost and were correct, they did appear correctly. I traced the actual connecting of the phone to the medical device to “m_threadPool.execute(task);” on line 238 in MedicalDevicePlugin.java, however, since that execute() is an Android library function, I do not have access to the source code.
I have been able to previously retrieve medical data from the device with my phone.
EDIT: The phone is retrieving data from the blood pressure monitor but only after about 2 minutes*.
*Although the issue of taking long or never retrieving the data from the device has not been resolved, the fact that the phone is able to retrieve data confirms that the user now is able to truly select which device they wish to connect to.
The bluglu device was integrated into the MMDI project
This week my job is focus on figuring out how to integrate the bluglu device into the MMDI project and implementing the integration. Eventually, the bluglu device was integrated into our project successfully. From the Demo application, we can start and stop the device and get the emulated readings.
The newly created classes implementation include: DeviceManager, BlugluDeviceManager, BluetoothAndroid, DeviceStartCommand and DeviceStopCommand. The DeviceManager is a super abstract class for all device manager and adapters. It provides the supported brands and devices of medical devices by the project for the TypeCommand and also defines 3 abstract methods: _start(), _pause() and _stop(), which are used for the basic device operaction. And the BluetoothAndroid is used for basic Bluetooth operation for the Android device.
There is an issue of that When the application is start to connect/listen to the AND device, the application can catch the Bluetooth signals sent by bluglu devices. AND and bluglu use different service name, so the interference should not happen. Meanwhile, the bluglu integration is test on the emulator of blood glucose device. It need to test on the real device.