When Your GNSS Base Station Drifts: Fixing 3 Common Coordinate Shift Errors

You set up your GNSS base station on a known monument, let it log data, and start roving. Everything looks fine — until you post-process and see the rover positions are off by half a meter. The culprit? Base station drift. It's subtle. It creeps in. And it's maddening because you followed the procedure.

But here's the thing: base station drift isn't mysterious. It's almost always one of three coordinate shift errors: antenna height mistakes, datum transformation blunders, or multipath interference. Once you know what to look for, you can fix each one in under an hour. I've been there — staring at a scatter plot of base coordinates that look like a drunk snake. Let's walk through the fixes.

Who Needs This and What Goes Wrong Without It

Survey crews running single-base RTK

If you're setting up one GNSS base station and sending corrections to rovers—whether for topographic surveys, construction staking, or asset mapping—you're vulnerable to drift. Full stop. The base sits there, antenna locked to a tripod, logging raw data, broadcasting corrections. You assume it holds position. That assumption breaks more often than most techs admit. I have seen week-long monitoring campaigns where the base walked 0.7 meters horizontally over three days—nobody noticed until the client compared as-built coordinates against design files and nothing lined up.

The catch is that drift doesn't announce itself. No red light. No warning beep. The rover keeps getting "fixed" solutions, but the fix gradually shifts because the base itself moved—thermal expansion in the mast, frost heave under the legs, or simply a loose tribrach screw that settled after a truck drove nearby. Wrong order: most surveyors blame the rover first. By the time somebody checks the base, they have already shot two hundred points that will need to be reoccupied.

What uncorrected drift actually costs

Real money, not just metadata errors. A boundary survey I consulted on last year shifted 0.4 meters overnight. The crew set the base on a concrete pad that looked stable—a parking lot curb—but the pad had a hairline crack. When the temperature dropped after midnight, the curb tilted. Next morning the crew resumed work thinking they were on the same control point. They staked a fence line that ended up half a meter inside the neighbor's property. That meant re-staking, a title company review, and an angry phone call from the homeowner. Total rework: two field days and a revised plat. All because nobody checked the base station for drift before starting.

Most teams skip this: running a time-series plot of base coordinates before they begin collecting rover data. They assume the base is static because it's bolted down. Bolts loosen. Ground shifts. Even a 0.05-meter drift over eight hours can throw a utility survey far enough that backhoe operators hit the wrong line. That hurts. And it's completely avoidable.

'We had a 0.4 m overnight shift on a concrete curb. The base never moved—until we looked at the raw file and saw the antenna wander south between 2 a.m. and 6 a.m.'

— utility survey project lead, recounting a job that required 11% re-survey

Who else should care—and who can ignore this

GIS technicians collecting points for asset inventories? Yes, if you rely on a single base for differential correction. Drone pilots doing PPK post-processing? Absolutely—your ground station is the anchor for every image. The only people who can ignore this are those running network RTK (CORS networks) with station monitoring, or surveyors who check their base coordinates every morning against a known monument. That said, even CORS users get burned if the nearest permanent station goes offline and they switch to a local base without verification.

The tricky bit is that drift doesn't respect credentials. I have watched experienced party chiefs miss a 0.3-meter shift because the base was in the shadow of a building and the multipath masked the movement. Their occupation log looked fine—nine satellites, PDOP under two—but the coordinate solution was walking. The only way to catch it's to compare time-stamped positions from the base log against a known static point. If you can't do that before every major shift of the rover, you're gambling. And the house usually wins.

Prerequisites: Before You Blame the Base Station

Known monument coordinates and why they matter

You reset the base station, log a new session, and the numbers still look wrong. Classic blame-the-hardware move. I have done it myself — swapped radios, replaced cables, even yelled at the tripod. Nine times out of ten, though, the drift was already baked into my setup before I pressed 'Start.' The root cause? Nobody verified the known monument coordinates. If your base sits on a temporary mark you surveyed last month with a handheld GPS, you're not fixing drift — you're just rotating your error budget. A monument coordinate must come from a static occupation of at least 4–6 hours, processed against a CORS network. Anything shorter, and that 'known' position could be off by 20–30 cm horizontally. That hurts. Your rover corrections inherit that offset, and suddenly your utility pole lands inside the road.

