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.

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!

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.

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.

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).

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!

So this first section does some basic AGC and compression.  AGC standing for Automatic/Average Gain Control.  It acts a bit like a person riding the gain on a mixer, trying to make everything be at a set level.  In order to prevent ‘suck up’ – that is, making background noise louder, there is a threshold at which it will stop trying to increase the gain.  This AGC is done by the two levellers in the diagram.  Unfortunately, they’re not stereo linked – this means it’s possible for them to apply different amounts of gain to the left or right channel, potentially affecting stereo image.  That’s rather unfortunate, but at the moment I don’t have a solution to this.  The gate will further reinforce the ‘freezing’ by reducing the gain further after a given threshold.  This is set pretty low, just in case someone has some really quiet programme material – really all it does it cut out any noise from total silence (which is required, from time to time).

The compressor will reduce the dynamic range of the signal a little bit, and compensate for overshoot on the levellers (if they bring up the gain, then something really loud happens, they take a bit of time to react to this – the compressor will kick in and reduce the gain a little bit faster than the levellers will).

This beast is the multiband AGC.  This does what the wideband AGC does, except it splits it off into separate bands of frequencies before doing so.  The stereo crossover block is what splits up the frequencies.  I have found that designing an effective crossover is a bit tricky – it can take quite a bit of tweaking to get it to be transparent.  When I started tweaking, I put all of the levellers into bypass and solo’d each band on the mixer.

I have decided to use a 5-band design here – this seems to be fairly standard in broadcasting.  It allows us to get the most out of the high end, which is important when making your audio sound clean, crisp and ‘sparkly’ – though overdone it can sound harsh and screechy (think blackboard + nails).  My settings for this are around about 0-200Hz for Low, 200Hz-750Hz Mid Low, 750Hz-2.6kHz Mid High, 2.6kHz-10kHz High, 10kHz up Super High.  Or something like that (a lot of tweaking was involved, I can’t remember the exact frequencies!).  A bit of gain correction was applied to the signals, owing to the fact they have different energies.  Getting the right crossover curves was tricky – if you get the wrong ones and set the crossover points wrong, you end up cancelling out frequencies, giving a comb effect which can sound nasty.

The levellers are set with a fairly low threshold, and a reasonable amount of maximum gain.  Tweaking these levellers is quite time consuming, and rather tricky.  Getting them to add gain to the right frequencies without making things sound too unbalanced is tricky.  Ideally, you don’t want the settings across the board to be too different – this can wreak havoc on your stereo image.  Again, annoyingly there’s no sidechain input on the levellers, so they’re independent left and right.  I’ve linked the controlls left and right, but as before – this doesn’t make any promises they’ll apply the same thing to both channels!

The mixer at the end mixes all the bands back together.  You can apply some fine tuning here, gently tweaking what bands you want to be preferred.

Next up, the magical “enhance” stage.

I’ve looked through a lot of processors – and they all seem pretty mysterious when it comes to this stage.  Most, if not all, provide you with an EQ that lets you provide your output with a signature sound.  In this case this is done by the parametric EQ on the far right.  The EQ adds a little extra bass (about +3dB at 65Hz) and takes out a few frequencies that can make voices sound a bit boomy.

What I’ve not shown here is there’s a bunch of meters attached at various points.  These meters are used to dynamically control things, such as the EQ.  The idea is that a combination of meters can let me work out whether the output is speech or music, and tweak the EQ accordingly.  Music will sound better with a more generous bass boost – whereas speech won’t benefit so much.  I’ve also added a few extra little bits that make our style of music sound a little nicer – adding to the station’s branding.

You will notice two sections which look fairly similar – one which has a low pass filter then a delay going into the mix, the other with a high pass.  The idea of this is to add to stereo image.  In radio, you want to sound loud, wide and big to keep people tuned in.  One way of doing this is to widen your stereo image.  The technique I’m using here is one method of stereo widening, which Wikipedia calls a 3D Audio Effect.  This essentially amounts to taking the each side of the signal, delaying and attenuating it a bit, inverting the phase then adding it back to the opposite side.  I have found, however, that doing this can make voices sound a bit… strange.  Old Dr Who villeins come to mind.

Apparently, humans are more sensitive to the directionality of high frequency sounds than low (makes sense, they diffract about less in normal environments) – as such I’ve decided to not apply the effect to the midrange at all – just the high (from about 7kHz and up).  The delays are set slightly differently, making it sound more spactious (almost a basic reveb).    I’ve also done this to the low bass, just to add a bit of extra fat, wide bass.  The difference between these two delays (and the amount they are above the undelayed signal) is what a few processors I’ve seen call ‘width’.

