Is there a way to reproduce the RTK coordinates in the office through post-processing? I can't seem to get the same results using only 1 base/1rover setup using kinematic processing. Is it possible to use the corrections from the base and recompute based on the timestamp of a fix status point?
I don't know.
I do know that how different brands do things, varies. And, within brands, things vary, as technology expands.
I have a javad, and it allows RTK, in the field. But, it now, (as of about a month or 3 ago) it seems to store the parallel base/rover files, in the reciever, AND allow post processing in the field. This coord, generated via post processing in the field is usually a few hundredths away from the rtk generated coord. This is a completely different algorithm, from rtk, and theoretically is a stronger coord. I've not proven this, but from what I read it WILL eventually (if not now) become a stronger solution.
So, I think I understand your question. Is it possible to regenerate the rtk work? Back 20 (!) Yrs ago when TDS was an entity, there was some sort of mechanism in TDS to modify the base coord, and all sideshots from that base. (Essentially moving the underlying geodetic lat/Lon) but, I cannot remember how it was done. From what I read, there is some mechanism in Trimble office software, that does something like what you are asking, PROVIDED you have the raw data intact.?ÿ
So, did you loose a file, raw file, or something?
If you tell us your equipment brand, and file type, it'd help.
There are people on this forum that are 10x smarter than me, and some are smarter than that. (Once you get that smart, you have to find somebody to help them find their slippers, and put them on, but that's another story!)
(Grin)
I've ALWAYS been fascinated/uncomfortable by the fact that I cannot re-do, and review the raw data, for rtk, in the SAME way I can review the raw field book data, generated from the "old way" we used to do.
So, this essentially MADE me a dependent on a set of computations, spit out of my data collector, that I cannot work out with my TI-30, and a cup of coffee.
It makes for a bizarre form of trust, in the Mfr. That I'm not exactly happy with. More or Less. But, there's no goin back. Your post hit a nerve. I hope you forgive the semi- hi-jack
I think you will get what you need, so long as your trust in the Mfr. Is working. At least within a couple of hunnerts!
Thank you,
Nate
?ÿ
Is there a way to reproduce the RTK coordinates in the office through post-processing?
One requirement for that is that your rover setup must store the raw data from all the satellites, not just the computer positions. Can yours do this and do you have it selected?
I've done post processing for base-rover vectors using receivers that stored the sat data with good results. The software let's me add as many CORS as I want to the solution.
If using a?ÿ proprietary network, you would need to download their equivalent station data.
Yes, it's called RTK and logging. A survey style available in Trimble, don't know about any other vendors.?ÿ
As Bill mentioned, the critical thing for post-processing is to store vectors (and associated quality information) rather than positions. Only then will you be able to post-process and update positions.
Unless there is something strange going on in the controller, or in your post-processing software, after importing just the raw data the vectors (and subsequent points) should reflect what was seen in the field. I would double-check the coordinates of the base position first.
Thanks for the reply. We were doing a topo in relatively low wooded areas. We completed a section of the site last week. Yesterday, we processed last week's data and found that there were bald spots in the data. When the survey team went back to take RTK shots of the bald area, they were able to overlap with last week's data. After processing, we found that the overlap area points from the 2 sessions were off by 2+ meters. Only some portions were off in elevations. Reviewed the RTK csv file and all points were Fixed with RMS values less than 0.10m.
I could not find where the errors were coming from. This was why I wanted a procedure to reprocess all the RTK data in the office to see if I can debug it.?ÿ
?ÿ
I used 2 post-processing software to compare the kinematic results. Magnet & RTKLib. Both returned different values for the same timestamped data. I had a colleague recheck the base coordinates, HI, pole ht to see if I made an error. Both base information are correct but the 2 software returned different results between themselves & the RTK points. Now I am really confused.
?ÿ
the critical thing for post-processing is to store vectors (and associated quality information)
I think it is pseudoranges from each satellite that are needed. Vectors usually refer to distance and direction between two stations, and is only a little more information than positions, having lost the time dependence in the sat data.
Are you comparing LLH and ECEF coordinates, or only XYZ coordinates? I would check the LLH coordinates and be sure the two processing engines are converting to XYZ the same.?ÿ
Good point, should have specified that I was referring to "post-processed RTK" rather than PPK.
Actual PPK processing, in my experience, results in slightly different coordinates than RTK, which I have always chalked up to my (rudimentary) understanding that RTK processing engines operate differently than PPK algorithms.
LLH, actually I am comparing the H values and roughly converting the LL differences.?ÿ
I have had an issue with groups of points not fitting due to an error in field work, or other unexplained error.?ÿ in my case usually caused by someone using with equipment with little experience of training.?ÿ Although many years ago there were sometimes seemly random points shifts, with groups of points off by a metre.
If not other way to correct, I would then adjust the points in cad (civil 3D), create point groups and shift horizontal and or vertical to correct.?ÿ So that the data matches.
If in doubt I would survey check in the field to ensure everything fits as it should.?ÿ
@jt1950
Honest answer: I think you may have some bad inits out there. We're these redundant shots (overlapping data) under canopy??ÿ
Fixed does not always mean "correct". It can mean your unit is over there saying: "fooled me too" 🙂
My thoughts are: develop a sequence.
Set up base. Shoot a sideshot to an easy, local item, every day out. This can help you catch a bad hi at the base, or a bad rod height.?ÿ
My first guess is you may have some bad shots out there.?ÿ
One way to demonstrate this is to shoot c/l on a nice straight, (both horiz and vert) section of road, that runs under thick trees. Import this into cad, and look at the weird potholes, and mountains, that show up in the drawing, that don't exist on the ground.
Thank you,
N
But how many of us can afford the extra time to recheck even just every 10% of all points surveyed. It is similar to TS shots where you just shoot as you go but then you have a closure check for the traverse loop. In RTK, it's different. I read that the FIX means that only 67% of the shot's value is correct. If it means what I think it means it is saying that we are reading field data that's MAYBE 1/3 erroneous for every shot taken?
Which brings to mind how many topos that we have done using RTK that had erroneous data because of this 67% threshold.
yes, I have the raw logs from both the base & rover. These were what I used to post processed (PPK) but using 2 post processing software, I got different results for each timestamp point. Magnet & RtkLib are producing 2 different elevations for the same timestamp point. Which is causing us to lose confidence in the RTK shot itself.
From the discussions here, am I to understand that RTK coordinates are as-is recorded on the data recorder? Are the ambiguities not recorded in the raw logs for us to reprocess in the office?
?ÿ