The catch is—many teams skip this step because it feels slow. They assume the monument was 'close enough' from a previous job. Close enough is not a geodetic control strategy. We fixed this on a pipeline survey last year by re-occupying every base monument for eight hours overnight. Three out of five shifted more than 5 cm from the recorded values. The client had been blaming the base station hardware for weeks. It was the point, not the box.

Not every geographical checklist earns its ink.

Antenna calibration and phase center offsets

Wrong antenna height. Wrong antenna type selected in the controller. Phase center offset mismatched between the antenna calibration file and what the receiver actually uses. These three mistakes account for maybe 40% of the 'drifting base' calls I see in forums. The antenna doesn't drift — you told it the wrong phase center location. Modern GNSS antennas have an electrical phase center that shifts with satellite elevation and azimuth. The calibration model compensates for that. But if you load a generic 'TRM57971.00 NONE' when your antenna is actually a 'TRM57971.00 SCIS,' the compensation fails. That looks exactly like slow drift on a time-series plot. We chased this ghost for three days on a bridge monitoring project. The fix was deleting the stale antenna file and downloading the correct calibration from the manufacturer site. Thirty seconds. Three days wasted.

Antenna height measurement is its own trap. Slant height vs. vertical height. Measuring to the bottom of the antenna vs. the notch vs. the ARP (antenna reference point). I have seen a single misread tape produce 12 mm of apparent drift over six hours. Not hardware failure. Human error, baked into the metadata. Always double-check the height measurement with a second person before locking the session.

Ephemeris files: broadcast vs. precise

Here is a situation that repeats monthly: A surveyor posts a plot showing 3 cm of easting drift over eight hours. The diagnosis is broadcast ephemeris — specifically, the rapid orbit degradation that happens when the broadcast message ages past four hours. GNSS satellites transmit their own orbital parameters, but those predictions degrade. After six to eight hours, the broadcast orbit error can reach 1–2 meters. For a single-base RTK setup, that degrades the baseline solution. The fix is switching to precise ephemeris files (IGS final or ultra-rapid) in post-processing. That alone can collapse the apparent drift back to the noise floor. Many teams don't realize their post-processing software defaulted to broadcast. Check the processing report. The odd part is—some users resist this fix because downloading a 24-hour SP3 file feels like overhead. Compare that to losing a day of fieldwork and having to re-occupy every point. Not a hard trade-off.

A quick rule: If your base station logged for more than four hours and the drift exceeds 15 mm, try re-processing with precise ephemeris before touching any hardware. Most cases stop right there. We saw a client's weekly monitoring data jump by 20 mm every Wednesday — because that was the day their scheduler restarted the base and used stale broadcast data for the first four hours. Swap to precise, and Wednesdays became normal again. No new antenna. No new receiver. Just a smarter file choice.

'We replaced the receiver twice before someone checked the ephemeris source. That was an expensive way to learn what the processing report already said.'

— Lead surveyor at a deformation monitoring firm, after switching to final IGS orbits

Core Workflow: Detecting Drift with Time-Series Plots

Logging Static Data for at Least Two Hours

You can't spot drift with a five-minute grab. I have seen teams burn an entire day chasing a phantom offset, only to realize their base-station log was barely thirty minutes long. That's not a dataset — it's a guess. Park your rover. Put the base in static mode. Then wait. Two hours is the practical floor for consumer-grade receivers; four is safer if you suspect thermal swings or multipath from nearby structures. The log should record at a one-second epoch interval, dumping raw positions into a single file. Most free tools — RTKLIB, u-blox u-center, even some Trimble Business Center trial modes — will do this without a license. The catch: many field crews forget to disable elevation masks or SNR filters during logging. Those filters hide the very noise you need to see. Don't filter yet. Let the data breathe. A two-hour run with a clear sky yields roughly 7,200 epochs. That number matters — not for pride, but because drift below 2 mm/hour can take 3,000+ epochs to separate from random noise.

