phydat units: Align with SenML

[chrysn]

Description

SenML is maintaining a good list of IoT base units at https://www.iana.org/assignments/senml/senml.xhtml (along with secondary units that are affine transformations of the base units).

Phydats unit list is a much more unmanaged (literally "extend this list as needed") collection contains many of these, but unlike SenML contains no guidance as to which are preferred, and worse, has no well-described way of getting the types out to interoperate. (phydat_unit_to_str{,_verbose} do not claim compliance with any scheme).

Proposed way forward

• Sort units as they are in SenML, document correspondence, and document preferences. (A marker enum entry could make it possible to read where which section start or ends).
• Provide a function like phydat_unit_to_str that maps precisely to a SenML name if one is defined.
• Migrate producers of non-base units to produce the base units where sensible.
• Consider deprecating phydat units that don't fit in.

Links

• https://github.com/RIOT-OS/RIOT/pull/17569 triggered this
• This would likely simplify https://github.com/RIOT-OS/RIOT/pull/16384 -- partially in conversion (no need to list which units are SenML compatible, they'd be annotated), but also because some conversions could be skipped (if some phydat units are deprecated, not converting them becomes an option)

[chrysn]

@silkeh, given you've worked a lot in this area, I'd appreciate your input on this. In particular, do you think it'd make sense to pull all defined SenML units into phydat? (For #16384 that could allow unifying these types, and would make the currently big-switch-statement list of which phydat units have a corresponding SenML unit a simple if (unit < UNIT_END_SENML)).

[silkeh]

do you think it'd make sense to pull all defined SenML units into phydat?

Yes, I think that makes a lot of sense to follow the standardized SenML unit list. It both clarifies the use of the units in RIOT OS, and greatly improves the maintainability of the SenML code. The proposed way forward seems sensible to me as well.

As for deprecating/migrating units: the complexity of this varies:

• UNIT_DATE, UNIT_TIME and UNIT_TEMP_F seem to be unused.
• UNIT_BAR, UNIT_GPM3 and UNIT_GS are used but can be converted using an adjustment of scale.
• UNIT_G needs a multiplication using gravitational acceleration.
• UNIT_CPM3 (count per cubic meter, used in sps30 and hm330x) and UNIT_DPS (degree per second, used in various sensors) are used and have no base unit equivalent.

[chrysn]

Thanks.

g and F probably both can go into the bucket of bar, g/m³, Gs by being non-SenML units but having known affine transformations to primary units, and could become secondary units if anyone went through the IANA procedure. (Not a fan of F, but I can see how g is somewhat practical around accelerometers).

The CPM (/m³) and DPS (°/s) could probably even become primary and secondary units, respectively (the latter for rad/s).

Given #16384 is in rather good a shape and approaching completion, I for one would hold off on actually tackling this until that's in, unless you prefer it the other way 'round.

[silkeh]

Ok, so for a migration to the SenML units, I think we would need the following SenML primary units:

Symbol	Description	Type
1/m3	1 per cubic meter	float
rad/s	radian per second	float

And the following secondary units:

Symbol	Description	SenML Unit	Scale	Offset
deg/s	degree per second	rad/s	π/180	0
g-force	gravitational force equivalent	m/s2	9.80665	0

We could request bar, gram/m³ or gauss as secondary units, but I think it makes more sense to convert these to pascal, kg/m³ and tesla within RIOT-OS itself. Fahrenheit is not used, so I would propose to remove it entirely.

I'm open for suggestions for something better than g-force.

[chrysn]

Thanks, good split; two remarks:

• The 9.8 is precisely 9.80665 as specified in ISO 80000-3 (allegedly, that's what the wikipedia article says but I trust the designated experts have a copy of that around)
• The deg/s might be a bit trickier that I hoped, because the registry definition talks of "rational number[s], expressed in decimal (optionally, with a decimal exponent given) or as a fraction represented using a "/" character to separate numerator and denominator". I hope that the designated experts treat this as an oversight on the side of the RFC and accept it in; if not, deg/s will stay in a class of "secondary units private to us but we can convert them" together with Gauss.