VRS RTN Base Position

[Jim Frame]

I'm demo'ing a VRS subscription for use in an upcoming project in which I hope to use RTN vectors in OPUS Projects via GVX export. In its current form, the J-Field GVX exporter has some problems, and I've been working with John Roscoe in Support on the ones I've identified so far. But I encountered a new one today that's got me stumped: the Javad GVX files don't include the physical RTN antenna position, only the virtual base position, which is very close to the rover location. Without that physical base position, there's no way for OPUS Projects (or any other software) to adjust the RTN vectors.

I've been making fixes to my GVX files to address the deficiencies I've found so far (only 1 is serious, consisting of incorrect values in one of the correlation fields), and thought I could do the same for the physical base position. But everywhere I've looked in J-Field and the various files saved in a project archive, I've not found it.

I know that the RTN sends that data to the rover, because I've worked with Trimble GVX files that have it. Is J-Field really not storing that information?

 

[John Rosco]

How do Virtual Reference Station (VRS) networks operate?

VRS provides RTK corrections for a 'virtual base location' close to the 'rover' area of use, by combining all 'physical base station' observations (in the network).
VRS does not provide the location for all of the 'physical base stations' in the network and only provides the computed 'virtual base location' and the combined RTK corrections thereof.

 

[Jim Frame]

Below is a snippet from a GVX that was recorded using Trimble equipment a couple of years ago. The Initial Point (00000064) is a CORS (PLSB) that's owned and operated by the local Trimble VRS. The data collector was set to record data as vectors.

<GNSS_VECTOR>
<ID>V1</ID>
<INITIAL_POINT_ID>00000064</INITIAL_POINT_ID>
<TERMINAL_POINT_ID>00000072</TERMINAL_POINT_ID>
<SURVEY_SETUP_ID>00000069</SURVEY_SETUP_ID>
<OBSERVATION_TIME>
<START>2023-09-28T14:41:11.00</START>
<END>2023-09-28T14:46:11.00</END>
<UTC_OFFSET>7</UTC_OFFSET>
</OBSERVATION_TIME>
<QUALITY_CONTROL>
<EPOCHS_USED>300</EPOCHS_USED>
<MASK>
<ELEVATION>10</ELEVATION>
<PDOP_MASK>6</PDOP_MASK>
</MASK>
<DILUTION_PRECISION>
<GDOP>2.0216922669466</GDOP>
<HDOP>0.81126379966736</HDOP>
<PDOP>1.5379185676575</PDOP>
<VDOP>1.3065391778946</VDOP>
</DILUTION_PRECISION>
<SATELLITE_USED>
<TOTAL>15</TOTAL>
<GPS>9</GPS>
<GLONASS>6</GLONASS>
<GALILEO>0</GALILEO>
<QZSS>0</QZSS>
<BEIDOU>0</BEIDOU>
</SATELLITE_USED>
<ORBIT>
<TYPE>Broadcast</TYPE>
<SOURCE>Broadcast</SOURCE>
</ORBIT>
<CORRECTOR_AGE>2</CORRECTOR_AGE>
</QUALITY_CONTROL>
<ECEF_DELTAS>
<DX>33323.8965070178</DX>
<DY>-37233.3331203843</DY>
<DZ>-14771.3421934208</DZ>
</ECEF_DELTAS>
<CORRELATION_MATRIX>
<SDX>0.00539808609509</SDX>
<SDY>0.00660101314724</SDY>
<SDZ>0.00677521593235</SDZ>
<PXY>0.66468135533223</PXY>
<PXZ>-0.54091147825543</PXZ>
<PYZ>-0.60498920262513</PYZ>
</CORRELATION_MATRIX>
</GNSS_VECTOR>

When I connect to the same network with my T-LS, I don't see an option in the setup to record the physical base position, and all I get is the virtual base (which is ephemeral and therefore not susceptible to subsequent adjustment).

 

[Matt Johnson]

Below is a snippet from a GVX that was recorded using Trimble equipment a couple of years ago. The Initial Point (00000064) is a CORS (PLSB) that's owned and operated by the local Trimble VRS. The data collector was set to record data as vectors.