Both of the levels that these two effects come in at are controlled by meters – they are mixed in at about a maximum of -10dB on the mixer, and a minimum of -36dB (almost inaudble).  Again, a lot of tweaking to get this right was involved.  But when it’s done right, it sounds pretty excellent.

And once we’ve added this mysterious loveliness, we’re almost there – onto the multiband limiter!

This is surprisingly similar to the mutliband AGC – in fact, it’s almost exactly the same, except the tasty filling between the crossover/mixer sandwich.

This time, we’ve got 5 stereo compressors (yay, stereo!).  These are set up much like any compressor for each of the 5 bands.  The bands picked for the limiter were slightly different, and more evenly spaced to control the full spectrum a bit better.

The low bands are quite heavily compressed, to give that tight bass sound that you want from pop and rock tracks, with a fairly high ratio and a medium threshold (I think they were around the -10dB mark with 8:1 ratio on the last tweak).  Appropriate amounts of makeup gain are applied, and you have some very energetic bass.  The midrange is less heavily processed, but still compressed a little bit to keep things equalised.  The high end is very heavily processed, very low threshold (around -20dB) and a very high ratio (about 14:1) with lots of makeup gain (about +10dB I think?).  This gives you the typical full trebble and bass sort of sound, which sounds decent over many different kinds of speakers.

The dynamic range of the input has been very very squashed at this point – aiming for everything to fit within about 3dB of range.  The final push is to give it a little extra in the final limiter.

This is the simplest stage – consisting of just a compressor and two limiters.  Again, the limiters aren’t stereo – but in this instance we’re not that bothered.  The compressor is configured with a very high ratio and a high threshold (about -1.01dB) and the fastest attack time possible.  This should nicely clip the top of any remaining peaks which have made it through the other stages.

Anything that the compressor doesn’t catch, the limiters will cause them to hit a brick wall – with a faster attack time and a threshold set at about -0.3dB, they will almost guarantee that the final output will never ever be saturated.

And that’s pretty much it!  The auctual configuration is pretty straightforward – but configuring the parameters to be just right is the tricky bit.  There are some parts which could certainly be improved (if I ever find a solution to making the mono objects stereo, that’ll be excellent), but for the last week I’ve been tweaking this system and have finally started homing in on a good sounding output, with a range of about 4dB (which is perfectly acceptable for an online stream, I’d say).

This is quite an experiment, and I’m not totally sure this is the right thing to do at all – but the results are sounding pretty good so far, so it can’t be that far wrong!

So, yeah – recently my radio station has acquired a rather lovely BSS Audio London Soundweb BLU-100.  It’s a “sound management” device, which (on the main unit) has 12 inputs (6 stereo) and 8 outputs (4 stereo), as well as 12 logic inputs and 6 logic outputs.  You can also add break-in and break-out boxes to get even more inputs and outputs.  You can also hook two of them together with CAT5e and have 48 channels of audio going over it from one side to another.  Oh and did I mention it also has an Ethernet and RS232 interface?

But what does it do?  The question is rather what doesn’t it do.  What we’re going to be using it for is mainly routing audio around the radio station, and doing on-air switching (i.e. feeding the transmitter with audio from the right studio at the right time), as well as doing the processing for the online stream.

It is programmed using a (free) program called London Architect.  This program allows you to build up the configuration of the device by providing you with all the building blocks you need (source selectors, mixers, EQ, compressors, limiters to name but a few) and lets you join them up in any way you can imagine.  It’s quite reminiscent of LabView, except for audio – to give you an idea.  You can then send it the configuration over the network, and tweak the values using the same program.  It’s pretty intuitive, and an extremely powerful tool.

Audio Processing

This thing has so many options for audio processing.  For our purposes, our main use for this unit is to route audio from one place to another.  For example, we want to route audio from Studio 1 to Studio 2, or vice versa. All that’s required to do this is to drop in a matrix router object, hook all the inputs and outputs up and then set where the signals get routed to.  The particularly handy thing is you can define preset groups – for example a group of presets which alter what is sent to Studio 2.  You can then set up a preset for every audio input (changing the source each time) – and then later you can recall the preset remotely (say, over IP) and the audio will instantly get routed to the right place.

But you can do more than that!  There’s also EQs, and compressors, and levelers, limiters, crossovers, mixers, AGC mixers, and more.  With these blocks it’s possible to build up pretty complex designs – right now I’m working on a broadcast processor which includes a multiband AGC, and a multiband limiter, along with a stereo field expander and bass enhancer (I think that project is probably a post in it’s own right).

