![]() |
|
|||||||
| RDM Timing Discussion Discussion and questions relating to the timing requirements of RDM. |
|
|
Thread Tools | Search this Thread | Display Modes |
|
|
#3 |
|
Task Group Member
Join Date: Aug 2008
Posts: 390
|
Are you implementing a controller, or a responder? The problem looks different depending on which type of device you're implementing.
In a responder, you can't really use a timeout to guarantee receiving a complete packet from the controller. Consider the case of a broadcast request: DMX NSC (~200us delay) RDM Broadcast Request (~200us delay) DMX NSC If you're counting on a 2ms idle to receive a complete RDM request, it will never happen and you'd miss the broadcast. Some RDM Controllers insert idle time on the wire after after a broadcast request, but it's not required. Controllers on the other hand *can* use a timeout to detect the end of a response. In fact, I've done exactly that in one of my controllers. The controller can just wait however much time it needs to finish receiving the response before sending the next NSC or RDM packet. However, I'd consider using a timeout to be poor practice since it can reduce line throughput substantially. Most RDM request/response pairs take between 3 and 4ms to complete (assuming well-behaved responders). Adding a >2ms timeout to this can really slow things done, especially during setup/initialization when you're trying to query everything from every responder and don't have active fades in progress (and thus can send NSC data infrequently). |
|
|
|
| Bookmarks |
| Thread Tools | Search this Thread |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Timing contraints driver switch from controller to responder | mkoelman | RDM Timing Discussion | 2 | March 18th, 2015 01:44 AM |
| 3.2.1 Responder Packet Timings | prwatE120 | RDM Timing Discussion | 6 | May 23rd, 2009 08:32 AM |
| Packet Captures? | jhuntington | RDM General Implementation Discussion | 0 | March 4th, 2007 07:19 PM |