Feed Onocoy Without Giving Up Your Own RTK

If you run a GNSS reference station for Onocoy, you have probably hit this fork in the road: the receiver can push its RTCM stream to Onocoy's caster, or it can serve your own rovers — but its NTRIP server only makes one outbound connection. Most operators pick the rewards and quietly give up using their own base for RTK. You don't have to choose.

The usual workarounds, and why they hurt

The community's answer has been to split the stream yourself: an str2str chain or a Docker container on a Raspberry Pi that takes the receiver's output and re-serves it to Onocoy, RTKDirect, and a local caster. It works — until the Pi's SD card dies, the container restarts into a half-configured state, or the stream silently drops and you find out two weeks later when your rewards graph flatlines. There is no health monitoring, no credential management for the people using your base, and one more box to babysit.

Split in the cloud instead

The cleaner topology: your receiver makes one connection, to a private mountpoint on a hosted caster, and the fan-out happens server-side.

Create a base station on RoboGNSS — declare its position and datum, get an upload token.
Point your receiver's NTRIP server at your private mountpoint. Any NTRIP-capable receiver works; no port forwarding, no static IP.
Add a forward to Onocoy. In Onocoy's dashboard, go to Reference Stations → NTRIP Credentials and add a credential: the auto-generated username is your Onocoy mountpoint, plus the password you chose. Paste both into the forward form. RoboGNSS keeps the connection up and reconnects automatically after stream gaps.
Mint rover credentials for your own equipment — each rover, tractor, or crew member gets its own revocable login to the same stream.

One upload from the field; Onocoy, your rovers, and a RINEX archive all fed from the cloud. If the base drops, the 24-hour uptime strip and live satellite view show you exactly when and for how long — before the rewards graph does.

Getting a good Onocoy quality score

Two receiver-side settings matter more than anything else:

Send MSM7, not MSM4. Onocoy's scoring wants full-resolution observations (the x7 message set: 1077, 1087, 1097, 1127…). On u-blox receivers this is a message-selection change in the RTCM output config.
Broadcast 1005 regularly. The station position message should go out at a steady cadence (every 5–10 seconds is typical) so the network always knows where your antenna is.

Occasional broken pipe disconnects from Onocoy during stream gaps are normal idle drops — what matters is that your forwarder reconnects on its own, which is exactly the kind of thing you want handled for you.

Where Geodnet fits: split at the antenna

Geodnet does not accept third-party NTRIP streams — authentication happens in a crypto chip inside their miner hardware, so no caster (ours included) can forward to it. Operators who want both networks use an RF splitter at the antenna: one antenna feeds a Geodnet miner and your own receiver side by side. Some Onocoy-oriented miners even ship with a built-in splitter port for exactly this.

The rule of thumb: split at the antenna for Geodnet, split in the cloud for everything that speaks NTRIP — Onocoy, RTKDirect, RTK2go, or any private caster you need to feed.

The same base, working for you

Rewards are nice, but the point of owning a base station is centimeter positioning on your own terms. With the cloud-split setup you also get what the DIY splitter never gave you: per-rover credentials you can revoke, live health with position-integrity checks, and any window of raw data downloadable as RINEX for OPUS or PPP.

Start free with one base station — or read how SNIP users migrate to a hosted caster.