Setting Up London with a PM5D
bsaaudio
Posts: 9
Does anybody have any experience interfacing London with the Cobranet cards for the Yamha PM5D? (MY16-C and CII)
My specific question is in regards to the channel count on the I/O cards- if the card allows both Rx of 16 channels and Tx of 16 channels? The documentation is confussing stating 16 channels. I'm assuming the cards have 2 bundles for tx and 2 bundles for rx (total 32 working audio channels).
I would assume setting up London that we would simply set up the bundles as normal and make sure that the I/O cards are assigned to rx or tx accordingly?
Please elaborate...
My specific question is in regards to the channel count on the I/O cards- if the card allows both Rx of 16 channels and Tx of 16 channels? The documentation is confussing stating 16 channels. I'm assuming the cards have 2 bundles for tx and 2 bundles for rx (total 32 working audio channels).
I would assume setting up London that we would simply set up the bundles as normal and make sure that the I/O cards are assigned to rx or tx accordingly?
Please elaborate...
0
This discussion has been closed.
Comments
Each Cobranet card for Pm5d can send two bundles of 8 channels at 48kHz. If you go to 96kHz you get two bundles of 4 channels.
The assignment of signals to each bundle is the same as for any other MY type card.
Dan
True story.
Dan
We had two switches in the way to each console. 1 from Londons to local switch in the main rack and second switch at each console. We had Gigabit fiber connection between the switches. We measured the latency using SMAART and it was very very low- It suggested that the 1.33msec was kept. It was longer than 1.33msec, but under 3msec. We attributed it to the converters and processing latency. But, maybe Cobranet did switch internally to 2.66msec and the other latencies were just so small.
In any case, you have to tell all devices to start with the same latency or it won't work.
Even weirder, you can actually have devices with different latency settings all on the same cobranet network as long as they only talk to devices that match their latency settings. I have no clue why you'd want to do that, but you could.
Dan
Your information was extremely helpful. We knew that sampling rate and bit depth had to be consistent, but latency was overlooked. Thanks for the heads up. We are executing one switch hop between stage tech position and FOH. We'll be completing this remodeling install in the next three weeks.
I expect to give a glowing report back on the performance of London.
It hasn't dispointed yet!
Bit depth is a lot easier since the receiving device sets itself to match the transmitter. Wouldn't it be cool if latency worked that way?!
Dan
In our case we had (3) I/O cards, (2) Blu-80's and (3) Blu-32's While it did recognize the London stuff, you there was no distinction as to what you were addressing. That is the London devices simply showed up as blu-48K or blu-96K etc... so we simply addressed each unit one at a time and changed the name and location in the property windows until everything was orginized in Cobranet manager. It would have been so nice to use LA as the main manager program, but at this junction it isn't set up to deal with 3rd party devices.
In the end, our objective was to create a digital snake with compliment split to the broadcast suite and typical return pathways from the stage all the way through the amplifiers and that was accomplished thanks to the London gear. The defualt design was left with devices operating at 48K and 1.33ms latency on a standard 10/100 backbone. At some point, I'll install a gig backbone and start pushing the limits of sampling rate and latency to get the most out of the gear.
One interesting tid-bit...the BSS London sounds tons better when the acoustic guitar channel by-passes the PM5D in a little experiment we did. Too bad the Vista VI-4 wasn't available to our customer at the time they wanted to go digital. In any event, the system is better off completly digital verses a hybrid digital analog contraption where signals get converted too many times along the chain to have any sonic quality.
The London stuff again comes through for us!
Also known as making a brick.
Dan
However, in this situation the manager supplied by Yamaha for its I/O cards only allows the cards to be set up. But it does recognize ALL devices on a network. No sleep should be lost in this situation because you can't change any of the London Cobranet settings minimizing the risk of having to send a brick back to Utah for a brain lock proceedure.
The guys over the pond should consider making this a feature for L.A.
At present, L.A. only recognizes its own children on a network. Since Cobranet is licensed to more than just one manufuacturer, it might be nice for L.A. to represent and manage an entire network as-built to the client. Especially when we are required to leave design files with the completed installation.
On the other side of the topic, you have a critical misunderstanding which is illustrated by \"Since Cobranet is licensed to more than just one manufuacturer\". CobraNet is an audio transport protocol. The CobraNet protocol defines that a bundle carrying 8 channels of 20bit audio at 48k must always look the same after it leaves the device. CobraNet does not define how that device must accomplish the creation of that bundle. CobraNet also does not define the manner in which the CM1 card will/must be used to create a bundle. Any manufacturer who is doing anything other than the most basic operations with the CM1 module will have modified or replaced the CM1 firmware. Two pieces of identical hardware with different firmware are two completely different devices. If these two devices respond to the same control signals, that will be by luck rather than design. So, there's no way for London Architect to control/program a Yamaha console other than for BSS Audio to reverse engineer the firmware in that console and figure out how to control it and then hope Yamaha never changes the firmware.
Dan