Implements helper classes and base types relied upon by all subsystems. Primarily, this contains the built-in types used to define study protocols which subsequently get passed to the deployments and clients subsystem.
DataTypes are identified by a given name within a namespace and identify the data contained within matching Data points.
When a data type describes data relating to a time interval, the time interval isn't stored in the data point body, but in the header of the data point, common to all data point types (e.g., interbeatinterval).
Sensor data types and task data types can be accessed through CarpDataTypes.
They all reside under the namespace: dk.cachet.carp.
Input data types can be accessed through CarpInputDataTypes.
They all reside under the namespace: dk.cachet.carp.input.
Passively collected data by hardware sensors is called SensorData (implements Data).
Sensor data types are device-agnostic.
The goal is that they can be reused for devices by different vendors.
They act as a common data format.
If device-specific data is needed, it can be passed using the sensorSpecificData field, which is of type Data.
Custom infrastructures built using CARP Core can specify custom Data types in their own codebase to hold sensor-specific data.
All extendable domain objects, including Data, can be uploaded to CARP backends that use the recommended CARP serializers;
they don't need the types at compile time or runtime, although then the data won't be validated on upload.
| Name | Description |
|---|---|
| geolocation | Geographic location data, representing longitude and latitude. |
| stepcount | The number of steps a participant has taken in a specified time interval. |
| ecg | Electrocardiogram data of a single lead. |
| ppg | Photoplethysmogram data for one or more individually emitting light sources. |
| heartrate | Number of heart contractions (beats) per minute. |
| interbeatinterval | The time interval between two consecutive heartbeats. |
| sensorskincontact | Whether a sensor requiring contact with skin is making proper contact at a specific point in time. |
| nongravitationalacceleration | Acceleration excluding gravity along perpendicular x, y, and z axes. |
| eda | Single-channel electrodermal activity, represented as skin conductance. |
| angularvelocity | Rate of rotation around perpendicular x, y, and z axes. |
| signalstrength | The received signal strength of a wireless device. |
Data related to when tasks (configured using TaskConfiguration) were triggered (configured using TriggerConfiguration) or completed.
| Name | Description |
|---|---|
| triggeredtask | A task which was started or stopped by a trigger, referring to identifiers in the study protocol. |
| completedtask | An interactive task which was completed over the course of a specified time interval. |
Data which is typically entered by users, as opposed to collected passively.
CarpInputDataTypes links these data types to a reduced set of InputElement abstractions.
UI frameworks can map each InputElement type to corresponding input fields.
Using helper functions in CarpInputDataTypes, the data input by users can be converted from/to strongly typed and validated input Data.
| Name | Description |
|---|---|
| sex | Biological sex assigned at birth of a participant. |
Implementations of DeviceConfiguration are used by the framework to describe the type of device used to collect data, its capabilities,
and to configure how it participates in the study protocol.
Primary devices (PrimaryDeviceConfiguration),
in addition to supporting data collection from internal sensors,
act as a hub to aggregate, synchronize, and upload incoming data received from one or more connected devices.
| Class | Primary | Description |
|---|---|---|
| Smartphone | Yes | An internet-connected phone with built-in sensors. |
| Website | Yes | A website which participates in a study as a primary device. |
| AltBeacon | A beacon meeting the open AltBeacon standard. | |
| BLEHeartRateDevice | A Bluetooth device which implements a Heart Rate service. | |
| CustomProtocolDevice | Yes | A primary device which uses a single CustomProtocolTask to determine how to run a study on the device. |
Supports specifying the sampling scheme for a DataType, including possible options, defaults, and constraints.
From sampling schemes, matching sampling configurations can be created.
Per data type, only one SamplingConfiguration is ever active on a device.
The sampling configuration to be used is determined on clients in order of priority:
- The sampling configuration, if specified in the study protocol, of the
Measure.DataStreamin the last triggered activeTaskConfiguration. Once a task stops, it is no longer "active". - The default sampling configuration, if specified in the study protocol, for the
DeviceConfiguration. This can be retrieved throughPrimaryDeviceDeploymenton the client. - The default sampling configuration hardcoded in the
Sensorssampling schemes of the concreteDeviceConfiguration, if none of the previous configurations are present.
Some sampling schemes support specifying a different sampling configuration depending on how much battery is left, indicated by the "Battery-aware" column. These extend from BatteryAwareSampling.
| Class | Battery-aware | Description |
|---|---|---|
| AdaptiveGranularitySampling | Yes | Specify a desired level of granularity at which to measure depending on the battery level. |
| GranularitySampling | Specify a desired level of granularity, corresponding to expected degrees of power consumption. | |
| IntervalSampling | Specify a time interval in between subsequent measurements. | |
| NoOptionsSampling | Does not allow any sampling configuration. |
| Class | Description |
|---|---|
| BackgroundTask | Specifies that all containing measures and/or output should immediately start running in the background once triggered. |
| CustomProtocolTask | Contains a definition on how to run tasks, measures, and triggers which differs from the CARP domain model. |
| WebTask | Redirects to a web page which contains the task which needs to be performed. |
| Class | Description |
|---|---|
| ElapsedTimeTrigger | Triggers after a specified amount of time has elapsed since the start of a study deployment. |
| ScheduledTrigger | Trigger using a recurring schedule starting on the date that the study starts, specified using the iCalendar recurrence rule standard. |
| ManualTrigger | Initiated by a user, i.e., the user decides when to start a task. |