NG
Yes - though if you're used to operating kit 'not via BNCS' not that complicated. That's the downside of BNCS - people don't actually know how the kit they are operating is really operated in anger without BNCS.
It's more that if you're using BNCS to control it then sources and destinations probably aren't named on the device itself. Routing server 4.1a to OS 3 is easier than src 137 to dear 344. It's also sometimes the case that one route on BNCS is actually several simultaneous routes on different routers, or one thing to more than one destination... But none of that is obvious as BNCS handles it all seamlessly
Out of curiosity I know each studio has their own router. But I assume there’s a master router taking the outputs of the studio and the various OS (how many OS can NBH handle at one moment - galleries seem to be 12) to the individual galleries. Could BNCS be over ruled if they had a router patch panel control to individually put them into the local router?
Yes - there are local routers in each studio, and then a large building-wide redundant router (I suspect actually building-wide routerS with highways between for resilience) BNCS is just a control system for the local and station-wide routers, but the routers can still also have their own control panels running in parallel (and you'd expect an XY panel to be available). However if the router hasn't been configured helpfully with clear source and destination labels (as they were planned never to be seen by the end user) then this might be quite time consuming... Most hard panels in use in BBC control rooms with BNCS are actually BNCS hard panels (usually configured as dumb panels, not smart ones though...)
On resilient installs you will often 'salt and pepper' install - splitting sources and destinations between router cards, or even routers, in a manner that means your input and output eggs aren't all in one basket (say splitting all the OS destinations for a studio between two routers, or at least two different router output cards for example)
However BNCS adds a whole extra level of functionality over basic routing (such as CleanFeed/MixMinus/IFB-queueing and routing, 4-wire routing etc. that would be trickier to implement from basic router controls) In some situations BNCS will also control multiple smaller routers as if they were one big virtual router, handling intermediate routes invisibly. This functionality may also be lost in 'manual' mode.
noggin
Founding member
Yes - though if you're used to operating kit 'not via BNCS' not that complicated. That's the downside of BNCS - people don't actually know how the kit they are operating is really operated in anger without BNCS.
It's more that if you're using BNCS to control it then sources and destinations probably aren't named on the device itself. Routing server 4.1a to OS 3 is easier than src 137 to dear 344. It's also sometimes the case that one route on BNCS is actually several simultaneous routes on different routers, or one thing to more than one destination... But none of that is obvious as BNCS handles it all seamlessly
Out of curiosity I know each studio has their own router. But I assume there’s a master router taking the outputs of the studio and the various OS (how many OS can NBH handle at one moment - galleries seem to be 12) to the individual galleries. Could BNCS be over ruled if they had a router patch panel control to individually put them into the local router?
Yes - there are local routers in each studio, and then a large building-wide redundant router (I suspect actually building-wide routerS with highways between for resilience) BNCS is just a control system for the local and station-wide routers, but the routers can still also have their own control panels running in parallel (and you'd expect an XY panel to be available). However if the router hasn't been configured helpfully with clear source and destination labels (as they were planned never to be seen by the end user) then this might be quite time consuming... Most hard panels in use in BBC control rooms with BNCS are actually BNCS hard panels (usually configured as dumb panels, not smart ones though...)
On resilient installs you will often 'salt and pepper' install - splitting sources and destinations between router cards, or even routers, in a manner that means your input and output eggs aren't all in one basket (say splitting all the OS destinations for a studio between two routers, or at least two different router output cards for example)
However BNCS adds a whole extra level of functionality over basic routing (such as CleanFeed/MixMinus/IFB-queueing and routing, 4-wire routing etc. that would be trickier to implement from basic router controls) In some situations BNCS will also control multiple smaller routers as if they were one big virtual router, handling intermediate routes invisibly. This functionality may also be lost in 'manual' mode.