Input¶

The input block defines all hardware inputs such as sensors or the microphone used in the experiment.

<phyphox version="...">
    ...
    <input>
        <sensor type="pressure">
            <output component="x">Pressure</output>
        </sensor>
        <sensor type="accelerometer" average="true" rate="0.5">
            <output component="x">AccX</output>
            <output component="y">AccY</output>
            <output component="z">AccZ</output>
            <output component="t">AccT</output>
        </sensor>
        <audio rate="48000">
            <output>recording</output>
        </audio>
    </input>
    ...
</phyphox>

Input module: audio¶

The audio tag defines audio as a data source (i.e. a microphone). Phyphox will record continuously and write the recording to the buffer at the beginning of an analysis execution (see analysis block). The target buffer is defined with a simple output-tag.

<audio rate="INTEGER" append="BOOLEAN">
    <output component="out">BUFFER</output>
    <output component="rate">BUFFER</output>
</audio>

Attributes

rate: The recording rate in Hz. This attribute exists for specific needs on a specific device: supported recording rates are very device specific, so do not change the default of 48 kHz in an experiment that targets a wide audience. The platforms also enforce a changed rate differently. Android uses the requested rate exactly and refuses to load or start the experiment if the device does not support it. iOS only requests it as a preference and silently records at whatever rate the hardware chooses - read the actual rate from the rate output and use that for any calculation with a time base. On iOS, if the experiment also contains an audio output, the output's rate takes precedence and this attribute is ignored.; optional, integer in Hz, default: 48000
append: Append data to the output data container instead of only offering new data since the last analysis cycle.; added in 1.16 optional, boolean, default: false

Outputs

Each <output> names the data container receiving one component, selected with component. A tag without component fills the first component.

out: The recorded audio samples. This is the component a tag without a component attribute fills.; required
rate: The rate the device actually recorded at. On iOS this is not guaranteed to be the rate you requested, since the requested rate is only a preference to the system; on Android it always matches the request, because an unsupported rate is an error. Use this value for any calculation with a time base. It is written independently of the recording output - mostly when the rate changes, which normally only happens if the audio setup changes - so do not clear this data container while reading it.; added in 1.6

Input module: bluetooth¶

The bluetooth block defines an input from a Bluetooth Low Energy device. Please refer to the documentation on the Bluetooth Low Energy interface in phyphox for details.

<bluetooth name="STRING" uuid="STRING" mode="STRING" rate="FLOAT"
           subscribeOnStart="BOOLEAN" autoConnect="BOOLEAN" address="STRING"
           id="STRING" mtu="INTEGER">
    <output char="STRING" extra="STRING" conversion="STRING" offset="INTEGER"
            repeating="INTEGER" length="INTEGER" decimalPoint="STRING"
            separator="STRING" label="STRING" index="INTEGER">TEXT</output>
    <config char="STRING" conversion="STRING">TEXT</config>
</bluetooth>

Input module: camera¶

Get data from the phone's camera(s). At the time of phyphox file format 1.19 (phyphox 1.2.0) this data is photometric data, but this is expected to be expanded in the future.

Photometric measurements¶added in 1.19

When feature is set to "photometric" (the default if you omit this attribute), you can collect various photometric properties from a stream of camera frames. For each frame you will get a single value like luminance or hue. The coordinates x1, y1 and x2, y2 mark a rectangle from the camera image (ranging from 0 to 1 from one edge of the image to the other) that is taken into account to calculate the value.

The remaining attributes control the exposure settings of the camera. auto_exposure can enable or disable automatic exposure adjustments to adapt the brightness. This auto exposure does not use the phone's internal auto exposure, but is an implementation within phyphox that can be set to use a specific aeStrategy. These strategies determine whether the auto exposure should prefer framerate over the ideal exposure or whether it should avoid overexposure more aggressively.

The camera input is typically used together with a camera-gui view element (see view elements), which shows a preview and allows the user to adjust x1, x2, y1 and y2 along with auto exposure, exposure settings or zoom. In this case, the values set here are just the initial values.

