Log in to your Altimeter Cloud account
Don't have an account? Create one
We'll send a confirmation link to verify your email. Check your spam/junk folder if you don't see it.
Already have an account? Log in
Jupiter carries a full multi-constellation satellite receiver for live position tracking, recovery, and flight logging. This page covers the receiver itself, how Jupiter gets it to a fix in seconds rather than minutes, what accuracy to expect and where the physical limits are, and the installation realities, carbon fibre and launch rails included, that decide whether GNSS works well in your rocket.
The onboard receiver is a u-blox SAM-M10Q, a module built on u-blox's M10 platform with its own integrated patch antenna. Jupiter runs it at a 10 Hz navigation rate over a high-speed serial link, and configures it into the airborne dynamics model, which tells the receiver's internal filtering to expect rocket-like motion rather than pedestrian drift. That configuration matters enough that Jupiter audits it after boot and reports if the receiver is ever found running anything else, because the default model assumes low dynamics and will smear or reject genuine high-speed motion.
GPS is one satellite constellation, the American one. GNSS is all of them, and Jupiter tracks four concurrently: GPS, Europe's Galileo, China's BeiDou and Russia's GLONASS, plus the QZSS and SBAS augmentation systems. The practical difference is the number of satellites usable at once, typically two to three times as many as GPS alone, and that surplus is what buys real-world robustness: better geometry for a more accurate solution, faster fixes, and, most relevant to rocketry, tolerance of a partially blocked sky. A rocket lying on its side after landing, an antenna shadowed by the airframe or a rail, a recovery site next to trees, all of these hide part of the sky, and the receiver that can see four constellations keeps a solution where a GPS-only receiver loses one.
A satellite receiver starting cold has a problem: before it can compute a position it needs to know where the satellites are, and downloading those orbits from the satellites themselves happens at a painfully slow broadcast rate, which is why an unassisted receiver can take minutes to first fix. Jupiter sidesteps this entirely. AltimeterCloud maintains live orbit data for all four constellations, refreshed every 20 minutes, and Jupiter downloads it over its cellular connection and injects it into the receiver along with an approximate position and precise time, so the receiver starts already knowing the sky. The result is a fix in seconds under open sky rather than minutes.
The seeding looks after itself. At power-up Jupiter fetches and injects promptly, retrying in a burst until the first seed lands. After that it works on the same cycle as the satellite data itself: broadcast orbit data is valid for roughly two hours, so Jupiter re-fetches and re-applies its aiding on that cycle for as long as it is powered, and the agnss_ttl setting lets you choose one, two or three hours, with two as the default. Because the cloud rebuilds its orbit set every twenty minutes, each fetch delivers data that is never more than minutes old, and the cost of staying fresh is negligible: AltimeterCloud compresses the orbit set with LZMA before sending, so each re-download uses only around 6 KB of cellular data, about 0.006 MB. The orbit data is cached on the device, so a patchy signal at the launch site doesn't cost you the assistance, and the cache management is deliberately suspicious: stale aiding can mislead a receiver worse than none at all, so aged data is purged rather than trusted, and if the receiver sits fixless for twenty minutes the cache itself is blamed and re-fetched fresh.
Under open sky, expect horizontal accuracy in the region of one and a half to two and a half metres, with vertical accuracy roughly one and a half to two times looser, which is the general character of satellite positioning: the geometry is simply better sideways than up. That is excellent for tracking and recovery, and it is also why GNSS altitude is recorded but never used for apogee detection or deployment, as covered on the Altitude & apogee page.
The limits worth knowing are dynamic. The receiver's airborne model tracks up to roughly 4 g of sustained acceleration; a high-power boost beyond that exceeds the tracking envelope and the receiver can lose lock during the burn, reacquiring in the calmer coast and descent phases. Receivers of this class also carry standard operating ceilings around 500 metres per second and 80 kilometres of altitude. None of this affects what matters most: by the time the rocket is on the ground and needs finding, dynamics are zero, the sky is open in at least some direction, and the four-constellation solution is at its strongest.
For maximum reliability Jupiter supports an expansion GNSS receiver on a separate board, mounted wherever suits the airframe, and it receives the same treatment as the onboard one: the same navigation rate, the same airborne configuration and the same orbit seeding, with its data recorded alongside the onboard receiver's in the flight log. The reliability gain comes from mounting it in a different orientation: a patch antenna sees a hemisphere, so two antennas facing different ways cover the sky between them however the rocket comes to rest. A rocket on its side with the onboard antenna facing dirt is exactly the situation a nosecone-mounted expansion receiver facing the other way exists for.
Two installation realities decide GNSS performance more than anything electronic. The first is carbon fibre: it is electrically conductive, and a carbon fibre airframe tube is close to a shield at satellite frequencies, attenuating signals to the point of unusability. If your airframe is carbon, do not expect the onboard antenna to see through it; the working solution is the expansion receiver mounted in a non-carbon section, and a fibreglass or plastic nosecone is ideal, transparent to the signal and pointing at the sky for the whole flight. The second is the launch rail: a metal rail inches from the antenna blocks and reflects a large slice of the sky, and can noticeably degrade the fix while the rocket sits on the pad. Orient the device so its antenna faces away from the rail where the mounting allows, and expect the pad fix to be the worst of the day, improving the moment the rocket leaves. Neither of these is a fault to diagnose; both are physics to plan around, and the expansion receiver in a clear nosecone answers both at once.