PDA

View Full Version : RDM with Open DMX dongle


DynamoBen
06-17-2008, 07:43 PM
As it turns out RDM may be possible with the Open DMX device. Here is an example of a Open DMX clone device "talking" RDM.

http://translate.google.com/translate?u=http%3A%2F%2Fwww.hoelscher-hi.de%2Fhendrik%2Flight%2Fopenrdm.htm&sl=de&tl=en&hl=en&ie=UTF-8

I emailed the developer and he claims the Open DMX dongle is "too slow" to be able to do RDM. I took a peek at the RDM spec and I disagree. If someone out there is a C++ Builder 6 developer I would like to alter this code and try it.
tconley
06-18-2008, 01:09 AM
i wonder if the lynx dongle will work since it is more based on the pro dongle.
DynamoBen
06-18-2008, 10:07 AM
If memory serves RJ didn't add the circuitry required to do RDM. I know the actual DMX Pro does have some RDM ability.
tconley
06-18-2008, 07:31 PM
Well I asked him on the LYNX forum on his site
Henne
11-24-2008, 12:45 PM
I just saw, you noticed my OpenRDM project :)

The difference between Rowan's OpenDMX and the Devantch-Dongle I use for OpenRDM is the automatic port turn-around:
This feature of the actual FT232R switches the RS485 converter to listening mode as soon as all data is transmitted.

With OpenDMX you have to to that manually with one of the GPIOs - which takes much longer... So a device might be responding BEFORE you switched to listening mode.

That is the problem with OpenDMX and RDM.

BTW:
May I add my transceiver to the DMX projects thread?
Schematics and Layouts are already published and I plan to add the sources under GPLv2 in the next months...

best regards,
hendrik
DynamoBen
11-24-2008, 12:50 PM
May I add my transceiver to the DMX projects thread?
Schematics and Layouts are already published and I plan to add the sources under GPLv2 in the next months...


You may, and thank you.
DynamoBen
11-24-2008, 01:01 PM
With OpenDMX you have to to that manually with one of the GPIOs - which takes much longer... So a device might be responding BEFORE you switched to listening mode.

That is the problem with OpenDMX and RDM.


I will have to take a look at the RDM spec tonight. I believe there is a waiting period between when a device receives a packet and can send a response. RTS (pin 22) controls the data direction, depending on the delay in the spec the Open may be able to do it.
Henne
11-24-2008, 01:11 PM
@Dynamo:
You find it in ANSI E1.20, page 9 (page 19 of the pdf): 176µs is the min time between request and response. Because the break on / break off sequence of my dongle takes 1ms, I think this won't work...

Would it be possible to listen to the universe all the time (means: while you are transmitting)?
(You can eliminate your own echos and dont miss the response...)

best regards,
hendrik
DynamoBen
11-24-2008, 01:26 PM
You find it in ANSI E1.20, page 9 (page 19 of the pdf): 176µs is the min time between request and response. Because the break on / break off sequence of my dongle takes 1ms, I think this won't work...

So what you are saying is that the code that controls your dongle takes 1ms to switch RTS low/high. Since this isn't a limitation of hardware I wonder if it could be done with a little different code set.

Another option might be rewiring assuming there is some onboard hardware that can accomplish this task in place of RTS.



Would it be possible to listen to the universe all the time (means: while you are transmitting)?
(You can eliminate your own echos and dont miss the response...)


Can't based on how it is designed. I would need to add another 75176 to the design...at that point your dongle is a better option. See here:
http://www.enttec.com/dmx_usb/schematic.pdf
Henne
11-24-2008, 01:43 PM
Since I use the d2xx Lib from FTDI with CBuilder6, I'm quite sure the problem is the bad realtime behaviour of USB...

What about forcing /RE of OpenDMX to GND?

best regards,
hendrik
Henne
11-24-2008, 01:57 PM
BTW: You can add a link to my RDM responder lib for AVRs in the (closed) RDM thread if you like... I'm glad if it is used and improved.
DynamoBen
11-24-2008, 02:01 PM
Since I use the d2xx Lib from FTDI with CBuilder6, I'm quite sure the problem is the bad realtime behaviour of USB...

What about forcing /RE of OpenDMX to GND?


That might work.

On your schematic you are using CBUS2 (pin 13) to control the data direction. The default function of this pin is TXDEN#, are you changing that functionality in software? If not the TXDEN# is not connected on the Open, I could move from RTS to TXDEN#.
Henne
11-24-2008, 02:22 PM
The function isn't changed - I'm using the TXDEN-fnct.
DynamoBen
11-24-2008, 02:30 PM
The function isn't changed - I'm using the TXDEN-fnct.

Perfect, that means the Open is a trace cut and mod wire away from doing RDM with your software. I just need to move from pin 23 to pin 16. I will solder it up tonight and let you know how it works.
Henne
11-24-2008, 03:34 PM
That would be great :p

RDM would be possible!
Firmware Updates via DMX would be possible!
Secure DMX extensions would make pyro and LN2 FX possible!

Please let me know if it works.
DynamoBen
11-24-2008, 07:42 PM
The conversion went well, a cut here and a jumper there. I've tested both DMX in and DMX out and everything seems to work just like it did before. I'm unable to test RDM since I have not gear to do so at the moment. Based on the LED data appears to be passing when I read/write with your software.

I have created a set of instructions for this mod and made them a sticky.
fkostyun
11-26-2008, 08:55 PM
I just saw, you noticed my OpenRDM project :)

BTW:
May I add my transceiver to the DMX projects thread?
Schematics and Layouts are already published and I plan to add the sources under GPLv2 in the next months...

best regards,
hendrik

Hendrik - your work has been excellent - I did a dmx servo board based off of your design (would love to see the actual ASM code - as I'd love to update it to run 6 servo's and 2 LED's with PWM)