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 December 7th, 2013   #1
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default Enttec RDM USB Pro not decoding get response

Hello everyone, this is my first post here.

I am implementing RDM for our new LED fixture range (to be released soon I hope). I have not implemented RDM before, and so this is very early days for me. I am using an Enttec RDM USB PRO as the controller device. I have written a custom application in windows to control it and that seems to work ok.

However, I am having a problem with it not decoding the GET_COMMAND_RESPONSE packet. My micro in the fixture is correctly decoding the GET_COMMAND, testing the checksum, manufacturer ID etc, and sending the appropriate response. I have checked the return packet as best I can with the DSO, and all values seem to be correct. I have very accurate timing control in the micro (PIC24 series @ 40MIPS). I am using a timer driven state machine and set my timing accuracy for all DMX generation to increments of 200nS, which easily allows me to adhere to the specification outlined in the ANSI E1.20 document. All timing seems correct to me, but he RDM USB PRO will not decode and send back any packets to my software.

I have confirmed that I can get packets from it before while I was developing. But now that I have all the RDM data filled in correctly I don't get anything.

Am I missing something? Does anyone know what the rules are for it to decode a packet and send it back? I cannot find any documentation that outlines how clever this device is, like is it aware of what the last request was that it transmitted, and therefore what it expects to decode next? I would have thought that it would decode anything and leave it up to the software to determine the validity of what was received by the device.

Sorry for the long explanation, I can supply further details if required by anybody that has had any experience with this device.

Thank you,

Daryl.
dtewksbury is offline   Reply With Quote
Old December 8th, 2013   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 422
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Daryl,

Welcome to the forums! The first thing I would normally say is check your timings! But it sounds like you've covered that. If you're sure all the timings are good, then lets move on to the data.

You said you were trying to use it through their API to your own software on Windows. Can you confirm if you just use the Enttec Controller Software if it is decoding and displaying the response properly? If so, then it may be an issue in their API or your interface to it.

Otherwise if the Enttec controller app is not displaying the response then I'd suggest sending us a full dump of both the GET packed from the controller that you are receiving in your fixture and then the exact data you are responding back to it with including checksum and everything that way some of us can look through it and see if we spot anything.

Scott
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old December 8th, 2013   #3
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default

Hi Scott, thank you for your response.

I have further information now. After posting my original question, I got desperate and I removed the payload from my response packet, disabled the transaction incrementing so that the checksum would not change, then I spent the next hour decoding the waveform on the DSO by hand. Everything looked correct in the packet, so I assumed that was not the problem. I then added all the data back into it to look further.

Next it dawned on me that maybe the device requires a specific address to decode, which makes no sense, but still I thought I would try to send data back to FFFF:FFFF:FFFF. This worked and everything was decoded and the transaction was complete. Everything working as it should.

This makes no sense to me, if the Enttec device will only receive data on a certain address, why do I have to fill in the source address? It should do that itself.

Clearly I am missing something else, however this does allow me to continue to implement the rest of the GET and SET commands. I will also tackle device discovery.

On another note, I came up with a good way to generate the break using the PIC24, but without the need to use an extra port bit and resistor. Simply use the output invert bit to toggle from line Idle to break and back, this works a treat.

Daryl.
dtewksbury is offline   Reply With Quote
Old December 9th, 2013   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

Are you saying that you're putting a Broadcast UID in the "Destination UID" field for the GET_COMMAND_RESPONSE packet? This may be a quirk of the Enttec software API, but it's unlikely to work with many RDM controllers. The "Destination UID" field for a response should be the UID of the RDM controller that sent the GET request. The broadcast UIDs "BROADCAST_ALL_DEVICES_ID" and "ALL_DEVICES_ID" are only defined for requests in section 5.2 of the RDM Standard.

I've never used the Enttec API for windows. Does your windows software pass fully formed RDM packets to the API, and the API simply passes them along to the 485 wire? Or, do you just send the payload to the API, and the Enttec software takes care of building the packet? It may be that you have to ask the API for the RDM USB PRO's UID, then include that UID when building RDM requests.
ericthegeek is offline   Reply With Quote
Old December 9th, 2013   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

I skimmed Enttec's documents.

Are you using this Enttec RDM Library for Windows:
http://www.enttec.com/?main_menu=Products&pn=70533

