Monthly Archives: October 2013

Large SD Cards on Z-Max Receivers

Last week I encountered a ZMax receiver that took forever to read the SD Card. And after it completed registering the card (about 10 minutes), the ZMax just rebooted. I watched it happen.

I pulled the SD Card and stuck it in my laptop to check out the Micro_Z.bin.

Of course the file was 512 megabytes in size.

This won’t work! There is not enough internal memory in a ZMax to mount a Micro_Z file larger than 128 meg and I STRONGLY recommend that you use a 24-Meg file.

If you find yourself in the position, you can quickly fix it by

1. Download this ZIP file:

2. Unzip the contents to a ‘MICRO_Z.bin’ file.

3. Format the SD card.

4. Just copy the extracted ‘MICRO_Z.bin’ file to the SD card.

The smaller bin file will mount very quickly.

My theory is when the file is damaged, the ZMax builds a new one that completely fills the available SD card. And 512 Meg is just way too big.

BTW, I don’t think that the ZMax can read SD cards larger than 2 gig.




Filed under Uncategorized

NAD27 UTM in “FAST Survey” and “SurvCE”

SurvCE (and FAST Survey) don’t have NAD27 UTM projections built-in. So if you are working with an older dataset (like Oil and Gas) you are going to need to enter a new projection manually.

Here is how to set up for NAD27 Zone 12:

Make a new job, be sure to select ‘Meters’ (unless you want US Survey Feet or International Feet.)



Click on ‘Edit Projection List


Press the ‘Add User Defined’ button.


Configure to match as above. (You will need to adjust the C. Meridian to match your UTM Zone.) Then click the ‘New Datum’ button.


Configure to match as above.

Click the ‘Green Check Mark’ four times to return to the main menu.

Let’s check our new projection:

Now click on ‘COGO, Calculator, Conversion and put the dot in LLH->Grid’


Enter the lat and lon as shown above. If you entered everything correctly, then the computed Northing and Easting will be as shown.

You are now ‘Good To Go!’


Leave a comment

Filed under Carlson, FAST Survey

JDtM (Just Do the Math): Let’s compute the ground distance between two grid projected points!

If you have not noticed, I still am not on the LDP bandwagon. I am the designated LDP Curmudgeon! 

In this second installment of JDtM, let’s compute the ground distance between two points with State Plane Coordinates:

Here are two points (East and West quarters that fall in the undeveloped area north of I-15/Washington City) shown in Carlson SurvCE:



Inversing between them we find:


The “HDist 5,314.116 sft” is the GRID distance.

Note that there is a 168 foot elevation distance between the two points. Is it Okay to just use a single scale factor (like the scale factor for point 10432)?

The LDP Curmudgeon says “Who cares? Just Do the Math!

1. Reduce elevations to ellipsoid

