More complex units definition

[j123b567]

It is currently needed to expand all possible units, prefixes and suffixes.

It will be nice functionality to implement separate definitions of prefixes, separate definitions of suffixes, separate definition of units and connect it somewhare together.

[j123b567]

Temperature units would require a linear conversion, so a multiplication and an addition.

This is true, but it is very simple to define new unit "fahrenheit". You then implement ParamTemperature on your own and do the conversion yourself. In your function, there must be also specified, what is default unit for temperature. So if the user send command with parameter "20", is it "20 °F", "20 °C" or even "20 K"?

Logarithmic units often used for signal power in spectrum analyzers would require logarithmic operations.

There are two problems:

• definition of logarithmic units using dB prefix, there are also suffixes RMS, PP, ... and this make everythink more complex
• do we always need the real value? If I specify some RF parameter in dBm and friends, isn't it better to leave it in dBm for some internal calculations in the instrument?

[jeras]

Here I added units for angle (phase) it is not yet ready for merging, and tests are missing: https://github.com/RedPitaya/scpi-parser/commit/fb6979d1926bb6813898012de934eca366d93ff8

For now I used the quantity in the enumeration name in types.h, using the unit name seemed a bit strange, since unit names for angle do not have much in common.

Did you have in mind a SCPI_Result* function, which would accept a unit and recalculate the value before printing it?

I will have a look at the source to see if I can do this LOG/MUL/SUM unit recalculation without too much trouble. The inverse operation of log might not be obvious. If the base unit is not linear, POW should also be available.

Regarding a use case, the user might wish to define the output amplitude of a signal generator in volts of decibel, depending on what is beeing measured.

[j123b567]

Here I added units for angle (phase) it is not yet ready for merging, and tests are missing: https://github.com/RedPitaya/scpi-parser/commit/fb6979d1926bb6813898012de934eca366d93ff8

For now I used the quantity in the enumeration name in types.h, using the unit name seemed a bit strange, since unit names for angle do not have much in common.

I prefer name of unit over name of measure.

For everyone, base unit is different. Everyone in continental europe will use meter for distance, but everyone in US will use inches, etc. For me (european), "1 distance" will be 1 meter, but somebody in US will presume, that "1 distance" is "1 inch" and it is wrong approach. If the enumeration name will be SCPI_UNIT_METER, everything is clear for everyone.

It is the same as "1 ANGLE". What does it mean? I think, that it is common to use "radian" or "degree". After looking into units.c I see, that it is "1 radian". So I prefer naming everything by its right name - SCPI_UNIT_RADIAN, SCPI_UNIT_DEGREE. If you are mathematician, you will prefere radians, but if you are engineer, you may prefer degrees or revolutions.

There is problem with "MIN" and "SEC", because it can colide with time.

Did you have in mind a SCPI_Result* function, which would accept a unit and recalculate the value before printing it?

There is already SCPI_NumberToStr so I can introduce SCPI_ResultNumber to produce what you want. For now with base unit only.

I will have a look at the source to see if I can do this LOG/MUL/SUM unit recalculation without too much trouble. The inverse operation of log might not be obvious. If the base unit is not linear, POW should also be available.

I think, that we can produce some helper functions for conversions, but I don't like the idea of automatic non trivial recalculations while processing of the unit. So having conversion functions for dB, °C/°F, RAD/DEG/REV, etc. is nice, but doing this inside SCPI_ParamNumber is not so ince for me.

We can have table, how to convert some units to other units. This conversion table can support log/exp, multiplication and addition.

Regarding a use case, the user might wish to define the output amplitude of a signal generator in volts of decibel, depending on what is beeing measured.

But I still think, that it is up to developer of the generator, how he internally represent output value. If he prefer dBV, it is his choice. I don't want to force him to use V, so he must recalculate it back to dBV to do some internal calculations.