The framerate of your measurement will depend on your phone's camera. Different cameras on the same phone can have different framerates and the exposure setting can also reduce the framerate if the exposure time (shutter speed) is longer than the duration of a frame. This could be a reason to lock the shutter_speed, but in most scenarios the better solution is using an auto exposure strategy aeStrategy for this.

The photometric properties are calculated on the GPU, so keeping up a high framerate is not limited by processing power on most phones.

<camera x1="FLOAT" x2="FLOAT" y1="FLOAT" y2="FLOAT" auto_exposure="BOOLEAN"
        aeStrategy="STRING" aeFPSTarget="FLOAT" locked="STRING"
        feature="STRING">
    <output component="t">BUFFER</output>
    <output component="luma">BUFFER</output>
    <output component="luminance">BUFFER</output>
    <output component="hue">BUFFER</output>
    <output component="saturation">BUFFER</output>
    <output component="value">BUFFER</output>
    <output component="shutterSpeed">BUFFER</output>
    <output component="iso">BUFFER</output>
    <output component="aperture">BUFFER</output>
    <output component="pixelPosition">BUFFER</output>
</camera>

Attributes

x1

Left edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.4

x2

Right edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.6

y1

Top edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.4

y2

Bottom edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.6

auto_exposure

Determines whether auto exposure is enabled after loading the experiment. This is not the phone's internal auto exposure but an implementation within phyphox, which follows the strategy set by aeStrategy.

optional, boolean, default: true

aeStrategy

What phyphox's auto exposure should optimize for.

mean: Aims for a mean luma of 0.5 over the selected area. Exposure times shorter than the frame duration are preferred, so ISO is raised first, but in a dark scene the exposure can go to 1/15 s, which limits the frame rate considerably.
avoidOverexposure: Like avoidUnderexposure, but darkens the image when bright pixels approach overexposure.
avoidUnderexposure: Like mean, but brightens the image when individual pixels are particularly dark, even if the mean luma then exceeds 0.5.
prioritizeFramerate: Like mean, but never exposes for longer than the frame duration at the highest frame rate the camera supports, accepting underexposure to keep that rate. See aeFPSTarget.

optional, one of mean, avoidOverexposure, avoidUnderexposure, prioritizeFramerate, default: mean

aeFPSTarget

Sets a target framerate when using aeStrategy prioritizeFramerate. If this is not set, prioritizeFramerate defaults to the shortest supported frame duration (the inverse of the maximum framerate). If it is set, the target FPS acts as a maximum exposure time to at least achieve the set FPS. It does not prevent the camera from going above the target FPS.

added in 1.20 optional, float, default: 0.0

locked

A comma-separated list of camera settings to hold fixed, which also blocks them in the camera-gui interface so the user cannot change them. Each can also be set to a specific value with an equals sign followed by a floating point value, and fractions may be used: locked="iso" prevents the user from changing the ISO value, locked="iso=1600" also sets it, and locked="iso=100,shutter_speed=1/240" locks the camera to ISO 100 with an exposure time of 1/240 s. The available locks are shutter_speed, iso, exposure, aperture and, since file format 1.20, focus_distance. Be aware that the same settings have very different results on different phone models. Aperture is not supported on iOS, as no iPhone has an adjustable aperture, and it is untested on Android where it is also rare. exposure is the exposure value used by the simplified exposure control of the camera-gui element. focus_distance disables auto focus and fixes the focus distance, given in meters, with zero meaning focus at infinity.

optional, default: empty

feature

Determines the kind of camera analysis this input performs.

photometric: One value per frame - luma, luminance, hue, saturation or value - averaged over the selected area.
spectroscopy: A spectrum per frame, taken across the selected area. Only the luminance output receives the spectrum, paired with the pixelPosition output; no other component carries spectral data.

optional, one of photometric, spectroscopy, default: photometric

Outputs

Each <output> names the data container receiving one component, selected with component.

