OB links over 802.11n

By naxxfish on April 22, 2012

So, after starting my job with “a well known british broadcaster” I’m still actively involved in my favourite community radio station in Canterbury, as part of the Technical Committee.

As of late, apart from helping with the project to move the student newspaper InQuire into one of CSRs rooms, I’ve been looking into improving their OB capabilities and reach.  For some time now we’ve been looking at more secure ways to get audio back from an OB for transmission.

Our traditional method of getting audio back is to run SimpleCast on a laptop with an Internet connection, to stream the audio back to our HQ where it’s played out onto air.  Whilst this does work, it’s less than ideal – the audio link only goes one way, it’s not particularly great quality (depending on the codec used, AAC is fairly good, MP3 less so), and the latency is huge and very variable.

We can scale back our bandwidth usage by using lower quality codecs,  but it’s not a great compromise to make.  Also, we can’t do talkback.  Not ideal.  All this over a possible flaky DSL line or Wifi connection and you’ve got issues.

Some of these issues might be resolved by using James Harrison’s rather nice little bit of software, OpenOB, however it won’t solve an unreliable connection.  This also doesn’t let us send non-live audio for production back to base easily.

Most major broadcasters (with rather more money) will go for an ISDN codec to send audio due to the low latency and reliability of an ISDN connection.  The lines will get installed by BT before the event, and the OB truck will just roll up and hook into them as required.  This would set you back around £30 per month for the line at your HQ, plus a good £100 or so to get the line connected at the OB site temporarily.  Another option is a leased line between the OB site and their HQ, commonly used for more full on OBs (like festivals or day long events).  However, this costs upwards of £300 per month, plus installation costs (which will be significant).  Finally, you might also have a satellite uplink and sat truck – costing you something like £15,000 year for the uplink plus the cost of the truck.  Major events often get several of these, to serve as backup links in case one or more fails.

Clearly, well out of the budget for most any community radio station that doesn’t have vast amounts of financial backing.

Community radio is a bit of s special case – in that it serves a small area (smaller than the average “local” radio station, perhaps only a town or small city) and as such, you can exploit this fact.  Also, the price of 802.11 based wireless has come down significantly in the last few years – and there are some pretty good devices out there for very cheap.  Ubiquiti make some extremely good wireless linking devices (for example the NanoBridge or AirGrid series) which have enough power and directionality to allow you to link two devices over a range of several kilometers, providing you have line of sight.

So this is what I’ve been researching.  Clearly, the directional antennas are only good if they’re pointing at the right place – this can be solved by putting an automated rotator onto the pole it’s mounted on, allowing it to be steered as required.  The one I’ve found so far is a HyGain AR-303X.

As for the actual devices themselves, I’ve been considering the Ubiquiti AirMax M5 27dBi which is the highest gain and power we can get without breaking any laws.  It’s very directional, but for our purposes that’s perfectly fine.

I’ve been using Radio Mobile to generate some plots of what sort of coverage we might be able to achieve with this setup.

Coverage area for an AP on Eliot College

This is the calculations assuming the antenna can be rotated to any angle, the recieving side is at least 2m from the ground, and including misalignment errors of up to 5 degrees, as well as taking into account clutter on the ground (i.e. buildings, trees, etc), and in the worst possible weather.

Anywhere in green, yellow or red we should in theory be able to get full 802.11n speeds MS7 (108MBps).  The blue areas should be able to support anywhere between 2 and 54MBps (though we may want to set the speeds lower to ensure a good connection).  This speed should be more than good enough for several low latency audio links in both directions, as well as sending large files.

And all this for about £250 quid (not including the remote side pole fixings for the radio).  Not bad – lets hope we get to do it!

Posted in | Leave a response

OB to end all (my) OBs

By naxxfish on March 3, 2012

Today marked the end of my time at the University of Kent, Information Services.  After working in Campus Support for 8 months, and prior to that on the Support Desk for 3 years, I left at 1630 today.

The moment I left, I was thrown straight into preparations for CSR’s Outside Broadcast of the two student union elections.  This was to be my last OB that I have worked on as Technical Manager for CSR, and it wasn’t an easy one.  As it turned out, both of the student unions that support CSR were having their elections at the exact same time (whether that’s through coincidence or planning, I don’t know), and we were expected to cover them both.

