naxxfish

(featured image is a Class 800 test train set spotted at Paddington shortly before the launch of the Intercity 125 replacements in October 2017, operated by GWR and Virgin East Coast)

As a long time user of Realtimetrains.co.uk , and someone with an appreciation of Open Rail Data (having used it myself), I jumped at the chance of helping their development.  They’ve put out an appeal to record GPS tracks of train services that you travel on with the link to the service on the application.

A lot of the work behind the scenes performed by a small team involves maintaining data relating to train positioning and comparing this with the signalling system outputs we use. This is an entirely manual task involving one of us going out with a radio controlled watch and monitoring the passage of trains through stations and junctions. An area of recent interest for us has been attempting to compute this automatically using other known bits of information.

In order to validate this effort, we either have to do the manual task with a watch or collect a large dataset of GPS traces to compare against our dataset. The more data we have will allow us to improve the end product.

Which is awesome.  I wanted to contribute. I found a suitable app for Android called GPSlogger which seemed to fit the bill.  It has quite a few settings, so I thought I’d write a quick guide on what I’ve used to successfully generate a working track for a service.

Wanting to make sure the data I produced was as useful and error free as possible, I asked @Realtimetrains for some guidance

It does two checks, relating to distances between points. First is that the median distance between point in your file is less than 250m apart, second is that the 90% percentile point is less than 250m. Some of the stuff we're checking against them requires a fair whack of points

— Realtime Trains (@realtimetrains) March 14, 2018

When we've been taking the logs we've been going for as frequently as we can. The main thing we need is temporal data (or we'd use OSM, etc!) as this is where our interest is focusing, obviously the more points the better. We're trying to avoid recommending any particular app 1/2

— Realtime Trains (@realtimetrains) March 14, 2018

I have put together some settings that should help achieve these goals using GPSlogger.

One of the main things is to make sure that we are recording the data frequently – which isn’t necessarily great for battery life, so be wary of this on long journeys! 

 

First of all, hit the hamburger menu (stack?), and go into …

Logging Settings

Tick Log to GPX

Set New file creation to Custom file

Set the Custom file name to “%YEAR%MONTH%DAY-” – this will mean when you create your GPX files, you can append the service ID and uniquely identify the service with the ID and the date.

Tick Ask for a file name on every start, so you have the chance to put the WTT schedule UID into the filename when you start a track.

Untick Allow custom file name to change dynamically to prevent multiple files from being created (you can merge them later, but it’s an extra step that’s not really needed!)

Next, go back and navigate to ..

Performance (Timings, filters and listeners)

In Location Providers, have:

• ✔ GPS enabled
• ❌ Network disabled
• ❌ Passive disabled

(this prevents your location from being sourced from the cell network or wifi/bluetooth beacons, which can throw off the accuracy)

Set the Logging interval to 0 (zero) (as frequently as possible).  You’ll need this to ensure your GPX file contains enough points!

Set Distance Filter to 0 (in order to log new points even when you are stationary), and ensure that Don’t log if I’m not moving is turned OFF (the fact you are not moving at a particular time is useful information!)

Set Accuracy Filter to 60 (so that points that are wildly inaccurate are not recorded)

Optional: You might want to tick Keep GPS on between fixes, which will increase the accuracy and frequency of the measurements (as it won’t have to wait to get a lock between each measurement).  However , it will drain your battery a lot faster when combined with the Logging interval set to 0 as above!

You’re pretty much set now…

Creating a Track

First, find your service using the Realtime trains website.  Click the More detail link, and find the WTT schedule UID (which might be something like W07729).

Go into GPSlogger – once the train is at the platform, press Start Logging. If you’ve set it up as I describe above, it’ll prompt your for a filename.  Paste the WTT schedule UID at the end of the filename – so “%YEAR%MONTH%DAY-W07729″ in our example).  This will result in a filename like 20180314-W07729.gpx , which uniquely identifies the service.

The logger will begin recording data points.  Keep your phone out with visibility of the sky to give it the best chance of getting accurate fixes.  When you reach your destination, press stop.

Now hit the share button bottom left, pick the GPX file you just created and email it with a link to the service to Realtime Trains for them to include in their dataset ! Or do whatever else you like with the file (there is integrations for various cloud storage platforms, SFTP, FTP etc).

One of the unique challenges of CSR FM is it’s structure, where it is part funded by two separate universities each with a presence in Canterbury (University of Kent and Christ Church University) and their respective student unions (Kent Union and CCCU).  Student members could be enrolled at either institution, and as such each institution has it’s own radio studio on campus – each of which has an equal chance of being put on air. The station also invites members of the community to participate. 

This has presented a challenge, in that live audio needs to make it’s way from either studio to the transmitter, hosted at the University of  Kent in Eliot College.  From the outset of the CSR project, the route between the two has always been over IP – there was no other reasonable option.  Up until recently, that was realised using a IP Codec – with it’s packets being routed over the institution’s networks.

This is perfectly fine, and for the most part worked very well.  However, recently CSR has had a fundamental infrastructure change to it’s audio distribution (as part of the Student Media Center project), which has made every single audio source and destination available using Axia’s Livewire Audio over IP protocol over their internal network.  This allows fantastic flexibility and allowing studios to route any source to their mixing consoles, as well as increased interoperability with our automation systems and customisable GPIO control.

However, the second studio (Studio Blue) was still connected via an IP codec link, which was not integrated into the system at all and offered limited capacity for routing over the link (only a stereo pair to and from the router).  Unfortunately the link between the two sites, over the academic networks that link the universities, would not be suitable to transport Livewire (for a number of very good reasons, lack of multicast and custom QoS being one).  It was therefore necessary that we provided a Layer 2 link between the two locations to carry this traffic, which we had complete control over.

Continue reading “CanterburyMedia Site to Site Link”