E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old October 28th, 2010   #1
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 52
Send a message via Skype™ to hamish
Default SENSOR_DEFINITION - User Defined

At LDI, I found a responder with a user defined Unit (Table A-13 Manufacturer-Specific Units) So far so good. What appears to be missing in respect of this, is a 'SENSOR_UNIT_DESCRIPTION' PID.

Reading ahead, some consideration should also be given to a 'SENSOR_TYPE_DESCRIPTION' PID. (Table A-12 Manufacturer-Specific Sensors)

This point is not irrelevant to the 'RPM' unit issue that keeps coming round.

I've not yet worked on a possible format for such PIDs, although I'd be happy to do so. Please discuss, comment so on and so fourth.
Attached Images
File Type: jpg Sensor Signal.jpg (34.7 KB, 350 views)
hamish is offline   Reply With Quote
Old October 28th, 2010   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 179
Default

My preference would be to get the necessary units added to our existing list, as we already have a good number already defined, so hopefully there is only ever a small need for really manufacturer specific ones. Also, the two or three that have already been suggested have universal application.
prwatE120 is offline   Reply With Quote
Old October 28th, 2010   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

From what I've seen, using the string in "SENSOR_DEFINITION" works well enough. You can include the human readable units in that string. I my controller, when I see a mfg specific Type or Unit, I just display it as a unit-less number.

The "Signal Strength (dBm)" shown in the attached graphic is a good example. I've also seen it done with "Lamp Blower RPMs". The user gets the information they need.

Pedantic: For dBm, I believe a type of SENS_POWER would be appropriate. dBm is a power ratio relative to 1 miliwatt.
ericthegeek is offline   Reply With Quote
Old October 29th, 2010   #4
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 52
Send a message via Skype™ to hamish
Default

Eric

So far, I have done fairly much as much as you have you have suggested and to a point it works. The 'well enough' part is what concerns me. My problem here is that I can not foresee what units I should be searching for. Would the addition of a PID(s) not be a far more elegant solution? What would be the disadvantage of such an addition?

The addition of PID(s) would circumvent the problem of non SI units being added to the list of pre-defined units, which in turn lead to the flood gates of imperial and arbitrary units being declared.

By the by, I've only just figured that DB is an IEC and not an SI unit, being a ratio rather than a quantitative measurement. Something new every day eh!
hamish is offline   Reply With Quote
Old October 29th, 2010   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

I don't object to the PIDs being added. It's just that getting PIDs added takes a long time. In the mean time "Well Enough" will work, it's just sub-optimal.
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Welcome to RDM General User Discussion Forum sblair RDM User Discussion 2 August 15th, 2006 08:01 PM


All times are GMT -6. The time now is 07:14 PM.


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