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.