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)
-   -   Sensor Defintion/Support Parameters (http://www.rdmprotocol.org/forums/showthread.php?t=1192)

gthaliath February 2nd, 2014 05:27 PM

Sensor Defintion/Support Parameters

I would like to get some support on how to define a temperature sensor using RDM.and also how to use it.(examples would be great)

Also would a RDM controller normally have a stock standard supoprt parameter for all the RDM units, or can a RDM controller get support parameters without calling the SUPPORT PARAMTER PROTOCALL.

Thanks in advance,

sblair February 2nd, 2014 06:24 PM

Welcome to the forums George!

I'll take the second part first. All the units for Sensors are pre-defined within the protocol. So a controller that supports Sensors should have support for all the unit types listed in Table A-13.

SUPPORTED_PARAMETERS is only used to tell the controller what messages (PIDs) that are implemented in the device. There is very little a controller can do with a device without using SUPPORTED_PARAMETERS to find out the capabilities of the device.

Here's some code snippets that show temperature sensor implementations. Sometimes code is faster than English :)

Sorry for the whitespace mangling the forums do to it, but it should be somewhat readable. This is how to define a message. Then the SENSOR_VALUE message is used to get the actual values for the sensor after it has been defined.




case 0: //CPU Temp
    i = 0;
    ParamData[i++] = 0;                                    //Sens #
    ParamData[i++] = E120_SENS_TEMPERATURE;  //Type
    ParamData[i++] = E120_UNITS_CENTIGRADE;    //Unit
    ParamData[i++] = E120_PREFIX_NONE;          //Prefix
    ParamData[i++] = (BYTE)(RDM_MINIMUM_TEMPERATURE >> 8);  //Range Min Value 16-bit
     ParamData[i++] = (BYTE)(RDM_MINIMUM_TEMPERATURE);
  ParamData[i++] = (BYTE)(RDM_MAXIMUM_TEMPERATURE >>8); //Range Max Value 16-bit
    ParamData[i++] = (BYTE)(RDM_MINIMUM_TEMPERATURE >> 8); //Normal Min 16-bit
  ParamData[i++] = (BYTE)(RDM_MAXIMUM_TEMPERATURE >> 8); //Normal Max/ 16-bit
     ParamData[i++] = 2; //Recorded Value Bit Masks: Bit 1 indicates Max/Min support
  strcpy((char*)(pParamData+i), "CPU Temp");
  BufferSize = (BYTE)(i + 8);

  respond = TRUE;    //Description variable 32 chars.


gthaliath February 2nd, 2014 07:01 PM

Hi Scott,

Thanks for the quick reply.
I am quite new to RDM. This does answer a lot of my question. Then again brought about a lot more questions :).
Please tell me if I am correct or not.

first the controller asks for the SUPPORT PARAMETERS in which the SLAVE replys saying I have a sensor or two. which all happens after discovery.

Then by selecting sensor definition from the controller we get what the values of the sensors are.
Then if the sensor values are selected we get the value that the sensor is recorded.

Please let me know if this is correct, if not please do correct me.
Thanks a lot

sblair February 2nd, 2014 07:44 PM

Here's the basic steps related to sensor messages.

DEVICE_INFO message contains several basic parameters about the device, one of which is the number of sensors it includes. This and SUPPORTED_PARAMETERS are the first messages the controller requests.

The controller will also ask for SUPPORTED_PARAMETERS where the device will need to respond with SENSOR_DEFINITION and SENSOR_VALUE PIDs among those being supported by the device.

The controller will then send a request for the SENSOR_DEFINTION for each of the qty of sensors indicated from the DEVICE_INFO message to understand what type of sensor each is and what it is monitoring.

At this point the controller knows how many sensors there are and what each of the sensors does so it can then start sending SENSOR_VALUE messages for each of the sensors to get current readings.

Hope that helps.


gthaliath February 2nd, 2014 10:29 PM

Hi Scott,
Thanks for all that information.
we have got most of it working.

It would be great if you could guide me in how to address the sensors too.
for example?
I got 3 senesor which I have declaird in my device info.
I have also got sensor definition done.
But how do I dedicate a PID to a specific sensor.
do i just say
PID 1 is X
PID2 is Y and
PID 3 is Z

Also if the sensor number is defined as 0x03, would that mean when the sensor definition is called out it is called in the order.

sblair February 2nd, 2014 10:43 PM

The 2nd to last paragraph of Section 10.7 covers sensor addressing.

Sensors are consecutively numbered starting from 0. The request message from the controller will specify which sensor number it is requesting the definition or value of.

gthaliath February 2nd, 2014 10:46 PM

Hi Scott,
Thanks a Lot for the help.
Really apreciate it.

sblair February 2nd, 2014 10:48 PM

No problem! Let us know if you have any other questions.

gthaliath February 2nd, 2014 10:50 PM

sure will.. :)
Thanks once again

gthaliath February 3rd, 2014 05:56 PM

Hi Scott,
How are you?
We got the entire system working in the way of sensors.
while using the RDM controller it had the option on its user interphase which said STATUS MESSAGE.

I had hard coded the GET SENSOR VALUE to a value more than the normal value(which was defined in the SUPPORT PARAMETERS) but the STATUS MESSAGE would not show a thing.

would that mean I have to write a pice of code to reply to STATUS message?

