Trimble Access - Specify PRS?

I think this should work...

Take a look at editing your GNSS correction source entry in Settings - Connections

There is an option in the NTRIP configuration box for 'Connect directly to mountpoint'

Turn this on and you can specify the mountpoint.

The hard bit will be working what the Mountpoint name should be - probably easiest to connect to the one you want, and note the details

If you're close enough to be able to use a single-base mountpoint, that will work.

But I don't think there is a way to force it to tie to a specific PRS; it's all automated when you're running with a true network solution, so Access will always tie back to the nearest station.

If I end up with two PRS in my project and need to adjust my data in post-processing, I download and process a few hours of static data between the two stations so I have the two tied together.

@rover83 Should also be good for a network solution that broadcasts the individual mountpoints (most do)

But you are right, with pure VRS all bets are off - you take the virtual base you are given

I can't use single-base, I have to have NRTK vectors. I guess I'll take whatever the VRS gives me.

I just thought it would be better to have all vectors from the same PRS for two reasons: consistency (but hopefully the network is consistent, as this is a vertical project), and the one mountpoint I'll mostly be using is an NCN CORS, which means for those vectors I won't have to download the PRS files and load them into OPUS Projects. (The other PRS isn't an NCN station.).

Rover is correct. If you have VRS. Before going out down load and process static between the two or 3 stations holding the NCN station. You can then verify those values vs what VRS gives you. Also like rover stated you can download the VRs station data for the time periods as well. Building a network along with the RTK VRs vectors.

When I operated a VRs network we had multiple mount points. One that would force you to the closest base physical. One that did VRS one that allowed you to choose which base you wanted. Of course all of these we had multiple different broadcast formats. And some others for helping specific manufacturers be able to use.

"Before going out down load and process static between the two or 3 stations holding the NCN station."

OPUS Projects will take care of that for me, I just need to upload the files.

Yes you could pull that data into opus projects. Even the prs or VRs stations if that’s what you need. I always process the stations in my rtk network just to see how well they tie to CORS NGS values in new work areas. That way before my crews hit a site I know how well the VRs RTK values should be in relationship to published values. Most of the time the network stations are usually relatively tighter to each other than CORS . If the VRs network operators have had them up and running for a while. Here we have a large area not covered then a few stations on the other side of that area separated from the main backbone network RTK area. Those few are off from CORS published values if I process the data from published CORS. However they are not far off. But enough I held my static positions vs the network’s positions . In the main area it’s not enough to worry about as its values are all within the uncertainty anyway so all is good. Do you have TBC. Or just using OPUS projects. You can do all your RTK vectors in gvx along with your static rinex bring in the non CORS NGS stations and the VRs stations and such.

I've asked this question to both NRTK/RTN operators and to Trimble's Access and Pivot teams.

Disappointingly, the answer was a solid no.

(Trimble Pivot Platform is the software that network operators use to manage their CORS and deliver the VRS corrections.)

I’ve asked this question to both NRTK/RTN operators and to Trimble’s Access and Pivot teams.
Disappointingly, the answer was a solid no.

Since the entire system sprang out of virtual reference stations, I have to imagine it's no trivial task to query the stations that are going to be used in the solution, send a request to the user to identify their desired "controlling" PRS, and then crunch the numbers based on the answer.

As the user moves around and/or stations are brought into or kicked out of the solution, that throws additional complexity in there. What if the user moves far enough away that their preferred station is no longer being used? What if they are on the border between two subnets? (The latter happens to us all the time.)

Personally, if the RTN is aligned with the NSRS I don't have a problem treating one VRS solution tying to a PRS in the same way as another VRS solution tying to a different PRS.

if the RTN is aligned with the NSRS I don’t have a problem treating one VRS solution tying to a PRS in the same way as another VRS solution tying to a different PRS

The issue at hand is that if the PRS is not part of the NSRS, meaning it is not in the NOAA CORS Network (NCN), then an OPUS Projects user (if they intend to submit their project - aka bluebook) must go out to their network provider and download the 24hrs RINEX datasets for the PRS, and upload it to OPUS Projects just like any other static data. It's not a problem per se, just a hindrance.

From what I have been told by Trimble POCs, the PRS-Rover vector is nothing but an inverse from the Rover point calculated based on the VRS-Rover vector. If that is the case, then math is math and it shouldn't matter what subnets are involved, or even how long this inversed vector is... but then unreasonably long vectors would toss into question other factors. Although the technology is beautiful, the method is sound, and the results speak for themselves, the whole VRS thing is a headache to deal with from the perspective of allowing users to submit VRS-based data for inclusion in the NSRS.

After typing it out and thinking about it, it's probably statistically better to have different PRSs. That's one additional form of redundancy, and if different PRSs result in agreeing coordinate results that's a good thing.

I only initially chimed in on this thread because I had a direct answer to the question posed. Hopefully I didn't derail things!

"not blue-booked"

There is a fairly good chance in the WSRN that reference point will be "blue booked". Grateful to the hard work that goes into that!

> the PRS-Rover vector is nothing but an inverse from the Rover point calculated based on the VRS-Rover vector

@jalbrz Actually it is just a little more complicated than that

The rover calculates its position using the corrections stream it gets given from the base . That stream is basically the base position; a list of satellites and how the base station 'sees' them.

With a true virtual base station both the base position and observations are calculated (made-up if you like). They are a best estimate based on what the real reference stations are seeing. The base position being given so as to be close to the rover.

So the rover calculates its position. This can be stored in a number of ways. Usually (at least with Access) it is stored as an ECEF offset to the base (alter the base position and rover positions will move to match). But you can store in terms of a fixed ECEF (lat/lon) or in terms of local or grid coordinates.

With an ECEF offset, the base-rover vector is the stored 'observation'. The other schemas do get that value by way calculating an inverse

Since those vectors contain quality control information, I would expect that Access is computing the relative accuracies between the designated PRS and rover in realtime based on the full network solution. A simple inverse wouldn't do us much good.

I only initially chimed in on this thread because I had a direct answer to the question posed. Hopefully I didn’t derail things!

Doesn't bother me in the least, this is good stuff to discuss!

I think in the future most GNSS work will be done through either RTNs or L-band corrections...it pays to know what's going on under the hood and what is being stored where.

Yes very good discussion. When I operated a VRS network one of the things that we as operators had to decide was.

1: how often do we update the VRS or virtual base . The first guy was keep it as close as possible to the rover since that was the selling points via Trimble. So several stations fixed surrounding your rover miles away we started in feet . The issue was you would hear the voice on survey controller hollering as you walked a site new base station detected blah blah blah. We had it down to every 100 foot. Then we tried a mile not bad but as customers started using it and they would run down hit and tie to a HARN Mon and then back to the site they felt having the VRS station changing that there tie was not good no way to see inside the black box at the time. The other was route work for DOT for many miles. We ended up around 3 miles or so back then Now if one logged out for lunch and then logged back in they could have a new VRS station computed as well.

The above was all Trimble at the time we did have several mount points for all users and some custom ones for special jobs like dot and their uses etc we had VRS single base Mapping grade DGPS which even with a Trimble 5800 worked nicely for rough searches and such in canopy as no rtk was needed

2: we also ran GEO ++ and had their VRS thing the FKP method and a few others for different mounting points running at same time from same physical stations . Also had the whole single base thing as well. For mounting points.

3: two other software platforms we ran at same time same stations as above eagle net and I can’t remember the other. They all had pros n cons but these last two never went prime time just to unstable for us. We were a private company and being up and running 24/7 literally was a big deal for us. When the recession hit we had a 95% up time on all stations on a 24/7 run. When an antenna was knocked out by lightning in a storm in middle of the night we were heading to replace it asap.

At the time we tested the other manufacturers the green and yellow and they were not really ready for our needs. Trimble did the best for repeating and confidence at the time geo++ was good but it shined for the business side of the house in how we managed customers and reporting. Also being able to customize data formats etc.

I imagine they all perform about the same now it’s just which flavor you prefer.

I have always liked that I could down load the VRS data as if it was a static physical station and use that or create one based on geometry for a static network and just didn’t have anything in that area or needed strength of figure etc.