Hi All! LTE and/or Satellite-based corrections can be extremely convenient at times compared to a dedicated local basestation. In light of the solar storms over the weekend, is there a major benefit to a local basestation compared to external corrections sources when it comes to accuracy during events like this?
Thanks!
I would expect a huge range of answers to that question.
Here’s my personal experience and opinion:
Solar Activity impacts the GNSS signals more than it does the transmission protocol for the corrections.
I’ve performed several Non-Scientific tests for RTK/RTN during high solar activity (including the current storm).
Recently, my RTN tests (base was 10 miles away, or 16km from Rover) didn’t fair any better than L-Band corrections during side-by-side tests.
Both were receiving their corrections but would remain in RTK Float during times where the receiver(s) couldn’t properly resolve the positions.
On the other hand, I wouldn’t argue against the suggestion that a truly local base (on the same site, or very short baseline) would produce a RTK Fixed solution easier. However, I wouldn’t put a ton of faith in any position that was collected with GNSS during a major Solar Event. The Atmospheric Conditions are a major Error Source for GNSS. I think of GNSS as just 1 tool in the toolbox. A Solar Event is not the right time to take it out of the toolbox. 
Thanks Ryan for the quick response! That makes a ton of sense.
We’re looking at long-term deployments where rovers are less than 1km baseline from the basestation, which is properly surveyed-in with PPP. My hope is that this will minimize inaccuracies during storms, but we definitely still need to watch for events like this and rely on other localization methods during them.
Wow, Then you are in the best Position that you could be in :lol:
Your Field Procedures are an easy way to keep you out of trouble.
(I wish that I could say that I typically check the Solar Weather forecast beforehand… but I don’t).
Simple things like always start and end a mission with checking in to a previously recorded point with the Rover to confirm the precision is what you expected.
I like to think like this: “A GNSS position is an educated guess.”
It’s always possible for the receiver to “botch” the calculation in a bad way, without you knowing.
However, it’s unlikely that the receiver will reproduce that same (non-typical) error with a 2’nd try at a later time with different satellite geometry.
That’s why we can gain some trust by an easy “Check-in” to a known location with the RTK Rover (it doesn’t have to be a control point). You aren’t confirming absolute accuracy within the System, but you do have a good feeling that nothing wonky is going on.
Agreeing with Ryan on a lot of these points. Over confidence in the reported location, and over promising location accuracy is a major pit-fall opportunity…
The proximity of the Base is primarily to provide a secondary view of the sky with which to contrast that of the Rover, in a geometry problem. The similarity in view/experience is what drives the ability to remove common-mode error.
You could perhaps look at multiple Base locations for information, or a consolidated view from a Network of base receivers and VRS, localized very close to your operating location.
Most of the newer ZED firmwares also have a NAV2 solution which can be used as a sanity check to the primary solution, and protection level reporting where u-Blox tries to quantify the amount of error they think they are playing with in the solution and measurements.
From some observations I made over this past weekend, it seems that corrections from a physical base station (OSR) handle high solar activity better than modeled corrections (SSR). I’m guessing this is due to real-world tropospheric variance that isn’t captured by the data fed into the model, and is thus missing from the model’s output.