SurvPC 7.0 upgrade?

Never tried SurvPC, but I thought it was designed for field use with ruggedized tablets and such. If that is the case, I would think it should handle a generic NMEA GNSS unit. Most versions of SurvCE do.

SurvPC definitely works with NMEA. It is listed on their hardware support page. I have, personally, done the following:

SurvCE 5 NMEA

-Emlid RS2 

SurvPC 6 NMEA 

-Emlid RS2

-Polaris S100

Caveat:

Since they are NMEA, Carlson does not record the vectors from the base station (UHF or NTRIP) in my experience. Not an issue if you are just using it as a "beater" rover on an ATV. One can use the data in Starnet to adjust by just bringing things in as coordinates in a separate tab, but this is far from ideal.

I have been told by tech support that Hybrid mode does not work with NMEA, but have yet to verify.

Personally, we find Carlson to be a better bang-for-buck than the other manufacturers in our area. We use the ublox NMEA as "beater" rovers and Carlson for traditional, pole rovers.

The most interesting thing to me about SurvPC 7 is the on-the-fly Survey least squares adjustment. I will be testing it out at the AOLS AGM this March and likely purchasing the upgrade if it does what I hope it can. No more sending data to the office/booting up the laptop in the truck for an adjustment. Here's hoping Gary (Carlson) and Mike (Horizon Measurements) put on a good show 🙂

Interesting video about the new enhanced GNSS averaging in SurvPC 7 just popped up in my YouTube feed. Looks better than storing multiple points and check shots, and sorting/choosing/averaging them back in office with CAD.

I’m going to call my dealer and see if that works when I’m using the Generic NMEA driver  

I often use the Generic NMEA driver for one of my receivers (u-blox) and that of course doesn’t support GNSS vectors or the enhanced averaging of GNSS vectors.  

Interesting video.

I was surprised the time box did not get selected with an x when she put in a minimum time.

One could get carried away with deleting "outliers", especially if the number of measurements is small. Back in stat class they told us deleting points was controversial, but if our area of practice did allow it, to use Chauvenet's criterion. That would be a nice addition to the software: The point you asked to delete does not meet Chauvenet's criterion. Are you sure you want to delete?"

https://en.m.wikipedia.org/wiki/Chauvenet%27s_criterion#:~:text=In%20statistical%20theory%2C%20Chauvene t's%20criterion,is%20likely%20to%20be%20spurious.

@bill93 I wondered the same thing about deleting the outliers.  I didn’t know about Chauvenet’s criterion, thanks, something new to learn today.

@toeknee FYI, SurvPC 6 has a great GNSS point averaging routine too. Its definitely better than storing multiple points.

Since I’ve upgraded to an RT4, it makes sense to upgrade to common operating systems. They say it ‘s the same point averaging as 6, just more robust and automated. My first question was voice coding. All of this hardware and software and I am still standing there poking the snot out of a touchscreen. Once I am setup and ready, how hard can it be to let me say “curb shot asphalt shot concrete shot”?

I am hoping the ESRI upgrade will make it easier to pop up an aerial, tolerance switch (so my receiver can act like a Javad when I flip the switch) and Hybrid for control. Otherwise, not much there for my use.

@toeknee FYI, SurvPC 6 has a great GNSS point averaging routine too. Its definitely better than storing multiple points.

@GMPLS, I'm familiar with the "A" or "Sigma/n" GNSS averaging, but to my knowledge it's a one-session deal.  Is that what you were referring to?  Average for X number of readings or minutes, and store the point.  

If I want to reoccupy the same monument a couple hours later and again average over a few minutes, in SurvPC 6 I need to save it to a different point number.  At least that's my understanding. Did I miss something?

As far as I can tell, with SurvPC 7's enhancement, when I reoccupy the same monument a couple hours later, I can (1) use the same point number, (2) run another averaging session (eg. 3 minutes), and (3) average with all the readings from earlier in the day.   I can come back the next day, reoccupy for a new (third) session, and average that third session with the first two sessions into the same point.  I can also go back and examine each of the three sessions results separate, and every reading in each session separately, to look for issues.   I can later decide to toss one of the sessions (eg. if I realize I had a HI bust), for example. 

Note: The averaging of GNSS vectors is, as I understand it, a different (and useful) function.  Different topic.

@toeknee I'm 99% sure you can average over multiple sessions with survpc 6. You just enter the existing point number in store points and you can average additional observations.

@toeknee I'm 99% sure you can average over multiple sessions with survpc 6. You just enter the existing point number in store points and you can average additional observations.

Thanks!  I’ll try that.  Appreciate the info. 

Mark Silver has a great you-tube video explaining GNSS point averaging with version 6.

The main issue I have found with the GNSS Analysis tool is that if you average some shots in COGO and do a grid-to-ground localization, the average point does not get updated.

Example:

-one shoots 6000,6001,6002, and 6003 in a "grid" coordinate system (ie. NAD83 UTM)

-one averages those shots all as 600