What usually breaks first is patience. Technicians skip the log, assume a ten-minute convergence is enough, and then blame the processing software when coordinates disagree. Wrong order. A proper static log is your witness — without it, you can't tell whether the base walked or the correction link glitched. So log first, troubleshoot second. And if you're in a city canyon or under tree canopy? Add another hour. Multipath introduces periodic noise that mimics drift. More data helps you distinguish between the two.

Plotting Easting, Northing, and Height Over Time

Now you have a file. Don't open it in a text editor and squint at numbers — your eyes will lie to you. Plot it. Use any tool: Python with Matplotlib, Excel with a scatter chart, or RTKPLOT which ships with RTKLIB. Three axes, three separate plots. Easting on one, northing on another, ellipsoidal height on the third. Time flows left to right. What are you looking for? A flat line is the holy grail. A slow ramp — easting climbing 3 mm every hour — means the base antenna is sagging, or the monument is settling. That's drift. A sawtooth pattern that repeats every ten minutes usually points to a nearby rotating structure like a radar dish or a crane. I once diagnosed a 2 cm offset that turned out to be a hotel air-conditioner cycling on the roof next door. The plot showed it clearly: rhythmic jumps every twelve minutes, exactly when the compressor kicked in.

Height is often the most revealing. It drifts faster than the horizontals because the troposphere tricks the signal path. A height slope of 5 mm over two hours is common even with a stable base — that's not always hardware failure; it's unmodeled water vapor. But if the height line shows a sudden step, a 1 cm drop inside one epoch, your receiver likely lost a satellite constellation or switched from GPS-only to GNSS multi-band mid-log. That step is a coordinate shift, not drift. Different fix. More on that in the pitfalls section.

Identifying Trend, Noise, and Sudden Jumps

Once the plots are up, talk yourself through three signatures. Trend: a linear slope across the full window. Measure it by fitting a line through the last 1,800 epochs — half an hour. If the slope exceeds 1 mm per ten minutes, something is physically moving or the ephemeris model is degrading. Noise: the scatter around that line. Standard deviation above 3 mm in horizontal, or 6 mm in vertical, suggests weak geometry or high multipath. A noisy base will poison every rover correction that touches it. Sudden jumps: a vertical break in the data that stays flat afterward. That's almost always a receiver reset, a firmware glitch, or a reference frame change — the base is reporting coordinates in a different datum mid-session. I have watched a surveyor reprocess an entire week of fieldwork because they ignored a single 4 mm jump at 14:23:17. That jump was the moment the base automatically switched from ITRF2014 to WGS84(G1762). The rover never knew.

What if the plot looks like a shotgun pattern with no obvious line? Then your base was never stable to begin with. Tighten the tripod, check the tribrach bubble, and re-log. Don't skip this step — no amount of post-processing magic can unbake a bad static session.

Honestly — most geographical posts skip this.

‘The plot is not optional. Every time I have skipped the visual check, I have found the error a week later — in the client’s final report.’

— independent surveyor, during a 2023 workshop on GNSS quality control

Tools and Setup: What You Actually Need

Software options: RTKLIB, Trimble Business Center, Leica Infinity

You need software that can stare at a static occupation and tell you if the coordinates are walking. Free option: RTKLIB's RTKPOST or the newer RTKPLOT. The catch is RTKLIB’s learning curve is a cliff—expect to wrestle with obscure config files and cryptic error codes. That said, it costs nothing and outputs raw residuals. On the paid side, Trimble Business Center (TBC) hides the complexity behind buttons labeled ‘Report,’ but the sticker shock hurts: you're looking at $3,000+ for a license, and TBC won’t read every brand’s proprietary RINEX without extra modules. Leica Infinity sits in the middle—friendlier than RTKLIB, cheaper than TBC, and built to digest data straight from Leica receivers. I have seen surveyors burn two days trying to export from a non-Leica hardware to Infinity, so check compatibility before you commit. The punch line: start with RTKPLOT if you can read a help file, skip Infinity if your gear is a mix of manufacturers, and buy TBC only if your client bills hourly for project delivery.

