View Single Post
Old August 27th, 2020   #1
Junior Member
Join Date: Aug 2020
Posts: 4
Default Questions on In Line Devices

Hi all, we're implementing a new transparent in-line device and I have a couple of questions on my interpretation of the spec.

1) Port Turnaround during Discovery. What counts as a discovery request here? Is it anything with the DISCOVERY command class? Or is it only DISC_UNIQUE_BRANCH?

DISC_UNIQUE_BRANCH is the only message that should have collisions, and as such this rule seems like it should only apply to that, but I saw some other posts here suggesting that it was the entire DISCOVERY command class.

2) When should an in-line device return to forwards data flow during non discovery transactions, when errors are detected with the responder's response?

Let's say that we have a responder that watchdogs at some point during it's transmit. The in-line device has to eventually time out and return to forward data flow in order to catch the controller's next request. I think the key to this is how should a controller treat a partial response? Table 3-2 Controller Packet Spacing Times, has:

line 4: responder response -> controller any packet, min 176us
line 5: controller request -> controller any packet, min 3ms

What should the controller consider the start of a reply? A falling edge on the line, regardless of whether it's for a valid break or not?

3) 4.2.1 Port Turnaround states:

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. Note that this port may be the responder port, in which case the in-line device shall return to forward data flow. Otherwise, data from the active port shall drive the responder port and may drive all other command ports on the in-line device.
In the case where a command port receives the start of a response should we disable reception from all other command ports? A well behaving system should not have two responders respond in this case since it's not a discovery message, but there could be badly behaving responders on a system causing this collision. Should the in-line device block that or allow it to reach the controller?


4) If the responder were to send a break and then never send it's first data slot. The controller should timeout the MAB after 88us according to table 3-1. When can it start it's next frame? Table 3-2 line 4 would suggest 176 us after the last rising edge of the responder (end of break), since it's already timed out the MAB after 88us, that would mean the controller could start to transmit in 176us - 88us?

Same for a timeout in the inter-slot timing. The controller would time out an inter-slot after 2.1ms, so when could the controller start it's next reply? It should be 176us after the last stop bit of the last responder slot, but it's already been 2.1ms since then, so could it start immediately?

In these two cases when should the in-line device turn the bus around?


Last edited by Andrew_Parlane; August 27th, 2020 at 10:24 AM.
Andrew_Parlane is offline   Reply With Quote