One of the reasons we built Nexus Telemetry was to see what the Starlink app doesn’t show you. Over the past couple of days it proved its worth in exactly that way, catching my dish silently spinning 190° and going almost flat, all without any impact on performance and completely invisible to the official app.
My dish had been in the same position for over three years. Same azimuth, same elevation, same tilt. It found its spot shortly after installation and stayed there. Until this week, when Nexus flagged that the alignment data had changed dramatically.
What Nexus showed me
I’ve been running Nexus Telemetry continuously, streaming telemetry from the dish every second. On reviewing the alignment data I noticed something unexpected. The dish had physically driven itself to an entirely different orientation.
In February, the boresight azimuth was roughly -171° (pointing south), elevation around 68.3°, and tilt at 21.7°. By April, those numbers had shifted to an azimuth of about 20° (pointing north), elevation of 80.5°, and tilt of just 10°.
The dish hadn’t simply tilted back. It had spun almost 190° on its axis, rotating from facing south to facing north, and then flattened itself out to near-zenith. The tilt halved and the elevation climbed to over 80°. It effectively turned itself around and lay almost flat. This wasn’t subtle.
The actuators reported IDLE and the attitude filter showed CONVERGED, which means the dish intentionally drove itself through that entire rotation, settled into its new orientation, and decided it was happy there. This wasn’t wind damage or a physical knock. The motors did this deliberately.
The firmware changed
Between my February and April snapshots, the firmware had updated from 2026.02.16.cr74084 to 2026.04.03.mr77363. There’s an interesting detail there: the build prefix changed from cr to mr, which likely indicates a different build branch or release track. Whether that’s related to the repositioning or just coincidental timing, I can’t say for certain, but the correlation is hard to ignore.
The desired boresight didn’t change
This is the part that caught my attention. The dish exposes desired_boresight fields in its status response, and those hadn’t changed at all. They still read -170° azimuth and 70° elevation, exactly where the dish had been pointing for three years.
So the dish had moved itself nearly 190° away from its own target position and was sitting there contentedly with a converged attitude filter, apparently ignoring the values it was supposed to be aiming at. Either the firmware was using a different internal targeting algorithm, or something in the update had broken the link between the desired boresight and the actual pointing logic.
Nexus surfaces both the actual and desired boresight values side by side, along with the delta between them. Without that comparison, you’d have no way of knowing the dish was off target because everything else, the attitude state, the actuator status, was reporting normal.
Zero performance impact
Here’s the genuinely surprising part. Performance was completely fine.
Latency averages were normal at around 23ms. No ping drops. Zero obstruction at 0.0%. Excellent signal quality with a mean SNR of 0.997. I pulled down the full Google Gemma AI models on the same day the dish repositioned itself and had no issues at all.
The repositioned direction was pointing roughly north, where the Starlink constellation is relatively thin at my latitude (56°N in Scotland). The fact that performance was indistinguishable from the original orientation raises some interesting questions about just how much redundancy the constellation has, and whether the dish’s pointing direction matters as much as we might assume for a phased array system.
The fix: a reboot
I rebooted the dish. That’s it.
Nexus logged the entire sequence. The dish started its boot cycle at 14:35 with an OUTAGE BOOTING advisory lasting 1 minute 22 seconds. At 14:38 it performed a sky search for about 5 seconds, followed by a brief NO DOWNLINK warning of another 5 seconds while it reacquired the network. By 14:39 it was back online and stable.
The sky search is the key moment. That’s when the dish re-evaluated its pointing and snapped back to the desired boresight values it had been ignoring. After the reboot, the alignment showed azimuth at -171.5° and elevation at 71.1°, which is only 1.5° and 1.1° off the desired target respectively. Tilt was back to 19.1°. The attitude filter converged with an uncertainty of just 0.27°.
Total downtime: 1 minute 32 seconds. Almost entirely the boot cycle itself.
What does this mean?
I’m speculating here, but it looks like the firmware update introduced a change to the pointing logic that caused the dish to drive itself to a new position without updating the desired boresight fields. The dish thought it was where it should be (converged attitude, idle actuators) but the target it was using internally didn’t match the one exposed in the status API. A reboot forced it to reinitialise and re-read the original targets.
A couple of other users on Reddit confirmed similar behaviour. One in North Florida reported their dish had been pointing straight up for a couple of weeks. Another noticed their dish move for the first time in years before returning to its original angle. The pattern seems consistent with a firmware-driven change rather than anything environmental.
If your dish has recently repositioned itself, particularly after the mr77363 firmware update, try a reboot. It took under two minutes and mine went straight back to where it belonged.
What we’re building next
This experience highlighted a gap in Nexus that we’re now going to fill. We had the telemetry data to spot the repositioning, but only because I happened to compare two snapshots taken weeks apart. That’s not good enough.
We’re adding a firmware history table to Nexus that will automatically log every firmware change with the exact timestamp it was detected. No more guessing when an update landed or trying to remember what version you were on last month. When SpaceX pushes a new build to your dish, Nexus will record it and you’ll have a clear chronological record of every firmware version your terminal has run.
Alongside that, we’re adding positional change tracking. Nexus will periodically record the dish’s alignment and log any changes to a dedicated table. If your dish moves, even by a fraction of a degree, you’ll have a timestamped record of when it happened and how far it shifted. Combined with the firmware history, you’ll be able to see at a glance whether a position change coincided with a firmware update, a reboot, or something else entirely.
Both of these features are lightweight. The data is already there in the telemetry stream; we just need to persist it and surface it properly. If I’d had this a month ago, I wouldn’t have needed to manually compare February and April snapshots. Nexus would have shown me the exact moment the dish started moving and exactly which firmware build triggered it.
This is what Nexus Telemetry is for
The official Starlink app would have shown a green dot and a speed number throughout this entire episode. It wouldn’t have told you your dish had rotated 190°. It wouldn’t have shown you the mismatch between actual and desired boresight. It wouldn’t have logged the sky search that corrected it. You’d have had no idea anything had happened, and no way to fix it if performance had been affected.
Nexus Telemetry connects directly to your dish on your local network and streams every data point the terminal broadcasts. Alignment, obstruction maps, signal quality, boot timings, firmware versions, GPS coordinates, subsystem health, and the raw status fields that the official app abstracts away. It works when your internet doesn’t, because the dish is still broadcasting locally even when your connection is down.
It runs on Mac, Windows, and Linux. You can try it free for three days at nexustelemetry.com.
We’ll be writing more about what the telemetry data reveals as we dig deeper into how the constellation and firmware evolve. If you’re interested in Starlink beyond “is it fast enough,” follow @nexustelemetry on X or subscribe to the newsletter for new posts.