t: Timestamp of the frame.
luma: Luma - non-linear brightness relative to the image's color range - of the selected area, in the range from 0 to 1.
luminance: Relative luminance in arbitrary units. This is linearized (gamma corrected) and adjusted for the exposure parameters such that the value 1 represents a white image when the camera is set to ISO 100, a shutter speed of 1/60 s and an aperture of f/1.
hue: Hue according to the HSV color model, ranging from 0 to 360 degrees. Note that this is a cyclic average of the pixels in the selected area.
saturation: Saturation according to the HSV color model, ranging from 0 to 1.
value: Value according to the HSV color model, ranging from 0 to 1.
shutterSpeed: Shutter speed used to take this frame. Note that a change to shutter speed, aperture or ISO does not necessarily take effect immediately - the phone may ramp the setting smoothly or execute it with a delay of a few frames. On individual frames around such a change, this output can therefore mismatch the shutter speed the frame was actually captured with.
iso: ISO value used to take this frame. Like shutterSpeed, this can mismatch on individual frames around a setting change, because the phone may ramp the setting smoothly or execute it with a delay of a few frames.
aperture: Aperture used to take this frame. Like shutterSpeed, this can mismatch on individual frames around a setting change, because the phone may ramp the setting smoothly or execute it with a delay of a few frames.
pixelPosition: Position within the spectrum, for the spectroscopy feature. This output holds exactly as many values as the matching luminance output - the two are written together, so the i-th luminance value belongs to the i-th position. The positions are absolute pixel indices along the dispersion axis of the camera image, so a calibration stays valid when the user moves the selected area.

Input module: depth¶added in 1.14

Get a depth measurement from the depth sensor, which is typically a dedicated optical sensor as part of the camera array. On iOS, this type of sensor is called "LiDAR", while on Android you usually have to look for "ToF". Both systems have very different APIs to access this data with various advantages and drawbacks:

On iOS we access the LiDAR sensor through ARKit, which is the framework for augmented reality applications. The depth data is almost perfectly aligned with the camera image, but it is not raw data from the sensor, but processed and remapped for AR applications. Therefore, the data might have been fused with depth data derived from the normal color camera (for example depth estimation from parallax effects). Most current iOS devices also feature a depth sensor on the front, which is designed for FaceID. This is often also available on the base models that do not support LiDAR on the back of the phone. However, note that this to our knowledge uses a different technology as it projects a pattern onto a viewers face and might therefore not be suitable for some physics experients.

On Android we decided against using ARCore, Google's augmented reality framework, as a more direct API is available and dependencies on Google Services could be avoided in favor of platforms that do not have Google support. Here we use the camera2 API to access the sensor data, which has the benefit that we do not expect any fusion with AR data. However, the disadvantage is that the depth data has not been remapped to align with the regular camera image and you will experience an offset, which in particular will depend on the viewing distance as camera and sensor are not in the same lens. The camera2 API allows for accessing front and back facing depth sensors, but be aware that some phones advertise a ToF sensor in their specs for camera autofocus without exposing its data through the camera2 API. (Details on the camera2 API can be found at: https://developer.android.com/reference/android/hardware/camera2/package-summary)

Typically the user selects an area within the camera/depth data (which can be preset using the attributes x1, x2, y1, y2) that is aggregated into one depth value per frame. For each frame a pair of an aggregated depth value "z" and the corresponding timestamp "t" will be returned.

In order to give the user a preview and control over the depth input, you will want to also add a depth-gui view element to the configuration (see the views section).

<depth mode="STRING" x1="FLOAT" x2="FLOAT" y1="FLOAT" y2="FLOAT"
       smooth="BOOLEAN">
    <output component="z">BUFFER</output>
    <output component="t">BUFFER</output>
</depth>

Attributes

mode

Defines how all data points within the selected area are aggregated into one depth value per frame. Note that phyphox automatically drops the lowest confidence value, and that lower confidences typically only appear at edges and represent a small portion of most scenes; the difference between average and weighted should therefore be negligible in most situations.

closest: The data point with the smallest distance to the camera.
weighted: The weighted average, using the confidence data provided by each API.
average: The plain average of all data points in the area.

optional, one of closest, weighted, average, default: closest

x1

Left edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.4

x2

Right edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.6

y1

Top edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.4

y2

Bottom edge of the initial acquisition area, which the user can still modify. The value is a floating point number from 0.0 to 1.0, with 0.0 referring to the left/top edge of the image and 1.0 to the right/bottom edge.