-one then changes to "ground" using the Equip->Localization->GPS tab

-600 still shows the average of the "grid" values

Caveat:

This may be avoided if one uses point 600 for all the shots. I have not attempted it yet because if I'm doing it back at the office (like in Mark's video), I'll just do it in Starnet and have it produce "grid" and "ground" coordinates.

I have been told Access does this better on the fly (ie. grid to ground and even back to grid with multi averaged points), but cannot personally attest to that. I am unaware of what Leica has up its sleeve for this.

@jaccen

SurvPC must be storing the averaged position as grid values rather than ECEF or LLH, because a simple grid-to-ground conversion should be easy to recompute on the fly for most software.

Access is pretty good with this routine, but you still have to make sure that averaging is performed with points/observations stored as Global (LLH) or ECEF, which of course is always the case if you're just averaging GNSS data.

But once a Grid point or observation (perhaps from a total station or a keyed in point) is thrown into the mix, the averaged store position can only be Grid, and then you'll run into the same problem as SurvPC if you change the system afterwards.

Of course, the easy/best-practices solution is to not mess with the coordinate system after the job is set up and data collection begins.

If you collect quality data, you do not need to use averaging. 

If you collect quality data, you do not need to use averaging. 

Genuinely asking for you to elaborate. Are you talking about conventional survey? I'm not clear in what way you could collect 'quality' GNSS data without averaging or applying some other statistical analysis to derive a most likely position from a given set of observations.

Seeing some discussion on using the GNSS Analysis routine in SurvPC, as shown in the Mark Silver video previously posted. Perhaps this is common knowledge, but it was a learning lesson for me so thought I would share:

GNSS Analysis and GNSS Averaging (Raw Data Averaging) are two separate and distinct routines present in both SurvPC 6 and SurvPC 7. However, in operation, both are implemented from the 'Average' menu button. It is a setting which determines which type of average you will use when 'averaging', either GNSS anaylsis, or a plain-old average.

From my understanding, GNSS Analysis looks at each of the vectors in each of your observations and performs some type of least squares adjustment. If you have at least 3 separate observations, after running it will give your position a 'quality' rating of 1, 2, 3a, or 3b. The documentation is very vague on this, but evidently those ratings are supposed to correlated some unknown jurisdiction's classification of survey precision requirements, (1=City Center, 2=Rural, 3a=Farm Land, 3b=Forest, 4=Unproductive Land). You could also export a fairly extensive report detailing the results of the analysis.

GNSS Averaging, in the software called a Raw Data Average, is just a plain old add-them-up-and-divide average.

In SurvPC6, I used the GNSS Analysis routine as my main method of storing boundary or other key points. What I've found is that the new workflows of SurvPC7 do not seem to play well with using GNSS Analysis. Most of the new features seem to be expecting you to use the standard Raw Data Average, including the new Least Squares Adjustment routine. I'm also not sure that you're able to take multiple observations on the same Point ID and using GNSS analysis to get a coordinate anymore, you would need to take each observation separate, then use GNSS Analysis to store a final point.

Overall, the updates to SurvPC 7 are so extensive and useful, it's definitely worth the tradeoff.

If you collect quality data, you do not need to use averaging. 

what way you could collect 'quality' GNSS data without averaging

I'm guessing he means to let the receiver and/or data collector do the averaging before storing one point, rather than storing multiple points in the collector and then telling it to average them.

@bill93 Yes - that is what I meant.  I have observed multiple sets of data on the same point in the same near time and generally do not find any reason to not accept that first point stored. 

Errors in positioning - if sensor on a pole and not bi or tripod, then there is error in manually centering.  And if your rod is not plumb, you have error.  These errors influence positioning and from my experience, adding another observation has not increased the accuracy of the survey. 

If you want to do averaging for a geodetic position, then come back later with a new constellation and observe same points again.  Relative positioning to other points in the survey are best done with same/similar constellations and averaging generally does not improve the accuracy.  Just my 2cts.

We used to have a really screwy procedure for GNSS work - crews would have to observe six ten-second (or ten six-second?) observations one after the other, and would never come back to the point.

No re-centering, no turning the rod 90/180, no RTK reinitializing, no dropping & reacquiring SVs...

Even worse, the office would simply look at the spread of the points and arbitrarily decide which ones were "outliers", and toss them from the average. We definitely got some skewed data, because after we switched manufacturers and changed up our procedures to better align with best practices, we were noticing some very loose check shots when going back to legacy projects.

My preference (assuming decent conditions) is to take two 1-minute observations, re-initializing RTK and re-centering the rod in between, and then return to the point no less than half an hour later and do the same thing once again. This provides a check on the rod each time as well as a check on the initialization solution (even though we don't have fixed/float receivers and rarely see a "bad" solution).

The only reason I don't observe a single 2-3 minute observation each time is that I don't want to return to a point later on in the day, tie it an again, see a large delta, and have to wonder whether the rod or the RTK solution was off on the previous session.