Does the framework support live streaming of data to the 'cloud'?

During the QA session at the end of the webinar “mCerebrum: Enabling Development and Field Validation of mHealth BioMarkers and Interventions” it is mentioned data is uploaded every 15 minutes to the cloud.

Is there an opportunity to do live streaming (perhaps not continuous, but upon request), and how do you deal with this in the case of 500hz data?

Steven,
Not live in the sense that everything is sent as soon as it is created, but the batch interval can be reduced to 1-minute. The 15-minute window was chosen as a way to constrain the amount of energy (battery power) used to transmit data. This being said, the cloud interface is REST-based and can accept data as fast it can be transmitted. It is possible to modify DataKit to enable a more continuous upload pipeline that would accomplish your goals.

What is your intended use-case for requiring 500Hz continuous data at the cloud interface?

I understood from the webinar (and recent publication) that the data upload window was introduced to save battery life. I am impressed with the many other non-functional requirements which also seem to be addressed by mCerebrum.

My question was primarily targeted at understanding how the architecture was structured. As of now, I do not have an actual use case which needs continuous data upload (as it comes in) at the cloud interface. One could imagine several though, although I can’t judge how likely they are:

  • Based on ‘suspicious’ data analyzed locally, switch to continuous data upload to perform more advanced analysis on a server, impossible to run on the mobile device (e.g., expensive computations, combining data with other data streams).
  • Time sensitive interventions where such ‘suspicious’ activity would need to be reviewed in real-time by someone (e.g. clinicians).

Although I have not looked into this, I doubt a REST-based API would perform well with such high-frequency data. In that sense, am I correct in presuming introducing the functionality I describe would be quite a severe change to the architecture?

The paper on mCerebrum, to appear in SenSys’17 on November 6, 2017, has an extensive discussion of the architectural details of the platform. I do not think continuous upload capabilities necessitates changing the mCerebrum architecture.

Keep in mind, we tend to do some computationally expensive operations on the phone right now, see cStress and puffMarker, but we also acknowledge the limitations of smartphone CPU/GPUs. The cloud architecture that accepts this data is currently not set up to handle proper streams of computations and it currently based on Apache Spark’s streaming model.

1 Like

Great. I’ll look more into that! Thank you for elaborating.