AVO Pearl issue - refresh rate?

[nflutter]

Firstly I know I'm setting myself up for abuse BUT I've bought 8 Chinese Beam 200s (sharpy copies)....... there we go, I've said it!

 

Using them on my AVO Pearl classic (NOT a Chinese copy!) and they work fine BUT when the fixtures are in blackout, very randomnly I get a single strobe flash from one fixture. It does appear to happen on all of them but only one at a time and it's very fast, but bloody annoying! It's like a bad DMX cable or unterminated line and yes I have terminated the line and using all proper DMX cable, no mic leads!

 

It doesn't seem to happen when DMX line unplugged from the fixtures only when theres a DMX signal.

 

Could it be the refresh rate? Have to say I know very little about the refresh rate but know it's there, had to fiddle with it a few years ago when some LED battens were being weird and after slowing the rate it fixed the issue.

 

Any info on refresh rate or any other thoughts appreciated.

 

Cheers

[timsabre]

If you set all the fixtures to DMX address 1, does it still happen? And if it does happen, do they all do it at the same time?

 

Refresh rate is how often a full packet of DMX (512 channels on the Pearl) gets sent out. In between packets there is an idle time. If fixtures are using slow processors, making this idle time longer by reducing the refresh rate can give them time to catch up with their internal processing.

[Caerdydd]

Equally try patching something in the desk at 512, some desks don't output the full 512 if nothing is patched that high.

[timsabre]

Equally try patching something in the desk at 512, some desks don't output the full 512 if nothing is patched that high.

Classic Pearl always 512 channels regardless of patch.

[nflutter]

I'll give that a go tonight and post back any outcome.

 

Also as far as playing with the refresh rate, am I right in saying it's 'service mode - user settings' then near the end of the list, just states a time in ms?

 

Not in front of console at the moment so quoting this from memory.... I can change the time with the up down keys, but also there's a number after the actual time in ms, from memory it changes with the timing, numbers like 66.6, 44.1 etc etc (that's from memory, don't quote me on those number). Do these numbers have a meaning? they seem to change randomly, is that right?

 

Any good articles online about understanding DMX signals a bit more would be appreciated, feel I should know more.

 

Thanks

[niclights]

Yes, yes and no in that order.

 

On behalf of Tim:

 

From section 12.1.1 of the manual (user settings):

 

13. xxx mcS - Sets the DMX idle time (the delay between the end of one packet and the start of the next). This allows you to slow down the DMX refresh rate if you have some equipment that can’t keep up. Increasing the delay will degrade the performance of the DMX link so you should not change this unless you have to. The figure in brackets shows the DMX refresh rate in milliseconds.

 

 

Try increasing this. In my experience you usually only need to increase it by a small amount to stop flickers.

[nflutter]

Okay I'm at the desk now, I'm still a little confused at what I'm looking at in the user settings. No.13 in the settings list reads....

 

189 mcS (50.0)

 

Using the left and right arrow keys I can step up and down the 1st number (189 in this case) BUT the number in brackets changes every time with absolutely no pattern so even if I step up and come back down to 189 the number in brackets will usually be different, even when I scroll up and down the user settings list the number in brackets is changing every time, what is this number?

I've set it at the default rate of 189 mcS and addressed 2 of the fixtures the same, just sitting and watching now!

Cheers

[kgallen]

Is RDM being output by the desk? Try turning this off or patching the fixture above about address 250.

[Caerdydd]

No RDM in a pearl.

[peza2010]

Having recently had worked with some horrible chinese fixtures with a similar problem, the only way around it was to run the problem fixture from a DMX buffer.

 

I presume one, or multiple fixtures were spitting nonsense from the output.

[nflutter]

Well after an evening of playing around I'm more confused than before.....

 

Not sure it's anything to do with the refresh rate, I played around with the rate and actually found that a shorter delay time works better, the higher I went the more the issue seemed to happen, going down to around 100 mcS seems to stop the random flash BUT if I leave all the intensities at 100% I'm now seeing a little flick on tilt and sometimes even a gobo spins in. Interestingly the 'flick' I get on tilt is more drastic if the packet delay is higher, if the delay is short it's a tiny flick but go high.... I went right up to about 6000mcS and it was a large flick and I think the colour was moving as well but the it rights itself.

 

I tried setting all fixtures at the same address but rather than all fixtures glitching at the same time, it's the same as before, only one fixture glitches at a time so now I'm thinking the glitch is not in the DMX signal? But if I disconnect the DMX line it seems to stop?

 

I also tried with my Titan One dongle which gave me more control over the DMX settings but just the same, again tried everything but still couldn't eliminate the issue completely.

 

 

Cheers

[Tomo]

Two (sadly) common DMX reception mistakes that can cause of this are when the fixture uses "framing error" as Break, and when it can't empty the receive buffer fast enough (losing count of bytes).

 

Using framing error as Break causes a fixture to interpret a framing error followed by a zero level as being the break & start code, effectively briefly repatching themselves to a random, much higher DMX address.

 

Being unable to empty the receive buffer makes them lose count (drops the odd byte), effectively briefly repatching themselves at the next address up.

 

To test for these you could readdress to DMX address 1 and the 'highest possible':

• If it's misdetecting Break, then the fault will be much more common at DMX address 1 and rare at the top.
  - In theory you can also test for this fault by setting every other DMX address to 1/255, except that many cheaper devices don't check the start code.
   
  
• If it's losing count then the fault is likely to be rarer at DMX address 1, and more common at the top.
  - Though not always, as it might be fine until reaching the values it actually uses. In this case the address makes no difference.
  

 

Losing count is easily worked around by using a slower DMX refresh rate - on most consoles, the options to slow down DMX refresh rate increase all of break, mark-before-break, mark-after-break and interbyte mark timings.

[martinw]

It's the interbyte time (or lack of it) rather than the refresh rate that is the cause of most reception problems. The fixture can't process the bytes quickly enough, and the fifo fills up until it overflows. If the firmware is really bad, it won't spot the overflow has happened, and will just keep receiving the packet as though nothing had gone wrong, causing all the subsequent channels to jump by 1 (or more).

 

Be wary of the 'refresh rate' setting in some consoles. Ideally, this would mean adding some interbyte time after each byte, but it's easier engineering just to add a big gap at the end of the packet. Both methods will reduce the refresh rate, but adding interbyte time is much more likely to fix your receiver issues.

 

In the console, what you want to do is dump as much data into the uart fifo and then do something else whilst it gets sent, but especially with older and cheaper microcontrollers, this often results in no interbyte time. There are various tricks you can do to get round this, but it usually needs to be considered when the design is started, it's hard to add this afterwards.

 

Martin