Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zio: initial channel definitions #14245

Closed
367 changes: 367 additions & 0 deletions include/zio/zio_defs.h
Original file line number Diff line number Diff line change
@@ -0,0 +1,367 @@
/*
* Copyright (c) 2019 Kevin Townsend
*
* SPDX-License-Identifier: Apache-2.0
*/

/**
* @file
* @brief ZIO core API definitions.
*/

#ifndef ZEPHYR_INCLUDE_ZIO_DEFS_H_
#define ZEPHYR_INCLUDE_ZIO_DEFS_H_

#include <zephyr/types.h>

#ifdef __cplusplus
extern "C" {
#endif

/**
* @brief ZIO device channel types.
*
* Each channel kind is associated with a specific SI unit type and scale,
* Expressed as the comments below.
*/
typedef enum zio_dev_chan_kind {
/**
* Raw data channel.
*
* No SI type is prescribed for this channel.
*/
DEV_CHAN_RAW,

/**
* Voltage.
*
* Expressed as volts (V).
*/
DEV_CHAN_VOLTAGE,

/**
* Current.
*
* Expressed as milli-amps (mA).
*/
DEV_CHAN_CURRENT,

/**
* Resistance.
*
* Expressed as ohms.
*/
DEV_CHAN_RESISTANCE,

/**
* Capacitance.
*
* Expressed as picofarad (pF).
*/
DEV_CHAN_CAPACITANCE,

/**
* Inductance.
*
* Expressed as microhenries (uH).
*/
DEV_CHAN_INDUCTANCE,

/**
* Impedance.
*
* Expressed as ohms (Z).
*/
DEV_CHAN_IMPEDANCE,

/**
* Frequency.
*
* Expressed as Hertz (Hz).
*/
DEV_CHAN_FREQUENCY,

/**
* Generic temperature.
*
* Expressed as degrees celcius (C).
microbuilder marked this conversation as resolved.
Show resolved Hide resolved
*/
DEV_CHAN_TEMP,
Copy link
Collaborator

@avisconti avisconti Mar 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to have 3 types of temperature?
Aren't DIE and AMBIENT enough?
I'm not against it. Just want to understand the reason.
Maybe we could have only two types: AMBIENT and GENERAL. The DIE case would fall into the GENERAL case. Or maybe we can keep it this way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many sensors out there include temperature measurement, but it's often only of the die so of less use to the outside world, and I guess I just wanted to clearly distinguish die temp (which could me many degrees different than ambient temp or the same measurement on another IC), from ambient which is device nuetral and closer to what people want, without ignore the need to sometimes track die temp for either generating appropriate offets for the sensor data, or for safety reasons.

The third (first?) generic temp entry -- DEV_CHAN_TEMP -- is basically for anything that isn't the two most common cases of DIE or AMBIENT, and you could then define exactly what that is via attributes (water temperature, heating-element temperature, whatever).

I'm open to change this, just trying to explain the reasoning in my own head!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many sensors out there include temperature measurement, but it's often only of the die so of less use to the outside world, and I guess I just wanted to clearly distinguish die temp (which could me many degrees different than ambient temp or the same measurement on another IC), from ambient which is device nuetral and closer to what people want, without ignore the need to sometimes track die temp for either generating appropriate offets for the sensor data, or for safety reasons.

Yes, I agree.
Actually if you see the history of commits of the current sensor.h you'll see that I'm the one that separated the two temperature types. So, yes, I agree with this part.

The third (first?) generic temp entry -- DEV_CHAN_TEMP -- is basically for anything that isn't the two most common cases of DIE or AMBIENT, and you could then define exactly what that is via attributes (water temperature, heating-element temperature, whatever).

I'm open to change this, just trying to explain the reasoning in my own head!

I was in fact more questioning about this third type.
We can keep it, I'm not against it. Maybe it is more clear like that, but we cannot have as many
temperatures definition as are out there. So, I was thinking to have only two types: AMBIENT and TEMP which means other non ambient. But, again, maybe this way it is clearer.


/**
* Ambient temperature.
*
* Expressed as degrees celcius (C).
*/
DEV_CHAN_TEMP_AMBIENT,

/**
* Die temperature.
*
* Expressed as degrees celcius (C).
*/
DEV_CHAN_TEMP_DIE,

/**
* Single-axis acceleration.
*
* Expressed as meters per second squared (m/s^2).
*/
DEV_CHAN_ACCEL,

/**
* Three-axis (XYZ) acceleration.
*
* Expressed as meters per second squared (m/s^2).
*/
DEV_CHAN_ACCEL_VECTOR,

Copy link
Collaborator

@avisconti avisconti Mar 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the number of axis should be specified in a different parameter.
The channel type should be always ACCEL (or GYRO or MAGN).
So, no need for a different type. Does it make sense to you?

Copy link
Member Author

@microbuilder microbuilder Mar 19, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does and I'm not in love with the concept of vector, my concern is that with sensor fusion you often want to be sure that the three values come from the same sample or conversion process, and if you have three different channels for X+Y+Z, you need to add a means to associate those values with each other, which becomes more code to validate.

The need to group multiple channels will come up elsewhere, of course, such as in light sensors with multiple photo diodes, each with their own channel, though that takes the approach of having a single channel per photodiode and the attributes fill the details in.

How would you see the problem of needing to keep X/Y/Z related to each other so that you don't get X+Y from one conversion, but Z from the next?

Copy link
Collaborator

@avisconti avisconti Mar 19, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you see the problem of needing to keep X/Y/Z related to each other so that you don't get X+Y from one conversion, but Z from the next?

I need to see more carefully the example of Google CHRE, where they define the sensor type as ACCEL or GYRO or MAGN only, but also define in the sensor property the number of axis supported by the sensor (One of SINGLE, TRIPLE, EMBEDDED, with latter one used for temp/baro/humidity/stepc and so on).

Then a sensor when generates samples enqueue above them as events, and a general task would consume them. This is different from how zephyr works now where samples are pulled from above and not pushed from below as events.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have some suggestions here, it will never be easier than now to make the right decisions and tradeoffs!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sure.
I'll try to get back to this asap.

/**
* Single-axis magentic field measurement.
*
* Expressed as micro-Tesla (uT).
*/
DEV_CHAN_MAG,

/**
* Three-axis (XYZ) magnetic field measurement.
*
* Expressed as micro-Tesla (uT).
*/
DEV_CHAN_MAG_VECTOR,

/**
* Single-axis angular momentum.
microbuilder marked this conversation as resolved.
Show resolved Hide resolved
*
* Expressed as radians per second (rad/s).
*/
DEV_CHAN_GYRO,

/**
* Three-axis (XYZ) angular momentum.
*
* Expressed as radians per second (rad/s).
*/
DEV_CHAN_GYRO_VECTOR,

/**
* Irradiance, which is the measurement of radiant flux (analagous to
* 'power' or 'intensity') received on given surface area.
*
* Expressed as watts per square meter (W/m^2).
*/
DEV_CHAN_LIGHT_IRRAD,

/**
* Irradiance in the visible light range (nominally 380-780 nm).
*
* Expressed as watts per square meter (W/m^2).
*/
DEV_CHAN_LIGHT_IRRAD_VIS,

/**
* Irradiance in the ultaviolet range (nominally <380 nm).
*
* Expressed as watts per square meter (W/m^2).
*/
DEV_CHAN_LIGHT_IRRAD_UV,

/**
* Irradiance in the infrared range (>780 nm).
*
* Expressed as watts per square meter (W/m^2).
*/
DEV_CHAN_LIGHT_IRRAD_IR,

/**
* Irradiance limited to a specific spectral component. The exact
* wavelength or wavelength range of the component should be
* indicated with an appropriate channel attribute.
*
* Expressed as watts per square meter (W/m^2).
*/
DEV_CHAN_LIGHT_IRRAD_COMP,

/**
* An approximation of human vision, which is the result of a
* conversion from irradiance (a radiometric unit expressed in
* W/m^2) to illuminance (a photometric unit expressed in lumen/m^2)
* by means of a version of the CIE luminous efficiency function.
*
* ?PTE: More technically, this channel should probably be named
* `ILLUMINANCE`, but `LUX` is used as present since it is
* a significantly more familiar concept to most people.
*
* Expressed as 'lux', or more precisely lumens per square meter.
*/
DEV_CHAN_LIGHT_LUX,

/**
* Relative humidity. Indicates the amount of water vapor in the air,
* relative to the maximum amount of water vapor that could exist in
* the air at the current temperature.
*
* Expressed as a percentage.
*/
DEV_CHAN_REL_HUMIDITY,

/**
* Latitude in a geo-localisation system.
*
* Expressed as a degree/minute/second notation string.
*/
DEV_CHAN_POS_LATITUDE,

/**
* Longitude in a geo-localisation system.
*
* Expressed as a degree/minute/second notation string.
*/
DEV_CHAN_POS_LONGITUDE,

/**
* The altitude or 'height' of an object or point in relation to an
* unspecified reference level (ground, sea-level, another object,
* etc.)
*
* Expressed in meters.
*/
DEV_CHAN_POS_ALT,

/**
* The altitude or 'height' of an object or point in reference to sea
* level.
*
* Expressed in meters.
*/
DEV_CHAN_POS_ALT_SEALEVEL,

/**
* The altitude or 'height' of an object or point in reference to the
* ground immediately below the point of measurement.
*
* Expressed in meters.
*/
DEV_CHAN_POS_ALT_GND,

/**
* Distance in a straight line (regardless of obstacles) between the
* source of the measurement and a specific reference point.
*
* Expressed in meters (m).
*/
DEV_CHANNEL_POS_DIST,

/**
* Distance in a straight line along the surface of an object (such as
* a sphere) between the source of the measurement and a specific
* reference point.
*
* Expressed in meters (m).
*/
DEV_CHANNEL_POS_DIST_SURF,

/**
* Proximity to an external plane or object.
*
* Expressed in millimeters (mm).
*/
DEV_CHANNEL_POS_PROX,

/**
* Encapsulates a raw NMEA sentence from a GPS-type device
*
* Expressed as a null-terminated string, with the exact string
* contents determined by NMEA standard. NMEA sentences are generally
* limited to 79 characters plus the null-termination character.
*/
DEV_CHAN_POS_NMEA,

/**
* An Euler angle, which consists of the three familiar X/Y/Z
* headings.
*
* Expressed as a 3-vector (XYZ) of degrees.
*/
DEV_CHAN_ORIENT_EULER,

/**
* A quaternion, which is generally used to represent a value in
* three dimensional space, avoiding the problem of gimbal lock
* associated with 3-vector Euler angles.
*
* Quaternions consist of four elements: a 3-vector and a scalar.
*/
DEV_CHAN_ORIENT_QUAT,

/**
* An indication of tilt in degrees on a single axis relative to an
* unspecified reference plane.
*
* Expressed in degrees (+/-180).
*/
DEV_CHAN_ORIENT_TILT,


/**
* Pressure, which is a measurement of the force applied
* perpendicularly to specific surface area.
*
* Expressed in hectopascal (hPa)
*/
DEV_CHANNEL_PRESS,

/**
* Barometric (or 'atmospheric') pressure, which is a measurement of
* the pressure within the atmosphere. Related to the concept of
* 'hydrostatic pressure' caused by the weight of the air above the
* point of measure.
*
* TODO: Would millibar (mb) be a better unit choice, or should this
* remain consist with the more general pressure channel unit (hPa)?
*
* Expressed in hectopascal (hPa)
*/
DEV_CHANNEL_PRESS_BAROM,

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I would keep hPa as unit (which equals mbar btw), just to be consistent with the usual unit.
Would DEV_CHANNEL_PRESS_AMBIENT be a better name?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ambient might actually be a clearer name, yes.

Copy link
Collaborator

@pabigot pabigot Jul 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer DEV_CHANNEL_PRESS_ABSOLUTE and DEV_CHANNEL_PRESS_RELATIVE, and perhaps DEV_CHANNEL_PRESS_GAUGE.

Most pressure sensors, e.g. BME280 or MS5637, produce absolute atmospheric pressure, which would range from about 1068 hPa down to 314 hPa. Others like SDP810 produce relative pressure in a differential application, such as output and return in an HVAC system, which is often on the order of 10-25 Pa (with precision down to cPa) and can be negative.

Gauge pressure would be like a tire pressure sensor: relative to absolute atmospheric pressure.

Terms like "barometric" or "atmospheric" may be interpreted as referring to absolute pressure adjusted for altitude, like you get in weather reports. This can be very different from absolute pressure. Barometric pressure could be a derived measurement, but having a sensor that measures it directly seems pretty unlikely (maybe one built into a GPS). Avoiding those terms might reduce confusion.

As for units: I'd really prefer SI throughout, so Pa. Let the consumer deal with scale conversions.

/**
* Particulate matter.
*
* Expressed as micrograms per cubic meter (ug/m^3).
*/
DEV_CHAN_PART_MAT,

/**
* Generic particulate matter measurement. The exact type of matter
* being measure should be indiciated with an appropriate channel
* attribute.
*
* Expressed as parts per million (ppm).
*/
DEV_CHAN_PPM,

/**
* Detected CO2 levels.
*
* Expressed as parts per million (ppm).
*/
DEV_CHAN_PPM_CO2,

/**
* Detected volatile organic compound (voc) levels.
*
* Expressed as parts per million (ppm).
*/
DEV_CHAN_PPM_VOC,

} zio_dev_chan_kind_t;

/**
* @}
*/

#ifdef __cplusplus
}
#endif

#endif /* ZEPHYR_INCLUDE_ZIO_DEFS_H_ */