Facet returning inconsistent elevations

I am trying to develop a method to use the Facet for surveying in tide gauge sensors for recording sea level. For this purpose I need as high accuracy as possible, but essentially ±5 cm would be good enough. Ultimately I would like to be able to record data without corrections and do PPK using OPUS for my final results but I’ve been having trouble with OPUS processing so I’ve been experimenting with RTK from a local CORS network to see if I can get the data in real time. The problem is (and seems to be the case with uncorrected data as well) that the elevation drifts significantly over time. For example:


Depending on what time period I choose, the elevation could differ by up to 50 cm. I’m fairly new to GNSS surveying but I have spent significant time trying to tweak this method with different settings and different occupation lengths without much success so far.

Welcome @scooperd !

Something is surely off. RTK fixed positions from the Facet won’t be moving half a meter in elevation under “normal” circumstances.

Possible suggestions could go in a number of different paths.

Can you describe your field work when using the facet with a CORS network ?

Are you getting a RTK “Fixed” or “Float” solution ?

Hi @rftop,

Thanks for replying. This particular result I’m showing was just a test from my driveway that I did while I was doing some other work yesterday. Everything in the graph above is RTK fix (green symbols). The receiver was attached to a 1/4" bolt on top of my porch and it was connected to a CORS network with the closest location ~20-25 miles from me, which I recognize increases the error, but I’ve tried this in other places with closer correction sources and seen essentially the same results. The Facet connects to a wifi network and gets the corrections internally from an Ntrip server.

I’m in an area where 20-25 miles is often going to be the closest correction source, which is why I would like to be able to do everything with PPK. I don’t really need real time data and I work with NOAA who created OPUS so they trust that more anyways, but I’ve observed the same kind of drift with non-corrected data so that if I choose different windows of the same observation, I get varied results and often times OPUS will just abort entirely because the dataset is too noisy.

I appreciate any help or pointers you can give me, I’m just trying to figure out the best solution to get the most accurate and consistent data possible.

This is strange. The results “look” more like DGPS and not L1/L2 RTK.

What CORS station was used yesterday ?
What app are you using to collect the data ?
How tight were the X,Y positions yesterday, in general ?

Sorry for the silly questions.

1 Like

Please, ask away. Here is the full graph with X and Y in the top two sections. All plots are ± 20 cm:


The x-y are tighter but still drifting a bit, more than I would expect.
I was using the ACORN network out of Connecticut for corrections, connected to their network solution. I’ve been collecting data directly on an SD card in .ubx format and then converting it to to RINEX files for processing. These plots are RTKlib plots of the .ubx files.

For reference, this is what DGPS looks like on an identical instrument that I was testing without corrections at the same time (±2 m):

We are mixing up methods.
PPK, OPUS, .ubx, RTKlib, etc are going to be harder to diagnose than simple RTK positions.

What precisions are you seeing with RTK Fixed ?

1 Like

Got it, yes let’s simplify. I connect to the Facet through bluetooth with SW maps to monitor the connection and the accuracy. During this test, with RTK fix, the vertical accuracy reported on SW maps was between 20 and 30 mm.

Perfect… How bad did the elevations spread in RTK Fixed at the 1/4" Bolt on your porch ?

I wasn’t monitoring it the whole time on SW maps, but I’ve seen that the results that I plot from the .ubx file tend to match the output on SW maps, so I was somewhat confident that it the spread was the same as that plot above. I’ve definitely observed a 50 cm spread in the reported elevations on SW maps when I have RTK fix and I watch it the whole time. But maybe I’m missing something, I’m happy to try a new method if you have a suggestion.

That is concerning.

This is a long shot, but you are selecting a RTCM Mount Point, correct ?

Yes, for the ACORN network I mounted to their multi-station mount point and I haven’t tried anything else. I’ve tested more extensively with MA’s CORS network and used multi-station points as well as single station mount points. Unfortunately I’m in RI which is in between the two networks and doesn’t have it’s own.

2 Likes

Another long shot: You might want to use the NTRIP Client in SW Maps, instead of the Facet’s internal Client. I can not personally confirm that something squirrely can’t happen with the internal Client.

I could give this another shot, it was how I connected initially back when I was first testing but I chose to go with the internal Ntrip to save battery on my phone. As I recall I was seeing the same problems, but I don’t have any direct documentation of this because I didn’t realize there was a problem yet.

You might want to use the VRS mountpoint.

From ACORN site:

Just for giggles, Try another location. You might be experiencing some weird multi-path situation on top of the porch.

1 Like

Will do, not until next week though. Thanks for the thoughts and responses. I’ll reopen this next week after I’ve done some more testing.

1 Like

Hopefully more folks will chime-in w/ more thoughts & suggestions.

My facet does really good horizontal in challenging places but vertical is trash a lot of times. An example today I could not obtain fix with my postcard so I whipped out the facet and got a check of 0.03 to my total station vertical was off 0.7. so this post doesn’t surprise me a bit.

Then I guess my question is, what does the vertical uncertainty value reported by the machine even mean? If it’s saying 20 mm vertical uncertainty but the value is off by 50 cm and, more importantly, the value drifts by 50 cm, then where is the 20 mm value coming from?