SQ5 with two DX168 – SLink Error flashing

[Los Lobos]

both DX168 in CASCADE Mode, all “SLINK Error LEDs flashing”

what´s the prob?

thx

[Mfk0815]

in 99% percent of all cases it is a problem in Layer 8;-)
In this case, the problem is that you gave us too less information.

[SteffenR]

both DX168 in CASCADE Mode, all “SLINK Error LEDs flashing”

the LED is labelled LINK/Error

yellow flashing indicates an established network link
like on most network devices

[Jeannot17229]

Hello,
Two days ago, I had the same problem. Have you find a solution?
Thanks for your help and answer. I didn’t solved the problem and I rented two others DX168 and it worked.

[peterm2]

I think I know what the problem is. I experienced it myself a number of times before I realized what was happening.

If a DX168 receives power for a short time, and then no more, the device goes into a reset mode. The next time it boots up, the unit will get the latest firmware from the SQ mixing console. This works fine, unless 2 devices are connected (cascade mode). Then they won’t start up again.

The solution is simple, but clumsy. You remove the power cable from both devices. You disconnect the link cable between both devices. Now you give the first device power again. You wait until it is ‘ready’ (firmware synchronized with mixing desk again). Then reconnect the link cable and start up the second device. Then it works again.

A not really practical way of working! I’d like to see a solution to this problem, as our DX168s are in a hard-to-reach place, and it can also cause stress for some sound engineers. The problem may not occur if both devices are connected to a separate SLink port, I’m not sure. In that case I might consider buying the SLink expansion card, or connecting them via a DX-Hub. But actually, this behavior should not occur (devices that no longer turn on) and it wouldn’t be so nice to have to make an extra investment for that.

Best,
Peter

[KeithJ A&H]

Hi all,

The firmware is checked every time an expander is connected and updated to match the console if necessary. It is stored within the console.
For example, if you connect a DX168 to a dLive and then later to an SQ, the firmware will be updated one or two times. Or if you’ve updated the firmware of the console, this may include an update for the expander which be automatically applied when the expander is reconnected after the system is restarted.
If the firmware is already matching, no update will take place.

The expander firmware can be lost if the unit is powered up and then powered down within seconds as @peterm2 says, though this just means it will download the firmware again when reconnected.
It will take slightly longer to update expanders further down a cascade i.e. through other expanders or a DXHub, so if there are problems, then as @peterm2 suggests, it will simplify and speed up the process if you connect one expander at a time directly to the console.

I’d agree that this isn’t a practical thing to be doing on every boot, but then the power should never really be switched on and immediately off again before the system has booted fully.

In 99% of cases, the automatic firmware updates won’t actually take place very often at all, being that the same expanders are often being paired with the same consoles.
So it would only be when there is an update to the expander firmware and even this doesn’t happen with every console firmware update!

There is more on the automatic updating of firmware and LED states for expanders along with other information on connections to an SLink port here – https://support.allen-heath.com/hc/en-gb/articles/4403666880913-General-Connecting-to-the-SLink-port-

Thanks,
Keith.

[peterm2]

Thanks for your quick response and additions!

If the firmware process would only take a little longer with a cascade setup, then there would be no problem. However, in my experience, the devices simply stop working until they are manually disconnected and reconnected one-by-one. Even after waiting for a few hours (!), the devices do not start up automatically.

If this problem only happened with an actual firmware update of the mixing console, then it wouldn’t be a big problem. In practice, we have now had a number of times that the expanders lost their firmware because the power supply was switched on and off too quickly. That does make it more annoying.

Would it work more stable if the second DX168 were connected to a second SLink port on the mixing console?

[Jeannot17229]

Thanks a lot for your quick response and explanations.
Now, my 2 DX168 are working very well.
Have a nice day.

Jeannot

[KeithJ A&H]

@Jeannot17229 – Great!

@peterm2 – Hmm. As you probably realise it should only take a few minutes at most. We’ll have a go at trying to reproduce what you’re seeing so we can figure out what might be going on. If you haven’t already, you could contact us using support.allen-heath.com with the information you’ve already provided (or just a link to this thread) along with letting us know more about the powering of everything and how it’s all connected (cable type, length, whether it’s a direct connection…) as this might help if we can’t reproduce. We’ll also be able to keep you updated on any findings.

Thanks,
Keith.

[BradWalker]

This is an independent issue from the SQ-to-GX4816 thread I just posted resolution to…

I went on a service call for a system we installed about 18 months ago. SQ5 -> DX168 in local rack where mains amplifiers and wireless receivers were housed, then -> cascaded to another DX168 in musician’s area. The issue was “no sound coming out of the main speakers.” This system is used every day with multiple users, some skilled, most not. This is the first time there’s been any problem.

The SQ5 I/O showed hatch-marked S-Link inputs, and the first DX168 showed power and network connection, but no “Ready” LED lit up. I should have but did not check the status indicators of the cascaded DX168. I do know it stays powered on almost continually, because the band members just leave it on. I do know we were getting sound out of a self-powered stage monitor connected to an output of the cascaded DX168 even while the main outputs were not working.

Several power-cycles of the system (mixer/FOH equipment and amp rack with first DX168 in it are sequenced from a single on-off switch) did not change the problem.

In the process of checking connections, I disconnected the _cascade_ ethercon cable from the first DX168. When I plugged it back in, the “Ready” LED on this first DX168 lit up again, and sound was restored. S-Link patch points in the SQ5 I/O screen were solid squares, no longer hatch-marked.

I couldn’t get the problem to repeat itself after this, so it leaves me wondering what the actual cause was. Would having a cascaded but always-on DX168 that finds the SQ5 before the first DX168 in the rack powers up cause this on some occasions? But why wouldn’t it be consistently a problem? This is the first time it’s been reported in 18 months.

Hopefully this extra data point helps with the troubleshooting. Keenly interested in what Keith and the team find out!
Brad

[Author]

Posts