Hardware: Dual-frequency receiver, choke ring antenna, stable tripod

That $200 single-frequency module you bought online? Not your friend here. Drift analysis needs L1/L2 data so the software can peel off ionospheric noise—single-frequency will leave you chasing ghosts. A choke ring antenna matters more than most engineers admit; without it, multipath reflections from nearby surfaces look exactly like base station wander. The odd part is—I have watched crews swap antennas and see drift drop from 8 cm to 1.5 cm in the plot. A stable tripod is the cheapest insurance you can buy. Wobbly legs introduce tilt, tilt changes the antenna phase center, and suddenly you're fixing geometry instead of drift. Concrete or gravel? Use sandbags on the feet. That sounds fussy until you see the time-series jitter from wind gusts on a lightweight tripod.

Data formats: RINEX 2.x or 3.x, and how to check quality

RINEX 2.11 is ancient but works everywhere. RINEX 3.x carries more metadata—glonass and galileo signals, antenna calibration records—but some old tools choke on it. The safe move is to log in RINEX 2.11 if you're sharing files across teams, or 3.03 if you control the whole pipeline. One concrete anecdote: a colleague spent four hours blaming a Leica receiver before realizing his SONY-style RINEX 3.03 file had a wrong header epoch—RTKPLOT just refused to parse it. Always run a quality check before plotting. Use tools like rnx2rtkp with the ‘-q’ flag or the TEQC command-line utility to flag cycle slips, data gaps, and low satellite counts. A file with 40% data gaps won’t show drift—it shows a useless mess. What to aim for: ≥95% epochs collected, at least six satellites above 15° elevation for the entire session. Fewer than that? Redo the static occupation before blaming your base station coordinates.

Hard truth: the prettiest time-series plot is worthless if your RINEX file is corrupted or your antenna mount slipped. These checks take twenty minutes. Skipping them costs a day. — Field note from a project that lost a week to a loose tribrach

Setting up the toolchain correctly means you stop guessing and start seeing the drift for what it's. Wrong order of operations ruins everything—but get the data flowing, and the plot will reveal what the base station is hiding.

Variations for Different Constraints

Short baselines (<5 km) vs. long baselines (>50 km)

You set up a base station five kilometers from your rover and watch the fix degrade within two hours. That sounds impossible—short baselines should be rock solid. The reality is subtler: multipath from a single nearby building or a wet tree canopy can inject enough common-mode error to shift your solution 3–5 cm, and nobody notices until the gap appears in the time-series plot. For short baselines, you can tighten the drift tolerance to 2 cm over 15 minutes and still catch genuine movement. But stretch that baseline past 50 km, and the rules swap completely. Ionospheric decorrelation starts dominating; your raw double-differenced residuals can crawl 8–12 cm over an hour without the station actually moving. I have seen teams burn a full day chasing a phantom drift on a 70 km baseline, trimming cables and restarting radios, only to realize the base was stable the whole time—the atmosphere was the culprit. The practical fix: double your acceptance threshold for baselines above 50 km, and always pair your drift plot with a sky-plot of satellite geometry. If the residuals trend up while PDOP stays low, that's the atmosphere, not a loose cable. If both trend upward together, shift your base location instead.

Most teams skip this distinction and apply one static tolerance across every job. That hurts—you either chase false positives on long baselines or miss real drift on short ones.

Urban canyons and partial sky view

