E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Missing RDM pararameters (http://www.rdmprotocol.org/forums/showthread.php?t=1069)

este_ July 15th, 2010 09:04 AM

Missing RDM pararameters
I'd like to open this thread and invite everybody to make proposals for missing parameters.

One example would be: Sensors can measure anything from voltage to centigrades (see Table A-13), but displaying a value in % (percent) is simply not possible. UNITS_NONE will not fit, a mfr-specific unit would be a workaround but I feel "percent" is a commonly used "unit". We may want this to be able to display (e.g.) fluid levels (filling level), relative intensity and so on. Also, displaying values in ppm would be available using a suitable prefix.

prwatE120 July 15th, 2010 09:21 AM

I asked for UNITS_PERCENT in the Task group Last year. I'll need to check if it was added as part of the erratta work.

Peter Willis

ericthegeek July 15th, 2010 10:15 AM

Playing devil's advocate for the sake of discussion:

The units in table A-13 "Sensor Unit Defines" are all derived from the SI Base Units (Meters/Kilograms/Seconds). In this system, a percentage is a unit-less value, thus UNITS_NONE is the most technically correct.

A percentage is unit-less because it is the ratio of two values with the same units. Thus the two units cancel out resulting in a dimensionless value.

For a fog fluid sensor, you could define a SENS_VOLUME with UNITS_NONE and a description string of "Fluid Level (percent)"

este_ July 16th, 2010 12:56 AM

you're absolutely right and I agree and disagree at the same time. Then, as you put it, "a percentage is unit-less because it is the ratio of two values with the same units" the mathematically correct result would always be less or equal 1 (not 0...100!).
I'd call this correct, but being a workaround, and not just user-friendly.

ericthegeek July 16th, 2010 08:48 AM

In most cases, you can convert whatever the percentage is reporting into the associated physical units and report that. For example, a fog machine can send the fluid level in liters. Add in the Range Min/Max and Normal Min/Max the controller has all the information it needs to present a pretty bar graph to the user just the same as it would with a percentage.

Example for a fog machine with a 4 liter tank:
Range Min = 0 (Tank empty)
Range Max = 4000 (4 liters)
Normal Min = 200 (5% remaining)
Normal Max = 4000 (Tank Full)

With these values, the controller can turn the bar graph red and warn the user when the fluid hits 5% (outside of the Normal range).

I'd argue this usage better maintains the spirit of sensors. It keeps the values reported in the context of physical units.

este_ July 19th, 2010 09:20 AM

Displaying a fan speed can also be an intersting item. Every computer can do so (look into your BIOS to see the CPU fan speed), RDM devices cannot. We have fans on stage.

To display a fan speed of say 2000 rpm we have to look table A-13 for UNITS_RPM, which we will not find since it is not a SI unit. Since the "r" in rpm is an artificial component and 1 minute = 60 seconds, the unit 1/s (UNITS_HERTZ) seems appropriate. But we do not have a divisor of 60 as prefix, thus we have to display 33.33 Hz instead of 2000 rpm.
There is no way for the desk or controller other than anlyzing the contents of the sensor label to get any information that this is not a "frequency", and the value supplied must be converted to rpm readout. Or?
Luckily, our console integrates a simple calculator...

ericthegeek July 19th, 2010 11:04 AM

For fans, I think SENS_ANGULAR_VELOCITY is a better choice than SENS_FREQUENCY.

I do understand the point that you are raising. It would be nice to have the commonly used units like RPM and Percentage available directly in RDM. The problem you run into is that there are an unlimited number of unit combinations.

Lets use fluid flow rates as an example (which could be applied to fans and fog machines), offhand I can think of at least 8 units that are commonly used:

Gallons/Hour, Gallons/Min, Cubic Feet/Min, CC/Sec, Cubic Meters/Sec, Liters/Minute, Barrels/Day, Gallons/Day.

Which of these should the standard support? You'll never find a superset of units that will please everyone.

By sticking strictly to MKS SI units the standard ensures that there is a simple, well-defined set of units that everyone can understand. There is one unit for everything. A controller can offer a right-click menu with the option to convert to arbitrary units if desired.

I want a unit for furlongs/fortnight!

este_ July 19th, 2010 02:33 PM

furlongs/fortnight, wow!

you're right, there would be unlimited possibilities. My intention was to raise some attention to this matter, and I think we got there. And,as you put it, [rpm] and [%, 0/00 and ppm] may be of some importance within our industry.

For Vegas, we thought of preparing a RDM-controlled slot machine (before Doug does it). This will fail, because UNITS_CURRENCY does not exist. Together with the LANGUAGE option, displaying EUR, GBP or USD might have been possible. Now we might quit this project :(

All for now.
best, e.

hamish July 27th, 2010 10:34 AM

An alternative approach
Fan speed is something I've just implemented... and by looking for ' RPM ' in the description. You'd never guess it wasn't in the standard!

sblair July 27th, 2010 10:39 AM


I've always known you were a clever and resourceful guy! As other of these UNIT issues come up, lets get them logged on the forums here.

As we start working on the next update to the E1.20 I'll make sure that we include them all for discussions. I think there is a middle road we will need to find to include more useful ones while rejecting the furlongs/fortnight and my favorite rods/hogshead.

ericthegeek July 27th, 2010 11:41 AM

For future reference, the MAC III uses the 16-bit counter type for its fan speeds (in software v1.5.0).

All times are GMT -6. The time now is 06:00 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2021, vBulletin Solutions, Inc.