Understanding the timing based on the RDM standard

[dannito]

Hello everyone,

I am trying to build a transparent in-line device (repeater) with AVR micro controller for receiving and logic control. In order to do that I need to clarify for myself some details. As far as I can understand the RDM requirements, the in-line device has certain rules to follow when activating port turnings:

1. During discovery. Whenever it sees the first preamble 0xFE it must turn all the transceivers to receiver mode.
1.1 Listening to each Command port, and soon as one of them is pulled to LOW state it must route its data to responders PORT so the console could receive it. As well as to "mute" the rest of the Command ports during its data delivering (?).
OR
1.2. Just route all the data received from each Command port to Responder Port?
(Is it 1.1 or 1.2 ?)

2.0. The time period for the port turning is 5.8mS? Then it switches back to normal forward data flow.

3.0. During non-Discovery mode, after receiving an RDM request packet, the first port that is pulled to a LOW state for the start of a BREAK becomes the active port. If the Port which is pulled LOW is Responder port, the In-line device must return to normal data flow mode. If this port is not Responder, it must send its data to:
3.1 Only to Responder?
3.2 Every other ports on the device?

4.0 The whole time for this port turning is again 5.8mS? After it, switches back to forward data flow.

Please accept my apologies, but I am new to this and it's all I can understand reading the standard.

Cheers,
Dani

[ericthegeek]

Originally Posted by dannito

1. During discovery. Whenever it sees the first preamble 0xFE it must turn all the transceivers to receiver mode.

You need to turn all of the transceivers into receive mode at the end of the Discover Unique Branch request (within 176us after the second stop bit of the last byte). This will allow your inline device to hear the DUB Response no matter what port it occurs on.

Originally Posted by dannito

1.1 Listening to each Command port, and soon as one of them is pulled to LOW state it must route its data to responders PORT so the console could receive it. As well as to "mute" the rest of the Command ports during its data delivering (?).
OR
1.2. Just route all the data received from each Command port to Responder Port?
(Is it 1.1 or 1.2 ?)

There's no required behavior, either behavior is valid. But, you do need to consider that the device being discovered may be attached to the responder port, not just to the inline device's downstream command ports.

A common mistake is to simply AND together all of the command ports and drive the resulting waveform back to the responder port during the discovery response period. This works if all of your fixtures are on the "outputs" of the splitter, but will create bus conflicts if there are other fixtures on the "input" port.

Originally Posted by dannito

2.0. The time period for the port turning is 5.8mS? Then it switches back to normal forward data flow.

The 5.8ms discovery response period includes time for transmission delays, as well as 200us of extra margin, and is officially only valid at the controller.

For inline devices it can be a bit harder to determine what value to use. You'll want to use a value somewhere between 2.9ms (DUB response delay + Max packet time) and 5.8ms. I think I use 5.6ms in my implementations.

Originally Posted by dannito

3.0. During non-Discovery mode, after receiving an RDM request packet, the first port that is pulled to a LOW state for the start of a BREAK becomes the active port. If the Port which is pulled LOW is Responder port, the In-line device must return to normal data flow mode. If this port is not Responder, it must send its data to:
3.1 Only to Responder?
3.2 Every other ports on the device?

Again, either behavior is valid. Personally I prefer to send it to all ports on the device because it allows you to connect a sniffer to any port in the splitter, which can make for easier troubleshooting.

Originally Posted by dannito

Please accept my apologies, but I am new to this and it's all I can understand reading the standard.

No need to apologize. You're asking good, solid technical questions, which is exactly why this forum exists.

[dannito]

Hi Ericthegeek,

thank you very much for the comprehensive explanation! Sorry for my late response, but I had some hardware roadblocks to overcome.

There are some questions emerged after I reviewed your answers. For instance, what about DISC_UN_MUTE message which is supposed to be sent by the controller prior DISC_UNIQUE_BRANCH in order to unmute all muted devices? Should I add it in the port-turning algorithm during Discovery? Same goes for the DISC_MUTE?

And what about Missing Response, what will happen then?

There's no required behavior, either behavior is valid. But, you do need to consider that the device being discovered may be attached to the responder port, not just to the inline device's downstream command ports.

A common mistake is to simply AND together all of the command ports and drive the resulting waveform back to the responder port during the discovery response period. This works if all of your fixtures are on the "outputs" of the splitter, but will create bus conflicts if there are other fixtures on the "input" port.

