Hector Minaya

@hminaya

Bringing Xamarin into the Enduro Scene

How did I get into this?

A couple of months ago I got a call asking me if I’d be interested in automating time-tracking for riders in an Enduro Race. Initially I had no idea what that meant, this would be something completely new to me, I had never ridden one of those bikes and new nothing about how the sport was setup or any of the rules involved. But having never backed away from a challenge I accepted.

Basics

Before I could propose any sort of solution I had to get my bearing straight, I needed to know what this was about, what the rules where, basically a crash course in the world of Enduro.

In it’s simplest version it’s a time-keeping race, where riders leave in groups/rows (based on category). They then proceed through a pre-defined course and pass several checkpoints before getting back to the starting point to complete a lap and continuing the process ‘till time runs out (about 3 hours!) or they complete a predefined number of laps.

Sounds easy, right? Not a chance!

Challenges

The first challenge was time, I had less than 3 weeks before the first race and needed a very quick turnaround from idea to reality.

The second was hardware, a few ideas came to mind around what to use: bluetooth, nfc, beacons, but they were all discarded due to time and budget constraints.

The third challenge was the hardest, 0% error rate :). We engineers tend to talk about acceptable or low error rates, we know how many things can go wrong given all the variables. But in this case we needed to make sure each rider each rider was captured accurately every time they passed through a checkpoint, no excuses.

Now the fun started

Our first decision was was to create a mobile app with Xamarin, this solved a few or our initial challenges:

  • Platform independent from day one (Android, iOS)
  • By using several components and nuget packages we could have a working prototype pretty quick
  • With the Zxing.net Xamarin Component we could have a tested barcode reader instead of creating our own from scratch (reduced error rates)

We still didn’t know what the final app would look like, but we needed to order hardware in time for testing to make sure it could withstand the abuse it was going to receive. For example:

  • The battery needed to withstand the screen at full brightness for 3+ hours
  • Also, the camera would be on for most of the time (scanning barcodes), another battery drain
  • Did I mention dust, rocks and mud?

Well, we settled on some entry level LG Android phones, turned off all unnecessary services, ran a few tests and got about 4 hours of use out of them, not bad!

Architecture

This is what we used on the mobile app:

We ended up sticking barcodes on each one of the riders, one in the front of the bike and one on each side of the helmets (just in case).

These are the barcodes that are mounted on the bikes that we scan

The app is able to scan the barcodes and log the time. Initially my though was to pass that in realtime to a webservice so we can have realtime results. But the races take place in remote areas where there is no internet access. So we store all of the information locally in a SQLite db, then when the race is over we pass all of the data using an ad-hoc wifi network to a local server and process the results.

Race Time!

How did we do?

  • We were able to provide for the first time accurate results between each checkpoint for all riders
  • All of the devices we setup performed beautifully, they were able to accurately scan the barcodes
  • Results were calculated instantly for all categories
  • All of the results were published online for everyone to view!

In the end, let’s just say everyone was all smiles!

Topics of interest

More Related Stories