View Single Post
Old February 20th, 2007   #2
Milton Davis
Task Group Member
 
Join Date: Aug 2006
Posts: 12
Default RDM "sniffer"

Harold,

I have had to work through this question for a number of projects in the past. We have a couple of methods that are appropriate for prototyping.

At a very low level, I tend to keep a scope probe on the line to see exactly when the line is being released by controllers/responders and to check for timing and collision issues. This solved a recent issue where a device appeared to have no response to an RDM query when, in fact, it was responding, but only after a very long pause.

At one data level, I have used software from Frontline Test Systems called ST Async. It lets me look at raw values easily.

At another data level, we made a box that "listens" to the traffic as you describe. It puts RDM packets in a circular buffer and sends the data in a somewhat filtered and formatted form to a Hyperterm screen.

So far as creating controller-originated messages, I have hard-coded some test setups as I needed them, but I really didn't want to get into a full-on controller design.

One device we have that does do a bit of controller work is our RAD. I think anyone in this group who has used it would say that it floods messages to responding devices like no other. If your responder can keep up with the RAD, you have a good, solid implementation of the discovery routines.

Beyond these methods, you need to start creating a somewhat sophisticated application on the PC or make a dedicated piece of hardware. Wayne at Artistic Licence made a piece of RDM test equipment at one point, but I have failed to keep up with his status on that device.

Regards,
Milton Davis, Engineer
Doug Fleenor Design, Inc.
Milton Davis is offline   Reply With Quote