Route planner
Plan a path, see the bytes
Pick two cities and a time within six hours of the orbit snapshot. Your browser computes where every satellite in the orbital planes of Starlink's 53° / 463 km shell is, plans the shortest path over our model of the laser links, gives every hop a deadline, and writes the result into the T-CRH routing header, byte for byte.
Loading the orbit snapshot and the laser-link model…
How it works
The same rules as the Python reference
The planner is a TypeScript port of the project's Python router (cr route). For the chosen instant it
builds the network of the shell: the laser links of our Grid-4 model
Label: MODELLED
laser links
that are up at that instant, and each city's links to the four highest satellites at least 25° above its horizon
Label: MODELLED
ground links
. Every link weighs its light time rounded to the nearest
nanosecond plus 0.5 ms of processing, so all costs are whole numbers and every implementation adds them up the same
way. Dijkstra's algorithm finds the cheapest path; when two paths cost exactly the same, the lower node number wins.
Each hop then gets a budget, the slack S (1.5 by default) times its predicted delay, and the cumulative budgets become the deadlines in the header, rounded up to whole deadline units (0.1 ms by default). If a delta exceeds one byte, it is clamped and SAT is set, as the specification's encoding rule requires. The header bytes come from the site's T-CRH engine, which passes every shared golden test vector. Label: REAL header bytes
Checked against Python. On every deployment, CI runs the Python router and this planner on the same satellite and city positions for 20 fixed city pairs, twice: on the project's reference snapshot and on the snapshot this page serves. It stops the deployment if any path cost differs by more than 1 ns or any byte of the header, packet or capture file differs. Two different paths whose costs agree within 1 ns are allowed, reported as ties (never as identical), and their header, packet and capture file are still compared on Python's path. Positions themselves are compared separately for both snapshots, using the published element sets for the served snapshot: the browser's SGP4 library keeps element epochs to the millisecond only, so its positions differ from Python's by up to about 8 metres, which is why the route check uses one shared set of positions.
What this is not: Starlink's routing. It is not public, and Starlink does not use T-CRH. Label: UNKNOWN Starlink's routing The modelling choices are listed on the methodology page; the header format on the protocol page.