Our usual approach for covering the Kent Union elections is to set up an OB studio in the green room in The Venue (the night club on campus at which the election result night is held), with a straightforward one way link back to CSR to be broadcast over FM and online.  Our arrangement for the Christ Church Students Union elections is much the same, except instead we use our studio on the other campus and a cable to the SU building to broadcast the results live.

Both of these options require broadcasting from just one studio at a time – which is easy with our OB encoder laptop and a couple of extra cables here and there.  But this time, we needed to broadcast from two places simultaneously.  The normal simple approach just wouldn’t do.  We decided that the main operation was to be run from Studio Red, at UKC, as this gave us the most flexibility in terms of routing audio.  The link between the main CSR facility at the University of Kent and Studio Blue at Christ Church is achieved with a pair of MDO STL-IP units, which connect over JAnet to transport audio between the sites, in either direction.  With a bit of creative patching, we were able to send a cue (or talkback) feed down to Studio Blue from an aux in Studio Red, so that they could do instant hand overs (“We’re now going to go to Studio Blue for the latest results”,”Hello, here are the results coming live from the Christ Church Student Union Elections…”).  We put that studio programme output onto a fader in Studio Red, so they could fade it up whenever they wanted to go to them.

To broadcast the results from The Venue, we build up our fairly standard OB studio in the green room, consisting of an A&H XB-14 mixer, some SM58′s, couple of Yamaha monitors, some headphones and a wireless mic.   The Tech guys informally dubbed this “Studio Green”.  The magic touch to this was a hired in BRIC-link IP codec – which allowed us to get stereo audio in both directions from Studio Green, allowing us again to have a different cue feed from an aux in Studio Red (preventing feedback), to allow for instant hand overs.  Back at CSR HQ, we had a BRIC-link patched into another fader on the desk, so they could turn it up any time.

The whole configuration looked something like this

All playout and other production was done from Studio Red, who also coordinated and contributed content.  This worked seamlessly, and the coverage was excellent (and got some pretty amazing feedback from our listeners – and even broke our record for listeners online, which was previously set earlier in the day!).  The first link really showed off the extent by doing a link that involved presenters from each of the studios, without breaking a sweat.  The team did an excellent job making compelling content, and catching the results live and providing a useful context for the events.  We had a laptop showing the tweets coming in, showing all sorts of praise for the output on the night.

Of course, there is always room for improvement.  This time around we did require some fairly hefty custom cabling to pull it off – hopefully something that will be eliminated by the implementation of the Soundweb audio routing which we are working on currently.  Even having a half-normalled patch panel, which we don’t currently have (no, really, we have none right now) would make life a lot easier.  The feeds from the stages were reasonable, but they could have been better quality.

I would say that this is the most overall complex OB that I have ever done for CSR.  Other OBs have been quite involved (setting up studios on farms) but none have required quite this level of coordination, which for a little community station with not a lot of infrastructure isn’t easy, both in terms of technical capabilities as well as programming and production.

Certainly a worthy way to make a grand exit.

Posted in , | Leave a response

Timing is something

By naxxfish on February 29, 2012

When you’re broadcasting, keeping to the clock is incredibly important.  Coordinating programming between multiple studios, live feeds from external sources (syndicated live content, like news), and making sure your audience know what programming to expect are all important reasons for keeping the time straight.

NTP is a protocol designed to synchronise time over a network, and it does it extremely well, and compensates for network jitter and congestion.  If you’re running a Unix based platform, or an embedded system that supports an implementation of NTP, it’s dead simple to set up.  You specify a NTP server (either one on your own network, or one from the public NTP pool), how often to poll it and other options in a config file or via some kind of administrative interface, and you’re done.  The NTP service will keep the time synchronised periodically, and depending on your local timing source (say, a crystal oscillator circuit) you can expect timing within a few milliseconds of the NTP server.

Of course, that’s no good if the NTP server is inaccurate.  Authoritative time sources are interesting things – ultimately the most accurate time source currently known is the atomic clock, which counts the number of oscillations of between two energy states in a Caesium-133 atom (the SI definition says that 1 second is 9,192,631,770 oscillations, incidentally). There are various methods for doing this, and you don’t have to use Caesium-133, Rubidium and Thalium work well too.

