1 Topic by wigl

  • wigl
  • Member
  • Offline
  • Registered: 2007-12-12
  • Posts: 13

Topic: CM1 Board Fault

I installed a system with a NION n3, 9 Cab4n and a Cab 16d. The system runs in Low latency mode with 2,66ms.
3 of the Cab4n are with the CM2 Board and 6 of the Cab4n are with the CM1 Board. The Cab´s with the CM2 Board and also the Cab 16d work fine but the others loose the low latency settings after a power cycle. The Cab`s work with the firmware version 2.9.11. With the firmware 2.9.12 the Cab´s fault Led is lighting.
Do you have an answer to this poblem?

Thanks,
Gerald

2 Reply by jvalenzuela

  • jvalenzuela
  • Initech programmer
  • Offline
  • From: Orlando, FL
  • Registered: 2007-10-10
  • Posts: 223

Re: CM1 Board Fault

As I understand it the latency setting is determined by the conductor. If those units are not acting as such, it doesn't matter what their latency settings are. They will respond based on the information in the beat frame.

Although this is what has been explained to me, I have experienced some other Cobranet products, non-Peavey gear in this case, that didn't work at all unless all the latency settings were set equal.

3 Reply by Fergy

  • Fergy
  • MM Tech Support
  • Offline
  • From: The Home Office--Meridian
  • Registered: 2007-08-15
  • Posts: 334

Re: CM1 Board Fault

If you are trying to run 5.66 latency with 2.33 latency on the same network, and it actually worked, you just got lucky.  The Conductor will only deal with one latency at a time.  (Makes sense, since two latencies would require two beat packets).

If you are using the same latency on a single network, and the question is solely about persistance, there is a "persistance" bit that must be turned on when using CobraNet discovery (make sure you are using the latest version from CobraNet.info) that should allow the CM-1 and the CM-2 to keep their settings after a power cycle.  I'm surprised that the CAB 16d can even do the lower latency, it is not supposed to be able to do anything but 5.66.

2.9.11(1) for the CAB 4n with CM-1 and 2.9.11(2) for CAB 4n with CM-2 is the only firmware that currently works with the 4n's.  2.9.12 is the current firmware for the CM-1 in the NioNode.

One last item, the lower latencies of CobraNet can be VERY, VERY tricky.  Be sure you really need the lower latency, and do good research, to make sure your project is a success.

Make it intuitive, never leave them guessing.

4 Reply by wigl

  • wigl
  • Member
  • Offline
  • Registered: 2007-12-12
  • Posts: 13

Re: CM1 Board Fault

I´m using the same latency settings on the network. I tried to set the "persistance" bit, but after the first power cycle the CM1 Boards loose the "persistance" bit and after the second power cycle the CM1 jump to the default 5,66ms. The CM2 Boards are okay!

5 Reply by wigl

  • wigl
  • Member
  • Offline
  • Registered: 2007-12-12
  • Posts: 13

Re: CM1 Board Fault

It´s just curious, if you don`t connect the CAB4n (with the CM1 boards) to the NION they hold the low latency settings after a power cycle. Maybe a bug of the NION firmware/software?

6 Reply by cobraguy

  • cobraguy
  • cobraguy
  • Peavey CobraNet Guru
  • Offline
  • Registered: 2008-05-28
  • Posts: 79

Re: CM1 Board Fault

I'd like to correct a commonly held misconception regarding mixing latencies on a network. You CAN most definitely run different latencies on the same network.
It could possibly not work well if you mix large amounts of HIGHER latency traffic that is also MULTICAST with lower latency traffic of any kind. At 5 1/3 mS 64 samples are sent every isochronous cycle. At 2 2/3 mS 32 samples are sent in 2 packets every 1/2 of a cycle and for 1 1/3 mS latency, 16 samples are sent in 4 packets every 1/4 of a cycle. So if you have enough higher latency traffic that is multicast, it could possibly eat up bandwidth within one of the critical 1/2 or 1/4 cycle times needed by the lower latency traffic. Chances are it will still be OK in most rational cases. You could do the math to figure out if it would work.  I have not yet done that.


But if all the bundles are unicast on a switched network, then there is zero possibility for interference and then you can absolutely send different latencies on the same net, 1 1/3, 2 2/3 and 5 1/3 mS with no worries. The only caveat, which you probably already know and which should be obvious,  is that only those devices set at like latencies can send/receive bundles to/from each other.

Nihilism is best done by professionals