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 March 25th, 2015   #1
alvangee
Junior Member
 
Join Date: Jan 2015
Posts: 10
Default RDM Responder Tests and background DMX

Hi!
I have trouble running tests with DMX in background. The tests are run on Windows with VMware Player and Enttec DMX USB Pro Mk2. Tests are passed, but my LEDs are blinking during testing.
I think this is because some tests are sent not between DMX frames, but they are breaking DMX frame, i.e. not full 128 slots are sent, but sometimes only 2 or 3 while my Responder has four DMX slots.

And this is what happens. My responder gets some values for four slots (say, 0x55), then gets RDM request and process it (this takes sometimes up to 8-10 ms when I save parameters in flash and MCU doesn't respond due to disabled interrupts), then there's broken DMX frame with only 2-3 slots with higher value in this slots (say, 0x77) and Responder now has slots 0x77-0x77-0x55-0x55.

And here's the question: is this normal operation when RDM tests are run not between full DMX frames, but break them at random places?

The picture shows short DMX frame followed by RDM request and RDM response. dt shows BREAK to BREAK time (from DMX to RDM request) of 880 us, which less than 1204 minimum required BREAK-to-BREAK time from Table 6 of E1.11.


Update: Setting high start DMX address for Responder, like 120 or 125, shows that full 128 slots DMX frames are rarely received by Responder during RDM tests run. The blinking could be avoided by driving LEDs with received DMX values only when full set of four slots received, thus dropping short DMX frames completely - this works for me, but I still want to understand if this behavior of RDM tests is normal.

First video shows test with driving LEDs even when only one DMX slot is received - frequent blinking.
http://www.youtube.com/watch?v=nPb7AF3w044
Second video shows test with driving LEDs only when all four slots are received - no blinking and gradually increasing brightness.
https://youtu.be/F9yS93qfidE

Last edited by alvangee; March 25th, 2015 at 03:34 AM.
alvangee is offline   Reply With Quote
Old March 25th, 2015   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

In older versions of DMX (USITT DMX512) you could send variable length packets. I don't remember if E1.11 disallows that or not, but it's always been a bad practice. In any case, the controller must maintain the minimum break to break time, so the behavior you show is incorrect.

I'm not sure if this is an Enttec problem, or an issue with the USB Host Software. Assuming you're talking about the OLA RDM Responder tests, a few of the OLA developers read this forum, so hopefully they can give you some guidance.

One other note, from the scope image, it looks like the responder may be enabling its line driver too soon. The responder should not start responding for at least 176us, and based on the slightly higher voltage levels I think it may be enabling the line drivers immediately after the request is finished.

Last edited by ericthegeek; March 25th, 2015 at 12:30 PM. Reason: Acronym Spelling Correction
ericthegeek is offline   Reply With Quote
Old March 25th, 2015   #3
alvangee
Junior Member
 
Join Date: Jan 2015
Posts: 10
Default

Quote:
Originally Posted by ericthegeek View Post
I don't remember if E1.11 disallows that or not, but it's always been a bad practice.
E1.11 allows frames of any length from 1 to 512 slots.

Quote:
One other note, from the scope image, it looks like the responder may be enabling its line driver too soon. The responder should not start responding for at least 176us, and based on the slightly higher voltage levels I think it may be enabling the line drivers immediately after the request is finished.
As far as I remember there's delay_us(170) after parsing RDM request and before enabling transmitter in my responder program, so it shouldn't enable driver at that time. I need to check this one more time, though. Thanks for the advice!
alvangee is offline   Reply With Quote
Old March 25th, 2015   #4
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

alvangee: can you open another issue on the github site please so we can track this. From my quick looks it appears this is a problem with the Enttec USB device.
__________________
Open Lighting Project: www.openlighting.org
RDM Responder Tests: www.rdmtests.org
nomis52 is offline   Reply With Quote
Old March 26th, 2015   #5
alvangee
Junior Member
 
Join Date: Jan 2015
Posts: 10
Default

Quote:
Originally Posted by nomis52 View Post
alvangee: can you open another issue on the github site please so we can track this. From my quick looks it appears this is a problem with the Enttec USB device.
Done: https://github.com/OpenLightingProject/ola/issues/684
alvangee is offline   Reply With Quote
Old March 27th, 2015   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by ericthegeek View Post
In older versions of DMX (USITT DMX512) you could send variable length packets. I don't remember if E1.11 disallows that or not, but it's always been a bad practice.
I finally had a chance to pull out my copy of E1.11-2008. In section 8.5.1 it says:
"Once a controller is configured for a particular application, all NULL START Code packets should have the same number of slots."
Now, that's a "should", not a "shall", so variable length NSC packets don't strictly violate the standard. Still, it's a *very* bad practice.
ericthegeek is offline   Reply With Quote
Old August 28th, 2015   #7
Arjan
Junior Member
 
Join Date: Jun 2015
Location: The Netherlands
Posts: 1
Default

alvangee : I just ran a RDM Responder test with 128 DMX slots in between. DMX Frame rate = 20.

I have two Raspberry Pi's which are acting as an Enttec DMX USB Pro. One is set in Mode 2, and one is set in Mode 3 (OLA RDM Sniffer compatible).

And one Raspberry Pi as a RDM Responder.

I have uploaded the output of the sniffer here :
https://drive.google.com/file/d/0B0Q...ew?usp=sharing

When you do a grep DMX 128" Sniffer.log then you will see that the DMX data is correctly outputted by the host and widget.

When you look at the sniffer monitor https://picasaweb.google.com/lh/phot...eat=directlink
then you see statistics where the break-to-break time is 25000 us


- Arjan
Arjan is offline   Reply With Quote
Old October 25th, 2015   #8
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

I've reproduced this issue with the Enttec MK 2 and have raised the issue with them.
__________________
Open Lighting Project: www.openlighting.org
RDM Responder Tests: www.rdmtests.org
nomis52 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
RDM Responder tests updated nomis52 RDM General Implementation Discussion 0 September 2nd, 2013 11:52 AM
Differences in current OLA RDM Responder tests? Robert040 RDM General Implementation Discussion 0 July 16th, 2013 05:51 AM
RDM Responder for low cost testing jpk__ RDM Marketplace Discussion 0 July 7th, 2013 08:00 PM
RDM Responder Tests are Ready nomis52 RDM General Implementation Discussion 2 March 17th, 2011 06:41 PM
Any RDM Responder Devices out there yet? sblair RDM Marketplace Discussion 8 September 20th, 2006 06:03 AM


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


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