I recently bought the “SparkFun Quadband GNSS RTK Breakout - LG290P (Qwiic)” and am trying to receive online rtk connections. I tried multiple providers but the problem is that my RTK connections fall after few seconds. I tried Polaris and RTKdata and even reached out to their customer support. This is the reply I received from them:
"Hi Aazar,
Thanks a lot for reaching out and for sharing the background on your project. I’ve had a close look at your testing logs and wanted to give you a clear overview of what’s happening, the interruptions, and how you can get to a more stable RTK experience.
First, about the coverage itself: during all of your testing sessions near Oakland International Airport, you were never further than about 3–4 kilometers from one of our base stations. To put that in context, RTK corrections are designed to maintain high-precision fixed solutions out to roughly 30 kilometers, and they will often deliver usable float solutions up to 60–70 kilometers depending on conditions. Even in more challenging areas like urban canyons, you would not expect performance to degrade significantly within just a few kilometers. This means that whatever issues you’re seeing are not due to the distance to the infrastructure, and adding another closer base station would not solve the interruptions you experienced.
Looking at your logs in detail, here’s what stood out:
Throughout your sessions, you own device had a consistent, very good satellite view. You were tracking between 27 and 31 satellites almost the entire time, with dilution of precision (DOP) values in the 0.6–0.8 range, which is excellent and indicates the rover had a clear sky view and solid geometry for positioning.
Your RTK correction stream was coming through reliably, with the average correction age typically between about 1.5 and 3.5 seconds, and occasional peaks a little higher but still within acceptable limits. The NMEA GGA messages were sent regularly as well, confirming that your rover was correctly communicating its own position back to the server to assign the right base station.
However, when you look at your RTK fix rate, that’s where the picture changes. In many sessions, the fix rate was 0%, and in others you did achieve a few fixes—generally just 1–2% of the time. For example, in one longer test you logged over 1,000 GGA sentences but only about 20 epochs showed a fixed solution, with the rest in float mode. So the system was working, and the corrections were valid, but the receiver was not consistently resolving the ambiguities to hold a fixed lock.
Because you were operating so close to the base station and with such good sky view, the reason for this is almost certainly related to receiver settings or specific environmental conditions. From the logs, there is no indication that the base station connection itself is the limiting factor.
Here’s what I’d recommend to help you get this resolved:
First, verify that your rover is configured to receive RTCM 3.x corrections and that all the necessary message types (like MSM observations) are enabled. Some receivers require you to explicitly enable certain messages.
Second, confirm your rover is set to NAD83 as the datum to match the AUTO stream in the US. If you’re working in WGS84 or another datum, you’ll either need to configure the receiver to transform the coordinates accordingly or choose the mountpoint AUTO_WGS84.
Third, check that your NMEA GGA sentences are sent every 5 seconds. Longer intervals can cause timeouts or delayed assignment of the optimal base station.
Fourth, if possible, do a comparative test in an open area with minimal multipath (for example, no nearby large metal structures or walls) to rule out reflection interference.
It’s also worth noting that RTK technology is designed to work while moving, including driving through urban areas, as long as the data stream remains connected and the antenna placement avoids excessive obstruction.
Just to reiterate, adding an additional base station closer to your site will not solve the issue you’re experiencing because you were already operating extremely close to the network infrastructure. The solution will come from refining the configuration and ensuring that the environment and connectivity are optimal."
Can I please get some guidance on what I am doing wrong here?
