Building Our Own RTK Rover, Part 1: From Breadboard to a Board of Our Own

Why We Decided to Build Our Own RTK Rover

At Plantec we spend our days helping customers put precise positioning to work on real jobsites: machine control, site setout, utility detection, survey. We reckon the best way to really understand a technology is to build it yourself, so over the past year a few of us have been doing exactly that in whatever spare time we can find: designing and building our own RTK GNSS rover from scratch.

This isn't about replacing the CHCNAV kit we know and trust, and it's not going to end up on a shelf next to it. It's more of a curiosity project that got a bit out of hand. It has meant getting our hands into every layer of the stack, from the satellite signals down to the plastic the electronics sit in, and honestly a lot of what we've learned along the way has already fed back into how we talk to customers about the kit we sell.

This is part 1 of that story. Early days, the bits that didn't work, and how it went from a mess of jumper wires on a bench to something that's starting to look like a real product.

RTK stands for Real-Time Kinematic. It's the technique that turns a GNSS receiver's "somewhere within a few metres" into "here, to within a couple of centimetres." Basically the difference between knowing roughly where the pole is and knowing exactly where it is.

What a Rover Actually Needs to Do

Before getting into what went wrong (a lot did), it's worth being clear on what the thing is actually for. Strip it back and a rover has three jobs.

First, it has to listen to the sky. A multi-band GNSS receiver and antenna track satellites across several constellations at once: GPS, GLONASS, Galileo, BeiDou. Second, it needs corrections. On its own a receiver is only good to a metre or two, so to get down to centimetres it needs a live stream of correction data, an RTCM feed, pulled from a base station or a correction network over the internet using a protocol called NTRIP. Third, it has to talk to the field app. In our case that's CHC's LandStar, and the corrected position needs to reach it as a stream of standard NMEA messages over Bluetooth.

Get all three of those working together reliably, in the rain, on battery, for a full day, and you have a rover. Each one turned into its own little rabbit hole.

The Early Days: A Bench Full of Jumper Wires

The first version was exactly what you'd picture: a development board, a GNSS receiver module, an antenna balanced on the windowsill, and far too many jumper wires. Nothing custom, nothing sealed, nothing tidy. Just enough to prove the idea would actually work.

We picked an ESP32 microcontroller to run the show. It's cheap, capable, has Wi-Fi and Bluetooth built in, and there's a huge amount of open-source code around it, which matters a lot when you're figuring things out as you go. Alongside it sat a UM980, a professional-grade multi-band GNSS receiver, the same class of chip that makes centimetre accuracy possible in the first place.

Getting the basic data flow working didn't take long. GNSS data comes out of the receiver into the ESP32, which then fans it out in several directions at once: over Bluetooth to a phone or tablet, over the local network, and up to an NTRIP correction service, while RTCM corrections flow the other way back into the receiver. We built a small web page so we could configure the thing from a browser rather than reflashing it every time, and got over-the-air updates working so we didn't have to keep plugging a cable in.

And then we ran straight into the problem that ended up shaping most of the project: Bluetooth.

The Bluetooth Problem That Wouldn't Go Away

LandStar, like most professional survey apps, expects position data over Classic Bluetooth, the older "serial port" style of Bluetooth known as SPP. Sounds simple enough until you look at what's actually available in the silicon.

The newer ESP32 variant we wanted to use for its extra memory, the ESP32-S3, only supports Bluetooth Low Energy. It can't do Classic SPP at all. The older ESP32 chip can do it, but has a lot less memory left over for everything else the rover needs to be doing at the same time.

So we tried the obvious thing: running Classic Bluetooth and Wi-Fi together on the older chip, and measured it properly on the bench against a phone. It was rough. With both radios fighting over the same antenna, the data stream stalled and dropped messages constantly, running something like a hundred times worse than a clean link. This wasn't something we could tune our way out of. It was two radios genuinely getting in each other's way.

