- @tommy-young I guess because technically it does give them SPCS. Just there??s will be a little different from the existing control ??aka error and confusion? but as long as it doesn??t cause a major blowout then the PMs don??t care. ??It??s not a problem until it??s a problem? mentality.
Some say it doesn??t matter scale them from a map. Google earth etc. ?ÿI know of 10 boundaries right now that are signed sealed recorded that are a half foot delta in north and east or way more. ?ÿFrom being in the correct location on the datum and projection. I will not even go to the fact the reason of this of using a grid ground scale not documented.
That??s similar to contractors using tax maps to determine where the boundary is for construction. Lol
* In regard to session duration. *
"An optimal real-time observation duration was found in the range of 180 to 300 seconds."
I totally agree with this because I keep a close eye on changes in horizontal and
vertical residuals, and ninety percent of the time there are no changes in either
after 180 seconds.
* In regard to distance from base station. *
"By keeping the rover in close proximity with the base (e.g., within 10-20 km), errors such as
ionospheric and tropospheric refraction nearly cancel during differencing of the observables (Janssen et al. 2011)."
"Real-time networks (RTNs) are often utilized to overcome these limitations by utilizing a network of permanent reference stations."
How does operating at a distance of greater than 20 km affect connectivity? There are times when we get a number of "Switching base stations" messages on the DC. Does that mean we're at about a halfway point between two base stations?
* In regard to single base line (SBL) versus multiple reference station (MRS) settings on the DC. *
Since we're using an RTN, should we be using the MRS setting?
I told one of my helpers a few months ago that 95% of the problems in our company were either due to a lack of communication, or a lack or training.?ÿ Survey technicians turning on their magic box and using whatever coordinates it spits out has fallen under both categories with my people.?ÿ I am pretty sure that now the problem has been rectified.
@field-dog ?ÿTechnically VRS was and might still be a Trimble copyright term for virtual reference station. Network RTK should be used as a term like GNSS for all satellites positioning. So vrs was might be for Trimble smartnet I think was the Leica propriety but could have been just a local name. Topnet was used by topcon folks could be more. Geo++ had something ftk I can??t remember they had there little magic. ?ÿThere was something used out west that instead on the server end was on the user end to solve maybe a university or geodesist created to do positioning. It??s con was doing topo and stake out. It showed very good potential in control work with rtk type set up. Vrs has become a general word that probably should not be used generally when referring to all networks of rtk but like anything it??s what happens overtime. Like message types cmr was for a bit Trimble only cmr+ now cmrx etc. rtcm and rtcm xx were created so any receiver could use a standard instead of proprietary. Like rinex files a way that any raw static data can be used instead of each manufactures proprietary file format. Same with ascii files crd carlson. Csv txt anyone can use.
So??Network RTK would generally encompass all VRS, Topnet, etc.?
what about RTN?
@on_point if RTN means real time network then it would encompass vrs topnet etc etc also the density of the network and if it is doing modeling of ionosphere troposphere etc. or it then even if it??s permanent just becomes single base or classical rtk even though your still connected via a cell or mifi sim card. I am sure topnet and Leica software are doing some modeling of ionosphere and troposphere . I am not as familiar with those. When Trimble first started they had a gps base software. It was single base but allowed the user to choose the closest base. So it was appealing to users because now they did not have to by anything but a rover so no base needed as long as they had a base station in their work areas. ?ÿIt could cause some issues because you could resolve the interger ambiguity (AKA fix rtk) much further than a typical radio could go. Depending on terrain etc. but some did not understand why they didn??t have the repeatability like they saw with a radio. They didn??t take into consideration the ppm x??s the baseline lenth. Nor the fact that the troposphere could no longer be assumed to be identical at the base and rover. They had the vrs about the same time. It was a different system prior but a lot of counties cities went the single base route it was much cheaper and fine for most gis inventory work. Vrs is good but it has its issues as well. Nothing is perfect. ?ÿVrs set up correctly managed correctly is an awesome solution and can be very accurate and precise. But it takes more than just randomly placing stations up. It requires planning and understanding of error sources. Things that effect gps now gnss. Also requires a lot of work on both the network side and user side. Keeping firmware in receivers updated on both ends. Using good procedures etc. we exhausted a lot of man hours in training educating and constantly checking ground proofing the network all over the state. I spent at minimum a half hour daily checking all manufacturers receivers firmware and software and reading release notes on bugs and such. We sent weekly and sometimes daily emails and news letters out making sure our customers knew of anything that could cause them problems. The hardest thing was telling a customer that there firmware had a documented issue and now they had to pay money to upgrade. We had nanu reports collected solar activity to keep our clients informed. We committed with cell carriers to stay on top of issues of outages latency problems. All of these and more went into making sure our customers did not fail. I don??t know how many private or public network providers do that now days. We operated 24/7. I don??t know how many hours I spent supporting clients on surveys while they were doing surveys on airport. 2 3 am we were available to receive a call. The recession might have saved me lol. I literally slept with a laptop close by so I could support the customer if they had issues. I could log in and check our server??s software while walking them through things on their end. That was 2006 2009 ish time frame. So a lot could have changed by now. Where i am now we have a subscription to a network here but i have not seen the repeatability not even close to what we had years ago. But it??s about the spacing of base stations and geometry I personally believe. And totally different environment. What it does well if i know where i am is it is on datum very well. No doubt about that. So depending on what i am doing i can use it to get on datum then use base and rover to build a network for least squares on site and achieve the relative requirements i need for the task at hand.
So depending on what i am doing i can use it to get on datum then use base and rover to build a network for least squares on site and achieve the relative requirements i need for the task at hand.
IMO that is the best method to get consistent results on the job.?ÿ
I??m mostly familiar with using Trimble VRS which seemed to have a horizontal accuracy of .1?? and vertical of .2?? although I??ve had the vertical blow out more occasionally. I think usually the DC was set up to automatically select the closest base station. Also, I have seen VRS switching base stations jump around almost .1??.?ÿI??m using Topcon RTN now so maybe it??s more accurate. I have heard though, the further you are from the base station the more prone to accuracy issues.?ÿ
@on_point well a few things on VRS. It can be set up on network side to recompute a base station based on distance from rover. In other words it can compute a new base virtual base every 100 ft from rover or further. Or shorter. These were the things we had to figure out when we ran our network. We had to find a happy medium of cutting down ppms and not having a data collector bugging the user every time they took a step. Now for vrs you can set up your controller if it is Trimble access or survey controller software for vrs cmr vrscmrx rtcme vrs etc. but the network side has to be ready and designed for that as well. I don??t know why you saw a tenth by two tenths often. I could see better than that with a 5800 receiver and gps only if i used best practices and watched what i was doing. Now the vertical blowing out a few things come to mind. Your in a area that was hostile aka multipath or poor vdop. Or no gps satellite above a 65 degree elevation close to vertical above your location. These are a few things besides latency on cell provider you can watch. ?ÿNow on network side. They can have latency issues as well from the base stations that surround you via internet. To the server and such. A station itself can go offline in the middle of an observation and cause issues on user end. A router bogs down or jams up. (Technical glitches I don??t know the correct terms of these issues) now early on i saw more vertical issues when we incorporated glonass with gps. When I personally was concerned with vertical at that time i would turn glonass off. This was years ago now so things have changed. I have not studied nor tested a full gnss system in a way yet I would feel comfortable in stating issues. ?ÿTopcon was a big pusher for years on glonass. I will state this glonass got more people in situations they should have never been in using rtk than it benefitted them . It was over promised and under delivered. This is my opinion and I still hold that belief today. And i know way more now then i did back then. What i have seen is with a base and rover full gnss it blows me away and i have pushed rtk in places I would have never done before. But I check it against a robot trig levels and multiple observations from areas i know have good gnss data. With a old 5800 I would easily be confident in setting control and knowing i was under a tenth horizontal and no more than .15 vertical but that??s was 180 epochs and at minimum 2 observations 4 hours apart. That was years ago on a network i knew very well. Topo shot stake out nope not that tight but i did feel comfortable doing topo and stake out if i could live with a tenth or so hz and a couple tenths vertical. If I needed better I would re observe. I think today??s equipment can achieve better if used properly. ?ÿA friend uses a topcon network and topcon receiver. They stake pipes drainage all the time curb and gutter etc. but thats on sites with relief that will allow it . They spot ck with a level or robot in critical areas . ?ÿWe have so many tools in surveying now days we just need to understand each one and weigh that against what we are doing and job tolerance requirements. ?ÿAnd state standard requirements. Gnss is a tool no different than a claw hammer or sledge hammer. I use claw hammer and sledge depending on site conditions dictate. Hard ground sledge soft claw hammer. No need for me to tote a 8 pound sledge to place a stake in 8? of mud. No need to tote gps if i need only a 100 ft tape to drop a couple stakes on an offset for a contractor to get a machine through. The robots today have all but replaced a level. I imagine their are surveyors here that did something like this for years. Go out run a traverse. Then run levels through all traverse points then begin topo or staking. Now I could take a total station and shoot distance 3000 feet. But trig no way. Yes I could look turn angles but vertical was not going to be good. I see people now trigging elevation 800 plus feet. And believe its good. Maybe but anything tight i would not curvature and refraction is real. The multitrack Trimble prism has like a 14? sighting spec so math doesn??t work. Now what do i need a gs on a farmer??s plowed field sure i will trig a shot and not worry. Stake out concrete no way. Take your rtk. Shoot hub and tacks randomly around a 10 to 80 foot area then tape between 15 or 20 of them with a good steel tape set a level up get all the height differences do this a few times over a week. Then you have a little sample test of data. Do it at different times of day keep a time log notes log about pdops vdops gdops any weather etc. a little test like this will let you see some things of error. Now in a network rtk you should be checking on new job sites new areas to see how it performs. You are actively seeking knowledge you will be fine keep learning keep learning.
I??m mostly familiar with using Trimble VRS which seemed to have a horizontal accuracy of .1?? and vertical of .2?? although I??ve had the vertical blow out more occasionally. I think usually the DC was set up to automatically select the closest base station. Also, I have seen VRS switching base stations jump around almost .1??.?ÿI??m using Topcon RTN now so maybe it??s more accurate.
Considering the myriad ways in which operators may set up their network, it's impossible to make a statement such as "XXX brand RTN software is XXX accurate".
While there are certainly differences in how each network software solution crunches the numbers, there are several factors which have far more of an impact on position quality, such as reference station spacing, installation and communication design of stations, constellations being used, location of network (iono varies considerably by region), Internet and cell communication speed, broadcast methods made available by operator, correction method being implemented by user, etc. etc.
I have heard though, the further you are from the base station the more prone to accuracy issues.
Single-base RTN solutions are just like working with a standard base. With a network solution it's less about how far you are from the nearest station and more about how well you are surrounded by stations, plus their average spacing relative to each other.
@rover83 very true.
They didn??t take into consideration the ppm x??s the baseline lenth.
I'm unfamiliar with what the baseline length is. Please explain.
All I??m saying is most of the time VRS was good but every once in awhile it would blow out (usually the vertical) and it??s the every once in awhile that gets you. If I??m doing work that??s several miles long and is elevation sensitive, I would rather use rtk and leap the base as I go to lessen the possibility of an elevation getting blown out. Also, I maybe misunderstood what you are saying but, by the time I check the GPS with the RTS I might as well just set up the RTS and get the job done. For me, any precision work I just use the RTS since it doesn??t care about bad satellite geometry or multi-path. Say I need to do layout for a SMH I would set two control points (3min observation) with rtk and set up the RTS and stake the MH hub offsets and elevations that way so everything would be relative to those two points. I suppose I could set the two points with RTN and set up the RTS since everything would be based off the BS elevation anyhow so long as I use the same setup later for repeatability. If I was matching into an existing system I would probably match the rod height to a known existing elevation before I did any layout anyhow.?ÿ
If I??m doing work that??s several miles long and is elevation sensitive, I would rather use rtk and leap the base as I go to lessen the possibility of an elevation getting blown out.
If a project is elevation sensitive and is large enough to require multiple base setups across the area of interest, for control work I'd rather stick with a static network and actually make direct connections between adjacent stations. Faster, easier, and better results. Especially with the number of inexpensive static-only receivers out there.
But if it's just going to need total station and/or level work throughout anyways, I'd just as soon stick with NRTK tagging every 3rd, 4th, or 5th point that is getting redundant TS observations as well. Levels if elevations are really critical.
As someone who really likes and strives for network accuracy, it pains me to say this, but for 99% of such design projects, the GNSS vectors are mostly just there to get the project roughly oriented with respect to a geodetic datum. Network accuracy is far less important than local accuracy; terrestrial observations will take care of the latter, and ensure that everything is locked down vertically.
?ÿ
For staking, if it's going to be GNSS and needs to be any better than a tenth by two tenths H/V, I agree that base/rover is the way to go.
?ÿ
If I was matching into an existing system I would probably match the rod height to a known existing elevation before I did any layout anyhow.?ÿ
Site calibration with just a vertical shift. Having crews "cheat the rod" to match a vertical datum is rolling a loaded pair of dice. Ask me how I know...it's certainly less of a likelihood if you'll be the only crew out there, but I've seen that procedure go sideways many times.
For staking, if it's going to be GNSS and needs to be any better than a tenth by two tenths H/V, I agree that base/rover is the way to go.
?ÿThe gravity system is a lot more sensitive to elevation than horizontal precision. If a MH is a tenth off horizontal no one??s really concerned but if it??s a tenth off on vertical they get a little excited. Now if your hubs and tacks are off on horizontal or elevation they start asking questions which is why I use RTS for layout so it all matches the best possible.?ÿ
Site calibration with just a vertical shift. Having crews "cheat the rod" to match a vertical datum is rolling a loaded pair of dice. Ask me how I know...it's certainly less of a likelihood if you'll be the only crew out there, but I've seen that procedure go sideways many times.
Typically try to send the same crew each time. Again, if the contractor sets up his level and checks your layout with a known existing elevation, say a BM on an existing MH, then it needs to match the plan elevation. I??m not sure how calibrating the rod to an existing elevation and matching your hub offsets to that elevation would be any different then using the level to do the same.?ÿ
Everything should be within plan tolerances whether the contractor is going to check it or not.?ÿ
Calibrating the rod is a nice way of saying fudging the rod height to match control, thereby saving a few bucks.?ÿ
The professional in responsible charge has a right to operate their business as they see fit. Based on what I??ve seen once someone heads down that road they don??t turn back unless it bites them in the arse.
@field-dog ok i will try to explain this two ways. Start with a regular old total station as an example. The specs of say XX total station has an edm (distance spec) of +/- 3mm + 2ppm. So the 3mm plus the scaler of 2 ppm x distance is its specs. On a rtk recievers or any equipment you have a spec as well it usually has a constant of say 8mm but also a ppm value. Depending on hrand specs etc. ?ÿthese specs are all in a perfect world perfect conditions. ?ÿSo the baseline length not stated very well by me. Is the distance from the base station to your rover just like the distance from your edm total station to prism. This can be for a single base or virtual base. ?ÿThe ppm scaler can be cut down in some instances if modeling of the ionosphere and troposphere is done. In classical rtk the base is dumb it just in a very basic sense just gives delta corrections out to rover it has no idea where the rover is. The rover algebraically just eliminates/cancels the variables. So it ASSUMES all conditions are same at base and rover. In a RTN real time network the base is no longer dumb as the RTN software knows where you are located. (In most cases ) this gives the software ability to model in real-time a large area and for ease of this the triangle of surrounding stations your rover is working. This modeling is on the ionosphere (space weather) troposphere (our rain etc weather). A neat fact. Weather folks can use the error sources we as surveyors model out to track weather space and on earth fyi. ?ÿSo all of that to just say base line length in this scenario is distance along the vector/ slope from APC of base to APC of rover.