<GNSS_VECTOR>
<ID>V1</ID>
<INITIAL_POINT_ID>00000064</INITIAL_POINT_ID>
<TERMINAL_POINT_ID>00000072</TERMINAL_POINT_ID>
<SURVEY_SETUP_ID>00000069</SURVEY_SETUP_ID>
<OBSERVATION_TIME>
<START>2023-09-28T14:41:11.00</START>
<END>2023-09-28T14:46:11.00</END>
<UTC_OFFSET>7</UTC_OFFSET>
</OBSERVATION_TIME>
<QUALITY_CONTROL>
<EPOCHS_USED>300</EPOCHS_USED>
<MASK>
<ELEVATION>10</ELEVATION>
<PDOP_MASK>6</PDOP_MASK>
</MASK>
<DILUTION_PRECISION>
<GDOP>2.0216922669466</GDOP>
<HDOP>0.81126379966736</HDOP>
<PDOP>1.5379185676575</PDOP>
<VDOP>1.3065391778946</VDOP>
</DILUTION_PRECISION>
<SATELLITE_USED>
<TOTAL>15</TOTAL>
<GPS>9</GPS>
<GLONASS>6</GLONASS>
<GALILEO>0</GALILEO>
<QZSS>0</QZSS>
<BEIDOU>0</BEIDOU>
</SATELLITE_USED>
<ORBIT>
<TYPE>Broadcast</TYPE>
<SOURCE>Broadcast</SOURCE>
</ORBIT>
<CORRECTOR_AGE>2</CORRECTOR_AGE>
</QUALITY_CONTROL>
<ECEF_DELTAS>
<DX>33323.8965070178</DX>
<DY>-37233.3331203843</DY>
<DZ>-14771.3421934208</DZ>
</ECEF_DELTAS>
<CORRELATION_MATRIX>
<SDX>0.00539808609509</SDX>
<SDY>0.00660101314724</SDY>
<SDZ>0.00677521593235</SDZ>
<PXY>0.66468135533223</PXY>
<PXZ>-0.54091147825543</PXZ>
<PYZ>-0.60498920262513</PYZ>
</CORRELATION_MATRIX>
</GNSS_VECTOR>

When I connect to the same network with my T-LS, I don't see an option in the setup to record the physical base position, and all I get is the virtual base (which is ephemeral and therefore not susceptible to subsequent adjustment).

You must have been connected to a single reference station and not a VRS. As John posted, a VRS uses the data from all the surrounding reference stations to create a nearby virtual base.

 

[Jim Frame]

Here's what Jeff Jalbrzikowski of NGS told me when I asked how Trimble stores VRS vectors:

"It's a true VRS solution, the PRS-to-Rover vector is calc'd from the resulting point back to the closest CORS that contributed to the VRS solution."

This is the reason that the new (still draft, but almost final) NGS 92 guidelines require more base-rover (SRTK) observations than VRS (NRTK) for a given accuracy.

 

[Jim Frame]

Unfortunately, this issue -- and, to a lesser extent, the glitch in the Javad GVX exporter -- have forced me to abandon my plan to use my Triumph-LS on this sizeable project. I bit the bullet and bought a Trimble R8-3 from a colleague, and I'll be renting a TSC7 with Access for the month or so duration of the job.

Trimble 1, Javad 0.

 

[John Rosco]

When using RTN or VRS RTK RTCM services, the correction 'link' provides the Stationary RTK Reference Station ARP in the RTCM/1005 data packet.

Thus the RTK 'rover' will use the information provided by the RTK RTCM correction service.

For an RTN RTK RTCM correction, the RTCM/1005 data packet will be a 'specific' base reference station position (IE; CORS station as an example).

Normally for a VRS (virtual) RTK RTCM correction, the RTCM/1005 data packet will be a position for a 'virtual base location' close to the 'rover', as reported by the 'rover' back to to the VRS network (via GGA or user entered LLH position).

The PRS-to-Rover vector is calc'd from the resulting point depending on the RTCM/1005 data packet information, yes ?

 

[Jim Frame]

The PRS-to-Rover vector is calc'd from the resulting point depending on the RTCM/1005 data packet information, yes ?

The whole process is a bit over my head. There's a good discussion of this at RPLS.com by some folks who know a lot more than I do:

Trimble Access – Specify PRS? - GNSS & Geodesy - RPLS.com

I have a project coming up in which almost all of the stations are within 10 km of a particular VRS sensor (PRS), but a few on the north end are a little closer

rpls.com

But the salient point is that there's little value in having correlation data for an ephemeral base station. In order to include RTK vectors in a network adjustment, they have to be tied back to something in common, like a permanent reference station. The current Javad GVX converter doesn't do that, which renders the GVX files useless.