The more the better obviously. Possibly also take several same point samples and average them if needed? It’s up to you.
@timd1971
Average samples taken over what time frame? When different satellite arrays are available?
thanks
boston
So like setting the averaging time of the surveyed point to 59 min but keep recording at the same point for like 3 h?
Thanks, everyone, for chiming in with excellent suggestions.
LoRa requires a direct line of sight between the base and the rover, and given the site conditions, I want to highlight @timd1971’s suggestion here: Record the logs while doing the RTK and PPK later on if RTK doesn’t give you the desired results.
In Flow, you can only average the point for a maximum of 59 minutes 59 seconds. Since you need to collect 5 points, an hour each for each point would take you a whole day.
Here’s the guide on how to Stop and Go with Emlid Flow.
If OPUS is supported in Guam, you can try uploading the logs to OPUS. However, they’re very particular about the log quality, so your dataset might get aborted for processing.
They only support Static for now, so you must divide the logs into several parts before uploading them to OPUS.
We do those quite often, can I suggest using a slam LIDAR scanner such as fjd and setup your control points in a clear view. You can walk all the way to the beach.
You can also use a pneumatic mast with the base to help.
Thanks. Was thinking if I get good horizontal accuracy, then the vertical could be obtained with Lidar.
Thank you Ruth. It wouldn’t be a problem to spend the whole day if I get good results. And I have other field work to do while I wait. So for the most difficult area a PPK with 59 min could give good results?
P.S.: I meant DEM derived from LIDAR. We don’t have a LiDAR slam scanner … I like your off the box thinking.
solo coloca tu base en la parte mas elevada del acantilado y tendras señal lora, esa vegetacion no se ve muy espesa y lleva un baston de aplomar de 5mts de largo para ciertas partes que este mas cerrada la vegetacion, yo he hecho replanteos de lineas bajo esas condiciones y con fix solo con LoRa
Translation:
Just place your base on the highest part of the cliff and you will have LoRa signal. That vegetation does not look very thick and take a 5m long plumbing stick for certain parts where the vegetation is more dense. I have done line layouts under those conditions and with Fix only with LoRa.
Thanks for the translation and also to @aoga66 of course.
The top of the cliff is military zone, would have to go through a lot of paperwork to place a base there. Long pipes seem to be a good idea and I guess you just put the surveying pole with the receiver into the pipe?
I’m leaning towards using both receivers to record points for 2-3 hrs and then post process the data using the CORS that is only 7 km away. Using both receivers will reduce surveying time while long recording should assure the desired accuracy. If vertical accuracy won’t be good, at least the horizontal should be, and that should help determine the elevation with 1x1m Lidar derived digital elevation model. Any thoughts on that?
The longer the pole, the greater degree of error to the ground. So pay close attention to that.
You’ll have to make a 5/8" x11 male thread fitting from the pipe to receiver. Good luck trying to keep it as plumb as possible too with so much increased chance of error as @dpitman mentioned. I would see if you can get away with standard pole first and go from there.
Sounds like lots of trial and error and a nice learning experience.
Would go without an extra pipe this weekend 'cos I don’t have time to find an adequate one (and the permission to survey was already granted) but found it a good idea to explore.
Static
Oh, thanks for sharing!! 1 h is suggested for static, but probably in better conditions, so 2-3 hrs per point in cliff-canopy conditions sounds like the way to go.
It’s hard to know just what the GNSS environment is like without an actual data file. You can guess with a picture, but that would only be a very rough guess.
You’ve got three possibilities with a multi-hour data set, say 3 hours.
One. When processed the data is mostly fixed and the variability of the fixed heights is only a few cm. That’s good. The average of the fixed heights is likely your true elevation at the sub-decimeter level. Your basically done. Maybe one more trial to confirm.
Two. When processed none or very little of the data is fixed. You really can’t say what the true height is with any confidence. Not at the one decimeter-level. Maybe time to think of another method.
Three. When processed the data has fixed periods and float periods. Say there are six periods of at least a few minutes in length with fixed integer data. If four of them happen to have similar elevations (within a few cm) and maybe two don’t an average of the four that do very well might be the true height. That’s useful if not definitive. Maybe one more similar session and you can be reasonably sure of the correct height if most of the fixed integer height values from both sessions match up.
A very valuable input!!
Btw, what would be the best update rete? 5 Hz?
While many people think faster is better, that’s not the case - at least under good GNSS conditions. But you aren’t going to be in a good GNSS receiving situation so uping the speed can help a bit. If you set both the base and rover in your environment 1 Hz would be plenty fast enough. 5 or 10 Hz I would think is overkill since this is a static situation and the noise levels in a receiver operating at its max will increase.
Now you have a CORS as a potential base. What rate does it record at? If it is a 30 second base that would be on the slow side - though it could still work. If it records at a 5 second rate that’s better for your situation. At 1 Hz I wouldn’t bother with your own base - at least from a speed perspective though shorter baselines always help some.
Ultimately you’ve just got to try it. It could work out well or be a complete failure. Again without an actual GNSS file from a similar environment I really can’t say much more.