The only thing that’s slightly annoying is not all of the objects are stereo.  For example, limiters only have one input and one output.  Not great for stereo signals.  You can link the controls together, but they are still controlled by individual channels.  Really, in that situation you need to be able to have a mix of both left and right which control the device so that it applies the same processing to both left and right (to avoid weirdness) – some of them have sidechain inputs, but not all of them unfortunately.

You also have to be a bit careful not to let the internal channels clip – which whilst there is a good bit of headroom, it distorts rather nastily.  Also the compressors do suffer from distortion if you try to squash the waveform too much – but then at those extreme settings you’d expect that sort of thing of any compressor, especially a digital one.

The DSP power available is more than sufficient for our purposes.  So far, even with the most complex design (in terms of DSP power, anyway) I’ve only just about managed to use 50% capacity.  I may hit a barrier when I start putting everything together, but considering what can be done with it that’s pretty darn impressive.

Digital Logic

At the moment we’ve got a RB-OA3 which does that job through the use of offer and accept buttons in the studios.   You can either “offer” control of the air chain (that is, what eventually feeds into the transmitter) and “accept” it.  This is all run on standard 5V logic – you use push button switches and LEDs to operate it, which are in the studios.  It’s essentially a finite state machine hooked up to some relays which switch the audio, not dissimilar to a hifi pre-amp.

With that in mind, we want to migrate away from this switcher to the Soundweb, as this offers the ability to do this switching over IP (and potentially in an automated fashion).  However, it’d be nice to have an intermediate stage whilst we’re re-training our presenters how to use the new system (which will likely involve touchscreens in the studios instead of buttons) so that the switching works the way it always used to using the existing hardware.

Turns out London Architect also provides similarly powerful tools for building up logic, as well as audio processing.  It has AND, OR, NAND, NOR, NOT gates, counters, truth tables, clock sources (logic pulses, as they’re called) amongst other things which can be arranged in such a way to develop pretty complicated things.

The most powerful is surely the truth table object, which maps a give set of binary inputs into another given set of binary outputs.  For those digital electronics boffins out there, you might recognise this behaviour of that of a logic array.  And, yes, you can build almost anything with these truth tables – the only limit is the number of inputs and outputs you can have (I think it’s limited to 12 inputs or outputs).  So universial is this tool, a chap from Radio France decided to write what essentially is a truth-table compiler.  You write code, in what suspiciously looks like VHDL, and it will compile that into the data to feed into a truth table.  You then wire it into your logic circuit and import the values it generates into the lookup table.   It’ll turn that truth table into a state machine (with some of the outputs feeding back into the inputs to indicate the current state), which can transition between states depending on what inputs you give it.

Aha! That sounds familiar!  Once I drew out the bubble diagram for the RB-OA3 – I could then write down all the states and transitions into this language and compile it into a truth table.  So that’s exactly what I did.  All that I needed to do then was wire up the inputs and outputs to the appropriate I/O pins (a very straightforward task), have it fire off audio routing presets when certain states were reached and voila!  Not only that, but we could also finally get the On Air light working in the studios (hurrah!).

So, to summarise: this thing is absolutely awesome.  Every small radio station should have one.  It’s a shame we’ve only got 2, both being installed – would like to have one to play with occasionally.  I have a theory I could use one to control a fridge….

One day I was walking past and saw a sign outside, boastfully promising that there’s over a million different milkshakes to choose from.  I wondered – is it actually over a million?

So I asked.  Unfortunately, this wasn’t something that the people working on the till at the time knew off the top of their head.  Also, they didn’t know how many different flavours they had.  Time to do things the hard way….

First things first, we need to know how many different flavours there are.  Lets get counting ….

OK, so, they said milkshakes – so I’m not counting anything hot chocolate, or anything else.  Just milkshake flavours.  And, by my reckoning, they have 182 different items that you can have in your milkshake (yes, I really did just count them).

So then, as we can see above you can have between 1 and 3 flavours in your milkshake, and it can be one of two sizes.  You also have the choice between Skinny, Standard, Creamy and Soya milk.

Lets start simply.  Lets say our total number of flavours is – there are possible combinations with one flavour – simple enough

There are then combinations of two flavours. However, that’s all possible combinations, including ones where both flavours are the same – so we minus , which is the same as the first figure (as both are the same, it effectively counts as the same as 1 flavour)

And then combinations of 3 flavours – again, we can minus as the number where all 3 are the same.  But then we also have   combinations where two of the 3 are the same – i.e. we count 2 of the 3 to be “one” flavour, and use the previous figure of how many 2 combination shakes and eliminate them.

