Yes: Starlink can carry the network connection
Starlink is a realistic way to give a Reticulum host or MeshSat gateway an IP connection when terrestrial broadband is unavailable. To the host, the terminal's router supplies ordinary network access. The software does not need a special Starlink radio driver. This is an architecture supported by the documented IP interfaces; it has not been field-tested for this research.
Starlink and RockBLOCK solve different problems. Starlink provides a broadband internet connection. RockBLOCK 9704 provides small, metered IMT messages through Iridium. Reticulum and MeshSat sit above those links and decide how applications use them.
Proposed arrangement: local radio traffic reaches a host, which connects through Starlink to a reachable remote peer or service. Radio users do not connect their LoRa antennas to a Starlink satellite.
Reticulum over Starlink
Connect a Reticulum host to the Starlink router using a supported Ethernet or Wi-Fi arrangement. Configure an outbound Reticulum TCP client to a reachable peer that accepts the connection. The documented TCP interfaces support internet and private-network paths; Reticulum supplies its own cryptographic networking above the carrier. Reticulum interfaces
A gateway can combine this IP path with a supported RNode LoRa interface. A stock Meshtastic or MeshCore radio is not automatically that RNode. Pick the radio interface and firmware for the actual protocol you intend to carry.
Starlink's default IPv4 configuration uses carrier-grade NAT. Ordinary port forwarding is therefore not a dependable assumption for hosting a public TCP listener behind it. Initiating an outbound connection to a reachable peer is the straightforward starting design. Public-address options depend on the service plan; do not assume a static public IP. Starlink addressing
MeshSat over Starlink
MeshSat documents a Hub connection using MQTT over a secure WebSocket with a client certificate. That is an internet path that Starlink can carry. The docs also describe reaching the Hub through SMS or Iridium when internet is unavailable. The configured routes and application behavior must still be tested on the chosen release. MeshSat Hub link
This is separate from plugging a RockBLOCK into the host. With Starlink available, a gateway can send eligible application traffic over its IP connection. If Starlink fails, an optional Iridium modem could provide a small-message fallback. Automatic failover is a policy to configure and validate, not an inherent property of connecting two satellite products.
A realistic three-level design
| Situation | Proposed behavior | Dependency that remains |
|---|---|---|
| Both users are on the local radio network | Keep local traffic local | A working RF path and powered nodes |
| Remote communication needed; Starlink available | Use an authenticated IP connection | Terminal power, sky view, active service, remote endpoint |
| IP unavailable; Iridium installed and working | Send only approved short messages | Modem, airtime, provider-side routing, sky view |
| Neither external path available | Keep local communication; queue only where implemented | Tested queue behavior, storage, power, later reconnection |
These are recommended design rules, not a claim that either application implements every row without configuration. Keep local delivery working when the external connection disappears. Define which traffic is permitted onto a paid bearer, how duplicates are handled, and how the user distinguishes queued from delivered.
The energy budget changes substantially
Starlink's current help material lists Mini average consumption around 20–40 W; a published Mini specification sheet lists 25–40 W. Use the exact terminal's documentation and measured consumption when sizing power. This is substantially different from a small, intermittently transmitting mesh radio or message modem. Starlink power guidance · Mini specification sheet
At 20–40 W continuously, the terminal alone uses 480–960 Wh per day. That is a calculation, not a measured site load. Add the gateway computer, other network equipment, conversion losses, weather reserve, and battery aging. A tiny mesh-node solar panel is not an adequate design basis for an always-on Starlink installation.
Plan the daily energy
Enter average terminal power and operating time. Gateway equipment and conversion losses are additional.
Energy = average watts × hours. No equipment is controlled by this calculator.
The estimator above uses your entered average load. It is a planning calculation, not a battery or solar recommendation. The default 30 W is illustrative.
What this would mean for a roof or White Tanks
If a reliable Starlink installation already exists, using its LAN for a controlled gateway experiment is realistic. If it does not, justify its energy and service costs against the actual requirement. Sending occasional battery alarms may favor a message modem; providing general internet to a site is a different job.
Do not call the full Starlink-assisted path independent of internet infrastructure. It can be independent of the local cable or cellular network while still depending on Starlink and remote services. Two distant sites using the same remote server also share that server as a failure point.
Test the transitions, not just the happy path
Prove a local message with Starlink disconnected. Connect the IP route and prove a remote reply. Remove only the IP path, confirm honest delivery status, and test any configured fallback with a strict message budget. Restore the connection and check for duplicates or unintended queued traffic. Record the software versions, provider settings, and actual power measurements.
This mix is a credible second-stage project once the local mesh is understood. The gateway and power budget deserve their own build and test plan.