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)
-   -   Discovery response format (http://www.rdmprotocol.org/forums/showthread.php?t=1315)

FishFood6 November 17th, 2020 03:14 AM

Discovery response format
I am having trouble with the Discovery Response signal and am unsure on how to fix it.

Current setup:
Iím sending an RDM Discovery signal with a DMXcat (controller) to a PSoC 4 controller (responder) with a rs485 shield to receive the data. The rs485 shield is in TX_CTRL mode, this would mean that the switch between TX and RX mode is made automatically by the shield. I am correctly receiving the Discovery signal on the responder but seem unable to return a response. I hardcoded the response in an array according to the standard in the E1.20 sheet. It consists of 8 Preamble bytes, 1 preamble separator byte, 12 EUID bytes and 4 encoded checksum bytes.

The Problem:
After sending the response I am unable to see any feedback as to what happened to this response. I am unsure what is causing the response to seemingly get lost. I have a couple of ideas as to what could be the issue but I donít know how Iíd be able to test if these ideas are true.

Possible solutions:
From what I can tell, the issue could be caused by a few things:
  • It could be that the response Iím sending is incomplete, but as far as I can tell from the E1.20 standard, this is not the case.
  • Another reason could be that I am incorrectly sending the array or it shouldnít be an array in the first place. Itís currently in an array of HEX values.
  • I do also still have my suspicions that the rs485 might not be correctly sending the data in automatic mode.
I think I might be able to properly solve this with a RDM sniffer but I am unable to find a proper one so far. The best one I found is the Enttecc RDM USB PRO (PN 70530), but it doesnít seem to be available anymore.

The main question:
The main questions are mostly centered on what could be an issue with sending the response and what is a good RDM sniffer.

Thanks in advance.

hamish November 17th, 2020 03:38 AM

Discovery response.
Welcome to RDM!!

In the first instance, I'd recommend equipping your self with a scope and monitoring the A/B of the 485 bus, to ensure that your response is genuinely being transmitted. If your (responder) transceiver is not reverting to RX within the specified time, you may miss subsequent controller traffic.

Stay well.


FishFood6 November 18th, 2020 06:25 AM

I can't believe I didn't check it before but I check the A/B lines of the 485 bus and no data was being send. I went to work on it and got it to work. Turns out that the rs485 shield I was using wasn't working properly. Now when I check the A/B lines I see data being transferred. My RDM controller still doesn't seem to recognize it though, so the bigger problem there hasn't quite been fixed yet. Do you have any idea what may be the cause?

Thanks in advance.

ericthegeek November 18th, 2020 11:16 AM

Have you looked at the RS485 line with an oscilloscope to see what's actually being sent?

The two RDM Sniffers I know of are the Enttec and the DMXter4.

In general using auto-direction control is a bad idea with RDM. The timing requirements are pretty tight, and you need to have control over when you assert TX-enable. I don't know the specific auto-direction implementation you're using, but they often are tuned for much lower baud rates and looser timing.

(Full Disclosure: I have worked for GDC who makes the DMXter4)

FishFood6 November 19th, 2020 02:03 AM

I have looked at the RS485 linef with an oscilloscope, but I haven't had the chance to use a digital oscilloscope so the signal is just there for one second and gone the next. The moment the signal is there does correlate with when I'm sending the signal, so I am left to asume that the right signal is being send.

As for the sniffers, thank you for the recommendations, I'll have to look into them.

I have also switched off of auto-direction in the past few days. It's generally better to have more control over things like that.

hamish November 19th, 2020 06:15 AM

Port turn-around and timing
I concur with Eric's comments.
Irrespective of any sniffers, some form of digital scope with a trigger to capture traffic and port control timing will be an essential base level tool, to get you passed the first basics. Your controller not relinquishing the bus after a discovery response may be a reason for no additional discovery traffic being received.

All times are GMT -6. The time now is 07:07 AM.

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