CRTN Mountpoint Position Discrepancy

Jim Frame

Well-Known Member
Sorry, I only uploaded the files from the project in which I noticed things weren't right. I've attached to this message a zip archive of the files from a prior project when things were still okay.
 

Attachments

  • 1280-099 Raw Data.zip
    1.3 MB · Views: 345

Alexander Khvalkov

Active Member
JAVAD GNSS
1280-099 zip file contains data of December 27, and the points are 2 miles away of Feb 12 , Feb 25 points, see please attached kml files. I cannot compare the positions.
I would expect yesterday's raw data to post-process and compare whether post-processing gives the same coordinates as real-time.
 

Attachments

  • kmls.zip
    1.8 KB · Views: 306

Jim Frame

Well-Known Member
To be clear, I don't have any points in common (i.e. same point, let alone same point/same project) that span the apparent change in RTN base position -- all I have is the fact that the RTN base position is wrong in my receiver, as shown on the stored points screens as being different after January 14.

Post-processing isn't an issue, nor are the exported g-files, which are what I normally use. The problem is that the real-time coordinates are coming out wrong, presumably because the base position the receiver is reporting is wrong, so when I'm searching for a point or trying to verify elevations (which is how this came to my attention) I'm getting wrong real-time answers. And I haven't been able to figure out *why* the base position is showing up wrong in my receiver.

CRTN tells me that the broadcast base position is correct, and I'm hoping to find another J-Field user who can verify that. Shawn tried yesterday but was unable to connect. Michael Glutting has CRTN login credentials, so perhaps someone else can borrow those from him and give it a try.
 

Jim Frame

Well-Known Member
We have had similar problems in Australia. Have you updated the Triumph-LS software recently?

I noticed an update available today, 3.0.1.415. I installed it hoping that it would fix the issue, but no such luck.

A couple of questions that might help me better understand where to look for the source of the problem:

1. Does the LS report verbatim the RTN base position it receives as part of the RTCM message, or are there circumstances under which it is deliberately modified to reflect a configuration setting in the rover?

2. How can I check to be sure that the coordinate system in my receiver named "NAD83(2011) / California zone 2 | NAVD 88" hasn't been altered? (I'm not sure that this could even play a role in the problem, but at this point the universe of possibilities appears to be wide open.)
 

Alexander Khvalkov

Active Member
JAVAD GNSS
LS takes the base's position from RTCM3 1006 message (or 1005 message), and the distance to the base indicated in LAN (WLAN) status screen is calculated getting current rover's position and base's position from 1006 (1005) message.

CRTN seems to transmit base's position incorrectly in what I had a chance to make sure when connected to MONB mount point and got base's position 519 km away, while baseline was estimated of 11 km in length, remained 'float' because of such inconsistency.
 

Jim Frame

Well-Known Member
Yehuda says the CRTN data streams are okay. Alexander, can you document the base position of UCD1 coming out of the RTCM message? I haven't been able to figure out a way to decode the stream using software like BNC or SNIP.

All I know for sure is that prior to sometime in February it was working fine, and now it's not working. CRTN is pointing the finger at Javad, Javad is pointing the finger at CRTN, and I'm getting bogus positions in the field.
 

Alexander Khvalkov

Active Member
JAVAD GNSS
Here is the position they translate from UCD1 mount point.
*** Reference position ***
HEADER 1006 ID: 10, Length: 21, Crc: 3663548, ITRF Year: 0, Flags: 0xA
Coord_XYZ_ID_1006: -2628826.3248 -4247932.4201 3952176.7324 10
Coord_BLH_ID_1006: 0.6726 -2.1250 -0.3172 10

*** Antenna descriptor ***
HEADER 1008, ID: 10, Length: 36, Crc: 7755806, Setup: 2
Desc (20): TRM29659.00 NONE
Ser (10): 0220073545

I cannot run RTK with UCD1 on the receiver locating in San Jose, it is too far, 128 km.

I tried MONB mount point, Monument Peak Milpitas, and found that they transmit position of MODB mount point, Modoc Plateau, 519 km away while measurements come from Monument Peak Milpitas.
 

David M. Simolo

Well-Known Member
I don't know anything about the realities of what you guys are trying to figure out but is there a feet vs. meters thing going on here?
 

Jim Frame

Well-Known Member
Here is the position they translate from UCD1 mount point.
*** Reference position ***
HEADER 1006 ID: 10, Length: 21, Crc: 3663548, ITRF Year: 0, Flags: 0xA
Coord_XYZ_ID_1006: -2628826.3248 -4247932.4201 3952176.7324 10
Coord_BLH_ID_1006: 0.6726 -2.1250 -0.3172 10

Is that the RTCM 1006 message being sent by CRTN? That fits the values I was getting.
 

Alexander Khvalkov

Active Member
JAVAD GNSS
Jim, please ask Yehuda what is the coordinate system they translate position in 1006 message, we suppose it is ITRF2014 at epoch 2019.0.
 

Jim Frame

Well-Known Member
From Yehuda:

All transmitted CRTN coordinates are in CSRS Epoch 2017.50 (NAD83) frame. See
http://sopac-csrc.ucsd.edu/index.php/epoch2017/ for details.
That should solve your problem (I think).
--Yehuda

What I still don't understand is that CRTN claims it hasn't changed its coordinate reference since March of 2018, yet I only started getting bad coordinates in February of this year. If CRTN hasn't changed anything, that would suggest that Javad changed something. But if the 1006 RTCM message decoded by Alexander is verbatim from CRTN, then it looks like CRTN is casting a different XYZ position from the one I was getting in January.

I'm very confused.
 

Jim Frame

Well-Known Member
FYI:

Hi Jim,
I found the problem that was causing the incorrect coordinates to be transmitted. Should be okay now. It affected all NoCal stations.
Thanks for alerting us to this problem.
Cheers,
--Yehuda
 

David M. Simolo

Well-Known Member
It would have been nice if they gave you a little more info on what the problem was, inquiring minds (like yours) want to know
 

Jim Frame

Well-Known Member
I've been such a pest at CRTN over the last couple of weeks that I didn't want to wear out my welcome. But I agree, a notice should be posted to the entire CRTN community describing what happened, and the dates and stations involved. Although I rarely rely on RTN coordinates -- I almost always use the g-files in an adjustment -- I bet there are more than a few people who use the numbers coming out of the receiver without any independent checks.
 

Joe Paulin

Well-Known Member
This is an excellent example of collaboration within the surveying community to solve a problem. Good job to all involved!
 

Jim Frame

Well-Known Member
This went out from CRTN a couple of hours ago:

Alert (3/26/2019): It was discovered that the northern California CRTN server (132.239.152.175) was transmitting incorrect coordinates in the RTCM3 messages. This started on January 16th when we moved the server to another workstation. The problem was resolved in the late afternoon of March 26th. Anyone who relied on the CRTN coordinates over this time period will need to revisit their rover coordinates. Please contact us if you believe your surveys may have been affected by the erroneous coordinates. Note that the southern California server was not affected. Thanks to Jim Frame and Art Andrew for discovering the problem. We’re sorry for the inconvenience.
 
Top