The cellular modem

The modem is what makes Jupiter different in kind, not just in degree: live tracking on a map, flight logs that upload themselves, and full configuration from any web browser, with nothing to pair, no app to install and no cable to plug in. This page covers the module itself and one hard rule about it, the two networks it uses and how it moves between them, how it repairs itself without being asked, what the data costs, and the SIM included with every device.

The module

Jupiter uses the SIMCom SIM7090G, chosen for a combination that matters in a rocket: it is genuinely tiny, it sips power, and it works well in the real world. It speaks both of the cellular network types built for small connected devices, LTE-M and NB-IoT, across global bands, so the same hardware works across countries and carriers, and it has proven itself reliable across long field days on marginal rural signal, which is exactly where launch sites tend to be.

One hard rule: never power on without the antenna

The modem must never be powered with no antenna connected. A transmitter driving into a missing antenna has nowhere for its power to go, the energy reflects straight back into the amplifier, and that can permanently damage the modem. This is not a Jupiter quirk, it is true of every radio transmitter, but it earns its own heading because it is the one way to break the modem that no software can protect against. Antenna first, power second, always.

Two networks: LTE-M first, NB-IoT as the deep-coverage fallback

LTE-M and NB-IoT are siblings with different priorities. LTE-M is the faster of the two and Jupiter's first choice. NB-IoT trades speed for reach: it is engineered with a substantially deeper link budget, meaning it keeps working on signal levels where LTE-M barely registers, punching further from the mast and deeper into terrain. At a remote site where an LTE-M attach is hopeless, NB-IoT is very often still solid, slower but reliable, and everything Jupiter sends is sized so that slower is fine.

The movement between them is automatic. Jupiter tries LTE-M, and if no attach lands within a set window, a minute and a half by default, it falls back to NB-IoT; while living on the fallback it periodically re-scans for LTE-M so an improving signal is never wasted, and every one of these timings is a setting if your site rewards different tuning. You never choose a network; the device simply finds whichever one works where you're standing.

It repairs itself

A field day is long and cellular networks are imperfect, so Jupiter treats connection recovery as a first-class job rather than an error case. It watches its own link continuously, and when something goes quiet it escalates through progressively firmer remedies: reconnect the session, then re-attach to the network from scratch, then hard-reset the modem itself over its dedicated reset line, each step re-entering the same hunt across both network types. It also notices the failures nobody plans for, a modem that has silently rebooted itself is detected and rebuilt, and a connection that has stopped carrying data is caught by watchdogs rather than trusted forever. The connection history is logged, so if a site was difficult you can see exactly what the device fought through. The design intent is simple: within coverage of either network type, Jupiter gets back on the air on its own, every time, with nothing needed from you.

Two bridges, everything protected

Jupiter talks to AltimeterCloud over two channels, each shaped for its job. The MQTT bridge is the conversation channel: settings, rules, commands and status flow through it in both directions, every payload encrypted. The UDP bridge is the data channel, built for weak signal: compact authenticated tracking beacons, and flight-log upload in encrypted, authenticated, integrity-checked chunks where anything lost in transit is simply re-requested. The full protection scheme, AES encryption, per-device authentication and why it is considered unbreakable with current technology, is covered on the Compression & Encryption page.

What it feels like to use

The point of all of the above is that you never think about any of it. Power the device at the field and it connects itself. Open the website and your device is there: change a setting and it applies over the air, watch live data as it streams, and when you fly, the flight log uploads itself and is waiting in your account, charted and ready, usually before you've packed the rocket away. There is no pairing ritual, no app, no cable, no "sync" button. The modem's job is to make distance irrelevant between you and your flight computer, and everything on this page exists so that it does that silently.

The included SIM

Every Jupiter ships with a 1NCE SIM included, and it comes with 10 years of line rental and 500 MB of data already paid for. There is nothing to activate and no contract to open: it works out of the box, across borders, on both network types. When you eventually want more, data top-ups and line rental extensions are purchased directly from your device's settings pages on the AltimeterCloud website, a couple of clicks, no third party involved.

How far 500 MB goes

Further than intuition suggests, because everything Jupiter sends is engineered to be small. A typical flight log is a few hundred kilobytes after compression. A tracking beacon is a few dozen bytes, so even a full day of live tracking costs less than a single phone photograph. Settings changes are effectively free, and the GNSS orbit refresh is around 6 KB a time. Run the arithmetic and 500 MB is over a thousand typical flight logs plus all the tracking and configuration around them: a typical user will fly for years, quite plausibly the full ten, without ever topping up, and even a heavy user, flying every weekend and uploading everything, is looking at hundreds to thousands of flights per top-up. The data allowance is not a meter you will feel running.