Activity Feed › Discussion Forums › GNSS & Geodesy › Converting Carlson .rw5 format to Star*Net
-
Converting Carlson .rw5 format to Star*Net
Posted by Kent McMillan on August 9, 2016 at 12:48 amWould anyone with a current copy of Star*Net Pro be willing to have a go at converting the .rw5 file attached below to Star*Net’s .gps format? (The file is properly named “mes002.rw5”. I just added the “txt” extension to the file name to be able to post it.)
I’m drawing a blank with the converter in Star*Net Pro V6 and suspect that the reason may be that the .rw5 gps vector format has changed during the last however many years it has been.
If you can do the conversion, would you mention the version of Star*Net Pro you are running as well as the file converted to Star*Net format?
Kent McMillan replied 8 years, 1 month ago 5 Members · 20 Replies -
20 Replies
-
Kent McMillan, post: 385252, member: 3 wrote: Would anyone with a current copy of Star*Net Pro be willing to have a go at converting the .rw5 file attached below to Star*Net’s .gps format? (The file is properly named “mes002.rw5”. I just added the “txt” extension to the file name to be able to post it.)
I’m drawing a blank with the converter in Star*Net Pro V6 and suspect that the reason may be that the .rw5 gps vector format has changed during the last however many years it has been.
If you can do the conversion, would you mention the version of Star*Net Pro you are running as well as the file converted to Star*Net format?
Hey that’s cool!
It has all of the GOOD stuff in it, do you know the “settings” used to create it?
I could extract the data easy enough, but I don’t know anything about what Star*net wants to see.
Loyal
-
Kent McMillan, post: 385252, member: 3 wrote: Would anyone with a current copy of Star*Net Pro be willing to have a go at converting the .rw5 file attached below to Star*Net’s .gps format? (The file is properly named “mes002.rw5”. I just added the “txt” extension to the file name to be able to post it.)
I’m drawing a blank with the converter in Star*Net Pro V6 and suspect that the reason may be that the .rw5 gps vector format has changed during the last however many years it has been.
If you can do the conversion, would you mention the version of Star*Net Pro you are running as well as the file converted to Star*Net format?
With STAR*NET 8.2:
[PRE]
.GPS WEIGHT COVARIANCEG0 ‘V1 2016/08/08 22:52:53,Base ID read at rover: 0023
G1 0023-1 -2759.824510 1229.748470 -52.539850 0.000/2.084
G2 5.892000000000E-005 8.180000000000E-005 8.786000000000E-005
G3 4.324000000000E-005 -5.278000000000E-005 -5.444000000000E-005G0 ‘V2 2016/08/08 22:53:46,(Average) – Base ID read at rover: 0023
G1 0023-2 -2759.830320 1229.749860 -52.537830 0.000/2.084
G2 8.435000000000E-005 1.356200000000E-004 1.144400000000E-004
G3 6.261000000000E-005 -6.640000000000E-005 -7.707000000000E-005G0 ‘V3 2016/08/08 22:55:17,(Average) – Base ID read at rover: 0023
G1 0023-3 -2759.179200 1231.473270 -50.441340 0.000/2.084
G2 1.355400000000E-004 2.360800000000E-004 1.919300000000E-004
G3 1.054700000000E-004 -1.118200000000E-004 -1.343700000000E-004G0 ‘V4 2016/08/08 22:57:52,(Average) – Base ID read at rover: 0023
G1 0023-5 -2760.977270 1226.925240 -56.170820 0.000/2.084
G2 2.511200000000E-004 6.494700000000E-004 3.220300000000E-004
G3 2.407200000000E-004 -1.942400000000E-004 -2.861700000000E-004G0 ‘V5 2016/08/08 22:59:33,(Average) – Base ID read at rover: 0023
G1 0023-6 -2762.132540 1224.186110 -59.478760 0.000/2.084
G2 1.651000000000E-003 1.411570000000E-003 2.598880000000E-003
G3 1.072960000000E-003 -1.059300000000E-003 -1.344820000000E-003
[/PRE]Also FYI, the GPS Importer works just fine in Demo mode as well, the latest version can be downloaded from this link
Jacob Wall -
Loyal, post: 385257, member: 228 wrote: Hey that’s cool!
It has all of the GOOD stuff in it, do you know the “settings” used to create it?
I could extract the data easy enough, but I don’t know anything about what Star*net wants to see.Yes, it has all the essential info in the file. The Star*Net format is:
G0 ‘optional remarks
G1 from-to DX DY DZ
G2 xx yy zz
G3 xy xz yzSpecimen:
G0 ‘V261 Day025(3) 21:06 00008341.ssf
G1 363-362 190.482400 -30.037207 1.334055
G2 3.18378042786085E-007 1.89480531625124E-006 2.41912013830421E-006
G3 -1.50610449416695E-007 -1.20847501448019E-008 -1.54065969949142E-006 -
Jacob Wall, post: 385258, member: 1674 wrote: With STAR*NET 8.2:
G0 ‘V1 2016/08/08 22:52:53,Base ID read at rover: 0023
G1 0023-1 -2759.824510 1229.748470 -52.539850 0.000/2.084
G2 5.892000000000E-005 8.180000000000E-005 8.786000000000E-005
G3 4.324000000000E-005 -5.278000000000E-005 -5.444000000000E-005Thanks. I see that the vectors are rendered as PC to PC with the antenna heights. I suppose that’s an accomodation to RTK users in versions of Star*Net after V6.
-
Note: just trying to answer a simple question such as when Star*Net Pro added the antenna height parameters to the vector format reminds me why I never upgraded from V6. Ron Sawyer produced really excellent documentation and MicroSurvey has evidently thought it would be neat to substitute a mess of YouTubes and other, uh, stuff for that. If there are user manuals hiding among all the marketing clutter I don’t see them.
-
Kent McMillan, post: 385263, member: 3 wrote: I see that the vectors are rendered as PC to PC with the antenna heights.
How can you tell that it’s PC-PC rather than mark-to-mark? Putting the antenna heights in is nice, but you need to know which way to go with them.
-
Jim Frame, post: 385268, member: 10 wrote: How can you tell that it’s PC-PC rather than mark-to-mark? Putting the antenna heights in is nice, but you need to know which way to go with them.
You’re right, I just assumed that it was, thinking that was what the RTK processor had generated as the vector to which the antenna height corrections would be applied for its Up components. If it were mark-to-mark, it wouldn’t make any sense to include the antenna heights that were built into the mark-to-mark calculation as a part of the vector.
Edit: Come to think of it, since the antenna heights don’t really mean anything if the antennas are of different types, and the types aren’t specified, the HA(Base)/HA(Rover) values may be just a mess waiting to happen.
-
Kent McMillan, post: 385269, member: 3 wrote: and the types aren’t specified
The rover antenna is listed in the RW5 header as a CHCX91R. I don’t see a base antenna ID anywhere.
-
Jim Frame, post: 385271, member: 10 wrote: The rover antenna is listed in the RW5 header as a CHCX91R. I don’t see a base antenna ID anywhere.
The base antenna was a CORS site, which Is why I automatically assumed that the vector was PC-to-PC with the heights true vertical to the PC (which is what I think they most likely are).
-
Kent McMillan, post: 385281, member: 3 wrote: The base antenna was a CORS site
That’s what I thought at first, but then I saw the notation that the RTK corrections were coming in via internal UHF, which suggests a local base.
-
I guess I should have RTFM’d last night. Yes, the Carlson vector format is PC-to-PC. Here’s the documentation explaining the .RW5 format that Carlson exports.
-
Kent I know this is not exactly what you asked for, but here is the file converted using Carlson Survey 2016 SurvNET:
G1 0023-1 -2759.23661942 1231.21388570 -53.89968944 –SINGLE EPOCH
G2 5.892000e-005 8.180000e-005 8.786000e-005
G3 4.324000e-005 -5.278000e-005 -5.444000e-005
G1 0023-2 -2759.24242942 1231.21527570 -53.89766944 –30 EPOCHS
G2 8.435000e-005 1.356200e-004 1.144400e-004
G3 6.261000e-005 -6.640000e-005 -7.707000e-005
G1 0023-3 -2758.59130963 1232.93868514 -51.80118013 –30 EPOCHS CP2
G2 1.355400e-004 2.360800e-004 1.919300e-004
G3 1.054700e-004 -1.118200e-004 -1.343700e-004
G1 0023-5 -2760.38937903 1228.39065664 -57.53065826 –30 EPOCHS UNDER TREE
G2 2.511200e-004 6.494700e-004 3.220300e-004
G3 2.407200e-004 -1.942400e-004 -2.861700e-004
G1 0023-6 -2761.54464866 1225.65152751 -60.83859716 –UNDER TREE BRASS PLUG
G2 1.651000e-003 1.411570e-003 2.598880e-003
G3 1.072960e-003 -1.059300e-003 -1.344820e-003SurvNET does not seem to bring in the ‘G0’ line. Not a problem, but you do lose the date and time information in the file.
PLS NJ & NY, PP NJ -
Dan Dunn, post: 385322, member: 911 wrote: Kent I know this is not exactly what you asked for, but here is the file converted using Carlson Survey 2016 SurvNET:
G1 0023-1 -2759.23661942 1231.21388570 -53.89968944 –SINGLE EPOCH
G2 5.892000e-005 8.180000e-005 8.786000e-005
G3 4.324000e-005 -5.278000e-005 -5.444000e-005
G1 0023-2 -2759.24242942 1231.21527570 -53.89766944 –30 EPOCHS
G2 8.435000e-005 1.356200e-004 1.144400e-004
G3 6.261000e-005 -6.640000e-005 -7.707000e-005
G1 0023-3 -2758.59130963 1232.93868514 -51.80118013 –30 EPOCHS CP2
G2 1.355400e-004 2.360800e-004 1.919300e-004
G3 1.054700e-004 -1.118200e-004 -1.343700e-004
G1 0023-5 -2760.38937903 1228.39065664 -57.53065826 –30 EPOCHS UNDER TREE
G2 2.511200e-004 6.494700e-004 3.220300e-004
G3 2.407200e-004 -1.942400e-004 -2.861700e-004
G1 0023-6 -2761.54464866 1225.65152751 -60.83859716 –UNDER TREE BRASS PLUG
G2 1.651000e-003 1.411570e-003 2.598880e-003
G3 1.072960e-003 -1.059300e-003 -1.344820e-003SurvNET does not seem to bring in the ‘G0’ line. Not a problem, but you do lose the date and time information in the file.
The G0 line also has the vector i.d. number, though, in addition to the other identifying data. I wonder if SurvNET will export vectors in some other format such as Ashtech “O”-file format that Star*Net can import completely normally.
-
While SurvNET will import quite a few different formats, including the Astech ‘O’ file, as far as I know it will only convert to the .GPS format.
PLS NJ & NY, PP NJ -
Dan Dunn, post: 385530, member: 911 wrote: While SurvNET will import quite a few different formats, including the Astech ‘O’ file, as far as I know it will only convert to the .GPS format.
That’s too bad. If it would only generate the C Pt. No. ‘Descriptor and G0 ‘VNo. [metadata] lines, it would yield Star*Net input files that were really ready to run.
The descriptor should be in the rw5 file, of course, and generating a series of Vector I.D. Nos. to accompany the metadata ought to be simple enough.
-
Yes the G0 descriptor is in the Rw5 file. Don’t know why Carlson didn’t include it in the conversion.
It does appear that SurvNet uses the HR and its .GPS file is point to point, although I haven’t checked it don’t have the time right now. Maybe later or maybe someone else wants to.
PLS NJ & NY, PP NJ -
Dan Dunn, post: 385533, member: 911 wrote: Yes the G0 descriptor is in the Rw5 file. Don’t know why Carlson didn’t include it in the conversion.
It does appear that SurvNet uses the HR and its .GPS file is point to point, although I haven’t checked it don’t have the time right now. Maybe later or maybe someone else wants to.
Just a quick look says that the SurvNET export is a Mark-to-Mark vector, as one would expect.
Is there an export menu that toggles exporting descriptors on and off ? I can’t imagine why a person wouldn’t want them, but I suppose it could happen.
In Star*Net, the vector format familiar to me would be something like this:
C 4 ‘SPIKE.WASHER
G0 ‘V1 Day276(1) 20:28 00027060.ssk
G1 1-4 -128.748477 -198.295413 -337.199425
G2 5.79377578780872E-007 1.77508719956934E-006 1.51166163674914E-006
G3 4.93268528767172E-007 -4.00532782010815E-007 -9.99915536188364E-007Where the C line assigns the descriptor and the G0 line is the vector i.d. for internal audit purposes and the associated metadata.
-
The Carlson Manual shows the G0 line in its example, it just doesn’t bring it in when it converts.
The conversion from a rw5 file to GPS file has no options.
Carlson uses —SINGLE EPOCH the double dash as the descriptor tag. They refer to the format as a StarNet GPS file, not sure why they don’t follow StarNet’s format exactly (at least the older format)
PLS NJ & NY, PP NJ -
Dan Dunn, post: 385557, member: 911 wrote: The Carlson Manual shows the G0 line in its example, it just doesn’t bring it in when it converts.
The conversion from a rw5 file to GPS file has no options.
Carlson uses —SINGLE EPOCH the double dash as the descriptor tag. They refer to the format as a StarNet GPS file, not sure why they don’t follow StarNet’s format exactly (at least the older format)
Yeah, considering that the older formats should also be recognized in the current version of Star*Net, it’s a mystery why the folks at Carlson would have written a translator intended only for the later, eccentric syntax. My guess is that it’s more evidence of oblivious software design than intentionality.
-
Part of the power of Star*Net is its backwards compatibility. I can still run the first jobs that I adjusted in the earliest version of Star*Net from 1988 I ever owned because the basic syntax, data types, and conventions have remained as stable as they have. Using “–” to substitute for “‘ ‘ ” for no good reason is definitely heading in the wrong direction.
Log in to reply.