In this article, we’re looking at the award for Best Technical Achievement. We’re going to have a look at a couple of examples of some past winning entries, and we’ll get some quotes from our judges about what they’re looking for and what makes a great entry.
What is this award all about?
This category celebrates a technical development that has improved your student radio station. You have identified a need and designed and developed a practical, successful engineering or IT based solution to fulfill this need. You should show the judges the usability of your product, and how the project was managed. Entries score highly here when a project shows a particularly high-level innovation and originality. Be sure to include additional material by way of uploaded content.
Audio: (If Appropriate) Maximum audio entry length is 4 minutes.
Written: A maximum of 1000 words about how and why the innovation was designed, developed, how work was carried out and how it impacted on the way the station operates. (up to 4 diagrams, images and illustrations may be uploaded as jpg, gif, png or pdf – but the main written entry should be submitted through the web system).
The winners of this category have been a **little** bit dominated (shall we say!) by our South West station, University Radio Bath. Well, it is a university that specialises in science and tech after all…
2015 – URB – Visualisation Rebuild and URB Digital
2014 – URB – Responsive Radio
2013 – URB – 1449AM URB’s UK Radioplayer Console & Unified Station Management Application
2012 – Bailrigg FM – Bailrigg FM Field Switchboard
2011 – Insanity Radio
What should I put in my entry?
It’s hard to explain something technical in just words. For example, I’m about to try and describe the first technical thing that I can see in front of me – my phone.
It’s a touchscreen with 10 numbers, plus a ‘*’ and a ‘#’ arranged into a grid of 3×4. The numbers start 1, 2, 3 in the top row, and then go all the way down to ‘* 0 #’ at the bottom.
All I really needed to do was have a photo like this – and then I would be sorted.
Similarly, if you’re trying to explain an electrical circuit, a flow chart, or a graphical interface, maybe consider if it’s best said in pictures.
Here are a couple of examples from URN’s 2010 entry about their Audio Management System which were simply screen shots of the system in action, and then annotated afterwards:
(As a side note, myself and my station manager edited that audio system a couple of years later so that we automatically dropped Christmas songs into our presenter’s shows playlists as little Christmas presents. They loved us so much.)
This is the full bronze-winning entry from URN last year. I have chosen this one because its name is AWESOME. And also it was written by my friend George, so he won’t mind me using it here. I have given him biscuits.
OB One – Universal Outside Broadcaster
Outside broadcasts are a crucial feature of student radio. They gives broadcasters the opportunity to put on shows and events which are simply too big to fit in the studio – as well as vital exposure to the public. Not to mention they can be serious fun. For URN in particular, the OB has allowed us to cover a range of events, from Varsity to live music festivals. However, our audio transmission kit had aspirations greater than it ability – a small Linux netbook which had to be plugged into the wall for both power and internet, and some old software with no instructions written by persons unknown. Something was eventually going to give. In quick succession a series of OBs had to be aborted due both hardware and software issues which were “beyond our control”. We realised that we needed an alternative needed to be sourced. It was quickly decided that with a budget of £0, it was best if we wrote out own system so there was total control.
The system had to meet certain criteria: it had to have a low memory/CPU footprint, be compatible with as many systems as possible and simple enough for presenters to use What resulted was a transmission system developed in C and a graphical user interface written in Python. Development took about 6 weeks, with the majority of that time being used to learn how to actually program in C.
The backbone of the project relies on two open-source technologies: First, , the PortAudio library, which acts a mediator between audio hardware and software protocols (ASIO, ALSA, CoreAudio, etc.) across all operating systems, This reduced the development time (and novel code written) considerably. Secondly was the use of the OPUS audio codec, and open access format which underpins VOIP systems such as Skype, but allows for low latency, broadcast quality audio whilst using a tiny internet bandwidth (for example 20kbps of OPUS data approximates to an audio quality of 192kbps of stereo MP3).
Figure 1 shows the simplified layout of how audio is transmitted, but a brief description is as follows. A small buffer of audio is captured from a sound card or mixing desk or of choice at the OB end, which is then encoded into the OPUS format to reduce the size and then sent as a UDP stream to a designated server in the studios. The receiving server waits for a packet of data to arrive, decodes the audio and plays it out. The minimum latency for a 5ms packet of audio is to be received from capture 25ms, which is short enough for natural sounding 2-way conversations over (as demonstrated in the example audio).
OB One can run on both Linux (great for reliable servers) and OSX (of which in a student radio station, you are never too far away from an MacBook). This allowed for greater portability in the kit as it could reliably run on battery power and transmit via WiFi or tethered to a phone. In addition, the software can run on a Raspberry Pi – a low powered, credit card sized computer, which allows for a cheap dedicated receiving server in the studio.
Next, it had to be simple to for anyone to use, so a user interface was created and the whole system packaged as an application so it could be easily launched. Combing Python and shell scripting allowed for a simple program to set audio quality and destination and allow to change settings on the fly. It also remembers the previous settings, so a user can simply resume with the same configuration if needs be. The interface can be seen in Figure 2 along with a shot of OB One being used on a broadcast.
The deployment of OB One to URN has allowed for greater freedom in spontaneously setting up OBs. It has allowed shows to avoid having to have an army of technically minded members trying to run programs in a command line terminal as was the case with our old system – which resembled someone hacking The Matrix to get working.
In addition to creating this for the station to use, it has been made available to download for others to make the most of. The installer for the client with documentation is available for download at http://urn1350.net/ob and for those who want to see under the hood the source code is hosted on http://github.com/urn/ob_one and released for anyone to build upon.
Good luck in putting your entry together. I hope you’ve found this useful. Remember the deadline is Friday 15th July at 5pm. No later than that as we are very strict and we turn off the entry system on the dot.
And remember, on the 10th November at the indigO2, this could be you picking up your award. This photo is actually of last year’s winners URB – Jonty and Chris – because I’m not psychic, I don’t know who’s going to win, and therefore I can’t Photoshop your heads onto theirs.