I’ve been hard at work this weekend on a new 2013 speed climbing scorer’s app for Android, iPhone, and iPad devices. Here’s a sneak peak of the app running on two Android Nexus 7 tablets. The same setup will work with an iPhone or iPad, too, so it’s very versatile from a hand-held device perspective…more about the setup a little later.
The app’s role is to serve the official scorer of the speed climbing event and sits on the scorer’s table at the base of the races. In this case I’ll have a couple of them at USAC Nationals at Stone Summit in Atlanta over the 4th of July weekend.
It’s purpose is so the scorers can easily see the race times without craning their necks to look at the display LED up high as well as taking the role of the official clock for marking down scores. Why not use a laptop and a GUI app you ask? Price – a Nexus 7 is less than $200 and a laptop…well, you know. They’re also a lot more portable so I don’t have to haul multiple laptops to events with me when I’m fielding multiple timing systems for various age-groups.
The scorer’s app works like other components in the Twin Dolphin system architecture – it listens to the protocol and commands emitted by the master timing unit over the wireless network. It’s the same protocol that the LED display is listening to for the start and finish to display the official times at the end of the race. It’s more complicated than that, but that’s the gist of it.
Lots of people think the large LED display for the audience is the actual clock, but that’s not true. There is only one master timer in the system and that is in the master timing unit to which all the sensors are wired. The master is almost always hidden behind the climbing wall. The master controls the overall state of the system based on input from the wireless starter and sensors and using this architecture I can add wireless peripherals to the system that are all in sync from the master timing unit. Here’s what the 2013 master timing unit looks like:
A little background on how the system works: the LED display clock starts running when it sees a ‘start‘ command from the master. When the race is in progress, and the LED clock is running, the LED isn’t displaying the official time until the end of the race when both lanes finish. The running clock on the LED is there as a fiction for the audience until the race is over. Once the race is over, the LED receives the official time from the master and it displays the official time in alternating sequence you may have seen before.
The scorer’s app doesn’t have a running clock like the LED display, as that’s not its purpose and there is no use for the scorer to have a running clock. The app’s only purpose is to display official finish times and the history of those times. The times it captures are the same as those the LED display captures at the end of the race, but the LED display doesn’t contain any history so once the clock is cleared, the display is cleared and that’s it. The scorer’s app keeps a history of the previous three races and the current race.
For 2012, I fielded a 100% embedded device for the scorer’s table which showed the current race’s finish time and the history of a few races prior. There was nothing to interact with on the display despite it having a touchscreen. The great part about it was not having to supply two laptops to show race times and history to the official scorer on separate tables. It was wireless and frequency keyed to the individual Twin Dolphin timing system it was dedicated to…since we had two full systems there, there were two devices, one on each scorer’s table.
It was quite a lot of work to put together. It was based on a dsPIC based LCD product from Mikroelectronika, but I added a wireless module to it. I designed the ABS plastic enclosure and stand, 3D printed the case, wrote the firmware in C and at the end, assembled the whole thing. Problem was, of the two I brought to 2012 nationals, one LCD died in the middle of the semi-finals and was a write-off. It worked well prior enough to serve as a reasonable prototype and show its usefulness, but I decided I wouldn’t build any more of them.
So, rather than going that route for 2013, I decided it was time for a tablet to do that job.
The photo below shows a Nexus 7 running the Twin Dolphin scorer’s app next to the 2012 scorer device I made. As you can see the screen size on the N7 is much larger and shows the current race status at the bottom including any false starts along the way and which lane false started.
I know I have some very geeky customers which is awesome, so I like to add details about the system for their benefit.
As you know, tablets and phones have a few wireless technologies on them – namely, wifi, cellular, and bluetooth. However, the Twin Dolphin timing system uses a wireless protocol that’s more geared towards sensors, a variation of Zigbee put out by Digi – XBee. So, the issue is how to get the timing system data into an Android or Apple device and that’s where some of the magic happens.
I have an XBee to USB device attached to a laptop that listens to each timing system for the Twin Dolphin timing protocol and there’s a program that immediately stores what it hears into a file. Next I wrote a program on the laptop that tails the timing data file, parses it and sends the data to the Android or Apple device through a wifi channel. So, the laptop and the tablets are on the same wifi network and the laptop, through the XBee->USB bridge, pulls in the timing data.
For those deeply into Geekdom, all the software is written with Ruby, osc-ruby, and TouchOSC and uses the OSC UDP protocol to communicate with the devices. I’ve been testing this on a Mac but there’s no reason the laptop couldn’t be Linux…I suppose Windows, too, but I won’t be doing Windows. The laptop software is all command line level, there is no GUI required for the laptop middleware.
The UI for the tablet app was done 100% with TouchOSC which is a client that runs on both Android and Apple devices. It’s about $5 from the Google Play store for Android or Apple ITunes for Apple devices. The laptop sends UDP packets to the devices to update various fields on the screen with timing data. There is no user interaction with the UI at all – it’s a display screen of timing data.
The nice thing about this architecture is I can drive multiple displays from one laptop listening to multiple timing systems at once. So, with a single laptop, I can drive multiple Android devices on separate scorers tables for two different timing systems. The middleware on the laptop is also logging all the data to a file so there’s effectively an unlimited history available for an entire session, not just what fits on the display. The tablets aren’t doing any of the sensing or real-time display, so the middleware latency is not an issue – even so, the times show up almost instantaneously on the table when the race finishes.
I think it’s going to work pretty well from what I’ve seen so far, though USAC nationals will the be the first place it’s ever been deployed. I’m sure I’ll find some surprises along the way.