Troubleshooting | AES67 PTP Grandmaster issues with Multiple Q-SYS Core110F’s
Learn how to address potential issues that could arise when connecting multiple Q-SYS Core110F’s together using AES67 PTP Grandmaster.
Affected Products
Hardware Model/Series | Core 110f |
Software | AES67 in QDS |
Problem
AES67 PTP Grandmaster issues with Multiple Q-SYS Core110F’s.
Causes
In installations using multiple Q-SYS Core 110F’s with AES 67 devices, most Integrators use LAN A for linking to the local AES67 device and LAN B to link the Q-SYS Core’s softphone to the customer’s corporate LAN to access the VoIP PBX.
When the AES67 stream was setup in each system, the AES 67 device became the PTP Grandmaster source on LAN A. The Q-SYS Core’s status window shows the Mac address of the AES 67 device that has become the grandmaster. The stream between the two device is fine until the Core 110F is plugged into the corporate network via LAN B.
At this point the Q-SYS Core 110F’s have discovered each other on the LAN B corporate network side and automatically try to select the best PTP clock source as a new grandmaster. Once the clock source has changed, the AES67 streams drop out and the core reports a PTP clock mismatch on LANA.
Solution | Workaround
By all accounts, it does not seem possible to link the AES67 device and a Q-SYS Core 110F successfully via AES67 unless the AES67 device became the PTP clock master.
Changing clock domains on each of the cores to try and avoid them syncing together wouldn’t work, the Q-SYS core again report a PTP mismatch between the AES 67 device and the Q-SYS core on LAN A.
The solution would be to disable PTPv2 on LAN B this can be achieved in Q-SYS Designer 6.1 or higher. To activate this feature select “Design Properties” under “File” in Q-SYS Designer, in the pop-up box select “Yes” in the drop down next to “PTPv2 Disable LAN B”.
Once this is done, each core will be reverted back to their respective AES67 device master clock sources on their local LAN A and the AES67 streams re-established.