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

This is litterally the first revision so it’s incredibly hacky, but it does work fairly nicely.

To create the benchmarker object, you issue the following commands:

benchmark = Benchmark(200, 5000, url_of_server,method_name, ['method','params','here'])

And then to make it go:

benchmark.setupReqs()
reactor.run() # start the reactor!

Here’s the code that currently makes it work. It’s not at all documented but you should kinda be able to see what it’s doing.

#!/usr/bin/env python

from twisted.web.xmlrpc import Proxy
from twisted.internet import reactor
import sys
import datetime

class Request():
       def __init__(self, url, method, params):
               self.url = url
               self.method = method
               self.params = params
               self.start_time = 0
               self.end_time = 0
               self.value =  ""
               self.error = ""
               self.finished = False
               self.error_file = open('errors.csv','w+')

       def addCallback(self, callback):
               self.callback = callback

       def addErrback(self, errback):
               self.errback = errback

       def makeRequest(self):
               proxy = Proxy(self.url)
               proxy.callRemote(self.method,*self.params).addCallbacks(self.retSuccess, self.retFail)
               self.start_time = datetime.datetime.now()

       def __returned(self):
               self.end_time = datetime.datetime.now()

       def retSuccess(self, value):
               self.__returned()
               self.finished = True
               self.value = value
               self.callback(self,value)

       def retFail(self, error):
               self.__returned()
               self.finished = True
               self.error = error
               self.error_file.write("Error: %s" % error)
               self.callback(self,error)

       def isFinished(self):
               return self.finished

       def getTime(self):
               return (self.end_time - self.start_time) # this should be a timedelta

class Benchmark():
       def __init__(self, concurrent = 10, total = 100, url = 'http://localhost:7080/XMLRPC', method = 'date', params=[]):
               self.url = url
               self.method = method
               self.params = params
               self.concurrent_reqs = concurrent
               self.total_reqs = total
               self.open_reqs = 0
               self.current_reqs = 0
               self.error_file = open('errors.csv','w+')
               self.req_times_file = open('times.csv','w+')

       def makeLog(self, filename):
               self.log_file = open(filename,'w+')

       def makeRequest(self):
               req = Request(self.url, self.method, self.params)
               req.addCallback(self.reqSuccess)
               req.addErrback(self.reqError)
               req.makeRequest()
               self.open_reqs = self.open_reqs + 1

       def printReqDetail(self, req):
               #print "Request time: %d ms" % req.getTime().microseconds
               delta = req.getTime()
               print delta

       def reqFinished(self, req):
               self.printReqDetail(req)
               self.open_reqs = self.open_reqs - 1
               self.current_reqs = self.current_reqs + 1 # completed requests
               if ((self.current_reqs + self.open_reqs) < self.total_reqs):
                       self.makeRequest()
               else:
                       if self.open_reqs == 0:
                               reactor.stop() # made as many requests as we wanted to

       def reqSuccess(self,req,value):
               self.reqFinished(req)
               #print repr(value)

       def reqError(self,req, error):
               self.reqFinished(req)
               #print 'error', error

       def setupReqs(self):
               for i in range(0,self.concurrent_reqs): # make the initial pool of requests
                       self.makeRequest()

What is the purpose of putting a paper napkin underneath your food?  As you can see – the food has been sitting on it and as such has made it dirty – and thus unsuitable for wiping ones hands or face on.  So that surely can’t be the reason for placing it there.  Is it instead to insulate the food from the plate?  Perhaps to make it simpler to clean?  If that were the case, why would you insulate the sandwich but not the salad – which has loads of (excessively mustardy) dressing drizzled over it.  Equally, if it was to prevent the food from touching the plate: why would the plate not be clean in the first place? And a similar argument regarding the salad again applies – if the plate isn’t clean enough to touch the sandwich, why is it in direct contact with the salad?

Now, thinking about it critically and somewhat laterally, I can see a potential reason for this.  A napkin would soak up any excess oil or fat which may be coming from the food.  This may be desirable, for example, with a cheese toastie – it would absorb the fat and prevent the plate from becoming greasy – and as such prevent the bread from becoming soggy and laden with grease.

Equally, as you may have noticed when making toast in the morning – if you place a hot slice of toast on a cold plate, water tends to condense under the toast making it soggy if left for any reasonable period of time.  The solutions to this being toast racks, or my personal favorite, a House of Toast (whereby you balance two pieces of toast against each other a la a house of cards – try it!).  Or, if you are in the business of turning out toast-based food items at a high rate, you may well place a clean, absorbent cloth underneath the toast such that any condensation is absorbed without making the toast soggy.

Condensation and excessive moisture is a problem for hot foods, especially during microwave cooking.  For example, MicroChips(tm) (the microwavable potato chips – not the electronic devices) have a “crisping pad” at the bottom of the pack.  This is essentially a thin metallic sheet adhered to a piece of card.  It’s purpose in life is to get very hot very fast (as metals tend to do in a microwave) and prevent moisture from collecting at the bottom of the pack, making the chips soggy.