An atomic clock is a fairly big, complicated bit of kit that not everyone is likely to want in their rack.  So instead, you can synchronise an NTP server will a NTP server with an atomic clock attached to it.  This NTP server that is synchronised with the server with the atomic clock is said to be Stratum 1 (the atomic clock being Stratum 0).  Servers that then synchronise to this Stratum 1 server become Stratum 2 – and so on.  Clearly, the lower the stratum, the more chance for error down the line, so they are less reliable (but still pretty darn reliable).

A few ISPs provide NTP servers – JAnet provide Stratum 1 NTP servers, however these are only accessible to peers on their network, and each institution is expected to provide it’s own Stratum 2 servers which synchronise to those Stratum 1 servers.

That said, you too can have your very own Stratum-1 NTP server, should you wish.  All you need is a GPS receiver with a PPS output (the GPS satellites are essentially atomic clocks in the sky (no, really)), and a PC to plug it into.

Or you could buy something like a TimeTools SR Series NTP Server which also includes a DCF-77 decoder (a radio based synchronisation signal) as well as GPS and external clock references, or a Wharton 4860net server (which also has the added benefit of being compatible with the rather swanky Wharton wall clocks )

However, this is only half the story – once you’ve got your authoritative time  source, you need to get your clients (workstations, playout systems, wall clocks, and so on) to use this source.  Which, especially with a Windows network, can be a bit tricky.

Posted in , | Leave a response

Union Elections: Practice for politicians of the future?

By naxxfish on February 28, 2012

This Friday marks the elections results night for Kent Union Elections and Christ Church Union Elections.  I have been around Canterbury and these two institutions for almost 5 years now, and in that time have done some significant volunteering for Kent Union and, effectively, for Christ Church Union through the CSR FM project.  We have covered many of their events, sometimes live on air, sometimes not.  I have generally tried to stay away from the whole democracy element, and rather focused on doing what I do well – that is Broadcast Engineering.  I know how things work ‘on the floor’ (so to speak).

Every year, we get a slew of outrageous claims and promises from the candidates at the Union elections (both of them).  Not all of the claims are outrageous, but some of them are clearly so.  After looking through the manifestos, there are a couple I’d like to highlight.

CCSU VP Activities, Anca, who is re-running for the position says in her manifesto:

What I’ve done so far: Actively involved in opening the Christ Church Radio Studio on campus

The CSR team (which comprise of Kent and Christ Church students, as well as members of staff and community volunteers) have worked in varying degrees for several years on this project – it has not been at all simple refitting and getting the studio on air.  The only time that I have seen Anca ‘actively involved’ in this particular project was when she was present for the Grand Reopening Ceremony which we had in January.  This project has been in the planning for years (realistically ever since it fell out of use in 2009 due to issues with our playout software), and no amount of external lobbying has helped this.  We were encouraged by Christ Church University to go ahead with the project, but little if any input was given from the students union.  Having spent a large proportion of my time on this project, it irks me to have someone else take credit for it.  Strangely, Anca in her election manifesto last year campaigned for a “CSR Studio at Christ Church” – which actually already existed (she just didn’t know about it).

This was also the case with the previous VP Activities for CCSU, by the way, so this claim is by no means new.  She did improve over the previous VP Activities and actually was involved in CSR, and appeared on a talk show we carried called ‘Sabb Time’ as well as helping put out a promo about student feedback at Christ Church.

She goes on to say:

What I promise! Make the new CSR Studio on campus Christ Church led

I’m not quite sure how to interpret this.  If she’s suggesting that all of CSR becomes “Christ Church Led”, that’s actually impossible, unless they buy out CYSM Ltd.  CSR is a project of CYSM Ltd., which is a limited company wholly owned by Kent Union, Christ Church Union, University of Kent and Christ Church University.  It’s administrative requirements (finance, HR, secretarial duties, etc) are performed by Kent Union, who have the infrastructure to do so (being one of the more extensive student unions in the UK).  Christ Church Student Union simply do not have (or really require) this level of infrastructure.

Quite what she is getting at regarding making the “studio” Christ Church led, I don’t quite understand.  The studio is for the use of CSR members to broadcast to the entirety of Canterbury (and the rest of the world online) using their community radio license – CSR members can be students at either University, or a member of the community (so basically, anyone).  The CSR Committee consists of  CSR members, who are elected in the internal elections once a year.  The committee positions are filled by CSR members – the only restriction is the Executive level positions can only be held by students (for some reason or another).  Our current Head of Studio Blue (the studio at Christ Church) is a Christ Church Student.  In fact, our current Station Manager is a Christ Church student!  So, I guess you can say that, going by the Station Manager, CSR is in fact already Christ Church led!