Drop your base station between two fifteen-story buildings and the GNSS receiver suddenly sees a sliver of sky—maybe 40 percent of the dome. What happens to drift detection? The multipath signature becomes brutal: reflections off glass and steel produce pseudo-range errors that oscillate with the satellite elevation angle, sometimes flipping signs every 15 minutes. Your time-series plot starts showing a sawtooth pattern, not a steady ramp. Is the base drifting? Probably not, but the coordinate shift looks identical in the first hour. The catch is that standard drift detection algorithms assume diffuse multipath, not the sharp specular reflections common in a canyon. So your software flags a 3 cm jump every thirty minutes. We fixed this once by adding a mask angle of 20 degrees and switching to a choke-ring antenna, but the real trick was logging the signal-to-noise ratio per satellite. When SNR drops below 35 dB-Hz on four consecutive epochs, the multipath is corrupting the fix—ignore the drift flag until the satellite rises above the building line. That said, if you're working a construction site in a downtown corridor, skip static base altogether and use a real-time network instead; the closest CORS station 4 km away will actually give cleaner data than your own gnarly base installation.

Rapid static vs. long occupation: when to accept more noise

A surveyor on a tight timeline sets up for eight-minute rapid static sessions, collects five points, and unloads. The base station drifts 1.5 cm during that window. Does it matter? For cadastral boundaries at 1:500 scale, probably not—the horizontal tolerance blows past that anyway. But for structural monitoring or deformation checks where you need 8 mm repeatability, that same 1.5 cm drift contaminates every baseline. The asymmetry is rarely discussed: short occupations amplify the impact of small base movements because the integer ambiguity resolution relies on fewer epochs of data to lock the carrier-phase fix. You get a wrong integer and everything downstream shifts by a full wavelength—roughly 19 cm. Long occupations, say two hours or more, can absorb small base drifts because the averaging window smooths the transient. The trade-off is uncomfortable: accept more noise in short missions and re-occupy a check point after every five rover setups, or budget the extra time for long occupations and trust the base to wander within 3 cm. Here is my rule of thumb from dozens of field fixes: if your occupation time is under 15 minutes, your drift tolerance should halve—drop from 4 cm to 2 cm—because the phase bias risk is higher. Not many calibration sheets mention that. One more thing: I have seen a single long-occupation session of three hours mask a cyclic drift that repeated every 90 minutes, so upload your time-series to a cloud plotter and inspect the pattern, not just the absolute value. Drift that comes and goes is usually thermal expansion of the tripod legs under a shifting sun, not a bad receiver.

“The base station that drifts 2 cm over two hours is still fine for boundary work—but the same drift in eight minutes breaks your phase solution.”

— field note from a structural monitoring crew, coastal California

Field note: geographical plans crack at handoff.

Pitfalls: What to Check When the Fix Doesn't Work

Forgotten antenna height measurement bias

You ran the time-series plot. It looks like drift—smooth, creeping offsets over four hours. So you swap the base receiver, reinitialize, and… the same ghost appears. The odd part is: the shift is exactly 0.084 meters vertical, every session. I have seen teams waste two field days chasing a nonexistent drift when the culprit was a tape measure read to the wrong reference point. Most GNSS antennas have a specified Antenna Reference Point (ARP) and a Phase Center Offset—mix those up and your base height is off by a fixed amount that masquerades as a systematic bias. The fix is not software; it's a single measurement from the ground mark to the ARP, recorded in millimeters before you log a single epoch. If your correction service or post-processing software expects a different antenna model or mounts the L1/L2 phase center at a different height, the error is constant, not drifting—but your time-series plot will show a flat offset that looks like a slow wander to the untrained eye.

That hurts because it's invisible in the field. The rover fix seems fine. Coordinates check against a known point are within tolerance—until you occupy the same mark a week later with a different crew and the vertical jumps. The catch is that antenna height bias is rarely suspected first; most engineers chase firmware bugs or radio interference before they look at a tape measure. Always measure twice: once at setup, once after the session ends. The difference tells you if the pole settled or you misread.

Datum transformation errors: using WGS84 when you need NAD83

