"GPS does not work in the woods".
This has been published and preached by mpost manufacturers. And for good reason. GPS in the woods, lies to you, a certain percentage of the time. So, in the woods, or multipath environment, it MUST be checked. And, rechecked.
And, SOME surveyors did not listen... Off to the woods they went. (Me and a few others)
Light canopy, and it worked, pretty good.
We played with it. It often varied by a tenth, or two, and sometimes threw us an outlier. 7,5 feet away, or thereabouts.
We learned our own statistical methods to check it. Move over 5 feet, or 10, and reshoot. Check it with compass and tape. Between shots, intentionally set, to catch multipath generated bad initalizations.
Or, change rod heights. Or both. Or come back, an hr later, or 3-4 hrs.
Now, there was a GPS manufacturer who LISTENED to all this stuff about how to QUALITY CHECK a woods mulipath shot. He automated the above process.
How stringent you quality check it, depends on how critical the shot is, and such.
So, to abreviate all this, here is a typical method, for getting a shot in the woods:
Set the Javad LS on the needed corner. It has 6 engines.
Set the settings:
1. At least 3 fixed engines.
Fixed, and reset, at least 25 times. (Or some similar value)
Then occupy point for at least 120 seconds.
Then, do another 10 resets. If they all agree, now you can save the shot. All automated. (This can often happen in under 3 minutes, I will add.)
In a pretty bad environment, you could sit there for 10 min or more.
If you sit, for more than 5 mins, it automatically begins a PPS Shot. Post Processed Static. However, it also begins this shot 5 mins earlier! (It has been doing it in the background) so, you finally get your rtk shot. You are on this point for a full 9 minutes.
But, it has a fairly high RMS value.
Go to the next shot.
Get home. After GPS midnight. Dpos it. And, along with your dpos, you get a full PPS Shot, that is 9 min long! And, it has a 1 second interval. So, it has 540 epochs, (or pretty close to that). To post process.
You get back from dpos a position, that may differ from the rtk shot, because it was a 9 minute long shot. Post processed.
You get to compare, and select what to use.
And, you have spc coords on all your work.
Welcome to modern GPS surveying!
Its GPS, to the max.
I think this equipment will appeal to the practitioner, who is already aware of, and doing those quality checks.
Those who are not doing them, well, it can bite you. Also, it's obvious that this PPS workflow method will work well beyond radio range.
Now I have a few questions for the Javad people...
If we "reverse shift" a point beyond radio range. (This is akin to wiggling in with a total station, it backs in the base station coord, off of a point, that already has spc established on it)
Can we also use this beyond radio range, and use our cell phone, made into a MiFi device, to access the internet, or would the base file, for dpos be too large to handle it?
And, since the base will fill up faster, at the 1" rate, should we delete old files... Or will the oldest files delete automatically?
Is there any merit to archiving the old base files? Will it warn you, if the memory at the base is getting low, so you can delete them, to make room?
I'm maybe asking questions that are not fully settled, but when I get buried under 30,000 coordinates... Its nice to know what kind of direction is being thought of.
I guess primarily what to do with old base files. Are they any future worth?
I will say, I love my new Javad.
A company that listens to surveyors, is going to get my approval.
Nate
That's a great summation, Nate. And I agree with you on the verification process. It's the core, in my opinion, of the software and it makes use of the core, in my opinion, of the hardware - those six engines you mentioned. The software and hardware are dancing together to deliver a quality coordinate at the end of collection.
Regarding the new Hybrid RTK...
It uses DPOS, but doesn't have the restrictions that DPOS has regarding GPS midnight (midnight UTC). As soon as you finish collecting the raw data at the rover on a point, you can return to the base, download the base file (over Bluetooth) to the rover, connect to the internet and send the files (base and rover) to DPOS. This is what we did last week in Arkansas. The internet connection can be over WiFi (like we did) or by MiFi, or by SIM in the receiver itself. I've done this literally while standing at the base. When you get the solution back from DPOS, you can then use the point for Shift. Shift is changing from its current methodology to something that will work with already collected points and will allow you to use multiple points. It's like localization, but doesn't produce a new coordinate system and it only includes translation (as far as I know - I hope to test that today or tomorrow).
The current DPOS was processing CORS to the base, like OPUS, and making the shift automatically from an autonomous base position to a CORS related base position. Because of the need for CORS data in this scenario, and because the server used by DPOS to gather the CORS data updated at GPS midnight, the user had to wait until then to get a solution for the base. Hybrid RTK is processing base to rover and doesn't require the CORS data to produce this vector, so it can be processed immediately once the base and rover data have been collected and uploaded to the DPOS server.
You will need to perform file maintenance on your base periodically. It has a lot of memory, so it will hold many days of static data. The LED's on the Triumph-2 will warn you if the memory gets full. Once the base file is downloaded to the LS, the data resides in the LS. If you will create an archive of your project, using the archive project button in files, you will have a zipped file that contains all of the raw data for your base points and your rover points. This is the perfect way to keep these files for future use.
Nate The Surveyor, post: 366571, member: 291 wrote: ...what to do with old base files. Are they any future worth?
Each project gets a directory, and each directory gets a subdirectory named "Raw Data"(or some such). Put your base files in there. You may never need them, you may reuse 1 in a 1000. But you should always have your raw data backed up just on general principles, IMO.
I have a cop buddy, who used to stop by occasionally. He told me something interesting. In a modern police cruiser, they have a number of cameras, standard. Pointing in various directions. They are running all the time.
When it runs out of room, it automatically deletes the oldest files. If he turns on his blue lights, it automatically puts an "event marker" at 5 mins before the strobe lights were turned on. And, it runs until 5 after they are turned off. (He did not want me or the kids playing with his strobes, for This reason....)
The LS does sort of the same thing. Press start, at the beginning of an observation, and it immediately begins a raw data file, for PPS. If you don't press store, for 5 mins, then it automatically begins the raw file, at the initial button press. And, it runs, until you press stop, or save, or the like.
So, watch this.
You are in a sort of poor environment. You set it up, with a bipod, press start, and your client walks up. You wind up spending 15 mins with him. The LS was set to store after 120 seconds. So, the rtk observation was done in 3 mins. A pretty good shot.
BUT... It now has a PPS observation, that is 15 minutes long!
No need to re-observe that one. Just do the PPS later, and compare with the rtk shot later.
Without this feature, you'd have 12 mins wasted. (15-3) with this feature, you have no time wasted.
Cool, huh?
N
Shawn, I was not saying you could not "process against the base" in the field... But I was saying that as a normal work flow, you *might* do it later, so that dpos, and your PPS Shot were done together.
Both options.
More options than Carter has pills....
🙂
N