So how does this relate to the problem of NEBFAP?  I can only assume that putting a napkin underneath sandwiches has become standard practice – given that a number of the items served may be served toasted or cold, it’s easier to train staff to put napkins underneath all sandwiches, rather than differentiate.

Mystery solved … ? I think that science may be required to verify this theory …

The main bulk of the server code which I have written is one giant XML-RPC server, using the Twisted Python framework.

The XML-RPC server itself was immensely easy to implement – using the Twisted XML-RPC howto. In fact, not a single bit of coding that I have done has had anything to do with XML-RPC. I could have written the application end-to-end without having any idea how XML-RPC works – which is fantastic because I don’t care that much for this application!

The next thing that I had to do was write in a component that would allow me to send out real time alerts to listening stations. I figured, since this will most likely be running in a call centre of some sort, I could take advantage of multicasting to achieve this. Essentially, all of the “listening” clients will join a multicast group (in this case, 224.0.0.1). Then, when the XML-RPC server receives a call to raise an alert, it will then send out a UDP packet saying that an alert has been raised to that multicast group.

Integrating a custom UDP protocol with an XML-RPC server? Whoa, that’s gotta be hard right? Nope. Not in the slightest. I wrote my (not particularly exciting) alert broadcasting code:

from twisted.internet.protocol import DatagramProtocol
from twisted.internet import reactor
from twisted.application.internet import MulticastServer

class AlertBroadcast(DatagramProtocol):
	def sendAlert(self,status,alert_id, alert_msg):
		self.transport.write("%d:%s:%s" % (alert_id, status, alert_msg), ('224.0.0.1', 1337))

	def startProtocol(self):
		self.transport.joinGroup('224.0.0.1') # join a multicast group

Then, in my main server building code, added this:

        r = APIRoot() # my root API class, descended from xmlrpc.XMLRPC
        alert_broadcast = AlertBroadcast()
        alertAPI = AlertsAPI(conn,auth,alert_broadcast) # the class to handle raising, acking and clearing alerts
        r.putSubHandler('alerts',alertAPI)
        # and I create all the required objects for the main XML-RPC server, and add it to 'r' (the root)
	reactor.listenMulticast(0, alert_broadcast)
	reactor.listenTCP(7080, server.Site(r))
        reactor.run()

And that’s it. That’s literally all there was to it. Integrating a HTTP server, and a custom mutlicast UDP protocol – done!

I like Twisted - it’s awesome.

They gave me the website address. We shall say it is called diversebiocultures.org.  I went to the address on my workstation (which is on the staff network) and sure enough, it went through just fine.  Perhaps they’ve got some weird proxy settings on their laptop, I thought.  Checked them and there was no such thing – everything set up correctly for Internet access, and they could access every other site just fine.  So I took one of our laptops which are pre-configured to use the wireless service, and bam – connection didn’t go through.  That’s odd.

So I decide to investigate further.  I looked up the domain name and it resolved to an IP which I knew was in the University’s network.  Except it wasn’t that of our usual web servers – it was on another network which I didn’t recognise.  Knowing that it must be on the local network, I did a traceroute.  The route mapped out went out of the building which I was in, to another building on the campus and down to a distribution switch – from the name I could see what building it was in.  That’s strange, I thought, there’s no machine rooms in that building that would be capable of hosting any servers.

I did a reverse DNS on the IP.  It has a hostname on the University’s domain: cromwell.wont.ac.uk (we shall say).  So clearly someone had requested that at some point with Computing – and most likely it was a static IP.  But again, the hostname wasn’t one which I recognised as being a server.

To the robtex machine!  I discovered by looking it up on robtex.com that it was in fact running a number of domains and websites.  About 12 domains in total.

I then decided to poke it a bit further.  I managed to get an error page up which told me that it was running Apache/1.3.41 on port 80.  Interesting. I decided to give it a portscan.  It was running ssh (OpenSSH), http and https. So most likely a Unix box of some description – makes sense for a server. I did some more poking and looking at the server headers, and discovered it was running PHP 5.2.13, which (as of this writing) is a pretty new version of PHP.  Bit of a strange combination, an old version of Apache but a brand spanking new version of PHP.  And, more interestingly, with the extended headers, it informed me that it was a Darwin build of PHP – so it’s more than likely an OS X machine (i.e. an Apple Mac – probably a desktop machine).

After investigating the other websites which the machine was serving, I managed to find a few references to the “creator” of the websites, with a link to his home page.  Surprisingly (or not surprisingly) his home page wasn’t hosted on the same machine.  However, this did give me the full details of who owned this machine, and, presumably, maintained it.

So there’s an OS X machine on the University’s network serving several websites – including one which is required to participate in a module on a course.  And the reason it doesn’t work on the wireless service?  Because the firewall rules were never requested from Computing to allow that kind of access to the network which it was sitting 0n.  Because it’s a staff network – for staff desktops.

Ended up passing the query back to be escalated to the right people – here’s hoping this person decides to host his website on, shock horror, the University’s web servers.  Which funnily enough have no problems being accessed on the wireless service or in student accommodation.