Hog III DMX Dynamic Refresh Rate?

Mark,

Our DMX refresh rate is almost always going to have slight variations, but this is still well within the DMX specification. There are also certain circumstances that can cause brief drops in refresh rate. If you are running lots of concurrent crossfades (or effects) and you then change page, the console sends the data for all of the playbacks on the new page to the DP2000s and they need to process and prepare that data while they're still running any active playbacks. This can cause a brief drop in refresh rate, but these are still usually just a few of frames in duration and still at allowable refresh rates.

You can adjust your DMX refresh rate from the DP2000 front panel or from its properties page in the network window on the console.

I haven't heard of "dynamic DMX mode" before. Can you explain any more about what this is?

Thanks.

Thanks for the quick response.

To answer your question about the whole "dynamic DMX mode", apparently it is some mode that will make it so the DMX rate is not constant. Didn't make much sense to me, but I thought I'd see if such a thing existed and wanted to make sure it wasn't enabled.

The problem I'm having is this - I'm seeing DMX dropouts, which causes the DMX recorder to think that the board has failed and puts it into a mode where it starts sending out its own DMX signal. While great when the board actually dies, I certainly don't want it happening when it hasn't.

As far as having a lot running, I wish that were the case, but I'm seeing these dropouts on basically static looks, so I'm not real sure why that is.

As a somewhat aside, I'm also seeing this same problem with the Jands Eschelon.

Mark,

What DMX recorder are you using and since you mention the Jands Eshelon has similar problems I am curious what products you have found that work well with this recorder. This might help us to determine where the problem occurs.

We have seen other products that required a change in their DMX reciever code to better function with particular consoles. This is not unusual and we have helped them to debug and understand how to properly implement their products. We are here to help as best we can whether the problem is ours or on the part of another product.

thanks,

Brad,

The DMX recorder we're trying to use is a Swisson XRC-150. We previously tried their XRC-100 and had similar problems, and upgraded when this one came out. I've been working with their engineer in Switzerland, and can give you his info if you'd like that.

As for consoles this has worked well on, unfortunately (in this case) we're pretty brand specific, sticking almost exclusively to the Hog consoles, of which all have the same problems (Jands Eschelon, Hog 3PC, Hog III). We also have conventional consoles like the Leprecon LBX series, which work fine with it, but I haven't tried it with other consoles that are controlling movers.

Thanks for all your help.

-Mark

I imagine what they're talking about with regard to "dynamic DMX" is the fact that the Hog's DMX refresh rate is not constant. The refresh rate set in the DP's menu is the maximum allowable refresh rate, but under sufficient load the refresh rate can and will drop below the set rate. Odds are the DMX recorder is designed under the assumption that consoles will output refreshes at a fixed rate.

Why don't we output at a fixed rate, you ask? The Hog is designed such that the values in a given refresh are correct for only the instance in time that the frame is generated. As such, we only transmit when we have generated a "fresh" frame of data. Some consoles will retransmit a stale data frame to keep up the appearance that they're refreshing at a fixed rate. We do not do this as it affects the fixtures that are receiving the data. It gives the appearance of a steppy fade/movement and throws off the fixture's rate interpolation algorithms. However, I see how a DMX recorder designed without this in mind could experience issues.

Is there a way to set parameters on how and when the recorded decides that DMX has stopped being transmitted?

Jason Potterf
HES/FPS R&D

Thanks for your detailed reply.

Unfortunately, from the user interface, I see no way to adjust the DMX recorder to handle how the Hog sends data. It would have to be something handled on the engineering side. According to the information I've gotten from them (and it could likely be far more complex than what I've been told) is that the DMX recorder needs to see at least 20 frames per second otherwise it thinks the data signal has been lost.

I'm going to send your post on to the engineer I've been working with, and hopefully we can figure out a solution that will work. Let me know if you want his info so you can work with them directly.

-Mark

Mark,

Some DMX splitters regenerate the DMX signal they receive. You may have better luck if you use one of these splitters between your Wholehog and your DMX recorder.

Thank you for the idea, it is something I can try as a stopgap solution.

Typically I don't have any reason to put the splitter before the recorder (normally I am set up with the Hog 3 and the DP at the mix position and the recorder is right there), and would hate to waste one simply to regenerate the signal. But until I figure out a better solution, that may be the way to go.

On a bit of an aside, I do know that I have seen some of the "steppy fade/movement", especially when using Mac 550s (in 16 bit mode) when they're moving slowly using the Hog 3. Could this be caused by a splitter regenerating the signal and causing the rate interpolation algorithms on fixtures that Jason was talking about to screw up? Or is that unrelated?

Mark,

I just finished a show with 14 MAC-550s in 16 bit mode and had similar problems. The fixture looks like it is being shaken-up as is moves from position to position correct?

It is basically a probelm with the motors in the fixture itself when set to "FAST". The workaround solution is to "force" the fixture to use "MED" or "SLOW" mode to smooth things out.

On H3 you so this by changing the the "Position Time" using "Track" mode(on right encoder next to Pan + Tilt). 100% is FAST mode, 75% is MED mode and 50% is SLOW mode.

The biggest pain though is that the fixtures then behave as if a "damped" fade path has been applied and add time to the overall fade, so you will need to adjust your fade times to compensate.:angryfire: This is unfortunately true with almost all Martin fixtures.

It is a bit of a pain-in-the-rear, but it works. I would much rather have fixtures that have appropriate sized motors that are powered properly in the fixture, but it was what I had to work with.

Hope this helps.:)