Star*Net Traverse Data Type

> I don't know if I miss something but the "T" data type does not support direct and reverse measurement modes at least in version 6 Pro version. Is it already supported in version 8?
>
> Thank you guys.

I just input the mean angle rather than worry about coding for both.

There are others much more knowledgeable on Star*Net than me, however.

That is exactly my problem. I always ended up averaging direct and reverse measurements. Very tedious and dangerous in my opinion.

> I don't know if I miss something but the "T" data type does not support direct and reverse measurement modes at least in version 6 Pro version. Is it already supported in version 8?

Doesn't your data collector already log an average of the angles on both faces of the instrument which the Star*Net converter automatically imports?

I use SurvCE and yes I have the option to get reduced D/R measurements but I feel uneasy until I saw the individual measurements in the StarNet project file. What I do is manually solve for the mean horizontal angles and I find it dangerous and tedious.

I am referring to reverse measurements.

> I use SurvCE and yes I have the option to get reduced D/R measurements but I feel uneasy until I saw the individual measurements in the StarNet project file. What I do is manually solve for the mean horizontal angles and I find it dangerous and tedious.

I routinely use the mean angles that the data collector generates. One can spot check to the data collector to verify that it is correctly calculating the means, but I'd think the greater risk is making an arithmetic error computing the means manually.

I'm a bit surprised that the data collector doesn't display the difference between the direct and reverse observations when they are made.

I don't have any other choice but to manually do it. StarNet only supports the vertical angle on reverse shots. This means that I need to manually derive the equivalent mean direct horizontal angle for each reverse measurement.

I'm using an older verions of SurvCE (v1.67, I think), and it produces SS records in the RW5 file that contain the meaned angles.

An example of a BSD-FSD-FDR-BDR set:

[pre]--Set Collection with Obs Order 123...321...
OC,OP1001,N 1955490.20401,E 6629743.17778,EL0.000,--CONTROL
LS,HI5.2300,HR4.9000
BK,OP1001,BP1002,BS184.4946,BC0.0000
LS,HI5.2300,HR4.9000
BD,OP1001,FP1002,AR0.0000,ZE89.5315,SD360.919613,--CONTROL AZ MARK
FD,OP1001,FP1003,AR0.0000,ZE89.5308,SD360.919613,--CONTROL
FR,OP1001,FP1003,AR179.5944,ZE270.0634,SD360.919613,--CONTROL
BR,OP1001,FP1002,AR179.5943,ZE270.0636,SD360.919285,--CONTROL AZ MARK
--SS,OP1001,FP1002,AR0.0000,ZE89.5319,SD360.919449,--CONTROL AZ MARK
--SS,OP1001,FP1003,AR0.0000,ZE89.5317,SD360.919613,--CONTROL
[/pre]

And on using BSD-BSR-FSD-FSR:

[pre]--Set Collection with Obs Order 112233...
OC,OP3864,N 1954933.41794,E 6628809.43069,EL58.632,--CONTROL
LS,HI4.4400,HR5.0000
BK,OP3864,BP3477,BS83.5920,BC0.0000
BD,OP3864,FP3477,AR0.0000,ZE90.0901,SD396.179015,--CONTROL
FD,OP3864,FP3901,AR5.3529,ZE90.1304,SD190.022922,--CHK 1018
BR,OP3864,FP3477,AR179.5949,ZE269.5049,SD396.179343,--CONTROL
FR,OP3864,FP3901,AR185.3522,ZE269.4702,SD190.021610,--CHK 1018
--SS,OP3864,FP3477,AR0.0000,ZE90.0906,SD396.179179,--CONTROL
--SS,OP3864,FP3901,AR5.3531,ZE90.1301,SD190.022266,--CHK 1018
[/pre]

I use the X-Port utility to get the mean values of everything.

My intention is to include all raw measurement data in the StarNet project file. In my opinion, I see the need of this in high precision work.

> My intention is to include all raw measurement data in the StarNet project file. In my opinion, I see the need of this in high precision work.

I suppose we all approach this a little differently. I consider the Star*Net DAT file to be a distillation of what occurred in the field, and the RW5 to be the original record of field measurements. I also use an intermediate file: RWB. This is a copy of the RW5 that contains corrected information that fixes field goofs (e.g., bad HI, description, offset). The RWB is what I run through a converter to produce the DAT.

If I understand your issue, why not use the backsight as a measurement code "M".

Something like this for example;

M 1-2-1 00-00-03 90-00-00 100.000
M 1-2-3 90-00-06 89-00-00 200.000

Where, of course "1" is the BS, "2" the OC, and "3" the FS.

> If I understand your issue, why not use the backsight as a measurement code "M".

I was just pointing out to the OP that the meaned angles are in the RW5, at least in my version of SurvCE. The converter I use creates M records from the SS records, as you suggest.

RWB? I am learning here.

> RWB? I am learning here.

RWB (the "B" indicates "backup") is just a edited RW5. It's not an industry standard, it's simply my own recordkeeping convention. I edit the RW5 to fix field goofs. In the example below, I forgot to change the HR before a shot, and it got recorded with a 5.00 HR instead of the actual 5.60 that I used. I realized it immediately after the shot, so I added a note to the RW5 beginning with a pipe character ("|"). Once back in the office, I search through the RW5 and look for all the notes beginning with that character and make the appropriate edits, saving the file as a .RWB, and then run the RWB through the DAT converter.

[pre]-- Fixed bad HR
--LS,HI4.4400,HR5.5000
LS,HI4.4400,HR5.6000
SS,OP3864,FP3942,AR248.3655,ZE89.1759,SD125.874137,--BLDG N&E
--|LAST HR 5.6 NOT 5.5
[/pre]

This is a good idea. Yes, it would be much better to first sanitize your backed up RW5 before sending it to StarNet. Yes, I'll do that. Thank you for the tip.

Wait! I think the main question in this thread is the D/R support for the "T" data type. Yes, it appears to me that D/R is not supported in V6 within the Traverse Block so I provide mean values. Is this correct?