optional, float, default: 0.6

smooth

Applies only to LiDAR on iOS. Chooses ARKit's smoothedSceneDepth over sceneDepth, that is, whether ARKit's own smoothing is used.

The setting chooses between two ARKit frame properties, so there is nothing for Android to apply it to; it is accepted and ignored there.

optional, boolean, default: true, iOS only

Outputs

Each <output> names the data container receiving one component, selected with component. A tag without component fills the first component.

z: The depth value aggregated over the selected area, one per frame.; required
t: Timestamp of the frame the depth value came from.

Input module: location¶

The location block defines an input from the GPS sensor. The data will be written to the output buffers at the rate at which it is provided by the sensor. On Android, the user can select in the experiment menu that location data should come exclusively from satellite navigation (although some unusual implementations may occur), but on iOS we cannot deactivate other sources. Therefore, in most cases on iOS (and Android default settings) the first reading is usually based on the mobile and Wi-Fi networks rather than satellite position systems.

<location>
    <output component="lat">BUFFER</output>
    <output component="lon">BUFFER</output>
    <output component="z">BUFFER</output>
    <output component="zwgs84">BUFFER</output>
    <output component="v">BUFFER</output>
    <output component="dir">BUFFER</output>
    <output component="t">BUFFER</output>
    <output component="accuracy">BUFFER</output>
    <output component="zAccuracy">BUFFER</output>
    <output component="status">BUFFER</output>
    <output component="satellites">BUFFER</output>
</location>

Outputs

Each <output> names the data container receiving one component, selected with component.

lat: Latitude in degrees.
lon: Longitude in degrees.
z: Altitude in meters above mean sea level, using the EGM84 geoid as reference. Note that the altitude provided by satellite navigation is generally rather imprecise.
zwgs84: Same as z but taking the WGS84 ellipsoid as reference, that is the coordinate system used by GPS (this quantity is also known as the ellipsoidal height). Note that the Android API provides the altitude above the WGS84 ellipsoid while the iOS API provides the altitude above the EGM84 geoid. Phyphox calculates the difference using a port of GeographicLib's algorithm with a 30' resolution EGM84 dataset.
v: Speed in m/s, provided by the system based on consecutive GPS fixes.
dir: Direction in degrees, counted from north towards east, determined by the system along with the speed.
t: Experiment time in seconds since the start of the experiment for this location, as set by the operating system.
accuracy: An estimate by the system of the horizontal accuracy in meters.
zAccuracy: An estimate by the system of the vertical accuracy in meters. Android provides this since Android 8; on older devices phyphox writes 0, which is also what Android reports when no estimate is available. On iOS a negative value means that the altitude is invalid.
status: -1 means that GPS is unavailable (usually deactivated by the user), 0 means that it is searching for a signal, 1 means that it is active. Note that this value is updated independently from the other outputs.
satellites: Number of satellites used for this measurement. iOS does not make this information available to apps, so on iOS this output is always -1.

Input module: sensor¶

The sensor block defines a sensor as an input. The data will be written to the output buffers at the rate at which it is provided by the sensor. Alternatively, you may define a different rate, in which case the latest reading is picked at the given rate. In addition you may turn on averaging in combination with the forced rate, in which case all data during the interval of the rate is averaged and only the average is written to the buffer. The exact strategy to achieve the target rate can be defined by the parameters rateStrategy and stride. Please see details about this in the explanation of these parameters and note that these have been introduced with a behavior change in file format 1.14 (phyphox 1.1.10).

The outputs are mapped to data-containers by simple output-tags. Each requires a component attribute to map the data to the data-container.

Note that the somewhat cumbersome names for "acceleration with g" and "acceleration (without g)" have been chosen to aid students in understanding the data given by these sensors. But internally we stick to the names commonly used on Android, "accelerometer" and "linear_acceleration". Usually, "accelerometer" (the one with g) is a physical sensor which measures the acceleration force applied to a sample mass (in the form of a MEMS device), so it will give a constant acceleration of 9.81 m/s² for a resting device (hence our descriptive name "with g"). In contrast, "linear_acceleration" is usually just a virtual sensor, which may use additional sensors to remove the earth's acceleration (hence our descriptive annotation "without g") to report the actual acceleration of the phone in the reference system of the user. So "linear_acceleration" will report zero acceleration when the phone is at rest or moving at a constant speed.

