Trying to run the automated tests

[LaurentG]

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]

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

[sblair]

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]

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]

Originally Posted by LaurentG

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]

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]

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]

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]

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 !