Add them all together, you get: ,  let and it comes out to be 5,995,444.  Waaay over our over 1 million already.  But that’s not the end of the choices: we can also choose from 4 different milks: multiply that by 4 and you get

23,981,776 combinations.

Almost twenty four million possibilities. 48 million if you count regular and large as being different.  However, quite a few of them will be horrible, because they contain black jacks (I mean, really? Liquorice? And milk?)  But, I wonder, how many of them will contain one given flavour?

We can say in the case of 1 flavour shakes, only 1 out of will have blackjacks in it.  Easy enough.  In the case of 2 flavour shakes, there will be out of flavours which have blackjacks as one of the two flavours.  And then, finally, there will be out of .  Adding it all together, that means that will have a particular flavour in it.  Let again, and that gives us 33,307 combinations in which a particular flavour features.  Ew.  That’s a lot of manky blackjack milkshakes.  Or, looking at it positively, that’s a lot of potentially yummy banoffee pie milkshakes.

Lets throw in some more numbers here.  I’d say that the average diameter of a milkshake cup is about 8cm, and about 12cm tall.  And probably contains about 330ml of milkshake (at a guess).

If you were to put every possible milkshake combination in a line, the line would be long enough to go between London and Birmingham 10 times.  If it was a straight line, unrestricted by water, it’d get you about 1/3rd of the way into the Atlantic Ocean.  Likewise (if you have a few million milkshake floatation devices) the line would be able to go from Canterbury to Fes in Morocco.

If you piled them up one on top of another (as if you are trying to build some kind of milky space elevator), the top milkshake would be at an altitude of 2,877 km high – which is about between 6 and 10 times higher than the orbit of the International Space Station.

If you poured out all of the possible milkshakes into a bucket, it would weigh about 7,900 tonnes, and be enough fluid to fill 3 Olympic Sized Swimming Pools.

If it takes you about 1 minute to drink an entire milkshake, then it’d take you almost 63 years of solid drinking to get through every single combination.  That’s not including toilet breaks.  And, y’know, having a life (not that I can really talk, I’m spending my spare time doing maths for no reason.  At least I don’t need to pee the entire time).

And out of all those combinations, the only one for me is Banoffee Pie.  Yummm….

UPDATE!: I did a piece on CSR FM based on this post! Unnececary Maths – Milkshakes

McDonald’s Litter patrols cover over 120,000 miles every year in the UK and Ireland. We are about the environment!

(or something to that effect)

I decided to break this down a bit. After doing a bit of research I found that there were 1,200 restaurants in the UK and Ireland (60% of which are franchisees). So, that makes each store cover 100 miles per year. Divide that by 365 and we get 0.2739 miles per day covered in each day. That’s about 440 meters every day.

Consider also that this is covered by presumably more than one person, and performed more than once a day.  Lets say for arguments sake that on average, there are 2 patrols every day.  So we cut out 440m in half to 220m.

The problem with this is it is a linear distance. This tells us little about how much area is actually covered by the litter patrols.

The actual distance travelled is dependant on the location of the restaurant.  If the restaurant is on a long street, then the distance travelled in each run would be approximately 4x the radius.  If it were located somewhere with more complex roads and alleys, this would be substantially more.  However, we can at least agree on that the distance travelled in one patrol is at least 4 times the furthest away that they get from the store.

So, we divide our 220m by 4.  That means that, roughly, the litter patrols go about 50m either side of the front door, twice a day

Now you break it down, it down I wonder why that sounds impressive.

I suppose if you inflate any number enough, it can seem impressive.  For example, my heart has beaten over 58026240000 times since I was born.  Wow!  And it never stopped once!  (well, not for very long anyway).  You’ve probably farted about 456.25 liters of gas in the last year.  Lets say that’s mostly air… that’s over 500g of farts!  And 16g of CO2.  I wonder how much of the UK’s CO2 emissions due to farts is generated by McDonalds employees going on litter patrols…

Here at CSR, we have a number of different places which we might want to broadcast from.  For example, we have two studios (Studio 1 at the University of Kent, Studio 2 at Christ Church University) a sustainer service and we often perform Outside Broadcasts which require taking a signal from another source again.

Therefore, we have an airchain which includes a station switcher (specifically two Sonifex Redbox OA3 daisychained together to give us 5 possible audio sources).  In order to allow presenters to switch the station output between the sustainer service and the studio output, we provide two buttons – offer and accept.  The station switcher allows the operator of a studio to “offer” to take control from other studios, and “accept” control for other studios.  The sustainer, since there is no human present, cannot offer to take control – therefore a special case is given whereby the studios may force it to take control by holding the offer button then pressing accept.

