Relative frequency of UID set changes to RDM messages events

[nomis52]

Hi,

I'd like someone to validate an assumption I've made while writing an RDM implementation or tell me that I'm completely wrong .

I'm looking for the relative frequency of UID set changes to RDM message events (get/set pid). My gut feeling is that this will be at least 1:100, i.e. on average for every time this UID set changes (one or more UIDs added/remove) there will be 100 or more RDM messages sent.

Does that sound about right?

Thanks,

Simon

[sblair]

Hey Simon,

I'm not certain if I'm fully following you here. Are you asking the relative ratio of RDM GET_COMMAND messages to SET_COMMAND messages?

If so, I would say that yes you will many more GET messages than SET messages occuring. There are times (configuring/patching a rig) where the number of SET messages will dramatically increase.

[nomis52]

Ah sorry, reading my post I've realized it's ambiguous. By 'UID set' I mean the group of UIDs that were discovered for a universe.

So I'm asking for the relative frequency of these two events:

i) The Ongoing Device Discovery process noticing a change in available UIDs
ii) Any GET/SET command being sent.

[sblair]

Ahh, I see what you are asking now. There isn't any specific requirements concerning the frequency of these.

You want the ongoing discovery to happen fast enough that it appears to be semi real-time...i.e. within a minute or so ideally.

When a new device is discovered there are only a couple messages it should need to fire off to get just enough info in order to put it in a display and then it can drill and get the remaining info as needed.

From a practical standpoint, the speed is going to be determined by the number of devices on the data link. The fewer the devices the faster the controller can get around to querying them all. Unless a controller is in the middle of a crossfade, then doing a 1-1 interleave with RDM and NSC packets is pretty typical.

[ericthegeek]

I don't think there's any way to answer that question. During rig setup or wring-out, you could see the UID list change several times in a minute. Someone unplugs one branch from the RDM hub and 20 devices disappear. They fix a cable problem, plug it back in thirty seconds later and new devices come online. A loose connection could cause the list of reachable devices to change from second to second.

In other situations, the rig won't change for months on end.

Can you be more specific about the problem you're trying to solve? A DUB request+response is slightly more expensive time-wise than most GET/SET request+response pairs, but only by a few milliseconds.

[nomis52]

Originally Posted by ericthegeek

Can you be more specific about the problem you're trying to solve? A DUB request+response is slightly more expensive time-wise than most GET/SET request+response pairs, but only by a few milliseconds.

I building a multi input -> multi output rdm message router (which leads to other interesting problems) and I'm trying to decide if I optimize the UID -> output port data structure. I can make the lookups more efficient by increasing the complexity of building the structure when the set of UIDs change.

[sblair]

When a system is up and running you'll find that it is very stable with few UID changes.

There are two major points where you'll see a lot of UID change chaos happening though:

1. When a system is getting powered up for the day, as each part a system is powered on you'll see a lot of UID list changes. This also includes setting up a system for a one-off show.

2. When troubleshooting a system. At that point you'll see cables being swapped around and plugged in and out, so that will result in a massive amount of UID's coming off and online.

Hope this helps.