These are always great events to time at - really friendly! This time saw a change of format which made things much better from a timing and (I think) a competitor point of view. Instead of multiple categories each with a different number of laps, there was a set number of laps for all categories and as soon as the leader of the whole race completed, the flag came down. So I could give accurate lap updates for once! The setup was using Sportiva Events  excellent passive RFID kit. It's shown below. It was made up of two readers (R1 and R2) and five circular polarized antennas (A1, A1-4). Timing software was of course Webscorer. The setup - riders traveled from the foreground of the picture towards the gazebo. Here are the results from the analysis of the reads- The big difference between this and past events? Running a reader with a single antenna. This massively improved read rates on the line. For the manual taps, one was a single pass by a lead rider (not sure why he didn't s

This was a Wild Running event, split over three days. based at Huccaby Farm in Dartmoor, a variety of races took place. I will note now, this post only covers technical aspects such as comms and timing! Aside from a brief discussion about GPX files, all route stuff is up to the race director. GPXs, GPSs and navigation via smartphones Due to various goings on with route markings, the importance of finding your own way was highlighted in this race. Now whilst I'm a firm advocate of using a compass and map, I am also on occasion lazy with my navigation and use my watch.  My watch - a Garmin Instinct - highly recommended! I cannot underestimate the importance of making sure your GPX is correct, whether it is for a training run or a race (in which case, ask the race director). That's before we get into the age old discussion about battery life and the susceptibility of technology to fail when you need it most. Also, for race directors, if you pre-import your GPX into Garmin and Suun

Rather than roll this report into the main Something Wild Festival timing report, I'll do it separately as it corresponds to a separate timing system. My love for Webscorer is well documented in this blog, and just before this race was supposed to take place Webscorer released a new update. This allowed "helper" devices to assist with on screen timing via tablets / laptops / phones. The instructions for setup are here . This race was timed in this way. What is the race? It's a fell race with around 100 participants. It's my favourite type of racing, where runners have to pick the best line they can between points. Normally over vague paths / pathless terrain, they tend to be very friendly, low key events. This one was on Dartmoor. So... timing? Webscorer app timing (no chips here), but split between two tablets (both android). it works, it works really well. The only thing to note is that there is a "send data" button on the bottom of the Webscorer scr

 One of the most time consuming things about race timing is sorting out the timing ships. This stands regardless of the method used. Inevitably at the end of a race you have a pile of chips (potentially soggy and muddy) which need cleaning, missing ones will need to be checked for and they will need sorting into a coherent order ready to put into race packs for the next race. I manage Wild Running's fleet of NFC chips in this way, and I'd got fed up of it. I keep the chips in a large box, numbered sequentially with bib numbers. However, I use the chip UID rather than programming the bib number into the NFC chips (which is an option on Webscorer ). It gives a marginally faster read. I still needed to be able to work out which chip UID was assigned to which bib, however I did not want to spend hours sorting them, putting them into order, working out which chip was missing and reassigning chips, changing my master list of UIDs etc. Takes too long. So using an idea from Ben at Spo

Timing back to back events whilst having a day job is a bad idea. Timing back to back events whilst having a day job and very little sleep is an even worse idea. This became very apparent last Saturday morning, at about 3am as I was attempting to turn around my car on a farm track I never should have gone down. It's probably fair to say my prayer life had a significant boost that morning as the smoke rose from the clutch. It was a lesson in realising a) whilst my Skoda Octavia is good, it's no mach for a Land Rover on rough ground b) I cannot do it all by myself and c) there are going to be times when I have to trust others to put out timing checkpoints. The event had two water exits / finish lines, two transition checkpoints, and one aquathlon finish line at the end of the run. I was using two remote timing setups (phone plus speaker plus two bluetooth NFC scanners) and four bluetooth NFC scanners connected to the tablet at the finish. I was also using the finish tablet to tim