<sensor type="STRING" rate="FLOAT" rateStrategy="STRING" average="BOOLEAN"
        stride="INTEGER" ignoreUnavailable="BOOLEAN" nameFilter="STRING"
        typeFilter="INTEGER">
    <output component="x">BUFFER</output>
    <output component="y">BUFFER</output>
    <output component="z">BUFFER</output>
    <output component="t">BUFFER</output>
    <output component="abs">BUFFER</output>
    <output component="accuracy">BUFFER</output>
</sensor>

Attributes

type

Defines the sensor type to be used. Note that the somewhat cumbersome names for "acceleration with g" and "acceleration (without g)" have been chosen to aid students in understanding the data given by these sensors, while internally the names commonly used on Android are kept.

accelerometer: The accelerometer in m/s². This gives the earth's acceleration when the device is resting. (Usually named "acceleration with g" in phyphox)
linear_acceleration: A virtual sensor giving the actual acceleration of the device. Should report zero when the device is resting. (Usually named "acceleration (without g)" in phyphox)
gravity: A virtual sensor giving the gravitational acceleration in the frame of reference of the device. This removes the device motion from the accelerometer readings and should therefore be approximately the difference of accelerometer and linear_acceleration. (Depending on the implementation on each device.) Available since file format 1.15.
gyroscope: Readings from the gyroscope in rad/s.
magnetic_field: Readings from the magnetometer in µT.
pressure: The air pressure from the barometer in hPa.
light: The illuminance from the light sensor in lx.
proximity: Distance from the proximity sensor in cm (most devices only output 0 cm or 5 cm).
temperature: Temperature. This is supposed to be ambient temperature, but there is some fallback logic to find any temperature reading from the device. This usually represents the device temperature and cannot be used for external temperature measurement. In °C. Available since file format 1.7.
humidity: Relative humidity in %. Available since file format 1.7.
attitude: The orientation (absolute rotation) of the device as calculated by the device's own algorithms. This uses TYPE_ROTATION_VECTOR on Android and CMAttitude from Core Motion on iOS, which (depending on the device) fuses data from the accelerometer, gyroscope and magnetometer to calculate the attitude of the device. The result is given as a quaternion in a reference system with y pointing towards magnetic North and z pointing upwards (the Android coordinate system, iOS attitude is converted to this system). The x, y and z channels correspond to the last three components of the quaternion (w, x, y, z) and w can be retrieved through the abs channel. Available since file format 1.9.
custom: Use typeFilter and/or nameFilter to use a sensor that is not directly supported by phyphox. You can check the device info (i menu on the main screen) to see which sensors are available on your phone. Phyphox will pick the first sensor with a type that matches the typeFilter (if set) and a name that contains the value of nameFilter (not case-sensitive, only if set). Note that not all sensors will work properly with phyphox, especially if they do not generate values but events or states. Available since file format 1.19.

required, one of accelerometer, linear_acceleration, gravity, gyroscope, magnetic_field, pressure, light, proximity, temperature, humidity, attitude, custom

rate

The rate at which sensor data will be provided in Hz. A value of 0.0 means "as fast as possible". Note that the maximum rate of a sensor is device-specific and will limit the rate that can be achieved.

optional, float in Hz, default: 0.0

rateStrategy

Defines the strategy to achieve the rate set with the attribute rate.