Aaron Watkins, running for VP Activities Kent Union, says on his manifesto (page 10) wants to have

CSR Part Time Officer

Which is rather vague (at least he’s not promising it).  Technically, with CSR being only one of many projects which come under Kent Union’s Student Media remit – having a part time officer just for that seems a bit of a waste of money.  Who would fund the post (even if it was unpaid, there would be some overhead)?  We have a Student Media Coordinator, a full time member of staff (and she really is full time, there’s a lot for her to coordinate – covering InQuire as well as CSR) who is part funded by CSR (well, CYSM anyway).  We also part fund a Technical Coordinator, who covers Kent Union and Kent Union Technical Services.

Also, I don’t know how that really works anyway – CSR isn’t a Kent Union project, it’s a CYSM project – electing someone to represent that project seems a bit odd, and doesn’t really represent Kent Union students.

 

There are plenty of other exaggerated claims there, but I can’t really comment on them, not having direct experience with them.  I’m by no means attacking these two candidates – just pointing out some exaggerations and misconceptions on their parts.  Besides, I’m sure there are more inconsistencies with the other candidates manifestos – I just don’t know about them and they don’t concern me so much.

Normal disclaimer applies – this is my personal opinion that does not reflect the opinion of my past, current or future employers (both paid and voluntary).

Posted in | Leave a response

A Walk through a Broadcast Audio Processor

By naxxfish on August 15, 2011

Recently, CSR FM have aquired a Soundweb London BLU-100 (which I’ve raved about in the previous post). Amongst the myriad of things which it can do, it can also do some quite complex signal processing. Currently, the CSR FM airchain goes from program output (via a switcher), to a DSPXmini FM processor – which processes the audio and compresses it so that it’s of uniform loudness, then on to a 50W FM transmitter (of which we’re only using 25W).

Unfortunately, the FM processor does not have an audio output on it, only a MPX signal which goes directly to the transmitter (which has fancy things like stereo pilot and RDS encoded into it directly) – as such in order to do our online stream we have to have a FM tuner tuned into the frequency, which then gets distributed to a few places, including a Delta 44 on the encoder machine which then goes out to the online stream.

This isn’t ideal, for a couple of reasons.  Firstly, any FM signal gets a bit distorted no matter how close you are to the transmitter (it’s directly below it in the rack, in fact).  Secondly, the FM signal adds ‘clipping’, which is essentially cutting the peaks off waveforms flat.  You’d normally say this is distortion – and it is!  However, over FM, being an analogue medium, this actually sounds good and can add to the loudness of the station if done right.

But when going over a digital medium, it sounds horrible (and sounds like the input on the soundcard has been saturated).  It’s especially bad when you encode it into a lossy codec such as MP3 – the square edges of the waveforms have lots of high frequency components (check out this video demonstrating how using the Fourier series a square wave is made up of an infinite number of sine waves of increasing freuquency).  An MP3 encoder tries to compress the audio by removing ‘useless’ information, that is frequencies that the human ear is less sensitive to.  If you throw in lots of high frequency components, it ends up thinking that these are important frequencies when in fact there is much more valuble information that it can compress in different parts of the spectrum.

So, we can come to the conclusion that using a clipped audio source for lossy digital transmission is not good.  This applies to online streaming as well as other digital media like DAB, DVB or XM broadcasting.

Therefore, we need a separate audio processor which does everything that our FM processor does, except without the clipping.  If we had a better processor – such as an Orban Optimod – it would have two outputs, one with clipping and one without.  Unfortunately we don’t have that much money to spend on processing, especially with the Studio 2 project ongoing.  So, therefore I decided that we might try to build our own processor using the BLU-100.

In essence, a broadcast processor has a few general stages which it uses to make the audio output of the station sound uniform and punchy.  Namely, these are -

  • Wideband processing (gating, AGC, compression)
  • Multiband AGC
  • ‘Enhancement’
  • Multiband limiting/compression
  • Final limiting/brickwall limiting

A bit like this:

 

My mission is to implement this using London Architect.  I have pretty much all the components I need in the audio processing section of my BLU-100, so lets give it a shot!

Continue reading “A Walk through a Broadcast Audio Processor”

Posted in | Leave a response

Next »