what the conditions might be that would give you that level of vertical accuracy.
In short, ideal and often in the laboratory. In the real world, I would expect double that or perhaps 30mm, but I agree with @rftop, 500mm is a lot. Do you have a 2nd RTK device that is capable of base mode? It would be interesting to see what a more localized base produces; yes the local base will be absolutely less accurate than the CORS station 38km away, but all you care about is proving whether the ZED is capable of outputting a less variable elevation when a base is nearer.
Yes this is a good idea. I have a second Facet that I bought to be able to use as a local base station for corrections but I moved on from that plan at some point. I have some old files from those tests, but I’ll also try to do some new tests with that setup later in the week. Thanks for the suggestion.
I have the impression from anecdata that ACORN does not lead to the same solution quality as MaCORS. MaCORS works amazingly well. I would suggest going to somplace in the MaCORS service area (so that you have stations in all directions and it can interpolate) and testing there. The MaCORS MSM4 iMAX mountpoint is the one I would recommend.
There is being in FIX, and then having lots of satellites. You need to wait to get more, and be in an open area, if you want the best vertical accuracy.
What you are reporting looks more like RTK Float behavior to me.
This is very useful to have some perspective on this. My most consistent results, i.e. this:
are from single-baseline solutions from the closest MACORS site to my location. I have had less success with the iMAX from MACORS, but I am not within the MACORS service area, but ~20 km outside of it, so I imagine that’s why.
That would make sense but the instrument is reporting RTK fix during these tests. I’m unsure exactly what information is going into that though, do you know if the instrument will report RTK fix when it is actually in RTK float sometimes?
I also just switched to stationary a few days ago to see how that changes things. So far the biggest change I’ve seen is that the velocity values seem to be constrained more (which makes sense because I think that’s most of what this setting does), but I haven’t been able to convince myself that it’s tightened the actual results at all. I’d be curious to hear what you see.
These 2 settings will likely make the most difference for you :
Using my NMEA message rates should stop the Bluetooth disconnects from your phone.
Again, I don’t use the onboard NTRIP, so we aren’t comparing the same system(s).
iMAX is very complicated; AIUI it is a network solution, synthetic data for very near you, both base coords and the carrier phases. The point is that it can interpolate among stations to get closer to the iono/tropo delays for where you are, and thus take out the 1st-order spatial terms. When you are outside, I don’t know how this works, but it’s Leica so I’d expect reasonable. I am surprised iMAX is ever worse than single base. Note that with MaCORS there is one site in RI, at URI, and I do not know if it’s the same Leica equipment. MaCORS seems to be run to a very high technical standard, almost like it’s part of NGS, so I’d expect them to insist on 1st-class operations.
Looking at your data there’s a jump at about 19:23:30. One thing that can happen is the receiver declares that it has a fixed solution but has incorrectly resolved the integer ambiguities. Then later, it makes a new estimate of the ambiguities and transitions. I find that when it’s wrong, it’s often a meter off, very ish, and there is slow wander. When it’s right, there is so little wander that the dominant horizontal noise is my ability to hold the pole level.
You said you had two. Try them both. I have never heard of a hardware problem that causes this, but the more data the better. Using your own base should also work, assuming the base has a full horizon view, and the units are close.
I have data from both and have had the same problems. I was initially thinking it could be a hardware problem but I’m fairly sure I’ve eliminated that (unless they both have the same problem).
I don’t know if it’s worse. I’ve had problems connecting sometimes, but now that I look at some plots where I used iMAX from MaCORS, it actually looks better. Here are a couple measurements I did a few weeks back. Note that the vertical scale is 20 cm on these plots and most of the above plots have a vertical scale of 40 cm:
The URI site is Trimble, the only one in the network which is not Leica. I’ve been confused about this site and I should follow up with the network operators. You can’t find it as a mountpoint to connect directly, so I wonder if it’s still part of the network solution. The reason I started using ACORN is because the URI station is in that network and I can connect directly to it.
The new graph has a big jump at 1509, but it’s 8 cm. And, your V wander is within maybe 18 cm. Not great, but much better.
Fair enough if two of them behave this way; that argues strongly for “not HW”.
I would contact the URI folks directly, esp. given that you’re working with NOAA and are thus legit and not some random hobbyist I would think that the Leica network software could take inputs from Trimble; it’s just carrier phase observables, but now I’ll really speculating.
I just did a quick base-rover test per @sparky’s suggestion. I put my two Facets right next to each other outside and had one act as a survey-in base and send corrections to the other one over Lora:
After a few minutes of warming up it looks like it at least returned very consistent results. Again, I’m not super familiar with looking at GNSS data, but this seems to suggest that the instruments are capable of getting good data with RTK. Does this kind of variation seem normal under the conditions?
I should add that the settings on this observation were default settings (i.e. elevation mask 10, signal mask 6) because this was a new configuration for me, so I hope I could do even better.
I’m no expert either, but your vertical data seems still a bit out of whack…most of it looks good (especially from ~5min onward), but it’s reporting a huge standard deviation and RMS (125cm) compared to your N-S and E-W (~2cm)
If there are big spikes (it looks like U-D goes off the chart downward at ~3.5min) it might be better to filter those out, or change the data window (to leave off those first 5 minutes, for example)
You can get much better results with a permanent base if that’s an option for you
Yeah you’re absolutely right. I would cut off the first 5 minutes of this run. I have the impression there can be a couple minutes of “warmup” as the satellites get and lose fixes and the beginning of an observation anyways, so I always tend to look at the first few minutes skeptically. The rest of it looks pretty good though, especially given this is on my porch which has a massive tree blocking the southern sky. I did some more extensive tests at a benchmark yesterday (with wide open sky):
Again, I would clip off the first minute of this, but I think I’m good with this particular network solution. I’ll have to do some more tests to make sure it all stays consistent but I’m happy with this for now.
I get the impression that the high variance plots that I showed earlier are actually in RTK float, as people suggested, even though the instrument is recording them as RTK fix. So I guess it’s important to just ensure that the vertical spread of the observations is within a reasonable range manually before accepting that it actually is an RTK fix. The same can be said about the first few minutes of these “good” plots where the variance is high to begin but then gets lower, all while the instrument records the data as RTK fix. I imagine most of you know this already, I appreciate the help getting there.
Ultimately the goal here was always to figure out a way to record data without corrections and then do PPK with OPUS to get elevations, but I’m happy that at least I seem to have a good solution for corrections when I have a good CORS network. The reason I would like to figure out a solution without corrections is that I have upcoming fieldwork in extremely remote places that are thousands of miles away from a CORS network, so I need to figure out a way to do this without CORS.
I have what I’m calling a semi-permanent base that I may use for this purpose and it would be good to get people’s opinions of this idea, because it may solve my remote corrections problem. I’m testing it at home, but essentially I have a fairly stable location that I can connect one of my Facets to. I then collect 24 hours of data and process it to get a PPP solution. Then I use it to provide corrections to my rover. It seems like it would be more accurate than a simple survey-in base but possibly not as accurate as a true permanent base.
The statistical values for the graphs don’t represent the data that’s shown.
X is much tighter than 17cm, Y is much tighter than 10cm, and Z is much tighter than 182cm. It Looks more like 2cm, 2cm , and 3cm to me. Something is fishy with the workflow.
Wouldn’t that would generally indicate a location that won’t be well served by NGS/OPUS ?
PPP would be the correct direction to take, IMHO.
Has your client already started the transition to ITRF ?
What Reference Frame and Datum do they want the Gauge locations/elevations expressed in ?
It was still in DGPS or float for the first minute which completely screws up those averages, you can’t even see the values because they were off the scale that I set. Here it is if I remove that first minute:
I’ve used NRCAN for PPP, do you have a suggestion? Would using a PPP-surveyed in local base make sense like I outlined above or would I want to do PPP on all locations? I’ve had trouble getting low errors for PPP without really long observations, which I can do it would just be nice to avoid.
Essentially my client is NOAA in the sense that the tide gauges need to be up to NOAA’s standards because they will be ingested into NOAA’s and the NWS’s observing systems. As far as I know they are working on the transition to ITRF but for my purposes they are still asking for NAVD88.
Can you physically occupy the tide gauges with a GNSS ?
Or do you plan to establish a control point nearby and level to it ?
[just my curiosity]
So you need to QA/QC your deliverable.
Here’s what I’m thinking (for discussion):
Assume you are setting a CP (and maybe even a TBM reference mark) nearby a tide gauge.
Occupy the CP for 24 hours and store RAW for conversion to RINEX. At the same time, use PPP-RTK corrections and store those RTK positions. When you come back tomorrow, you already have 24 hours of PPP-RTK positions (assuming Cellular Coverage, or use Facet-LB if no Cell Coverage), and the RINEX to send to OPUS And/Or CSRS for post processing.
But if 2cm is the goal, I’d do that with PPP-RTK not long after I got out of the truck (assuming Cellular Coverage). Then leave a PostCard-based logger there overnight (w/ NGS calibrated antenna model) for post-processing to confirm.
You could use the same workflow for every location. I don’t see any benefit with a local base for this application.
Use NGS tools to convert the coordinates for your final deliverable. Go overboard with metadata and keep them with the solutions.
My gauges are custom built with a 1/4-20 mount point on them so I do physically occupy them.
I do field work in remote parts of Alaska, from what I’ve read PPP-RTK may not work up there. Cell coverage is also very spotty in these regions and I think L-band also will not work. I’m really trying to figure out a method that doesn’t involve too many bells and whistles because most plans seem to fall apart when in remote places without any chance of help. I can likely do long occupations and post-process, but I’ve also run into situations where I can’t get back to a location 24 hours later because a storm has blown in and I’m stuck in town because all travel is by plane or boat. All this is to say, I want to give myself a few options that are most likely to work with long occupations and post-processing as the likely fallback plan. If I’ve got it wrong about PPP-RTK I’d love to hear so, and please point me in the right direction there.
