[hsas-shortcode speed="30" direction="left" gap="120"]
Filter by Topic
  • AES67
  • Analog IFB
  • Analog Intercom
  • Call Signals
  • Dante
  • Dante Clocking
  • Firmware Updates
  • Gooseneck Microphone
  • Intercom Audio Engine
  • Live Sports Production
  • Live-Link
  • Model 208
  • Model 348
  • Model 373A
  • Model 380
  • Model 391
  • Model 48D
  • Model 5401
  • Model 5401A
  • Model 5402
  • Model 5421
  • Model 5422
  • Model 5422A
  • Model 76
  • Model 76B
  • Models 214/215/216
  • New Release
  • Party-Line
  • Performance
  • Recommendations
  • ST 2110
  • STcontroller
  • Testing & Troubleshooting

06-Sep-2018 Dante Clocking Model 5401

Using Two Model 5401 Dante Master Clocks for Redundant Operation

Model 5401 Dante Master Clock

Model 5401 Dante Master Clock Lab Photo

The Model 5401 Dante Master Clock has proven to be a solid product that’s found successful use in the field. But trying to use two units on a single local are network to achieve redundant master clock operation currently has one limitation that’s worth noting.

In the Dante Controller software application both Model 5401 units will, by default, appear as Preferred Master and allow an external sync reference. Dante will automatically select one of the units to be the active clock master. (Which unit is specifically selected will depend on which is recognized on the LAN first and/or the lesser of the two units’ MAC addresses.) If the selected Model 5401 unit is no longer able to serve as the clock master the other Model 5401 will automatically be selected. But the switching process when changing between Model 5401 devices is not immediate nor necessarily “click” free. There can be an audio disruption for up to 10 seconds. After this interval the newly-selected clock master should perform correctly.

We don’t like this switch-over performance limitation but unfortunately we can’t do anything about it. Firmware within the Brooklyn II module, the device that implements Dante connectivity within the Model 5401, is in charge of this function. And as of now we don’t have control over the parameters that we’d need to do a smooth change-over. We’ve asked about this limitation, more than once, and have been informed that this is just the way it is. We have been told that it’s possible that future firmware releases will allow this condition to be corrected. If that comes to fruition we’ll certainly implement changes as soon as possible. The potential to resolve the issue is certainly encouraging and we hope that it will come to pass.