Code/Node v2

In my spare time I dabble in coding, like many of us I suspect. The challenge is always finding the right little project to work on and mix this with normal work, the project can’t be too demanding, can’t depend in other people (or rather the other way around, I never know when I have time to spend on the project), and needs to solve something useful.

I picked the following: create a real-time web-interface to the classic timing systems used in swimming competitions.

note: I'm happy to share the code on this if anyone is interested (right now it's on GitHub - but private ... too much unclean (read: undocumented, wrong, hack) code to share with everyone :-)

The setup

• Swisstiming is the de-facto standard and when I started the project we used the ARES timing system (yes, old school), now we have the Quantum system.
• Both systems send a stream of data via a serial interface to the scoreboard. However, the format is very different, but both have a command set that precedes any information they send to the scoreboard. Some of this information is available if you search for old manuals, but I got most by capturing the information directly from the serial interface (splitter) and guessing.
• The other trick is to make sure that the ARES or Quantum systems output the information you want (e.g. swimmer-name, club-name, event details, etc.) … without messing up the score-board itself (yes this happened as well).?
• Then we have a location problem. Typically, a swimming pool is well shielded, and doesn’t always have stable internet. So, the data stream that exits the pool has to be as minimal as possible (i.e. we’re not going to run a webserver directly from the pool) to ensure real-time information. At the same time, the webserver needs to display information in real-time.?
• Lastly, we have 2 major competitions per year to test the setup. So creating a way to test out-of-competitions is pretty crucial.??

The design?

It’s pretty simple at the core:

1. Scoreboard Reader?(reads the serial interface) that sends the data-stream as a json datagram to an external proxy with a competition specific identifier (so we can have multiple readers from different competitions at the same time).?
2. The?proxy server?(catch and dispatch to the scoreboard server), externally hosted (e.g. Azure, AWS)
3. Scoreboard Server: external hosted application that captures the json datagram, interprets it, stores it, sends it to the connected clients via a socket connection. The Scoreboard Server has multiple ways to display the information?
4. A scoreboard?data generator?for testing with an accurate simulation. I created a hardware one (with an Arduino) to test the RS485 interface of the SCB Reader, but mostly I used a software generator (using an AirConsole to create an easy way to create a serial port on my Mac)

The tools

A short overview of the tools and software I use:

• Arduino as HW in the loop generator
• Airconsole as part of the SW generator
• Raspberry PI with a serial to USB cable – this runs the Scoreboard Reader.?
• Virtual Machine than runs the Proxy and Scoreboard server
• MongoDB database to host the competition specific data and act as data-store for the captured data
• Most of the software is implemented on NodeJS + Express + Jade. The exception is the generator, this is done on Ruby (was easier – I had some existing code)
• The web client uses jquery, bootstrap and socket-io
• obviously github and other dev tools (PM2 for monitoring is a pretty good tool)

The flow

So what’s the flow??from start to finish:

1. Setup the timing systems software (the Quantum software) – usually this is a one-time thing.
2. Install a serial splitter (or use a non-used interface on the Quantum) to capture the datastream
3. The SCB Reader will translate the datastream in a json format with human-readable data and send it to the proxy (and store it locally on the RPi for future testing).?
4. After the proxy has verified the incoming data-stream it can forward it to multiple SCB Servers.?
5. The SCB Server is a classic NodeJS-Express setup. But each client (i.e. webbrowser) establishes a SocketIO connection back to the server. Up on reception of a datagram from the Reader the server will process it (until this point the data is not clean, it might be a resend of previous data for instance or incomplete) and will perform some calculation (e.g. last split time, add pool specific information such as length, how many active lanes, number of touchpads, language specific information). Once completed it will send the data to all the connected clients (read: socketIO connections)?
6. The clients (e.g. webbrowsers) have the mechanisms to process the incoming data from the socketIO connections and update the display?

Note:??I tested a number of message queue systems as well as IoT platforms (AWS). Neither of them was as quick as a the socket-IO setup but cost a lot more.?

So What can we do with this?

• Real-time scoreboard, I tested this and it’s really real-time. I’ve not seen something like this for swimming. I’ve placed monitor in other parts of the pool so people can see & follow without the 30+ seconds delay of a video feed.
• Create a specific view that we use as a?real-time overlay display on a life-stream?(OBS or vMIX). The beauty is that we can use all the tricks available in JS and jquery to create a dynamic view with swimmer-time information popping up and disappearing automatically.??(see screen shot below - each line stays visible for 5 seconds)

Final thoughts:

• There are plenty of things that can be improved (notably the interface to setup a competition)
• The API to transmit and receive the json datagrams is pretty stable, but could use some more standardisation. This is my next project, to clean up the API interface?
• It’s possible to augment the data with more information (i.e. I’ve been thinking to add some prediction capability – but for that I would need a more direct access to the data stored in?https://www.swimrankings.net/)?
• color code the fastest swimmer and fastest lap?- create a age-category display widget (so it because visible who competes with whom in a serie - in swimming the age-groups are typically mixed in a single serie)