CRTN Mountpoint Position Discrepancy

Jim Frame

Active Member
#22
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

#23
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

Jim Frame

Active Member
#24
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.
 
#25
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.)
 
#27
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.
 
#29
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.
 
#30
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.
 
#32
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.
 
#35
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.