Your base station logs in WGS84. Your project calls for NAD83(2011). The transformation between them in the continental U.S. is about one to two meters horizontally—not a drift, but a fixed translation. Yet when you overlay your corrected rover positions against a local control network, the error looks like a regional shift that changes with latitude. Most teams skip this: they assume the base station outputs the datum required by the job. The truth is that many GNSS receivers default to WGS84 even when the field software is set to NAD83, because the base logs raw data in its native frame and the transformation is applied only at the rover or in post-processing. The result is a constant offset that fools drift-detection algorithms—the time-series plot shows a stable baseline, but the baseline is wrong. I fixed one case where the base was broadcasting RTCM messages with a datum tag that the rover ignored; the fix was to force both ends to use the same coordinate reference system via explicit EPSG codes in the receiver configuration files. Wrong order. Not yet. Check your datum before you recompile your firmware.

“We replaced the antenna, the radio, the cable—everything. The shift wouldn’t budge. Turned out the base was streaming GGA sentences in WGS84 while the rover applied a NAD83 transformation. Twenty minutes of settings review fixed two weeks of false alarms.”

— Field supervisor, survey crew, after a highway stakeout project

Multipath from nearby buildings or vehicles

Drift that appears only between 10 a.m. and 2 p.m. is not drift—it's multipath from a delivery truck that parks in the same spot every day. GNSS base stations are supposed to be in open sky, but real sites have roofs, fence lines, and seasonal foliage. A single sheet-metal warehouse 30 meters east can reflect enough L2 signal to create a pseudo-random walk in your baseline solution that looks exactly like receiver clock drift. The time-series plot will show a repeating, diurnal pattern if the reflecting object is stationary—but if a crane or construction vehicle moves around the site, the error becomes erratic and impossible to filter. The fix is physical: raise the antenna, shift it laterally by at least two meters, or shield the ground plane with a proper choke ring. Don't try to model multipath away with software corrections unless you have a dedicated multipath-estimating receiver. I have watched a team spend three days adjusting elevation mask angles and signal-to-noise thresholds when the real solution was to move the tripod 12 feet north, away from a metal shed. The trade-off is that a higher antenna introduces wind-induced vibration, which creates its own noise—you trade one pitfall for another unless you stake the mount.

So when the fix doesn't work, resist the urge to blame the base station oscillator or the satellite constellation. Check your tape measure first. Verify your datum second. Walk the site for reflective surfaces third. These three overlooked causes account for roughly half of the false-positive drift calls I handle. Not yet ready to concede? Then log raw observations for 24 hours and inspect the residual plot for periodic oscillations—but that's chapter seven’s action plan, not this pitfall list.

FAQ: Quick Answers to Frequent Questions

How often should I check base station coordinates?

Everyday before a survey session. That sounds obsessive until you see what a 2-centimeter overnight jump does to a week of collected data. I worked with a team in Colorado who checked base coordinates only when something looked wrong — they lost nine days of RTK corrections because the monument had heaved during spring freeze-thaw. Check at startup, check after lunch, and check if you leave the gear running unattended for more than four hours. The catch is: don't rebuild the average every time. Use the same reference epoch for comparisons. If your software lets you set a fixed point from a 24-hour static log, do that once per season and compare daily averages against it. A >3 cm horizontal shift on two consecutive checks? Stop work, re-occupy the mark, and log a fresh 2-hour static session before continuing.

Can I use a virtual reference station instead?

Yes — but you trade physical drift for network latency and datum slop. VRS solves the "my base walked away" problem because there is no base. However, the network's own interpolated corrections introduce their own wobbles: typically 2–5 cm in suburban areas, worse near tall buildings. The odd part is — many operators assume VRS accuracy is uniform. It's not. The correction stream degrades as you move toward the edge of the network's cell. I have seen 8 cm vertical jumps at 15 km from the nearest physical reference station. That said, if your project tolerances sit at ±5 cm horizontal and you work inside a well-established CORS network, VRS beats maintaining a physical base for most jobs. But — verify the network's latency. Anything above 5 seconds between update packets means your rover is solving positions from stale data. Wrong order.

“A virtual station that drifts 1 cm per hour still costs you the same rework as a physical base that heaved overnight.”