2. Compute scale factors for two end points:

                (SF1)      10432    1.000,133,747,228

                (SF2)      10437    1.000,125,721,090

 You also need the scale factor for the midpoint of these points:

                 (SFC)     10023895.740 N, 1048125.982 E, 3059.909 Z           1.000,133,747,228

 The scale factor for line segment is: (If you don’t believe me Google “Grid Scale Factor(K) of a Line”)

                 SFLine   = (SF1 + 4 * SFC + SF2) / 6

                               = 1.000,132,409

 So the ‘correct’ ground distance is:

                 DistGround    = 5,314.116 * 1.000,132,409
                                         = 5,314.820 sFT

 If we wanted to just use a single scale factor (say the scale factor for the 10432 point:

                 DistGround    = 5,314.116 * 1.000,133,747
                                         = 5,314.826 sFT

You may ask, who cares about 6-thousandths? I say, it all adds up. 10 measurements and you have 6-hundredths. Next thing it is a tenth. Since you are not doing the math manually, (it is getting performed in the data collector) why not just do it and get the right answer.

Leave a comment

Filed under Uncategorized

Drinking the NovAtel OEM 6 Kool-Aid

I have tested the NovAtel OEM 5 boards in several receivers (Viva, Carlson Surveyor GPS, X900) and while they have been okay in a matched base – rover pairs, they have not compared well to systems based on the Trimble BD970 boards or Spectra/Ashtech ProMark 800 receivers.

A week ago, I had an opportunity to compare a BD970 based receiver with a receiver using the NovAtel OEM 6 board under the big tree in front of our office. (I will describe the test I run in a moment.) Both receivers use exactly the same antenna element (in fact they are nearly identical.)

The OEM 6 is simply amazing. Solutions are really snappy. The ‘verified fix’ usually happens a few seconds after the initial fix. [For some reason, I find myself liking the dual fixing quite a bit. Especially when the verified fix happens so quickly. The OEM 6 really feels good under canopy.]

Here is a quick description of the test I run:

1. Corrections are served by the TURN VRS network in RTCM3 format with a virtual base 1-mile to the north. The corrections are played through a Pacific Crest UHF radio so that both GPS receivers under test get corrections at EXACTLY the same time.

2. I use two prism poles, 1 meter apart. The left pole is 1/2 meter lower than the right pole.

3. I wait for both receivers to fix, count to 5, store a single position, then dump both receivers, exchange positions and repeat. 60 times. So I have 30 occupations for each receiver on each pole. (I wait 5 seconds after the receiver fixes, independent of the other receiver.) If a receiver won’t fix in two minutes, I move it away from the tree, then sneak it back onto the pole.

The test location is, well, horrible. There is a giant tree 2-meters to the South, a two-story building 2-meters to the East, and big power lines to the west. The location is not suitable for GPS work. Which makes it perfect for testing receivers.

In the past, the OEM 5 boards have not fared so well in the Trimble VRS network. (The Trimble BD970 is matched to the Trimble VRS network and usually beats out every other receiver that I have tested other than the PM800 which either as good or better.)

But the OEM 6 has as good of performance as the BD970 based receiver. Absolutely.

What makes this remarkable and noteworthy is: the OEM 6 is about $1,200 less when bundled into a rover solution. Thats $2,400 for a base-rover pair.

Your takeaway should be: “Consider OEM6 based RTK GPS receivers. They are hot. Much better than the OEM 5 based receivers.”

Leave a comment

Filed under Uncategorized

7 Free Alternatives to OPUS GPS Post-Processing During U.S. Federal Government Shutdown

This is a great article by Eric Gakstatter on alternatives to NGS OPUS (Static, Rapid Static or Projects):

7 Free Alternatives to OPUS GPS Post-Processing During U.S. Federal Government Shutdown ]

It is timely because all of the NGS websites, services, databases and tools are offline.

It is a great article because, well, I wrote most of it. (Check out my byline! I am published!)

Additionally, I sent out this [ newsletter ] this morning:

To stem the flood of calls, I want to warn everyone that the NGS OPUS system is unavailable (you know why.)
It is not clear if observation data is being accumulated during the shutdown; nor is it given that it can be ‘filled in’ when the NGS comes back online.
This means that all data that you collect during the Federal shutdown may not be processable in OPUS, even after the shutdown concludes.
Don’t despair, there are a number of similar online processing tools available. I have written a very detailed comparison of these tools, which was published in ‘GPS World’ online today:
Even without the current crisis, it is worth a read.
Please be aware that most of the alternative services will not do well with 15-minute observation files. I STRONGLY encourage you to collect at least 1-hour of observation data during the government shutdown in case OPUS-RS can’t fill in the gaps when NGS OPUS is reactivated!
If you are using the iGage/CHC X90-OPUS GPS Receiver [ more information here ]:
The latest X90 Download tool already supports direct submittal to RTX and AusPOS; two of the alternative services.
If you are using the X90-OPUS receiver and find that you want to use the excellent GAPS service (from the University of New Brunswick); you will need RINEX files with standard 8.3 filenames. The current Beta X90 Download tool has a checkbox to force 8.3 filenames on export. If you want to use GAPS, drop me a note and I will get you a copy of this beta tool, it will save you the hassle of manually renaming the files.

Leave a comment

Filed under Uncategorized