Or are you using their USB Protocol directly?
http://www.enttec.com/docs/dmx_usb_pro_api_spec.pdf

Since you mentioned disabling the Transaction Number, it appears you must be using the USB protocol (since the RDM Library spec doesn't mention a way to disable the Transaction Number sequencing).

Did you see the following in the "RDM Implemention Details" section of the USB protocol document?

"The Widget UID consists of the Enttec manufacturer ID concatenated with the Widget Serial Number, as follows: UID[0]=hex 45, UID[1]=hex 4E, UID[2]=SN[3], UID[3]=SN[2], UID[4]=SN[1], UID[5]=SN[0]."

Are you using this UID in the "Source UID" field for your RDM Requests? (If this UID is in the "Source UID" for a request, the responder should copy it into the "Destination UID" for the response.). It may be that the RDM USB Pro will only accept responses with this UID.


As a side note: You're making life unnecessarily hard on yourself by trying to implement both the controller and the responder by yourself right out of the gate. There is good RDM test equipment available these days that can tell you exactly what's wrong rather than you having to guess. I'll put in a shameless plug for a DMXter4RDM with the Advanced RDM option because it's designed for exactly this kind of development work, but I'm not exactly unbiased since I've worked for GDC. There are other products available too.
ericthegeek is offline   Reply With Quote
Old December 9th, 2013   #6
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default

Thanks ericthegeek, you are correct, I am using the USB protocol and forming the entire packet myself. I came to the same conclusion that I need to add the UID of the Enttec device. I am confused as to why that is even necessary because it would not receive any packets back from any other UID, except the broadcast one, so what is the point of allowing me to add a different one? Except in the case where I was pretending to be some other controller.
dtewksbury is offline   Reply With Quote
Old December 9th, 2013   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

I can't speak for Enttec, but in general there's a tradeoff between how much intelligence you put in the peripheral (USB to DMX adapter), and how much you require from the host software. In this case it appears they put address filtering in the peripheral. With something like a USB protocol it assumes your software is doing everything correctly and doesn't offer a lot of error handling.

When I glanced over their RDM Library for Windows it appears to be a bit more foolproof. You pass your PID and payload to the library, and it takes care of building up the packet around it.

One of Enttec's people posts here occasionally, he may have an official answer.

If you need this specific behavior to emulate another controller, may be worth dropping Enttec a note. Also, there are other USB to DMX+RDM peripherals available that may offer what you need.

If you haven't found them already, consider attending one of the RDM Plugfests. They're perfect for product developers.
ericthegeek is offline   Reply With Quote
Old December 9th, 2013   #8
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default

Yes, I could use their library, however I tend to understand things a lot better when I am forced to do everything myself. Although this can be quite frustrating at times. I can ask the RDM USB PRO for it's serial number and build the UID from that as described earlier in this post, which I will do. I am however interested in seeing what other devices people are using for RDM development, and which ones are recommended.
dtewksbury is offline   Reply With Quote
Old December 10th, 2013   #9
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

You're probably sick of hearing from me at this point, and I already put in my plug for the DMXter4. My other tools are a DFD RAD, a recent AL Art-Net node, a copy of ETC's Net3 Concert, and a Digital Oscilloscope for use with the DMXter's scope trigger feature.

I also have a collection of responders and splitters I use for testing controllers including a Howard Eaton Labpack, a Zero88 Betapack (good for testing sub-devices), and AL Railtran (AL responders have a number of quirks that can sometimes cause problems for other responders), plus whatever prototypes or demos are sitting on my desk at any given time.
ericthegeek is offline   Reply With Quote
Old December 10th, 2013   #10
sblair
Administrator
 
Join Date: Feb 2006
Posts: 422
Send a message via AIM to sblair Send a message via MSN to sblair
Default

My choice list of dev gear is:

Enttec RDM Snifffer (great for looking at traffic and decoding packet data but timing analysis is awful)

Goddard DMXter4 (great for timing analysis, useful for generating a 1:1 NSC/RDM packet interleave with a fade running to make sure your processing/handling is correct).

Saleae Logic8 logic analyzer, which is great for getting basic timing and looking what is happening on the wire in the early stages of getting it running. http://www.saleae.com/logic/
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old December 10th, 2013   #11
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default

Thank you all for the replies. It is always good to know what more experienced people are using for testing and their different quirks. I have always been disappointed by the stupidly large timing ranges of DMX, because it is not possible to analyze it to determine whether it is reversed or not. I have always wanted to design fixtures that would automatically invert the data line if necessary. I guess it was done this way originally because of hardware and processor limitations on simple implementations.

I have in no way implemented even the basic minimum required responses in my RDM implementation yet. I need to get the product working, with a nice software interface for demonstration, so I am using the manufacturer custom parameter ID 0x8000 and this GET/SET exchange does all the lighting parameters in one hit. I will do device discovery soon, so at least the fixtures can be found.

To be honest I have not quite wrapped my head around the discovery algorithm. What I mean is that I understand the concept, and in the PC it will be fairly straight forward to implement. But I am concerned about the micro's side of things. I need it to not be MCU intensive to do the comparisons, although I have found that 40MIPS is actually quite good at 25ns per instruction. But I am writing the micro code in C and I am not 100% sure how good the compiler is (ASM30/C30). I will find out when I put some set and clear pin statements at the beginning and end of some of the functions and then look at it on the DSO (yes, I am old enough to sometimes want to say CRO).

So far this has been quite a satisfying journey (frustrating at first).

Daryl.
dtewksbury is offline   Reply With Quote
Old December 10th, 2013   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

Quote:
Originally Posted by dtewksbury View Post
I have always wanted to design fixtures that would automatically invert the data line if necessary. I guess it was done this way originally because of hardware and processor limitations on simple implementations.
Auto-inverting has been tried before, and it never works out well. The problem is I can build a waveform that forms perfectly valid DMX both normally and inverted. Also, attempts to do auto-inversion by looking for framing errors or odd length packets invariably end up getting triggered when the user hot-plugs a cable.

Quote:
Originally Posted by dtewksbury View Post
I need it to not be MCU intensive to do the comparisons, although I have found that 40MIPS is actually quite good at 25ns per instruction.
Are you referring to the comparisons to determine if your fixture's UID is within the upper and lower bound given in the "Discover Unique Branch" request? I don't know the PIC24's instruction set, but on a PIC18 family part the comparison takes 28 instructions, two of which are dual-cycle instructions for a total of 30 instruction cycles when written in assembly (That's total for both the upper and lower bound, with each taking 15 instruction cycles).

