Android/Ios App WiSat_RFP

Android and iOS developer versions of the application. Three metrics (WSs, time between WSs, and an in-seat activity score). Throughout the day, the mobile application will send notifications to the end-user if they fail to comply with their WS goals. including a diagram of the flow of data from the Sensor Mat to the Data Logger to the Mobile Application. In brief, the WiSAT is comprised of 3 subsystems: hardware, mobile application and classification algorithms. The hardware consists of a seat sensor and data logger which captures forces on the seat surface at 4 Hz. The logger stores the data and transmits it to the mobile application upon request. Algorithms are deployed to classify the in-seat movements into the activity metrics to be reported to the user. The mobile applications, UI is used to inform the user about his or her in-seat activity. Specific Application Requirements I. Data Flow A. Transmitted by Data Logger Mobile Application 1. Hardware Status: Battery Life 2. Initialization Success: Confirmation of the receipt of initialization data parameters 3. Sensor Data/Time: A JSON object containing 6 integer values (sensor data) and a timestamp. One or two additional fields may be added if deemed necessary. The data logger collects data at a rate of 4 Hertz. B. Transmitted by Mobile Application to Data Logger 1. Initialization Data Parameters: values that allow the data logger to perform an initialization calculation 2. Bluetooth connection: Connection to data logger and mobile phone Bluetooth chips 3. Request to Send Data: A request for #A3 above 4. Confirmation of Receipt of Data: a confirmation of the receipt of #A3 C. Transmitted by Mobile Application to Georgia Tech Server 1. Errors: Errors and Exceptions that result in the loss of any data or interfere with the display of any UI elements shall be sent to a provided Georgia Tech RESTful API Endpoint when an internet connection is available. When offline, the application shall log errors to be sent once the application becomes online again. 2. Data Transmission: Twice daily, the application shall transmit all unsynced data to a second, provided Georgia Tech RESTful API Endpoint if online. If offline at the scheduled sync time, the application shall do nothing. 3. Manual Data Transmission: As a backup to the automatic data transmission, a button in the settings page shall send the Realm database to a Georgia Tech server when pressed. D. Overview: A data logger will record data from a pressure sensor mat regarding the user's sitting position at a rate of 1 to 4 Hertz. The data logger will save the sensor data II. User-Interface: A. Subject ID Prompt Screen: Prompt the researcher to input an alphanumeric subject identifier and other clinical variables upon first use. B. Initialization: Prompt the user to provide initialization data on their first use of the system. C. Bluetooth Connection Pop-Over Window D. Settings: User-configurable settings screen E. Medical Information screens: static screens displaying medical information about pressure ulcers and their treatment 1. Active Notifications: Display reminders to the user regardless of phone sleep status if the processed sensor data indicates noncompliance with PR goals. We prefer these to take the form of offline-only notifications but are willing to utilize Push Notifications/Firebase-based notifications (in the case of Android devices) if they are determined to be the best option. 1. Push Notification On/Off Resources Provided  API to interface with data logger module (in progress – available after project start)  API to transmit data to server as specified in I.C (in progress –available after project start)  Low-Fidelity UI prototype (available at project start)  Data logger module for development and testing  Algorithms (in the form of code libraries/packages) to calculate PRs, Activity Score, and any related metrics (in progress – available after project start)