I also looked into STATUS MESSAGE(10.3.2) but in its Responce it had "Sub-Device ID".
Now the question become how do I specify it is the sensor and not a sub device?

Looking forward to hearing soon.
Thanks once again in advance.. :)

ericthegeek February 5th, 2014 11:43 AM

You can use a STATUS_MESSAGE to deliver a message such as "Sensor 15 over temp at 100 degrees C" (In this example, you'd use STS_OVERTEMP with "Data Value 1" set to 15 and "Data Value 2" set to 100).

If you don't support sub-devices you always set the Sub-Device field to 0x0000. Otherwise, you set the sub-device field to the sub-device which contains the sensor that generated the status condition.

gthaliath February 5th, 2014 03:01 PM

Thanks for that information.
Would there be any command which would report that a specific sensor is recoding normal operatoinal values.
most of the commands in table B-2 is to do with errors or warnings.



ericthegeek February 5th, 2014 03:26 PM

Status messages are typically used to report unusual conditions. When a sensor goes outside of the normal range, the responder might return a Status Type "WARNING" for STS_OVERTEMP as we discussed earlier. Then, when the temperature returns to the normal range the responder reports "WARNING_CLEARED" STS_OVERTEMP. This can asynchronously notify the controller that a sensor has returned to the normal range.

Controllers can poll sensors periodically to look for values within the normal range. Some controllers will poll every sensor periodically, while others will only read sensors when the user requests an update, for example by opening a "sensor data" window in the controller's GUI.

gthaliath February 5th, 2014 03:29 PM

Thanks for that information.
Appreciate it

gthaliath February 13th, 2014 03:29 PM

I have been working on the status message.
Got a few question on that.
how does a slave understant that the controller is talking to it.
Pg49 has not got a UID in it. So just wondering how that works.
Also when replying to a Status message get, how do we deicde which sensor it is asking for.

For example if We got 2 sensors on a slave and the master is asking for status message how do i distingues which sensor it is asking for and also how do i deciced that it is asking a specific UID.

Looking forward to hearing from you soon.

ericthegeek February 14th, 2014 08:40 PM

The STATUS_MESSAGES data format described in E1.20-2010 section 10.3.2 is enclosed in the general packet format described in section 6.2. That enclosing packet has the responder's UID included.

Status messages (and queued messages) are more of an advanced feature for RDM. They are not required for basic operation. In fact, many simple responders don't implement status messages at all. Rather than focusing on Status Messages right away, you may want to get the rest of your responder working, then go back and add status message support once you have that foundation to build on.

gthaliath February 16th, 2014 03:36 PM

Hi Eric,
Thanks for that information.
We have got the system to monitor the sensors, set max and min opertation temperature and also do the remaining basic information such as
Discovery,identify, set/get DMX address, Software version,supported parameters, sensor definition, sensor value, and now currentley working on status message.

we believe that section 6.2 explains all that we where looking for.

we shall have a play with it and let you know how we go.
Thanks a lot for the support.

sblair February 16th, 2014 10:40 PM


I'd really encourage you to make sure that you've read the entire document pretty thoroughly rather than just focusing on the parts that have the messages you're interested in. There's lots of other requirements in the doc, especially concerning handling of other fields in the header that you don't want to miss.

I'd also encourage you to attend one of the upcoming plugfests in either the UK or in the US as they are a great opportunity to get some through testing done of your product with other products and test gear and plenty of knowledgeable people to answer all your questions and help debug any issues.

gthaliath February 16th, 2014 10:43 PM

Thanks Scott,
Will Do so.

Sadley We are in Australia and I dont think I be able to make in there(funds) but let see.
Will look into it.
Thanks for the advice and help.

prwatE120 February 20th, 2014 10:30 AM


If you contact me off-list I may be able to help review your design when I am next in Australia.

I would also draw your attention to the RDMLabpack which pretty much has support for all of the RDM commands and is a useful reference platform to see how things work.

Peter Willis

gthaliath March 11th, 2014 07:51 PM


Thanks for all that information.
I have informed my management of help available. will keep let you know how we go.

While playing with it, had another question.
Does RDM support displaying Temperature in Fahrenheit.

Looking forward to hearing from you guys soon.

sblair March 12th, 2014 12:09 AM

At the time we went with standard SI units, as otherwise it would have quickly become quite painful dealing with all the other unit variations.

To paraphrase a favorite Simpson's quote "My dimmer gets 40 rods to the hogshead and that's the way I like it..."

ericthegeek March 12th, 2014 01:01 PM

RDM only uses SI units for sensors. But, controllers can easily convert the sensor data and display it in whatever unit makes sense for its users.

For example, a controller that's configured for US Localization might convert units to Feet/Pounds/Farenheight when displaying sensors, but use Meters/Kilograms/Centigrade everywhere else.

gthaliath March 12th, 2014 04:00 PM

thanks Eric

zano_villa September 1st, 2016 04:13 AM

just a question about sensor addressing on STATUS MESSAGES.

I have 4 temperature sensors on my driver and they are addressed as 0,1,2,3.

In case of STS_OVERTEMP, are these the numbers to fill in DATA VALUE 1 field of table B-2?
In other words, is 0 a valid value or in this case I have to start with 1?

Thank you

ericthegeek September 1st, 2016 09:38 AM

Sensors are numbered 0x00 – 0xFE, so zero is a valid value for Data Value 1 in the status messages.

All times are GMT -6. The time now is 11:38 PM.

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