auto: Requests the target sensor rate directly from the system like the strategy request. If the actual rate provided by the system is more than 10% faster than the requested rate, the strategy automatically switches to generate, delivering the data points exactly at the desired rate. This strategy prevents duplicate data points as neither strategy can be faster than what the sensor provides, and it picks the ideal method to get close to the target rate. However, in cases when it has to switch to generate it is susceptible to strong sampling effects when the target rate is close to the actual sensor rate.
request: The target rate set by rate is directly requested from the system and the provided sensor data will be provided as is. It depends on the system whether the provided rate is close to the requested one; the system might not be able to provide sensor data at given rates or it might decide to provide a different rate if the sensor data is shared with other apps. This strategy is most likely to yield a rate that strongly differs from the expected one, but as it will not group or discard data points, it will not introduce additional sampling or aliasing effects. For the same reason, the average attribute has no effect.
generate: The target rate is generated internally by phyphox while requesting the highest possible rate from the system. It is guaranteed to give data points at the rate set by rate and can even exceed the sensor rate (be careful not to waste performance with this). While the resulting data points seem very easy to interpret afterwards and while it makes it easy to synchronize different sensors, this strategy can severely degrade the recorded sensor data as data points might be duplicated or discarded in unforeseen patterns. If the target rate is close to the actual internal sensor rate, this will very likely introduce additional sampling effects like aliasing between the sensor's sample rate and this target rate. Therefore, this strategy is recommended for educational purposes to simplify data analysis, but if you know how to analyze data and want the best possible data quality, it is highly recommended to use the request strategy instead, as you can emulate the generate strategy in your data analysis later but you could not go back to the quality of request from generate data.
limit: The maximum sensor rate is requested from the system and the setting of rate is used as a limiter. More precisely, phyphox generates a new data point whenever the time interval from the last data point to the latest sensor event exceeds 1/rate. The resulting rate will always be close to but lower than the requested rate and the actual rate strongly depends on the actual sensor rate. This strategy is a compromise to get close to a target rate without the strong degradation introduced by the generate strategy, as it usually leads to a similar number of sensor events per actually generated data point. The downside is that the data point rate may be quite different on different devices if the target rate is in the range of typical sensor rates. Note that this was the only rate strategy before file format 1.14, and that this is the default behavior if your phyphox file targets a file format before 1.14.

added in 1.14 optional, one of auto, request, generate, limit, default: auto from file format 1.14, limit below that

average

If set to true, instead of just giving the latest reading at the defined rate, the sensor data will be averaged over a period of the rate. This only makes sense if a rate is set which is lower than the maximum rate the device can achieve.

optional, boolean, default: false

stride

If stride is set to N, only every Nth data point generated by the rateStrategy is used. Other data points are simply discarded. A stride of 1 will use every data point, a stride of 2 only every second, a stride of 3 only every third and so on. This is mostly useful to achieve a very specific data rate on a specific device that is an integer fraction of the actual sensor rate, in order to avoid additional aliasing effects from non-fractional rates.

added in 1.14 optional, integer, default: 1

ignoreUnavailable

Allow the user to open and start the experiment even if the sensor is not available. You will not receive any data for that sensor if it is not available, and your experiment should still work and make sense for the user if this is the case. Without it, an experiment using a sensor the device does not have notifies the user and refuses to work.

added in 1.8 optional, boolean, default: false

nameFilter

Selects a specific sensor by name where a device exposes several of the same type, used with type="custom". Phyphox picks the first sensor whose name contains this value, which is not matched case-sensitively.

The attribute has no effect on iOS: CoreMotion offers no equivalent choice, so it is ignored there. The file still loads.

added in 1.19 optional, Android only

typeFilter

Selects a sensor by Android sensor type constant, used with type="custom". Phyphox picks the first sensor whose type matches.

added in 1.19 optional, integer, Android only

Outputs

Each <output> names the data container receiving one component, selected with component.

x: First component of the sensor reading. Many sensors (accelerometer, magnetometer, gyroscope) are 3D sensors writing to x, y and z; 1D sensors such as the barometer and the light sensor only fill x. You do not need to attach a data container to every output.
y: Second component of a 3D sensor reading.
z: Third component of a 3D sensor reading.
t: Experiment time of the reading, in seconds since the measurement started.
abs: The absolute value sqrt(xx + yy + z*z) of 3D sensor data. For the attitude sensor this is the w component of the quaternion instead.; added in 1.4
accuracy: Information about the current accuracy. Typically -1 means that the sensor is uncalibrated (which might be an error state), 0 means that uncalibrated raw data is presented (but this is expected) and positive values represent accuracy in a way specific to the sensor. This is currently only used by the magnetometer, which encodes its accuracy as 1 low, 2 medium and 3 high.; added in 1.5