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)
-   -   Trying to run the automated tests (http://www.rdmprotocol.org/forums/showthread.php?t=1147)

LaurentG August 7th, 2012 04:56 AM

Trying to run the automated tests
 
Hi everybody !

I'm currently implementing a RDM responder. I've been developping my system using the Enttec DMXpro interface. Everything seems to work fine with their software, and I'm now trying to test my device with the automated rdm test tool developped by Simon.

My only problem is that I can't discover my device (so I can't run the tests...). Here is the sequence of events I have, I would be glad if anybody could tell me what I'm doing wrong.
1 - the DMXpro is well patched to universe 1 : I can send DMX.
2 - when running a discover (ola_rdm_discover -u 1 -f), it is apparently correctly running : it sends DUB packet until the end of tree ("223: sending DUB packet 0102:03040506 - 0102:03040506" / "382: end of tree reached !")
3 - The discovery process is stuck here. No other packet is sent (the last one on the scope is a discovery one).
4 - If I try to run another discovery, I get the message "128 : Discovery procedure already running"

I feel like something is going wrong among the DISCOVER_MUTE/UNMUTE process, but I don't see any of these packet coming from the controller on my oscilloscope...

LaurentG August 7th, 2012 05:08 AM

I forgot to add one info : yes, I've updated the USBpro firmware. I'm using v2.4.

sblair August 7th, 2012 11:54 AM

Simon will probably best be able to guide you. Are you returning in the DUB packet the UID properly encoded? Not sure what Simon does when he gets to the bottom of the tree and can't decode the UID as to whether he tries to do a Mute anyway.

Have you tried using the discovery software with the Enttec or other controllers and been able to discover your responder?

LaurentG August 7th, 2012 12:11 PM

Everything is working fine with the Enttec controller.
I'm assuming the UID is properly encoded in the DUB packet, but I'm gonna check that again.

The last packet visible on my oscilloscope is a DISCOVER_UNIQUE_BRANCH, which I am responding to. There is no mute coming from the controller.

Simon, if you see this message, do you have any idea about what's going wrong ?

ericthegeek August 7th, 2012 03:04 PM

Quote:

Originally Posted by LaurentG (Post 2503)
Everything is working fine with the Enttec controller.
I'm assuming the UID is properly encoded in the DUB packet, but I'm gonna check that again.

That's not necessarily a valid assumption. I don't recall how the Enttec software handles discovery, but there are controllers out there that will add a responder to the table of discovered devices based solely on a DUB request with a single UID range (the same UID in both the lower and upper bounds).

Some controllers will even add a device if the mute request times out.

Both of these are undesirable behavior, but they do exist.

LaurentG August 7th, 2012 05:09 PM

Ok folks, I've found my mistake.

When sending a discovery response packet, my buffer size was altered. It resulted in the sending of one extra random byte after the encoded checksum.

As a result, the packet was broken and ignored by the controller.

Thank you anyway for your help, checking the encoded UID led me to the solution.

sblair August 7th, 2012 05:14 PM

Glad you found it!

In general when a controller gets to the bottom branch it should just try sending a MUTE. What Simon has built is more for testing compliance to the standard so while most controllers may have just kept drilling until it got to the bottom and then done a MUTE you wouldn't have realized your code was actually broken.

I agree with Eric though, adding a device as discovered when it has NOT done a successful MUTE is a bad idea.

nomis52 August 8th, 2012 08:26 PM

Hi Laurent,

As you've discovered, OLA is pretty strict about what it will accept. It's designed this way so people discover problems early. That said, there was a bug where the discovery process wouldn't restart if it hit the case you described. That's now fixed in the git repo and the fix will be out with 0.8.22 in a few days.

If you find any other problems do let us know. If it's an OLA specific problem then your best bet is to ask on https://groups.google.com/group/open-lighting since you'll get a faster response time.

Simon

LaurentG August 9th, 2012 04:07 AM

Thank you for your reply, and your speed to fix the bug.

Anyway, this test routine is a wonderfull debug tool, and I strongly recommand anybody who wish to develop RDM to use it.
Thank you for your work !:cool:


All times are GMT -6. The time now is 03:43 PM.

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