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 November 17th, 2020   #1
FishFood6
Junior Member
 
Join Date: Nov 2020
Posts: 3
Default 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.
FishFood6 is offline   Reply With Quote
Old November 17th, 2020   #2
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default 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.

Hamish
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old November 18th, 2020   #3
FishFood6
Junior Member
 
Join Date: Nov 2020
Posts: 3
Default

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.
FishFood6 is offline   Reply With Quote
Old November 18th, 2020   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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)
ericthegeek is offline   Reply With Quote
Old November 19th, 2020   #5
FishFood6
Junior Member
 
Join Date: Nov 2020
Posts: 3
Default

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.
FishFood6 is offline   Reply With Quote
Old November 19th, 2020   #6
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default 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.
__________________
______________________________________________
Hamish Dumbreck
hamish 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
Discovery Response Preamble prwatE120 RDM General Implementation Discussion 0 January 20th, 2007 12:22 AM


All times are GMT -6. The time now is 12:14 PM.


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