Hello, I want to make a query, when I configure RS+ to perform measurements in static mode, more than 2 points, is a single UBX file created? or one for each point? I need them separately and 20 exact minutes of observation.
Regards
It would be very useful if you can create ubx files separately for each static point !!!
1 Like
If you plan to use the static point again (as in for reference), you go for more obs time than just 20 minutes per point (when talking L1 only).
To me, having 1 raw file is quite beneficial, as increases the chance of fixed solution in non-ideal environments, especially using the static start option in rtk lib.
1 Like
Would toggling logging (say that 5 times fast) be a good option. Itâs a little more file management, but when using Reachview has worked well for me. Of course I am only doing control and normally less than 15 points at a time.
3 Likes
Yes, before the survey projects were available, that was one of my techniques as well - to turn off UBX logging between points.
BUT, you must occupy a point for as much time as it takes to get a fix, plus the time you need for observation on the point. And how much time is that? ⌠well you have to estimate.
Conversely, if you record a continuous UBX file, then you can usually assume that you have a fix upon arrival at a point and just occupy for your minimum time. Using this method, you have to track your start and stop times at each point. If RTK, itâs easy - just use the survey project point-collection function in ReachView. If PPK, itâs a little bit harder, but you can write down the start and stop time or you could also use the survey project function point-collection function for keeping track of your start and stop times (e.g. disregard the âpointâ coordinates, and just keep the âtimesâ for matching up later with your PPK results)
2 Likes
Not sure I understand this. Are you talking about turning off logging and using RTK? I am knowingly only using PPK. What I typically do is occupy the point, turn on logging, document the start time, document the end time and turn off logging. Then move to the next point⌠I donât necessarily need the start and stop times because each point is a separate UBX file.
Thank you very much for your answers, this is what I am going to do, and I am talking in a static way since I have to give the government organization one file per point, 20 minutes observation, Rinex 2.11 and post-processing commercial software not RTKLIB.
When I made a static with two points (really a PPK) and observations of 20 minutes, I divided the UBX into 2 files but RTKCONV generated the Rinex files but not the NAVs, and then I could convert it with CONVBIN but when I created the Rinex files in header the approximate coordinates were from the first point and had error in postprocessing (commercial software, Gnss Solutions)
It would be good if in Static mode when one defines the time in Survey Single for each point a separate UBX file is created.
Thank you
1 Like
What I was trying to point out is that when you start a new log, you need account for the estimeted time required to obtain a fix. Once that time has passed, then you can wait for your personal minimum point observation time. It you turn off the log at every point, then you have to wait for the same amount again at every point.
The difference is, If you leave the log running, then you only have to wait for fix at the start and you can capture multiple points in far less time. But the caveats are: that the rover maintains good sky view the whole time, and so the PPK result will stay fixed, also you must do your PPK in Kinematic mode since you are logging between points.
1 Like
That method sounds proper to me.
So when you say fix you are talking about the time it takes for the rover to gather enough satellites to get back to a single solution? I am only familiar with the term âfixâ in RTK. Still learning allot of PPK.
Well, I mean that when the processing engine starts (RTK or PPK), then it takes time to resolve the ambiguities and declare a fix. With RTK, you can see that live; with PPK, you have to estimate how long that might take(1min, 2min, 5min, 10min) depending on your environment, etc. Then, once you figure that enough time has passed and you should have attained âfixâ, now you have to stay and hold that fix for a certain amount of time. That time might be 5 seconds or 20 minutes or 2 hours+ depending on your situation and requirements.
You donât find out if your âwaitingâ was sufficient until you actually process the data back at the office.
Does that help shine some light on the point I was trying to make?
(disclaimer: This does not really apply to RS2 multi-band units as the fix comes almost instantly. It is more applicable to RS+ and M+)
2 Likes
Yes, that makes sense now. Considering I normally occupy 15-20 minutes per point I have never really noticed any issues. The receiver is mounted to my truck in between points, but maybe I should still analyze a little deeper and increase 5 minutes?
2 Likes
Yes, if you occupy for 15-20 minutes with the RS+/M+ then you can have an extremely good chance of having a fixed result every time. I suppose you would only need to adjust that time if you feel the âfixed portionâ of the occupation time was too long or too short.
With PPK, you have the opportunity to process the log forwards and backwards in time (combined mode), so one can sometimes obtain fixed status for 100% of the log. If your requirements allow for combined processing, then you can afford to shorten your occupation time even further.
2 Likes
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.