— field note from a pipeline surveyor in Alberta, 2023

What magnitude of drift is acceptable?

Zero drift if you are tying into a control network. For boundary surveys, ±2 cm horizontal is the common ceiling before you see closure errors on the traverses. For machine control — dirt work, asphalt — 3–4 cm horizontal is survivable, but vertical drift above 2 cm will cause grade returns that make the scraper operator curse your name. Here is the trade-off: intentional drift from a poorly constrained Piksi-based station versus drift from a stable Trimble NetR9 that suddenly jumped because a construction crew parked a plate compactor 6 meters from your tripod. Same result: re-obs. Don't calculate "average drift per hour" and apply a correction factor post-mission. That looks clever but fails in any area with tree canopy or multipath — the error vector changes direction. We fixed this once by running a 15-minute static check each morning and plotting those coordinates against the original occupation. Three weeks later the scatter showed no directional bias. That told us the base was stable. The project held. No statistics needed — just a plot and a ruler.

What to Do Next: A Specific Action Plan

Run a 24-hour static session on your base point

Block the calendar for a full day. Set your base station on its monument, log raw data at 1 Hz, and walk away — no touching, no power cycles, no rover connections. The goal is a single, uninterrupted 24-hour RINEX file. Most teams skip this because it feels wasteful: a perfectly good receiver sitting idle while fieldwork waits. I have seen crews lose weeks chasing phantom drifts that a single overnight session would have caught. The trick is to process that file in PPK (post-processing kinematic) mode against a trusted CORS station 50–150 km away, then plot the resulting easting, northing, and height values over time. What you want is a flat line — noise within ±15 mm horizontally, ±30 mm vertically. Anything beyond that and your base point is moving, or your equipment has a thermal sensitivity problem. The catch is that battery life often fails here. Solar panels with a 12 V deep-cycle battery, not a small lithium pack. Test that power chain under load before you commit to the full 24 hours.

Compare your coordinates to OPUS or a nearby CORS

Don't trust your base station’s autonomous position. Ever. Upload that same 24-hour RINEX file to OPUS (Online Positioning User Service) — it’s free, run by NOAA, and returns a solution tied to the National Spatial Reference System. Wait for the email; it usually arrives inside an hour. The OPUS report gives you a precise coordinate with formal errors around 1–3 cm. Now compare that to what your base station thinks its position is. The difference is your static error. Most amateur installs show a 0.5–2 meter shift in the vertical — that alone can wreck a drone lidar survey. But here’s the nuance: OPUS uses a single-baseline approach with ambiguity resolution, so it assumes your site has clean sky view. Multipath kills it. If your base point sits under a metal roof or next to a chain-link fence, OPUS will converge slowly or fail. In that case, pull data from a nearby Continuously Operating Reference Station (CORS) within 20 km and run a double-difference static solution in RTKLIB or Trimble Business Center. The results should match within 2 cm. If they don’t, your antenna calibration is likely stale — see the next step.

‘Every time I see a base station coordinate typed in by hand, I know a week of data will be junk.’

— field surveyor after re-processing 14 days of rover paths

Update your antenna calibration file and re-process

The most overlooked variable is the antenna model. A Trimble Zephyr Geo 5 is not a Trimble Zephyr 3 — throw the wrong calibration file into your software and the phase center offset shifts by 8–10 cm. That’s not drift; that’s a systematic bias pretending to be drift. Go to the manufacturer’s site, download the latest absolute calibration file (ANTEX format), and replace whatever your software defaulted to. Then re-process your 24-hour static session with the corrected model. The odd part is: many people update firmware but ignore the antenna file for years. We fixed one case where the antenna calibration was from 2017 — the phase center variation model had been revised twice since then, but the base station was running a 2008 epoch coordinate. The result? A 3.1 cm vertical jump that appeared every time the satellite constellation changed geometry. After the update, the time-series plot flattened immediately. Do this before you buy new equipment. A free file swap often solves what looks like a hardware failure.