Two weeks ago I was out on a decidedly damp Exeter evening timing the Green Lantern race with Wild Running . By damp I mean torrential rain. It was a self nav slightly longer than half marathon run, around the Green Circle route which envelopes Exeter. I haven't run it yet but want to. Timing was all NFC chip based using bluetooth NFC readers as described by Webscorer here . There was one timing point on the course (two readers plus a phone and speaker), and one at the finish (tablet plus four readers). The timing point on the course was using a SIM CRITICAL , whereas the finish was using an EE SIM. Firstly a note about the SIM CRITICAL - it works, it works really really well and I'd highly recommend them for low data remote timing points. Webscorer was setup to use multi-device timing and that worked well, with live results being streamed directly onto the web. Starts were individual and activated by a runner scanning in, me manually tapping them out via webscorer. There were

 It's a few weeks back now, but I timed the Burrator 10K with Sportiva Events . Under normal circumstances this a closed road, fast, mass start event which is done and dusted in a couple of hours. Not so in covid times. The race starts were spread out over the course of five hours, with the 10k runners starting in small waves every two minutes and the 5k runners starting after that, also in waves. As anyone who has timed any race in the last 18 months will know - wave starts, especially with a lot of people, can be a headache due to wave changes etc. This was no exception, but those changes are easy enough to rectify. The start was a point A on the map below (for the 10K) and the finish and point B, and there was no mobile signal worth talking about. Starting times were recorded using webscorer on a mobile phone. The finish line was made up of three UHF RFID readers (we were using passive tags), four floor antennas and six side antennas. Network was provided by a small consumer 4G

 It's been a quiet few months on the development side, had a lot going on with the day job and with actually timing events (more blog posts to come on that). However, where is the project at? Well the original hardware project is on hold, somewhat indefinitely. I've still got all the kit and it works, but the next big step is integrating it with Webscorer by getting a raspberry pi to emulate an RFID reader using the excellent open source project here (if you're trying to get an older RFID reader to work with Webscorer - this is the place to look). Why the need to integrate with Webscorer? Quite simply for price and feature set, I can't produce anything remotely close. Their support is excellent, I use the software and recommend it. Which brings me to the current solution, I'm using Webscorer's recommended bluetooth NFC setup , with both a tablet at the finish line and mobile phones at checkpoints. The mobile phones are setup with multi-network SIM cards so can

 Apologies for the delay in posting! So in the last few months... not much has happened. The combination of a global pandemic, working in education and taking on more in the day job has somewhat put the brakes on things. However, there are now two key priorities- Finish the schematic and PCB design Then get these sent off and built, hopefully leading to an increasingly reliable (none of my soldering to go wrong) device which can accept a variety of power sources. Integrate with Webscorer By far and away the most asked for feature, and I can understand why - Webscorer is really good and the developers are amazing. Now originally I thought this was totally impossible, but then I found this project by runner. He has managed to fool Webscorer into thinking a Raspberry Pi was an LLRP server. My steps (or anyone that wishes to help) are as follows- Adapt all the setup stuff in the code to get it working Read a google sheet to identify new records (timestamp + UID) Take that new record and c

 Just pushed what is approaching the final code update for this version to github. Three main areas of change- It's neater with better comments - it's been needing a tidy up for a while. There's probably a couple more I can do soon two.  The watchdog is enabled. With the enabling of pymesh, I've been playing around with what to do if everything goes wrong and it crashes. The watchdog will restart the device after 5 seconds. I've tried consigning the scanning or the network component to a separate thread and it still crashes if it's on wifi then the wifi dies. Now at least the device restarts. I'd love it if I could just restart the pymesh but not there yet - looks like something is getting in the way. The tap writes to SD before being added to the transmit queue - this prevents data loss by crash. On the hardware side, I have a PN532 board coming from Singapore (expecting delivery anytime in the next month). I'm toying with sticking with the current NFC

 Another change inspired by the Pi Wars conference was re-examining my use of threads. Let me add some more background. The pymesh lora mesh networking feature built into these devices and their corresponding pycom gateway is brilliant. It essentially nulls out the need for dedicated gateways to use lora to extend coverage beyond NB-IOT and wifi range. However, the catch was that whenever I enabled this feature performance slowed to a crawl. Evidently it was using a fair bit of processor grunt. it was probably using a fair bit of extra power too (I'll measure it at some point). The later I'm not worries about, battery life is already way above spec, but all that processor usage slowed the speed of reading and sending NFC data, and that was not good. The solution? Make my code run faster, and reduce processor usage. Easiest solution was I was running a thread that was not required. On the old code- Script started and did a lot of setting up Thread 1 started for NFC reading, time

After a superb PiWars conference a couple of weeks ago, plus some encouragement from across the seas, I'm going to make a custom PCB, or to be more correct two custom PCBs, for the timing device. At present, the most time consuming thing when building the devices is all the soldered wire connections between the modules. Plus the fixing of the components to the interior of the case is not as slick or fast as I would like. But.... I am no electronics expert, and if we want a PCB this century I'm not going to be able to reverse engineer the modules. So, the plan is to make two large PCBs, one for each side of the case. Each side will have mountings for modules (soldered), effectively reducing the wire connections to just a short cable (with a connector) joining both sides and the aerial connectors. This allows me to incorporate a much higher performance Adafruit PN532 NFC reader into the design, although it will need a ferrite shielding panel. Find out about PiWars here -  https:/

This post has nothing to do with timing! I have recently been distro hopping around trying to find one that works for me. However, I have a focusrite scarlett 18i8 second generation, which requires some fiddling to make work on linux. This has been a process of trial and error, reading lots of forums and seeing what works. After the fourth time of doing it, I now have a method which works. I'm assuming you are using nano as your editor here, but feel free to replace with whatever you are using. Loading the driver correctly There has been a working driver for this device in the kernel for a little while, but it needs to be setup correctly. Run -  lsusb | grep Focusrite This should give something like  Bus 003 Device 012: ID 1235:8204 Focusrite-Novation Scarlett 18i8 2nd Gen Note the ID, we'll need this later Run - sudo nano /etc/modprobe.d/scarlett.conf Add the following line, substituting vid and pid for the ID parts from stage 2 -  options snd_usb_audio vid=0x1235 pid=0x8204 d

There is a new update on github for the device code, the much needed reading UIDs in hex format. Much needed because that is what the rest of the world does, so it now means- You can check UIDs by scanning a NFC chip with your phone You can order pre-scanned and labelled NFC chips in bulk, and the prescanned hex code will be compatible The spreadsheet looks neater Pycom also released an update meaning longer (14 byte I think... off the top of my head) UIDs are now supported. Still more to get done this week!

Sorry for the recent silence - our beloved education secretary has been making sure the day job doesn't get boring for the last few weeks. Updates coming this week- Finally a move away from bytearray NFC UIDs to hexadecimal Updated build instructions (this has needed doing for ages I realise) The first draft of the redesign plans to accommodate Pycom's new M2 form factor Phones as NFC chips (maybe)