Positioning, at heart, is precise ranging
Satellite positioning boils down to one sentence: if you know how far you are from several points whose positions are known, you can work out where you are. The satellites are those known reference points — 20,000 km overhead, constantly broadcasting their own position and time.
Measuring distance with time
Satellite signals travel at the speed of light. Each signal is “stamped” with a precise transmit time; the receiver notes the arrival time, and the difference Δt times the speed of light c gives the satellite-to-receiver distance. The scale here is striking: a 1-nanosecond timing error ≈ 0.3 m of ranging error. That's why every satellite carries an atomic clock, keeping time to the nanosecond.
But to stay cheap, receivers use an ordinary quartz clock that carries an unknown “clock bias.” So what we actually measure isn't the true distance but a bias-laden “pseudorange” — a term that's the key to everything that follows.
Three spheres intersect, four satellites fix
Knowing your distance to one satellite places you on a sphere around it; two satellites, two spheres meet in a circle; three satellites, three spheres meet at a point — that's “trilateration.” So why do phones always say “at least 4 satellites needed”? Because on top of the x, y, z coordinates there's a fourth unknown: the receiver's clock bias. Four unknowns need at least four satellites, solved together as one system. The more satellites in view, the more stable and accurate the solution.
Where is the satellite right now? — the ephemeris
To use a satellite as a reference, you first have to know precisely where it is. Each satellite broadcasts a set of ephemeris parameters in its navigation message — essentially Keplerian orbital elements plus a series of perturbation corrections. Plug them into the formulas and the receiver can compute the satellite's 3D position and velocity at any instant. Ephemerides “expire” over time, so they must be refreshed continuously.
Time is the soul of the whole system
The entire GNSS rests on a common time base (GPS time, BeiDou time, …). Satellite-clock drift, relativistic effects, hardware delays on transmit and receive — any misalignment in time inflates directly into meters of positioning error. In a real sense, positioning is first and foremost a timing problem.
What exactly is broadcast from space
A satellite's signal is really three layers stacked together. Understand these three layers and you understand where the “time information for ranging” is actually hidden.
① The carrier is a multi-gigahertz sine wave that “carries” the signal to the receiver. ② The ranging code (PRN) is a public, pseudo-random 0/1 sequence — like each satellite's unique “fingerprint”: it lets a receiver tell satellites apart on the same frequency (this is CDMA), and it's exactly what carries the precise timing used for ranging. ③ The navigation message is the slowest data layer, broadcasting ephemeris, clock parameters, satellite health, and more to the receiver.
Modern systems also broadcast on several frequencies at once (GPS L1/L2/L5, BeiDou B1/B2/B3, …). Multi-constellation, multi-band not only puts more satellites in view and improves reliability under obstruction — a dual-frequency combination can also cancel most of the ionospheric error outright. That's the foundation of high-precision positioning, and exactly why our simulator runs 48 channels in parallel across 1176–1610 MHz.
What happens to the signal along the way
Over the 20,000 km from satellite to receiver, the signal gets “discounted” layer by layer. To simulate convincingly and position accurately, you have to model each of these losses one by one — and that's precisely the divide between a serious simulator and a toy.
The main “discounts” include: ionospheric delay (varies sharply with solar activity; commonly corrected with the Klobuchar 8-parameter model), tropospheric delay (depends on satellite elevation and station altitude), relativistic effects (the satellite moves fast and sits in a weaker gravitational field, so its clock runs faster and must be corrected — including an orbital-eccentricity term), group delay TGD/ISC (hardware delay bias between frequencies), multipath (signals reflected off buildings/ground superimposing on the direct wave), and satellite clock bias (described by an a0/a1/a2 polynomial).
That's exactly why we build in a full chain of loss and error models — Klobuchar ionosphere, elevation-dependent troposphere, relativistic and group-delay corrections, elevation-based power fade. What comes out is therefore not an “ideal signal” but one that approaches the real sky; only then does the testing you do with it truly mean something.
Rebuilding the whole sky in software
What a GNSS signal simulator does is run the earlier flow “in reverse”: given a scenario (time, place, motion trajectory), it computes each satellite's position, pseudorange, and Doppler relative to the receiver, synthesizes the corresponding RF signal, and feeds it to the receiver. It frees R&D and testing from real weather and real trajectories — inside a lawful closed environment you can reproduce any scenario on demand: weak signals, high dynamics, specific constellation configurations…
This path didn't start from scratch. In the open-source community, projects like GPS-SDR-SIM and GNSS-SDR proved early on that you can “generate GNSS baseband signals with a software-defined radio (SDR)” — typically single-constellation, single-frequency, generating an IQ file offline and replaying it. We stand on that work, but have pushed it up another order of magnitude to engineering-grade usability.
First, reliability. The old offline-file approach can't run long tests. We built a real-time signal engine that supports 7×24 continuous operation — no dropout, no accumulated drift over long runs — so endurance testing and unattended monitoring finally become feasible.
Second, cost. High-end signal sources easily run into six figures. We optimized heavily at the algorithm level so the engine is compatible with low-cost SDR devices, bringing lab-grade capability down to a price ordinary users can afford — so more teams and more individuals can actually use it.
Finally, performance. Compared with single-satellite, single-frequency prototypes, we deliver multi-constellation, multi-band parallelism across 48 channels which — together with the full error models of the previous section and a 1 kHz update rate — brings real gains in both positioning speed and accuracy, enough to validate high-dynamic, high-precision scenarios. For a finer capability list, see the specifications on the home page.
How a receiver completes a fix
The earlier chapters described positioning from the system's point of view; this one shifts to the receiver's side. For a receiver, a fix typically goes through four stages — acquisition, tracking, demodulation, and solving — completed continuously in the millisecond-to-second range, after which it keeps outputting results.
Acquisition and tracking
After powering on, the receiver must first find satellite signals in the noise. Satellites move fast relative to the ground, so their carrier has a clear Doppler shift and the ranging code carries an unknown code phase. In acquisition, the receiver correlates a locally replicated code against the incoming signal across a two-dimensional search space of “Doppler frequency × code phase”; when the two align and the correlation shows a distinct peak, that satellite is deemed acquired. It then enters tracking: a code tracking loop (DLL) keeps the code phase aligned and a carrier tracking loop (PLL) keeps carrier lock, together ensuring the receiver reads observables from the signal stably and continuously. If either loop loses lock, re-acquisition is required.
Demodulation, solving, and time-to-first-fix
Once tracking is stable, the receiver completes bit and frame synchronization, demodulates the navigation message, and obtains parameters such as ephemeris and clock bias; from these it computes each satellite's position at that instant, then combines the respective pseudoranges and solves the receiver's position, velocity, and time (PVT) via least squares or a Kalman filter. The time from power-on to the first coordinate output is the time-to-first-fix (TTFF): a cold start with no prior information usually takes tens of seconds, while a warm start with cached ephemeris and an approximate position often needs only a few seconds. The more satellites in view and the better their geometry (the smaller the PDOP), the more stable and accurate the solution.
Consumer devices like phones: the app layer can't reach the signal details
One point deserves emphasis: on consumer devices such as phones, signal reception, down-conversion, acquisition, tracking, and message demodulation are all handled by the GNSS chip (or the RF and baseband blocks inside the SoC) together with the OS lower layers. An app generally cannot touch the raw observables or the signal-processing process; it can only obtain a final conclusion through the system location service — a set of latitude/longitude coordinates with an accuracy estimate. (Some platforms expose an interface to read raw measurements, but this is neither available on every device nor free of system-authorization and framework constraints.)
This also explains why positioning tests should act at the signal or system layer rather than editing values at the app layer: the simulator targets the chip itself. It replays sufficiently realistic satellite signals at the RF front-end so the whole chain performs acquisition, tracking, and solving by real logic, and the device computes the preset position on its own — only such validation is credible, and only it can cover behavior under real conditions like weak signals, multipath, and high dynamics.
Know the how, and the why
From a faint beam of signal in space to a stable coordinate on your screen, in between lies layer upon layer of ranging, solving, timing, and error modeling working in concert. Understand the principles and you'll see more clearly where a good simulator needs to put in the work; and it's precisely along those three lines — reliability, cost, and performance — that we've refined an open-source prototype into a product fit for serious engineering.
To learn more about specific capabilities and ways to work together, head back to the product home page, or get in touch.
AnyLocate specifications
A summary of the core specs below; “✓” means supported, the rest are concrete figures. Full parameters are per the manual shipped with the software and your actual version.