|
RDM Timing Discussion Discussion and questions relating to the timing requirements of RDM. |
|
Thread Tools | Search this Thread | Display Modes |
August 7th, 2006 | #1 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
3.2.1 Responder Packet Timings
The last paragraph of section 3.2.1 on page 10 reads
"Responders may consider controller packets with interslot delays execeeding the maximum in line 3 of table 3-2 to be lost" However, Table 3-2 is a table of packet spacing timings , and does not detail min/max of Interslot times. Should not this paragraph refer to Line 1 of table 3-1, or better still, line 1 of Table 3-3, Responder Packet timing? |
August 7th, 2006 | #2 | ||
Administrator
|
*** Warning....this discussion is about to enter Task Group mode ***
Some of the following discussion and details are from earlier drafts. Just because I'm referencing for discussion does not mean they are what is in the FINAL approved standard. In all cases, it is the FINAL standard that is considered law. ************************************************ Just had to get that disclaimer out of the way. Peter, what you've brought up appears to be a valid error. It certainly isn't making sense to me. However, after a stroll down memory lane it has been referencing the same table since it was changed to be a reference rather than a hard # in the text. I had to dig back in draft versions to an early draft where it was actual hard numbers in the text. From draft v1.2c on May 11, 2004: Quote:
My guess at this point would be that it should have pointed to Table 3-3 Line 1. Draft v1.3 had the following: Quote:
When we were editing the v2.1 draft at LDI is when we must have spotted the issue but instead changed the line # rather than the table #. It then passed through two following Public Reviews with no comments. I would like to get confirmation from more Task Group members here to see if everyone is in agreement the current text is an error and then I'll forward to Karl to find out if/how to issue an Errata.
__________________
Scott M. Blair RDM Protocol Forums Admin |
||
May 8th, 2009 | #3 |
Junior Member
Join Date: Feb 2009
Posts: 7
|
inter-slot timeout
"Responders may consider controller packets with inter-slot delays of 2.1mS or greater to be lost"...
So, every USB/DMX PC interface which outputs packets directly (whithout esternal buffering & retrasmission circuit) may be cause packets to be lost, due the time scheduling of the operating system (for windows tipically >10ms). In my RDM-responder firmware I set up the inter-slot delay timeout equal to the packet timeout equal to 1S. Is it a valid solution? |
May 12th, 2009 | #4 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Technically it's a valid solution. The key word is "may". A responder can wait as long as it wishes for the inter-slot timeout. Realistically though, no controller would generate packets like that because it would fail with many responders.
RDM has pretty tight timing restrictions. A device (controller or responder) which has scheduling delays in the 10ms range is unlikely to work reliably with RDM. You really need sub-millisecond level control to build an RDM device. Typically, that means the USB UARTs from companies like FTDI and SiLabs won't work for RDM on their own. You need a microcontroller or PLD to generate more accurate timing. |
May 22nd, 2009 | #5 |
Junior Member
Join Date: Feb 2009
Posts: 13
|
With the exception of the break and MAB timing the FTDI and SiLabs chips have large enough FIFO's that for most RDM packets the inter-slot time would be zero as long as your USB driver can push the data down the USB lpipe in large enough chunks.
|
May 22nd, 2009 | #6 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
The problem with USB UARTs isn't with the inter-slot timing. The problem is meeting the line turnaround time requirements. At the end of a packet, you typically have 176 microseconds to turn the line around and be ready for whatever comes next (Table 3-2 lines 3 and 4).
Most operating systems don't give you very good control over USB transaction scheduling for bulk transactions. The OS's USB stack may send the turnaround right after the data, or it may delay it an arbitrary number of USB frames. You simply don't know, and the timing gets worse under heavy USB or CPU load. The other problem I had was break generation. The "Start Break" and "End Break" commands were sent in two different USB transactions which could have an arbitrary amount of time between them. With a few tricks, I was able to guarantee the break was never less than 176us, but it would regularly exceed the 352us maximum by several ms (Table 3-1 line 1). This issue came up during one of the RDM Public Review periods. As I recall, the conclusion was that accommodating the timing needs of the USB UARTs available at the time would have required such long turnaround and timeout periods that Null Start Code performance would be significantly impaired. Disclaimer: I'm speaking solely from my experience and not making any grand "It can't be done" proclamations. It's been several years since I tried using a USB UART for RDM. It's fully possible that I drew the wrong conclusions or that the problems I encountered have been resolved in newer chips or newer software. Last edited by ericthegeek; May 22nd, 2009 at 02:20 PM. |
May 23rd, 2009 | #7 | |
Junior Member
Join Date: Jun 2006
Location: London
Posts: 13
|
Quote:
If there is any interest, I could easily knock up a USB to serial chip that is DMX and RDM aware to get around these problems while still being compatible with software that thinks it is driving a COM port. I might even be persuaded to make it open source |
|
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Packet Captures? | jhuntington | RDM General Implementation Discussion | 0 | March 4th, 2007 08:19 PM |
Any RDM Responder Devices out there yet? | sblair | RDM Marketplace Discussion | 8 | September 20th, 2006 07:03 AM |