That result settled it for us. Instead of forcing one chip to do everything, we split the job in two. The ESP32-S3 handles GNSS, corrections, Wi-Fi and the web interface. A separate, dedicated Bluetooth module handles the Classic Bluetooth link to LandStar on its own radio, with nothing else competing for airtime.

It's less neat than "one chip does it all," sure. But it's solid, and on a rover that's going to spend its life outdoors in someone's hands, solid matters a lot more than neat.

The Moment It Clicked: RTK Fixed

The first time the rover reported "RTK Fixed" was a good moment.

That's the state every RTK setup is chasing: the receiver locking onto the correction stream tightly enough that its position resolves down to the centimetre, around 1.5 to 2cm for us. Watching a rover we'd built ourselves take corrections off the network and feed a Fixed, centimetre-accurate position into LandStar was proof the whole architecture actually held together end to end.

The rover's own web interface, served straight from the ESP32, showing an RTK Fixed solution: 33 satellites in use, an estimated accuracy of around 1.3cm horizontal and 2cm vertical, and the NTRIP client connected. (Position blurred.)

Getting there wasn't only about the radios, either. A fair bit of unglamorous work went into the details: making the position messages match exactly what LandStar expects down to how satellite counts get reported, squeezing the firmware into the chip's tight memory, making sure the rover recovers cleanly when Wi-Fi drops or the receiver resets itself. None of it is exciting to write about, but it's the kind of thing you only really learn by building it and watching it break.

The Newest Revision: Moving to PowerFeather

A bench prototype is one thing. Something you'd actually carry onto a site is another, and the biggest gap between the two was power.

Our latest revision moves onto a PowerFeather board, an ESP32-S3 in a compact Feather form factor with proper power management already built in: lithium battery charging, fuel gauging, and the ability to actually sense how the battery's doing rather than just guessing. That last bit matters more than it sounds. It means the rover can show its own state of charge, plus estimated runtime and charge time, right there in the web interface. So out on site you know whether you've got enough battery to see the job through, instead of hoping.

Alongside the new board we spent time maturing the firmware too. The link to the receiver is faster and more reliable now, running at a higher data rate and re-negotiating itself automatically on boot so it survives a receiver reset without fuss. Firmware updates are safer, rolling themselves back automatically if a new build doesn't come up healthy, so a bad update can't brick a rover out in the field. And the whole thing is just tidier: the sprawl of bench wiring is slowly collapsing down into a single, purpose-built board.

This is the revision that finally started feeling like actual hardware rather than an experiment held together with hope.

Starting on the Enclosure

Which leaves the last piece: giving the electronics somewhere to actually live.

A rover leads a rough life. Rain, dust, getting dropped in the mud, left on a roof bar in the sun. So we've started on a weatherproof enclosure, designed parametrically so we can adjust dimensions and reprint it as the boards keep changing underneath it. The first version treats every opening as a potential leak: a sealed, waterproof USB-C port for charging and updates, a gasket-sealed antenna connector so the cable can't wick water in behind it, a sealed pushbutton, a closed-off window for the status LED so light gets out but water doesn't get in, and a breathable vent membrane that lets pressure equalise without letting liquid water through.

We've been testing the seal as we go, and this is the first point in the project where it's felt less like a prototype and more like something we could actually hand to someone.

What's Next

That's part 1: a bench prototype that's grown into a battery-powered, weather-sealed rover running our own firmware and holding a centimetre-accurate Fixed position. There's still plenty ahead, a proper custom circuit board, batteries built into the design rather than bolted on, an on-device status screen, and real field trials against the kit we already know inside out.

We'll get into all of that in part 2.

---

Plantec is a UK supplier of GNSS positioning, machine control and utility-detection technology. This build series is part of our ongoing work to understand the tools we support at the deepest possible level, so we can specify them better, support them faster, and explain them clearly to the people who rely on them every day.