For the past few weeks I've been watching a dream of mine materialize, rather quickly, into a reality. Some time ago, I suggested to Javad that he should offer a post processing solution inside his flagship RTK rover.
I had this idea that this would be extremely useful for getting accurate positions on points when communications failed. Of course it was just a concept, the real work is in actual development of such an idea, so my credit in this ends at a rather nebulous request. Rather than put the processing software in the box, requiring processor resources and additional user interface, it was decided to use the same server Javad has used for a year now to post process base positions to CORS - DPOS. DPOS, which is similar to OPUS has been used for an automated way of processing a base raw data file and translating the base to CORS related coordinates. Using a cloud based service such as DPOS allows for the bulk of processing to be performed remotely. Raw files are uploaded over the Internet, processed on Javad's server and the results are sent back to the receiver.
Javad's team has quickly reworked DPOS to process vectors between the user's base and rover. The base file and the rover files are submitted to DPOS directly through the Triumph-LS (no PC download required). Each vector is processed and the vector results are returned to the user. The LS automatically selects the best vector based on "fix" status and number of epochs (and soon a combination of epochs and low RMS). The user can evaluate the vector results, seeing how the RTK compares to the post processed solution. Vectors that disagree significantly are highlighted for the user to take notice of and apply corrective action. The downloading of base data, the uploading to DPOS, the processing and the return results require only a handful of key strokes. It's highly automated.
Once implemented, I wasn't sure what to expect. I anticipated that this service would be good for processing files when communications failed and that the time on site would need to be longer and that the sites would need to be cleaner than typical RTK usage. What I am discovering is that DPOS can process vectors with an incredibly short observation time in some very miserable places and that the results are not only useful for filling in for communication outages but also for an added layer of verification of field results.
I've processed vectors that were 9.5 miles in length with observations as short as 6 minutes. I've processed points under excessive canopy that proved to be incredibly accurate in relation to known coordinates. The results continue to amaze me.
We started using post processing in 2000. This required observing the point, downloading the data, processing the data, evaluating the results, reprocessing the data, adjusting the data, exporting the data, and importing the data to the point database of our project. When we started mixing receiver brands, there was an additional step of converting data. When the CORS became available in our area, downloading data from the Internet and importing the data into the post processing software became a part of the process. All of this required time. Sometimes it required a lot of time, all for a very few points.
Javad's Hybrid RTK now does everything we were doing in hours back in 2000 literally within minutes with a half dozen button presses. It's a sight to see, accompanied by very impressive results. I foresee some incredible processes that will be developed from this concept. Revolutionary processes. But if the wheel stopped turning with Hybrid RTK, it would be enough.
There were settings in a TDS ranger, that hinted of the inclusion of storing GPS Raw data, but there was where it stopped. (Or I misunderstood the settings). I tried to use them for a while. Called Tech support. They said that it was a manual process, where you pushed the button on the GPS receiver, to turn them on, and off. And, you had to buy Topcon tools, (Or run it in DEMO mode.) I actually bought memory, for my Topcon receivers, so I could do this. I did it several times. I discovered that Post Processed RAW gps data would provide more solid solutions, than RTK. I finally gave up. Too cumbersome, and set my offset nails, and carried a total station to alot of places.
My point is, I tried it, 10 yrs ago. Liked it. BUT, I was hampered. I never bought Topcon Tools, (post processing software). At the time it was another 2500$, and I sort of gave up.
I'm glad to hear that MR Javad has chosen to re-visit this concept.It is a sound one, with GREAT potential. I'm curious (as always) about data flow.
Will the post processed points get new numbers? Point Descriptions, and Heights of Rod?
I know there are logistics, and I know it's just around the corner. I updated my JAVAD LS yesterday morning, and to my surprise, the default setting for BASE setup changed to 1 second rate.
Technology is like a tree. It blossoms in the spring, and produces later. Many things have to happen, to make it all work. But, I'm excited to see it coming. I am an old L-1 Post Process GPS fan. The re-integration of these technologies, can only mean good things for surveyors. I try to keep an open mind, and an eye for simplicity. The simpler it is to get good data, the stronger our surveys will be.
N
Hey Nate, this is one of the really nice parts about the new feature. When you have more than one position option, such as RTK, Base>Rover post processed and CORS processed, for a single point, the software has a chart that shows you all three solutions in a table and on a graph. You see the RMS of each, the number of epochs, and the distance between them. You can select which solution you want. If you change your mind, you can return to the chart and select the other solution. If the real time position is float or standalone, and a post processed fixed solution is returned, the software will automatically select the fixed post processed solution (after all, why would you want to keep an autonomous position over a fixed solution?)
Typically, I think most will stay with the RTK solution, but the BP (base processed) solution will provide an extra level of verification to results. Points with too much variation between RTK and BP will be highlighted in the points screen. There will also be a filter that allows users to view only these points in the point list so that they can be addressed by the user.
The process is ridiculously simple. I could not be more pleased with how it is turning out. Beyond expectations.
Ok, when will this be available ? Is it part of the new update ? Inquire ring minds want to know :stakeout:
Thursday and Friday I had the pleasure of going to Arkansas to the Arkansas Society of Professional Surveyors Convention. The location for the conference was really nice, particularly for surveyors. It's in a remote area outside of Little Rock with a nice facility, well manicured landscaping, and a large pond.
Friday afternoon, I got together with Nate Dearyan and Steve Hankins, both surveyors who use the Triumph-LS. I thought that while I was there, we'd spend some time looking at some of the new features in the next release of J-Field.
We set up the base, a Triumph-2 with the HPT901BT spread spectrum radio on a retaining wall with a good view of the sky. We then walked around the pond and located three points, each with varying degrees of obstruction to the sky discussing some of the software changes as we went.
Point 1 was on a concrete slab with fairly open skies, point 2 was on a sidewalk passing under some deciduous trees, what I would consider light canopy, and point 3 was under the drip line of a 40' tall cedar tree with some pine trees near by, what I would consider moderate canopy. We shot these points for about three minutes each along with a confidence of 20, minimum engines of 2, and validation with 2 engines at the end. So it resets the engines at the beginning of the shot about 20 times, waits until it has 2 engines fixed and records until the time is up (3 minutes) and resets one last time with validate until two engines are fixed, making sure that the last fixes match well with the first 20 fixes.
We walked back by the base and turned the radio off. The base is still running, but I have no communication. We walked through each point and collected them again. This time we used the Activate Post Processing After button that counts up to a required amount of time and notifies the user when the time has elapsed. So now we have no radio communication, but the base is recording raw data and the rover is recording raw data.
We collected raw data using Activate Post Processing to let us know when we collected enough data and we used the "Save Data for PP" which replaces "Accept" when there are no fixed epochs to use for a position. We did this for each of the three points and returned to the base. We used base rover setup to stop the base and download the data from the base to the rover. The base was logging at a rate of once per second. From my experience I estimate that the Bluetooth download of a file collected at the base at a rate of once per second requires about one minute for every hour recording. We recorded for about one hour fifteen minutes and Steve clocked us at a little under one minute for the download. Next we went inside and did our post processing.
It took a few seconds, literally, to connect to the WiFi hotspot for the convention center with the LS. I then went to DPOS on the LS and set it to only perform base processing, since I knew that CORS data was not yet available. Within about 3 minutes, the data had been uploaded to DPOS, the vectors processed and the results returned to the LS. This is how each compared:
Notice that point 3 has a valid RTK solution and Post Processed solution, but J-Field elected to use the post processed solution over RTK. This is because the RTK solution has 173 epochs vs. the PPK solution of 180 epochs. Also notice that the RMS is lower for the PPK solution than the RTK. The user is absolutely free to overrule this and select the other solution by selecting the radio button next to the solution type.
Notice that 4, 5, and 6 don't have RTK solutions (the radio was off), so the solution was Code Diff (using WAAS). The software automatically selected the PPK solution for these points. The radio button identifies the coordinates that are used in J-Field, such as for CoGo, as well as export.
How about the inverse between the first pass and second pass?
The base was about 500 feet from these points, give or take, but I believe these results could have been achieved with the same short data sets in the same unruly conditions just as easily within 3 miles (perhaps more).
Many surveyors are buying big 35 watt radios for the rare occasion that they need the extra operating distance. From what I understand, these guys mostly need to locate a point (like a section corner) and don't need the range for stake out. I believe this Hybrid RTK will significantly reduce the need for a big radio, allowing users more convenience and less expense.
No one else has this. Post processing completely managed by the data collector. Javad has it because he listens to surveyors and he likes surveyors. His team works like magic. The crazy thing to me is that this post processing feature first appeared in operational infancy on February 21, 2016, in our testing versions. Today, a month and a half later, it's almost completely functional and works as if the concept has been in place for years. It's that well thought out, that mature. I'm just continually amazed by it. Every current owner of the Triumph-LS will get this in the next software update for free. It's actually available now as a testing version (but I would not recommend doing so as it the testing version may have bugs).
Randy Rhodes, post: 365983, member: 10669 wrote: Ok, when will this be available ? Is it part of the new update ? Inquire ring minds want to know :stakeout:
I don't yet have a hard date. It will be part of the next update, free of charge to current owners.
Shawn,
Steve is from Garland Co. and Nate is from Montgomery Co., but they should know that, by State statute, Pulaski Co. Is in the North Zone..;-)
I overheard quite a few conversations discussing your gear and have a feeling you will be making many more training 'road' trips to Arkansas.
Next time you visit with Steve, have him take you to Goose Pond Mountain and test the 'Beast'...
DDSM:beer:
Shawn Billings, post: 366364, member: 6521 wrote: This time we used the Activate Post Processing After button
There wasn't enough room on the button to name it "Activate Post Processing After Subsequent"?
Dan B. Robison, post: 366371, member: 34 wrote: Shawn,
Steve is from Garland Co. and Nate is from Montgomery Co., but they should know that, by State statute, Pulaski Co. Is in the North Zone..;-)I overheard quite a few conversations discussing your gear and have a feeling you will be making many more training 'road' trips to Arkansas.
Next time you visit with Steve, have him take you to Goose Pond Mountain and test the 'Beast'...
DDSM:beer:
I really had a great time there. I asked Nate and Steve which zone to use, they said it was really close to the zone line, so I just picked one. I really wasn't looking to share it, but it just turned out so well AND I had witnesses 🙂
Is Goose Pond Mountain where you found the cane poles on the top of the mountain? I've got to see that place.
I sure enjoyed listening to all of the stories. I can't tell them like you and Brooks can. That was gold.:beer:
Jim Frame, post: 366373, member: 10 wrote: There wasn't enough room on the button to name it "Activate Post Processing After Subsequent"?
I was a little brief on that, I suppose.
The settings actually read like this:
So the bottom left button dictates the "Activate Post Processing option after..."
In actuality, APP turns a black button on the action screen into a counter. Once you press start, the counter advances. It doesn't matter if you are receiving corrections or have any epochs clicking, the timer just continues to advance. Once the APP time elapsing, it makes a tune and the button turns to "DPOS". The time keeps advancing until you press "Stop" at the top of the screen. Then the button that would normally show "Accept" shows "Save for PP". If you press "Save for PP" a point is created according to all of the rules you know, you can even attach photos, voice and text notes before saving. If you reject the shot, the file is discarded. You don't need to have Raw GNSS Data set to save in "What to Record". This supersedes that setting. So if you typically don't record raw data, but you find that you really need to for this point, you can, without toggling Raw GNSS Data on in What to Record before hand. So if you're right on the edge of radio range and think you hit Start, and it ultimately doesn't pan out for RTK, you didn't waste your time. Since you hit the start button, a raw file has been recorded, ready to be stored if you want it.
Shawn Billings, post: 366377, member: 6521 wrote: So if you typically don't record raw data, but you find that you really need to for this point, you can, without toggling Raw GNSS Data on in What to Record before hand.
That's going to be really handy. There've been plenty of times that I thought raw data might be useful for a particular point, but didn't want to go back through the menus and change the "what to record" setting.
Shawn Billings, post: 366364, member: 6521 wrote: I then went to DPOS on the LS and set it to only perform base processing, since I knew that CORS data was not yet available.
This is going to be a really nice feature in my neck of the woods. I have seen an error when DPOS has not been performed. Is that because it automatically submitted as soon as I had an internet connection, and it knows CORS is not available for the session? So you can resubmit these files you show later for a better solution right? Also, can you change the zone after the fact for base and rover and resubmit?
Currently if I can't quite get a base rover fix position with the confidence I want, I will change the setup to static and occupy for at least 20 minutes for a rapid static submittal. I gather the improvement in method is that the software is deciding when it has enough good data for post processing, which may be less time than my arbitrary guess (learned opinion from similar conditions)?
One thing you did not mention, is that all your work shown above, was done with a monopod. So... It would have been tighter, if done with a bipod.
Also, I noted "tilt correction" was not turned on. As I gather it, the theory is that the wiggle of the pole averages out.
However, is think it may make the RMS value larger (depending of course on if you had 1, Or 3 cups of community dark roast coffee, that morning!) as far affecting the final outcome, probably not much. But it could affect the appearance, of the data.
And how would it have appeared if tilt sensor was on?
Those of us who were trained to do good work, with primitive means, we tend to meander through procedure, more than once, looking for meaning of small things.
:stakeout:To quote that great philosopher Freddy Mercury " I want it all, i want it all, I want it all, and I want it now "
Duane Frymire, post: 366398, member: 110 wrote: This is going to be a really nice feature in my neck of the woods. I have seen an error when DPOS has not been performed. Is that because it automatically submitted as soon as I had an internet connection, and it knows CORS is not available for the session? So you can resubmit these files you show later for a better solution right? Also, can you change the zone after the fact for base and rover and resubmit?
Currently if I can't quite get a base rover fix position with the confidence I want, I will change the setup to static and occupy for at least 20 minutes for a rapid static submittal. I gather the improvement in method is that the software is deciding when it has enough good data for post processing, which may be less time than my arbitrary guess (learned opinion from similar conditions)?
I'm not sure which version you are using, Duane. But if you are comparing DPOS in the current release version to the testing version, the differences are very significant:
- The new version will process the vector between the base and the rover. There is no need for CORS data for this process, only the base raw data file and the rover raw data file. Because the base is typically much closer to the rover than the nearest CORS sites, the time required for a solution, compared to CORS only processing, is much shorter.
- The software doesn't recommend a particular time, it simply notifies the user when a particular amount of time, set by the user, elapses. In actuality, even if the elapsed time doesn't transpire, the user can store the data anyway. The minimum timer is 5 minutes (300 seconds), but if you interrupt the shot at 2 minutes (120 seconds) you are presented the option to store the point with the raw data. For now at least, you will need to decide how much time is necessary on a point for a good post processed solution.
- Once the CORS data is available, the data can be resubmitted and the base shift the software has been performing for months can be done.
- Users can select which solution they have from a menu of options. Without any sort of translation being done to the base, the user has options for relative positions (REL) which are the RTK position and the Base Processed position. If a translation has been made to the base (or could be made to the base), such as CORS processing, Reverse Shift, the user can select which version of the base they want to hold fixed. So if you entered the base coordinates from a control sheet and sent the base file to DPOS for CORS processing, you can elect to keep the entered coordinate for the base and view the CORS processed position as a check.
- This version allows for users to process rover points directly with the CORS without the base. This requires a lot more time on a point than processing from base to rover and will probably not be used very often by users, but will fill needs by some users.
Jim Frame, post: 366387, member: 10 wrote: That's going to be really handy. There've been plenty of times that I thought raw data might be useful for a particular point, but didn't want to go back through the menus and change the "what to record" setting.
Another thing I'm sure you will appreciate, Jim. The settings can now be saved as Action Profiles. These profiles can be recalled with a couple of button presses. So if you have a profile for CONTROL and a profile for TOPO, then you may have your CONTROL profile set to record raw data and you may have your TOPO profile set to not record raw data (as well as differences in verification, time on site, number of epochs, validation, etc.) Changing from one to the next is very simple now.
Shawn Billings, post: 366584, member: 6521 wrote: Changing from one to the next is very simple now.
Which, of course, begs the question: available when? I thought it was supposed to drop last week. (Not complaining, just anxious to try it out.)
I done one today where it would sure be handy . ( hint, hint )
