Remember that time you ripped the best lap of your life? You were sure it was way faster than any other lap you ran before. Way faster than anyone else, infact. You made no mistakes, hit every gate perfectly, and that throttle was pinned the whole time. Except, then you go check in with the race tent to see your times. None of your laps were logged. The tracker missed them all.

Yeah, we’ve been there too.

We solved that problem.

Here comes the WizardTracker!

It’s been a while since we showed off the first sneak peak of the WizardTracker, our very own race lap tracker. With our group of engineers, IT folk, and general FPV nuts, we set out to build a tracker without any of the common problems from existing trackers. Our goals were simple, basically aiming for the opposite of everything else:

Be accurate, all the time.

Calibration is awkward and fiddly. If you miss a lap in the middle of a race with current trackers, it’s gone into the abyss forever. Can we make it not do that? Make it get all the laps, all the time? Do away with calibration entirely? Maybe fix things if we do miss a lap, and fix them accurately?

Be simple to build, simple to use.

Minimize the number of components, minimize hardware size, minimize software complexity. Make use of every bit of hardware to it’s fullest without any waste. Make it easy for anyone to build or use. Make the UI beautiful and an actual joy to use instead of a complete nightmare.

Be inexpensive.

The cost of “professional” race trackers is downright offensive if you know what’s inside the magic box. We want anyone and everyone to be able to run a race event, not just those with sponsors. We want a bunch of pals in the park to be able to run their own races, just for fun.

Be open-source.

Open-source is what brings us the greatness that is Betaflight and all of its ancestors. The more people that can help out, the more people that can share their skills and ideas, the better for all of us.

Not really asking for much, eh? Over the course of this year we have been tweaking, refining, and testing the tracker. We’ve kept it under wraps until we had something that reasonably hits these goals, and now we’re finally ready to share our prototype with the world.

See it in action!

We’ve tested our tracker in various scenarios: from flying about in the woods for fun, to running as a backup at the Irish Drone Nationals where it recorded 180 races with 6 pilots each without a hitch.

How does it work?

Our tracker, fundamentally, works like other video RSSI-based lap trackers. It has several video receiver modules, where each is tuned to the frequency of the pilot you want to track. An Arduino reads the RSSI (signal strength) from each of the receivers. Our resident Wizard has magic’d up a slick PCB which can be put together for under £50 for a 6 channel tracker, and about £60 for an 8 channel tracker.

When a racer passes over the receiver we get a spike in the signal strength. By keeping track of the time between these spikes, we get lap times. Simples!

Below you can see a screengrab of the raw RSSI data which we captured of BanniUK during the Irish Drone Nationals. You can clearly see the peaks as he crosses the tracker. Timing between these gives you the lap times.

So, why is our tracker better than others?

The method of timing based on video transmitter signal strength has its challenges. Currently all trackers out there of this type rely on a calibration of the signal strength PRIOR TO the race, when the signal crosses this threshold, the tracker counts a lap.

The issue with this is that the signal can vary massively depending on the video transmitter, the antenna, the distance you pass at, the speed you pass at.. even the orientation of the quad as it passes. This leads to trackers missing laps or counting extra ones. We’ve witnessed this loads at various events and these are trackers from the big players!

Our tracker does NOT require calibration prior to a race, and does NOT miss laps! We can even retrospectively go back to a previous race interrogate and adjust our signal thresholds as we need to. How do we manage this? It’s actually very simple yet clever.

How on earth did we manage that?

Instead of processing the signal strength data on the fly, storing only the lap times and throwing away all that precious RSSI data, what we do instead is store ALL the raw RSSI data which is picked up by the receivers and we post process this data either on the fly or after the race is completed. This way none of the original data is lost! That simple!

This allows us to effectively ‘calibrate’ our tracker thresholds retrospectively and adjust the tracker to not miss any laps.

There’s more to it than that..

It may sound simple, and to an extent the concept is, however there are a number of challenges which we have overcome by some clever logic and programming. These include:

  • Minimal hardware – Unlike some other very bulky trackers, our Wizard aka Dan has managed to squeeze the required hardware onto a tiny little custom designed PCB.
  • Data write speeds – Storing all that data as fast as we can proved challenging. We have optimised our code and used SQL databases to handle this, which gives us an accuracy down to about 10 or 20ms per reading.
  • Noisy signals – The RSSI readings are fairly noisy. We have coded up and applied some filtering to our signals to help overcome this.
  • Peak to Peak Timing – We have some clever logic which makes sure we catch consistent peak to peak times as opposed to the majority of trackers out there which simply record the time from when you cross the threshold.
  • Browser based GUI – Our tracker is built around being able to be controlled via a browser.

What now?

Now that we have the working basis of a concept our plans are to share our work with the world! We are going to open source the firmware and software for the tracker as we need help from all the boffins out there to progress the functionality of the tracker and the GUI. Currently it will track and process times but there is no event / race management abilities. We are just finishing up a tidy up of the code, but expect to see it released for the world to see in the coming weeks.

Hardware wise, we will release a plan / schematic of the tracker and hopefully will have a stock of PCB’s available for people to purchase and make their own. But heres a list of things we’re still to do and hoping the wider community can also help us with:

  • Enclosure – We are yet to design a nice enclosure for the wizard
  • GUI – We have a basic functioning GUI but could do with spicing it up and making it fully portable
  • Pi – We would like to run the tracking portion on a Raspberry Pi instead of a laptop to save on kit we need on the field. We plan to interface with it over a wireless connection with a tablet or phone to run the tracker.
  • Race Management – There are currently no race or event management features, we need to add this into the GUI and database functionality.

The list is endless but this is the beginning of something great! We hope you can join us 🙂

Join the conversation


  1. The pcb has shrunk again since the images were captured in this article. It’s very near the stage of getting sent out to the pcb fab shop. The final design tweaks and function checks happen this weekend while we are all together at the final round of the SDRL in Edinburgh.

  2. What is the status of this atm?
    Where can I find how to collaborate or see the progress? 🙂

    1. We’re still working on getting it into a reasonable state but it’ll be let loose on GitHub very soon! 🙂

  3. Looks great guys would also like to help out with this even if it is just testing 🙂

Leave a comment

Your email address will not be published. Required fields are marked *