The buttons (and indicator lights) are connected to the station switcher via a D-sub connector, which goes into a control interface. This is fine – however we wanted to be able to control the switcher from within Engineering where the switcher is located.  Thus, many years ago, one of the Tech crew built a 2U rackmount box which allowed us to “press” the offer and accept buttons remotely.  It essentially consisted of a box with a bunch of push to make buttons mounted on the front panel.

However, there was one slight issue – Studio 2 is at a remote site, and obviously we can’t run a piece of wire from the buttons half way across Canterbury to the switcher!  Therefore, we made use of the remote GPIO pins on the MDO STL-IP units which we use to transport audio to and from Studio 2.  This allows us to send digital signals (i.e. high or low) over IP – we connected up a switch box at Studio 2, plumbed this into the GPIO ports which were replicated up at Kent.  However, the signals which came from the STL-IP unit were not the same as the ones required by the switcher.  Therefore, in our custom made box we had to build some level shifting circuitry which converted the levels to ones which the switcher could accept.

This circuit was built on veroboard, and looked a lot like this:

The chip at the bottom is a octal darlington array, the one at the top a hex inverter. This successfully shifts the level, and everything worked perfectly for the time which we had Studio 2 online.

This all worked just fine up until recently – however when we took out the STL-IP boxes for maintainance we discovered a slight flaw.  Since the STL-IP box was disconnected, the inputs on the CMOS inverter were floating.  This caused the control signals to the switcher to fluctuate wildly – this in turn caused the switcher to constantly give Studio 2 control of the switcher!  This was not good (thankfully we have backups in place to prevent this being a showstopping problem).

The solution: attack the insides of the switch box with a hacksaw, remove the circuit, and disconnect it permenantly.  Now, it shall never bother us again.

Until we need to work out how to remotely put Studio 2 on air.

What is the total number of unique messages you can fit into 140 characters (i.e. a tweet)

This seems like potentially quite a simple question. So, lets say you have a set of valid characters called , and a maximum message length of (in this case, equals 140). For all messages consisting of one character, you have size of possibilities. For two characters, you have possibilities – all the way up to . In math-speak:

Which, given that we know that the general formula for a geometric progression to be :

Geometric progression (Wikipedia)

We can substitute , and giving us

For the sake of argument, lets say tweets can only be 8-bit ASCII (I know, terrible assumption to make, but lets just run with this), so the size of . We shall also let , since that is the maximum length of a tweet. The answer is …. a very big number. According to Wolfram Alpha, it’s

That’s about 8 followed by over 300 zeros, and that’s being conservative (not including unicode, for example). However, what we have just calculated is in fact all possible messages. Including “xSADFt5hagarnw”, or ” s sssss akasf”. I can’t think of many people who would tweet that – or in fact be able to logically distinguish that from any other sequence of random letters. What we actually want to know is the proportion of legible tweets

This in turn requires us to define what we mean by legible. We could, naively, create a grammar for messages that they might follow. You might say that they contain words separated by spaces. Sometimes the words can start with a # or a @, they can end with punctuation (like . , ? ! etc). But then, we are eliminating legible (but low quality) messages like “!!!LOL!!!” or “i <3 my v1@gra”. Our grammar starts becoming more complex to accommodate these exceptions.

One possible approach would be to estimate a channel grammar by taking all of the current traffic on the channel and create an unweighted graph generated using minimal a priori information (i.e. that words are separated by words, and contain non-whitespace characters). The graph would then contain a path for every single “word” on the channel – with each node representing a character and it’s position in the word. Once this specific graph is created, one could group common nodes together and generalise the graph, reducing the number of redundant nodes.

Once the graph has been generalised sufficiently, one could then use graph theory to calculate all valid routes through the graph (or, as it would be, chain) – imposing the limits on the number of possible characters.

Chances are, it’ll still be a pretty darn huge number. However, we know that will certainly be a subset of the number we calculated earlier. By continuing to feed in data to the graph, you would then be able to adapt to new words being adopted in various languages. The total number of unique tweets is dependent on the vocabulary of the users.

So, I would say that the answer to the original question is in fact: it depends. And, given the general lack of any real central repository of vocabulary that all users must adhere to (which is a clarphing relief), the only way to determine it is by looking at it!

Unfortunately, not a very mathematically beautiful answer – but then anything to do with language rarely is ….