|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
December 7th, 2013 | #1 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
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. |
December 8th, 2013 | #2 |
Administrator
|
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 |
December 8th, 2013 | #3 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
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. |
December 9th, 2013 | #4 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
December 9th, 2013 | #5 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
December 9th, 2013 | #6 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
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.
|
December 9th, 2013 | #7 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
December 9th, 2013 | #8 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
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.
|
December 10th, 2013 | #9 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
December 10th, 2013 | #10 |
Administrator
|
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 |
December 10th, 2013 | #11 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
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. |
December 10th, 2013 | #12 | ||
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Quote:
Quote:
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. |
||
December 11th, 2013 | #13 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
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.
|
December 11th, 2013 | #14 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
December 17th, 2013 | #15 |
Junior Member
Join Date: Nov 2011
Location: Phuket, Thailand
Posts: 7
|
Thank you, yes that does seem reasonable I will give it a go.
|
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
JESE DMX-TRI RDM USB Controller | hamish | RDM Marketplace Discussion | 4 | January 6th, 2020 06:59 PM |
Uniquely defining the RDM response of devices | Andy Macdonald | RDM General Implementation Discussion | 6 | February 9th, 2009 03:24 PM |
ENTTEC RDM controller (subdevices) | nic123 | RDM Marketplace Discussion | 3 | October 24th, 2007 01:03 AM |
ENTTEC RDM Library | nic123 | RDM Marketplace Discussion | 0 | October 5th, 2006 04:23 PM |
ENTTEC RDM Software Available | nic123 | RDM Marketplace Discussion | 0 | August 4th, 2006 02:38 AM |