Even with C code it should take very little time. If your compiler doesn't natively support 64-bit data types (to hold the 48-bit UID), you can do it as a series of 16 or 32-bit comparisons. A few microseconds ought to be more than enough.
ericthegeek is offline   Reply With Quote
Old December 11th, 2013   #13
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default

OK thank you. I would be very interested to see the assembly or C code for the PIC18. I could then adapt that for the 24. And yes, it is the comparison that I am concerned about. 30 instruction cycles seems like a lot to me.
dtewksbury is offline   Reply With Quote
Old December 11th, 2013   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 363
Default

In pseudo-code you want something like this:

if( my_uid >= lower_bound ) && ( my_uid <= upper_bound ) && ( request_PDL == 12 )
{
send_DUB_response();
}

Skimming the Microchip C compiler docs it looks like a "long long unsigned int" is 64 bits, so you can let the compiler handle the multi-word math.


30 instruction cycles is fast. In a PIC18 running at 20 MHz (5 MIPs) that works out to 6 microseconds. You have to wait at least 176us to respond to an RDM Discovery Request, so that leave 170us available for the rest of the response processing, checksum verification, etc.
ericthegeek is offline   Reply With Quote
Old December 17th, 2013   #15
dtewksbury
Junior Member
 
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
Default

Thank you, yes that does seem reasonable I will give it a go.
dtewksbury 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
JESE DMX-TRI RDM USB Controller hamish RDM Marketplace Discussion 4 January 6th, 2020 05:59 PM
Uniquely defining the RDM response of devices Andy Macdonald RDM General Implementation Discussion 6 February 9th, 2009 02:24 PM
ENTTEC RDM controller (subdevices) nic123 RDM Marketplace Discussion 3 October 24th, 2007 12:03 AM
ENTTEC RDM Library nic123 RDM Marketplace Discussion 0 October 5th, 2006 03:23 PM
ENTTEC RDM Software Available nic123 RDM Marketplace Discussion 0 August 4th, 2006 01:38 AM


All times are GMT -6. The time now is 11:32 PM.


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