E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old May 1st, 2012   #1
erwin
Junior Member
 
Join Date: Apr 2012
Posts: 7
Default PID vs. PDL

Hey all,

while writing the Wireshark dissector I ran into a RDM packet that I don't know how to handle. It has a PID of 0x0401 (LAMP_HOURS) and a PDL of 2. But the spec (just bought the new one to verify) says that LAMP_HOURS should be a 32bit value. So, or the PID is wrong, or the PDL is wrong.

How should one deal with situations where PID and PDL disagree ?

- Erwin
Attached Images
File Type: jpg lamp_hours.jpg (22.4 KB, 407 views)
erwin is offline   Reply With Quote
Old May 1st, 2012   #2
erwin
Junior Member
 
Join Date: Apr 2012
Posts: 7
Default

Hmm the image was resize to unreadable size, but it just shows how Wireshark dissected the wrong packet.
erwin is offline   Reply With Quote
Old May 1st, 2012   #3
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

Erwin

not sure which version you have, but in

ANSI E1.20 - 2010
Entertainment Technology
RDM
Remote Device Management
Over DMX512 Networks
Copyright 2011 PLASA NA. All rights reserved.
CP/2009-1017r2
Approved as an American National Standard by the ANSI Board of Standards Review on 4 January 2011.

section 10.8.2 Lamp Hours PID is described with a PDL of 0x04 as you would expect.

It is also correct in a final draft which I, as a task group member, have.

What page are you referring to ?

Peter Willis
prwatE120 is offline   Reply With Quote
Old May 1st, 2012   #4
erwin
Junior Member
 
Join Date: Apr 2012
Posts: 7
Default

Hey Peter,

Yes the spec says LAMP_HOURS is 32bit, and that's the way I implemented it in Wireshark. But I have a capture file from someone that has a LAMP_HOURS PID with a PDL of 2.

The question should probably more be like; when PID and PDL disagree, should I assume spec is always right and mark the packet as broken?
erwin is offline   Reply With Quote
Old May 1st, 2012   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

In essence YES - even if the spec is "broken". It is the spec, warts and all, and is the only common reference we have!

In the example you cite, the capture file is evidence of a non-compliant device.

Peter
prwatE120 is offline   Reply With Quote
Old May 1st, 2012   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 359
Default

Quote:
Originally Posted by erwin View Post
The question should probably more be like; when PID and PDL disagree, should I assume spec is always right and mark the packet as broken?
YES!!! Mark the packet as broken. If the received PDL doesn't match the expected value for that PID, then the packet is corrupt and should be flagged as such.

This is a common problem, I've seen many devices that send incorrect PDLs, especially on ACK SET_RESPONSE packets. Such behavior can cause interoperability problems.
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
PID = SUPPORTED_PARAMTERS / PARAMTER_DESCRIPTION question berntd RDM Interpretation Questions 14 February 9th, 2015 04:54 PM
CAPTURE_PRESET pdl? berntd RDM Interpretation Questions 4 October 19th, 2009 10:52 PM
PDL size and manufacturer specific parameter ID's jamie RDM General Implementation Discussion 5 July 13th, 2009 01:31 AM
Is there a minimum required PID list for sub-devices? p_richart RDM Interpretation Questions 4 November 7th, 2008 02:04 PM


All times are GMT -6. The time now is 12:45 PM.


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