Units for PnPSA

Goals for the extension⚓

Support for units with square and cubic roots, like nV/√Hz, needed as bandwidth-related noise unit
Support all SI measures (here: mol)
Support for non-decimal unit multiples, needed for minutes, hours, and days
Support for human-readable, non-standard units using advanced rendering capabilities, like Nm³/h or

Nm³
h
(this example: cubic meters per hour at Nominal air pressure)

Nm³
h

Extension Proposal⚓

Units with square and cubic roots⚓

The low nibble of Unit() should support:

SI linear, half exponents
SI rotation, half exponents
Imperial linear, half exponents
Imperial rotation, half exponents
SI linear, 1/3 exponents
SI rotation, 1/3 exponents
Imperial linear, 1/3 exponents
Imperial rotation, 1/3 exponents

The highmost nibble of Unit() should encode exponents of mol.

Examples⚓

See table for development of nV/√Hz:

Unit code (hex)	Unit Exponent (hex)	Representation	Notes
00F0D121	7	V	The usual unit code
00E0A245	7	V	This is a possible but forbidden unit code, all exponents are even
00E0B245	7	V/√Hz (= V√s)	one exponent (for s) is odd
00E0B245	E	nV/√Hz	10^-9 multiplied

Non-decimal unit multiples⚓

The available bytes of Unit Exponent() should be used as follows:

0 (LSB)	10^x, -8 ≤ x ≤ 7	unchanged
1	2^x, -8 ≤ x ≤ 7	new
2	3^x, -8 ≤ x ≤ 7
3 (MSB)	5^x, -8 ≤ x ≤ 7

Beneath adding support for low prime numbers, this extension enables for decimal factors more than 10^-8 to 10⁷. Now the range is 10^-16 to 10¹⁴.

Note that USB HID documentation is not clear for negative numbers! (Nibbles or bytes are used?)

Examples⚓

See this table for development of m³/h

Unit code (hex)	Unit Exponent (hex)	Representation	Note
F031	0	cm³/s	base unit
F031	6	m³/s	10⁶ multiplied
F031	00FEFE04	m³/h	3600 divided

Human-readable units⚓

Those units are only needed to be sent by the device if there are non-standard. The client software should always decode usual units by itself. See appendix for a list that are mantadory for the client.

Units are stored as String Descriptor in Unicode. The device should deliver different versions of the unit in one string for some different usages! Unit strings must not contain delimiting characters.

The reference to a unit descriptor is done with a new global or local item. (To be defined!)

prefix character	type	usage	mantadory?
none	Unicode representation	saving into unicode-text files, visual representation	yes
U+1	plain ASCII	saving into non-unicode-text files	yes if Unicode representation contains character codes ≥ U+80
U+2	Unicode with HTML	visual representation	no
U+3	Unicode with RTF
U+4	Unicode with TeX

Units should not be language specific. But it's free for the firmware to use LCIDs for picking a culture-specific unit.

Examples⚓

How units are saved into local-codepage text files⚓

Local codepages often support some Unicode characters, e.g. ² or ³. In this case, writing Nm³/h in its ASCII representation Nm^3/h doesn't lead to be a good solution.

The client application first converts the Unicode representation using WideCharToMultiByte(CP_ACP) or similar, and checks for conversion errors. If so, the application uses the ANSI representation, otherwise, it uses the conversion result.

The usual case for Western code pages is the Ω sign which is then saved as Ohm. For greek and far-east users, Ω is available and used for writing.

Appendix⚓

Mantadory known units for any client⚓

Unit code (hex)	Unit Exponent (hex)	Representation
1001	0	s
00F0D121	7	V

To be continued!