Is this the reason the device should listen to Responder port too? If it is pulled LOW then the repeater should go to normal data flow (?)

The 5.8ms discovery response period includes time for transmission delays, as well as 200us of extra margin, and is officially only valid at the controller.

For inline devices it can be a bit harder to determine what value to use. You'll want to use a value somewhere between 2.9ms (DUB response delay + Max packet time) and 5.8ms. I think I use 5.6ms in my implementations.

Again, thank you for this. I will keep that in mind when testing the hardware.

Again, either behavior is valid. Personally I prefer to send it to all ports on the device because it allows you to connect a sniffer to any port in the splitter, which can make for easier troubleshooting.

If I go with routing the data from the active to all the ports, I think I need to change a little the concepta as I am trying to build opto-isolated repeater. Maybe I will stick to data sent only to responder for now, just to run and test it. Later I might change it to all ports.

No need to apologize. You're asking good, solid technical questions, which is exactly why this forum exists.

Thank you for the encouraging words, but I am really a RDM noob!

Cheers,
Dani

[ericthegeek]

One slight correction to my earlier post: I wrote:

Originally Posted by ericthegeek

For inline devices it can be a bit harder to determine what value to use. You'll want to use a value somewhere between 2.9ms (DUB response delay + Max packet time) and 5.8ms. I think I use 5.6ms in my implementations.

I forgot about section 4.2.1.1 of the E1.20-2010 standard that says:
"the in-line device shall return to forward data flow no sooner than Table 3-2 Line 2 Minimum Time minus 200μs from Table 3-2 Note 3. The in-line device shall be capable of returning to forward data flow no later than Table 3-2 Line 2 Minimum Time."

Based on this, during the discovery response period you have to turn around after between 5.6 and 5.8ms, not between 2.9ms and 5.8ms.

Originally Posted by dannito

For instance, what about DISC_UN_MUTE message which is supposed to be sent by the controller prior DISC_UNIQUE_BRANCH in order to unmute all muted devices? Should I add it in the port-turning algorithm during Discovery? Same goes for the DISC_MUTE?

As a transparent in-line device, there are two kinds of turnarounds you have to handle. The two differ in the format and timing of the expected response.

The first is when you see a Discover Unique Branch request from the controller. When you see this, you have to switch all ports into receive mode and wait for a discovery response for 5.6 to 5.8ms. When you see activity on one of the downstream ports you switch to reverse data flow for the remainder of the response period. When you see activity on the upstream port, you switch for forward data flow. The response does not have a break. This kind of turnaround is only used for DUB requests (not for Mute and Unmute).

The other kind of turnaround is used for all other requests, including Mute, Unmute, and any Gets or Sets. In this case, the response has a break before it, and you're allowed to shorten the break by up to 22us.

Originally Posted by dannito

And what about Missing Response, what will happen then?

Responders must respond to a request within 2ms (Table 3-4 line 1), and the system can have up to 704us of delay (Table 3.2 note 2)

Controllers must wait at least 3ms before deciding that a response has been lost (Table 3-2 line 5).

This means that after the end of the request, you should wait between 2.7 and 3.0ms for the response to start. If it does not you can assume that the response is lost and return to forward data flow.

Originally Posted by dannito

Is this the reason the device should listen to Responder port too? If it is pulled LOW then the repeater should go to normal data flow (?)

Correct.

Originally Posted by dannito

If I go with routing the data from the active to all the ports, I think I need to change a little the concepta as I am trying to build opto-isolated repeater. Maybe I will stick to data sent only to responder for now, just to run and test it. Later I might change it to all ports.

It's easier and fully functional to do it the way that you describe. Many other splitters behave this way.

Originally Posted by dannito

Thank you for the encouraging words, but I am really a RDM noob!

We all have to start somewhere. You've actually picked a challenging place to start. I've built a controller, a responder, a sniffer, and a splitter. It's my opinion that an intelligent, protocol-aware splitter is the hardest part of RDM to get right. It's easy to get mostly right, but the timing has to be exact, and there are lots of corner cases to deal with (for example, how do you deal with a partial response, or a corrupt checksum?). You'll want to do lots of interoperability testing, and consider attending one of the periodic RDM plugfests, they're a great way to test a product like this.