1

Topic: CM-1 and XDAB clock interactions

Can someone explain how the  CM-1 and XDAB clocks interact? How  should priorities be set?
Why does the system fault briefly when CobraNet is unplugged (even from non-conductor)?
Ta.

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

2

Re: CM-1 and XDAB clock interactions

Hi Phil.

Charles mentioned this some time ago, but the details aren't 100% clear to me - he's really the man to talk to (he's back from his holidays on Monday 3rd September).

I suspect it may be a system-level problem that was not fully considered in the clock architecture of the Nion. From my experience of system clock management in other technologies (before I joined Peavey), I suspect that unplugging CobraNet causes clock source to be switched internally, creating a phase jump in the audio clock which XDAB can't cope with.

I don't have an answer on how to set priorities: someone who's more familiar with designing systems with Nions and configuring them may be better placed to help you there. I'm sorry I can't be more helpful.

Michael.

3

Re: CM-1 and XDAB clock interactions

Here are some additional details.

The tightest and most critical clock in the system remains the CobraNet Conductor.  So if there is CobraNet coming into any NioNode of a Project, the Project and the XDAB will lock to the CobraNet Conductor.  If there is no CobraNet being processed, then the internal clock of one of the NioNodes will become the master for project.

So if the CN Conductor is the master clock, and the XDAB has locked to this master, then it would make sense that if the CobraNet is disconnected, the system would fault as the internal clock become the master clock.  And would fault again, as the Nions re-sync their clocks to the CobraNet Conductor when it comes back on line.

A short post on the Blog by Michel, called "XDAB Leader", is helpful to understanding this topic.  Perhaps Michel has some additional insight to add (and perhaps the original should be moved to this site).

Make it intuitive, never leave them guessing.

4

Re: CM-1 and XDAB clock interactions

Hey Fergy,
I see that if the Conductor is removed (and another NioNode doesn't then become the conductor) that the clock would switch across to internal. But... conscious of this, I removed CN from the non-conductor n3 in my XDAB'd pair. The system still faulted, and seemed to shuffle clocks around before settling back.

Also, what's the Blog you mention? Have I missed some other source of info?
Thanks, Phil

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

5

Re: CM-1 and XDAB clock interactions

Phil, I've run into this in the past. If the Nions are using CobraNet, then the XDAB clock is basically dependent on the conductor. We tried many things but found that the only complete way to make sure you don't have XDAB renegotiate upon conductor changes, is to use a conductor external to the Nions. Since the Nions default to high conductor priority, this has to be manually set using some kind of SNMP manager. Keep in mind that conductor capabilities depend on the CobraNet interface so not any CobraNet device can become a reliable conductor for a Nion system, specially for a large system.

6

Re: CM-1 and XDAB clock interactions

Thanks Rodrigo,
I guess these are issues that show up more on the bench while we're plugging things in and out than on a real project with a stable network.

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

7

Re: CM-1 and XDAB clock interactions

Some clarification:

When a set of NIONs are connected by XDAB, they all share a common clock.  One of the NIONs is the clock master for the rest.  You can force a particular unit to be the XDAB clock master by editing the NioNode device properties and increasing its XDAB Clock Master priority.  This is, in fact, recommended.

If one of the NIONs is connected to CobraNet, its Clock Master Priority is increased automatically.  It then receives its clock from the CobraNet interface, and drives the clock over XDAB to all the other units.  If the CobraNet interface in the NION is not the CobraNet conductor, it is receiving its clock from some other CobraNet device on the network (the conductor).  If the CobraNet conductor changes, there is a momentary disruption of the clock data going to the NION.  This disruption is passed to the XDAB and can result in  an XDAB clock reconfiguration, causing all audio to drop out momentarily on all NIONs in the cluster.  If you see  "xdab reconfiguration" in your log file, this is probably due to a conductor change.

Because of this, I recommend that you increase the CobraNet conductor priority for the NION CobraNet interface.  You can do this from the NioNode device properties.  This way, a conductor change will only occur if the NION itself is disconnected from the network or is shut down.

If you have multiple NIONs in an XDAB cluster with CobraNet in use, or if multiple clusters are connected by CobraNet, life gets a little more complicated.  I'll address this in a later post...

8

Re: CM-1 and XDAB clock interactions

I too have run into the need for moving the Conductor to another Cobranet device on the network. There was an instance where for some reason, 80+ Crest CKi amps with Cobranet inputs were causing the CM-1 module to crash in the NION. Moving the Conductor to a CAB4n was the cure. The CAB devices in NWare have a place to edit the Conductor priority on the Advanced tab. Default is 32. NIONs default to 64.

The only true wisdom is in knowing you know nothing. -Socrates

9

Re: CM-1 and XDAB clock interactions

Running standalone the,  CobraNet card (CM-1) supplies the master audio clock to the NION, which in turn feeds it back to the CM-1.
In an XDAB cluster the rules change a little. The same rule applies if the device is the XDAB master. But if the NION is an XDAB slave, then the NION will get its master clock from the XDAB and then feed that to the CM-1. So the CM-1 master clock is coming from XDAB in a NION that is not the XDAB master.


SO.. IF you have an XDAB cluster
THEN .. all of the CM-1s in the cluster can be performers, i.e. they can all get their audio clock from the same CobraNet device outside the cluster and it doesn't matter which NION in the cluster is the XDAB clock master.

BUT... (( AND THIS IS IMPORTANT))   if one of the devices in the XDAB cluster is a conductor, THEN it MUST also be the XDAB clock master. If you allow a range for priorities and let the NIONS automatically negotiate this, then the cluster should wind up with the XDAB master as the conductor node automatically.  But if you explicitly set priorites to override this and make the wrong choice, you could end up with the wrong relationship between XDAB master and CobraNet Conductor within the cluster.

If the XDAB master is also a CobraNet  performer and  one of the XDAB slaves is the  CobraNet conductor, then the XDAB master is trying to generate its master clock from the CM-1 conductor. But the Conductor is an XDAB slave and so is getting its master clock from XDAB.  So you wind up with an open loop as far as clock sync closure goes.

When this happens you can get a VERY long settle time on the clock sync between devices in the cluster with multiple resets and XDAB resyncs.  Getting everything back in sync becomes just a random timing  affair of what resets  when and allows the clocks to sync up. Eventually it can recover but only by chance. Theoretically it should never recover if all the devices are running and are out of reset when in this configuration.

I'll try to write up something more complete and definitive on this but if you just remember this then you will be OK:

If one of the NIONS in an XDAB cluster is the CobraNet conductor, then that NION must also be the XDAB master.

Nihilism is best done by professionals

10

Re: CM-1 and XDAB clock interactions

The exception to this is if you have multiple Conductors in a cluster.  This can happen if you have multiple CobraNet networks.  This is a complicated topic and we are working on more complete documentation.

11

Re: CM-1 and XDAB clock interactions

The project that initiated this post is still haunting us!
The added complications are:
Optocore system running at 96kHz, feeding AES (124ch) to multiple Nio-AES cards in XDAB cluster of 12x n6 (also 96kHz).
CobraNet running at 48kHz connect NIONs to another system (Audia), using down-sampling in NION.

Before going into all the permutations that have been tried, has anyone done battle in this area?

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

12

Re: CM-1 and XDAB clock interactions

Could you give us some more details? Is this all one Cobranet VLAN? Who is the Conductor? Who is the XDAB master?