Tag: RTK network

  • A Nationwide RTK Network: A Great Idea, But…

    Gavin Schrock, LS, is a licensed surveyor, technology writer, and administrator of the Washington State Reference Network, a regional cooperative GPS network (RTN) in the Pacific Northwest. He has worked in surveying, mapping, data management, and GIS for over three decades in the civil, utility, and mapping disciplines. He has published in these fields and has taught these subjects at local, state, national, and international conferences.


    Some folks are proposing that a nationwide RTK Network (RTN) be piggy-backed on the controversial LightSquared communications network. That could be cool, if it can be done. No one is saying that it can’t be done, but there are reservations on whether it would be worth the massive investments needed to pull it off, and that there might be little gain at all over the existing presence of RTN in the U.S.

    RTN are arrays of continuously operating GNSS reference stations that can provide correctors for high precision positioning. Centimeter positions instantaneously; imagine what could be done with a capability like that. People have not only imagined such things, but have implemented over 100 of these in the U.S. and over 350 worldwide serving industries such as surveying, mapping, construction, precision agriculture, science, machine control, public safety, precise navigation. If you feel you have heard all of this before, you probably have, and chances are you might have heard this from an RTN junkie like me.

    I am a strong supporter, even a rabid supporter and promoter of the expansion of RTN and the many benefits that can be realized where RTN exist. I have bored many people to tears with my idealistic ramblings about RTN, and have seized opportunities to jump on any bandwagon that promotes more widespread or even nationwide RTN (e.g. On-Grid Goal, GPS World 2006). There are many countries that already have nationwide RTN like Japan, Germany, Denmark, Greece, and many others; but under completely different circumstances, and none piggybacked on communication network towers. So why haven’t we seen a nationwide RTN in the U.S.? There are a lot of good practical reasons why this has not happened, and likely won’t. It is not a matter of a single design or business model issue standing in the way, and likewise the solving of a single issue will not bring the entire dream to reality. There are far too many moving parts to an RTN; hurdles that would have to be overcome to realize a nationwide RTN. Examining those hurdles might bring us closer to visualizing the dream, but perhaps instead we should focus on what is realistically possible and provide the best possible amalgam of many well run RTN to provide the same utility.

    The Nationwide RTN Carrot. In the course of the past year, and the LightSquared broadband plan interference controversy, RTN have been mentioned in the context of both a reason to oppose the broadband plan in question, and by others as a reason to support the broadband plan. Some have suggested that the LightSquared plan in question would be the catalyst for a nationwide RTN, as it could possible fulfill the crucial communications element of an RTN, and have touted this as a carrot for approval of the entire broadband plan. The idea of piggybacking an RTN on a communications network towers is not a new idea, and it has been studied seriously by many folks, including myself. There have been GNSS manufacturers and mobile phone service providers who have looked at this idea; but none that have acted on the idea; for good reasons.

    I would really like to see a nationwide RTN, but this particular carrot is not backed up yet by a credible plan that has been formally proposed and presented for scrutiny, it does look mighty tasty at first glance. Are there too many compound assumptions being made with regards to this particular carrot? Or is there real potential for a grand RTN? The controversial broadband plan asks a lot of people to sacrifice a lot in direct costs and lost productivity during transition; so the various carrots being touted should be scrutinized very carefully. The first glance look at the assertion that a nationwide RTN could be piggybacked on the proposed LightSquared LTE build-out does appear to provide two key RTN elements: secure station sites (perhaps as many as 40,000 to choose from) with power and low-latency communications for both stations and rovers. But are tower sites really suitable? And can it be done with the tower sites alone? Can it be done in a manner that would greatly improve the coverage of RTN and at a dramatically lower cost? Let’s takes a closer look at what it would take to stake a nationwide RTN on an array of wireless communication towers before we jump to any conclusions.

    Secure sites with power. Yes, the proposed tower sites are essentially cellular tower sites with fences and reliable AC power. But the assumption that one can simply rely on tower sites only applies to the limited area of the country that will be covered by the terrestrial component, the rest would need new stand-alone CORS sites to be presumably served by the satellite component of the plan (not a good idea and adds more infrastructure costs).

    Tower mounts. A communications tower is subject to movement, and therefore not a good candidate for mounting a high-precision GNSS CORS antenna. Even as little as one centimeter of incidental movement (and much more in high winds) is not only not a good practice for an RTN station, it would compromise the relative integrity between RTN stations and the resultant real-time solutions. If you expect your rovers to achieve centimeter positions, the RTN stations must be stable to a few millimeters. But don’t cell towers already have GPS antennas on them? Yes, but these are typically tiny little single frequency units used to time the communications systems where positional precision is not a consideration.

    Co-Location at Tower Sites. You will not find very many RTN stations co-located at wireless communications tower sites, and those that are have been placed on stable ground mount far from tower (south side preferred for maximum constellation) to mitigate as much multipath from the tower as possible. Most tower sites are not big enough to accommodate this. It may take a separate lease of a fenced area far away from the tower. This greatly reduces the number of potential sites.

    Leases. Wireless communications  tower sites are mostly leased from local land owners, and the towers themselves are often owned by third parties from whom communications companies lease space on the towers. The LightSquared plan is not calling for wholly-owned and leased sites; other parties and leases will be required. For instance, Sprint has been proposed as a LightSquared partner for providing tower infrastructure. Site and tower owners want to make money from their property. Towers = more ongoing costs.

    Site Geology. Potential RTN station sites are carefully vetted for sources of incidental geological movement. For example, alluvial fans or slumping slopes are not good candidate sites. An RTN serves as the active control component of a geodetic reference framework; and strict criteria are followed. Tower sites are not necessarily vetted on the same criteria. The potential site list becomes even more narrow.

    Interference. While sources of interference from other radio frequency appurtenances on the towers might not be an issue, then there is the question (ironically) of the possible LightSquared interference as these stations would be at ground zero. Assuming that there are solutions for what is referred to as the lower 10MHz plan interference, what of the upper 10Mhz plan? Recent lower 10MHz filtering tests aside, the upper 10 MHz band plan has still not been taken off the table. No one has demonstrated any credible filtering plan (even LightSquared admits this is still theoretical or at least years away) for the upper 10MHz. Would the RTN stations be immune to such interference? Depending on how the upper band issue plays out, this idea (and viability of every other every other RTN, not to mention all high precision GPS in the U.S.) might be dead in the water.

    Geometry and Coverage. RTN stations are spaced as close as 30km or as far apart as 100km depending on what type of solution is being sought, terrain and elevation differences, tropospheric trends, redundancy considerations, and site suitability/availability as outlined above. With the LightSquared plan proposing as many as 40,000 possible tower sites it would otherwise  be possible to find enough in densely populated areas of the country to have decent geometry and coverage, but only if all of the other design criteria can be met. The point may be moot as tower sites overall are not good candidate sites and won’t cover the majority of the country without adding satellite communication-served sites.

    Geodesy. If the relative positional integrity of an RTN is not maintained, and elements like plate tectonics and ocean tide loading are not taken into account, the resultant solutions suffer. Poor geodesy renders an RTN useless for high precision positioning. There are amazing tools for monitoring, maintaining, and updating the geodesy of an RTN available in some of the commercial RTN operations software suites, but this proposal would be taking on an unprecedented huge and expensive geodetic burden – even if a fraction of the 40,000 sites are included. The National Geodetic Survey maintains system of 1,800 CORS maintained by over 200 different partnering organizations. Even with the most advanced tools and some of the finest geodetic minds in the world, maintaining the geodesy of these sites is straining the NGS resources. The threshold for update on NGS CORS is when its network integrity exceeds two centimeter horizontal by for centimeter vertical; completely unacceptable for the relative integrity that RTN requires. RTN operators maintain registration to the National Spatial Reference System via constraining to a minimum number of CORS, but then have to maintain a further level of relative integrity locally for the RTN to run. A nationwide RTN would need to be run as an array of sub-networks for independent geodetic regions; some RTN have to do this even within a single state to accommodate regions of varied tectonic velocity. A small army of geodesists would be needed to oversee a nationwide RTN resulting in another significant cost.

    Ubiquitous Communications. The term “ubiquitous” gets thrown around a lot with regards to the current plan. Go online and look at a population density map and then look at any of your favorite cellular coverage maps. Now look at a terrestrial component deployment map (Source: TMF Associates) for the proposed network from October 2010. It does not cover huge areas of the country; instead the satellite component of the proposed plan would need to be used. RTN CORS do not need a lot of bandwidth, but they do need low latency communications. Satellite communications links are rarely used for RTN. An RTN might get away with a few isolated high-latency satcomm served sites, but too many clustered together in a network solution do not work. Also notice the population map and the coverage map of some common cell/broadband providers look very similar; the profitable areas are targeted. Many companies are steadily deploying LTE broadband (LTE was not invented in the past year). While the plan calls for providing services to an admirable goal of 260 million potential subscribers, the remaining 50 million plus in rural areas will be left out as they have been by other carriers, or simply served by slower satellite communications.

    Nationwide does not really mean nationwide in the commercial communications business, and that would be the same for RTN. Communications networks get built where the potential subscriber base can support the investments. The same can be said for RTN. You will find RTN covering the same densely populated areas, or over areas where precision agriculture is being implemented. There are actually RTN and arrays of single-base RTK stations in places that are not covered well by broadband and would not likely be covered by this plan or the others. In these areas radio and satellite-based augmentation systems are the cost effective alternative. Even though the communications component of the plan (that might arguably be more bandwidth and possibly faster or cheaper) will not be much more ubiquitous in terms of RTN functionality than what is available now, there would still be big holes in a “nationwide” RTN.

    Wholesale. LightSquared plans to offer wholesale bandwidth. This might equate to any number of retail providers offering the bandwidth through proprietary or open source communications devices. LightSquared is promoting this as “the dumbest of pipes”; essentially a great big pipe of bandwidth, which is a cool idea and prime for a wholesale model. More options for communications through these retailers might arguably be a good thing for RTN users, but not necessarily for any entity trying to put together a nationwide RTN unless there was some kind of exclusive deal attached. Competition can lead to lower costs overall, but subscriptions are typically what the market can bear and that might not be stupendously lower than what we pay now because everyone in between needs to take a cut. One strong point of the model was supposed to be unified communications for RTN, but instead we may be looking at a fractured element. The potential RTN operator would have to deal with as many, if not more, wireless communications providers than currently exist.

    But in another potential model, if the RTN provider were also a LightSquared broadband retail “reseller”, that might be a key to streamlining the model. However, if every end user was to buy the same units or brand with built in broadband receivers from one of the preferred retailers (wishful thinking), that would streamline the model even more. There are too many existing RTN (some free or at nominal cost), and too much legacy equipment out there to expect users to accept and rapidly execute dramatic upgrades, replacements, or carrier changes unless the full LightSquared plan is approved and they are forced to upgrade.

    The Elastic and the Brittle. I hate to rain on anyone’s parade, but RTN are not the dramatic cash cow one might imagine. The worldwide experience of RTN is very similar in that there is a limited market for network corrections. Even if one was to count on signing up all of the current RTN users in the U.S., plus all of the precision agriculture market (and a mighty hard sell that would be as they have made some huge investments in their own systems), it is still unlikely that there would be enough revenue to fund the initial and ongoing infrastructure investments, and to sustain the ongoing costs of operations, geodesy, leasing, maintenance contracts, and account management. If anyone is entertaining thoughts of consumers paying extra for higher precision on their cell phones and car navigation devices they might be greatly mistaken. The consumer seems quite happy with accuracy on the order of a few meters, and multiple constellations and  modernization will be providing higher fidelity to them soon enough. One wireless service provider even experimented with delivering corrections to mobile phone users from the national RTN where they are based and found consumers in their test group to be indifferent and even thinking it was a silly idea.

    Private RTN have spread across areas of the U.S., somewhat organically as opportunities arise, partners are secured, and where the market can support them. Public and cooperative RTN have spread in areas where the sponsoring entities can realize cost-benefits from their investments like a state department of transportation for their own projects. Public RTN have often filled regions where a private network may not have otherwise been cost effective. Together public and private RTN have covered a substantial area of the U.S. The nature of RTN in the U.S. is a healthy elasticity which fits the market and needs. With RTN being narrow-margin enterprises, this is a good thing. Developing a huge single entity RTN on narrow margins leaves the entire enterprise quite brittle. Investors might view areas that have a low or negative return as not worth retaining or even building out in the first place. The cards are really stacked against a ubiquitous nationwide RTN, unless as some assert there were elements of overriding public interest to justify some level of public investment or partnering.

    RTN Coverage of the U.S. as a percentage of Total Area

    Infrastructure Investment. Typical RTN stations have cost between $10,000 and $50,000 each to establish and sites requiring satellite communications start at a minimum of $20,000. Let’s say for arguments sake that only 10,000 of the tower sites were utilized, with perhaps just as many in satellite communications-served sites also needed. That might not even exceed the coverage of existing RTN. Even so, at $10,000 each, that is $100,000,000 up front; not to mention the satellite communications-served sites on top of that. Some may question those costs, so let’s break them down. A RTN receiver has to be dual-frequency, multi-constellation, geodetic-grade, enable remote operations, and be paired with a geodetic-grade antenna. Sure, used receiver/antenna pairs can be had for as little as $2,000-$6,000. Let’s say for arguments sake a manufacturer was able to build and sell (or essentially give away) a new unit for the unlikely price of $2,000, there is still the cost of a stable ground mount, conduit, enclosures, labor, site selection, engineering, fuel, logistics, and contract management. These would very likely add up to $10,000. But let’s say for arguments sake this could be done for $8,000. It would still cost $80,000,000 up front, and maybe triple that to add enough satellite communications-served sites. One would have to question the robustness and viability of an RTN built so cheaply. Realistically, it would be more like $100,000,000 to $360,000,000 to build out.

    Ongoing Costs. Break even operations costs for an RTN average around $1,000-$4,000 per station annually. This includes hardware replacement, software contracts, operations staff, geodesy, training, support, billing, leases, power, communications, data processing, and more. Again, for arguments sake let’s say on a grand scale that cost could be brought down to $1,000 per station per year, that sill represents $8,000,000 to $10,000,000 per year, but more realistically like $15,000,000 to $20,000,000 annually with double or triple to that cost for satellite communications-served sites.

    Pricing Model. The carrot has been touted with assertions that the services would be provided at dramatically reduced costs for both communications and corrections. No one involved would be expected to give anything away. A fair price for all elements would be exacted like it would for any other enterprise. For existing RTN, price is not typically what holds back potential customers. The RTN’s in the U.S. charge very reasonable prices, and much lower than some RTN in other countries. The limitation is the existing and potential pool of users as a function of geographic area. To operate an RTN at greatly reduced prices does not work because many public RTN that initially offered free services are exploring at least nominal fees for the future. It does cost money to run an RTN. Even if a new cut-rate nationwide RTN were to assume it could assimilate all current RTN users, plus a substantial segment of agriculture users, it is likely that the revenues would not be able to justify covering more area of the country than existing RTN already do.

    What do we make of this carrot?

    I completely welcome this idea for consideration, but it needs to be examined seriously before any speculative cost benefits can be added to the value equations folks are presenting as rationale for approving the LightSquared plan. There are a lot of unknowns about what folks have in mind when they tout this piggyback-on-LightSquared-nationwide-RTN carrot.

    Too many unknowns encircle this carrot. If a credible plan were offered up for scrutiny and proposed coverage were shown, all of the design and business model issues I’ve outlined were addressed, the FCC approves the LightSquared LTE plan and there were investors who were willing to see modest returns at best, then I would be among the first to jump on the bandwagon, sing praises, and actively promote the idea.

    However, in light of the tremendous uncertainty we face not only in considering this carrot, but the fate of the broadband proposal it serves to sweeten, touting of this particular nationwide RTN proposal must be viewed at best with a not insignificant amount of skepticism and perhaps at worst be viewed as somewhat disingenuous. The seed for this carrot has not yet even been sown.

  • LSAW Conference RTK Network Discussion Roundtable

    A couple of weeks ago, I participated in a roundtable discussion at the Land Surveyors Association of Washington (LSAW) annual conference on the subject of RTK Networks (RTN). Gavin Schrock, administrator of the Washington State Reference Network (WSRN), did a good job of selecting a number of industry folks who’ve got personal experience with RTN to be on the panel.

    I always enjoy listening to heavy RTK users about their thoughts, their procedures and how they arrived at them. We danced around a number of subjects with one being the “RTN’s biggest flaw.” My first thought was the communications link. That always seems to me to be the biggest problem with RTK in general. When it’s not working, the first thing I check is the communications link.

    “Wrong,” said the panel members.

    According to them, the biggest weakness of RTK/RTN is the vertical accuracy. They want vertical accuracy to be equal to horizontal. Duh, why didn’t I think of that? My only excuse is that I’m so used to expecting vertical to be 2x-2.5x worst than horizontal that I already have my expectation set and don’t see it improving until we have a lot more satellites in orbit that will bring very low VDOP values. But I guess if I really think about it, vertical accuracy is the Achilles heel (well, maybe behind the line-of-sight limitation).

    It was great to hear thoughts from real-life RTK users. Two panel members in particular espoused the value of RTK/RTN in their operations.

    Douglas Casement, PLS, a solo land surveyor using a Leica receiver on the Leica Spider Network, talked about the efficiency of RTK/RTN and doing projects in a half-day that would have taken a couple of days using conventional surveying equipment with a two-man crew.

    Mike McEvilly, PLS, works for a surveying/engineering firm in Washington State. He uses the WSRN for RTK corrections. He talked about using RTK on most of their projects in one way or another with the limitation being the vertical accuracy on some projects. I asked him if he had any problems with “brownouts” (lack of satellites), he said he didn’t, but then I found out he is using GPS+GLONASS receivers.

    Larry Signani, PLS, is responsible for the geodetic framework behind three RTNs in Washington State. He talked about how he constrains the networks and ties them into the National Spatial Reference System (NSRS). This is the behind-the-scenes grunt work that really makes an RTN perform. It really makes me wonder how other RTNs handle this.

    Gavin spoke a bit about procedures and the testing they’ve done, with RTN rovers, on NGS Calibrated Baselines (CBL) during the life of the WSRN. They’ve got a myriad of data that they’ve collected and used to develop their RTK operating procedures. It’s fascinating to look at the data they’ve collected…that’s another article altogether, but I will share with you a slide that summarizes their RTK field practice.

     

    There’s always been a lot of discussion about RTK procedures and occupation times. Last year, I wrote an article called “What’s Your Occupation Time?” that garnered quite a few e-mail responses. I want to address that subject again in the next couple of months.

    In the meantime, for those who haven’t read it, an extensive report was published by the UK Survey Association regarding RTK performance and procedures. I highly suggest downloading and reading the report. You can download it by clicking here. I would also suggest downloading and reading the National Geodetic Survey’s User Guidelines for Single Base Real Time GNSS Positioning. Although it doesn’t agree with the UK Survey Association on the time splits (the NGS suggests four-hour time splits) for setting project control, it is the most complete “RTK User’s Guide” I’ve run across. I think it’s a must-read for any RTK beginner as well as a refresher for veteran users.

    I could write a lot more about this, and will over the coming months. I’d love to hear about your RTK field procedures and how you arrived at them. E-mail me at [email protected] and let me know your procedures for setting control and topo surveying.

    Thanks, and see you next time.

    Follow me on Twitter at http://twitter.com/GPSGIS_Eric
    Edit: Link updated to User Guidelines for Single Base Real Time GNSS Positioning. Previous link was to a draft version of the document.

  • Survey Perspectives: RTK Networks Webinar Q&A Follow-Up

     

    I really enjoy doing webinars and the RTK Network webinar on April 21 was no exception. One of the reasons I really enjoy them are the questions and comments I receive because it gives me some feedback as to what the user community is thinking and wondering about. Clearly, RTK networks are a hot topic these days. The registration for the RTK Networks webinar was one of the highest in history for GPS World.

    If you missed the webinar, you can still download the file and listen to it.

    Now without further ado, following are questions that listeners sent in and my comments from the RTK Networks webinar.

    Question #1: Can you say anything about the proposed National Geodetic Survey Real-Time Networking (NGS RTN) guidelines?

    Gakstatter: The NGS is still in the early stages of developing the RTN guidelines so the agency would prefer public comment be withheld at the moment. It’s are working on guidelines to cover four areas: site considerations; planning and design; administration; and users. The agency has assembled quite a team of government and industry people to develop these guidelines. The team hopes to have draft versions ready by September 30, 2009.

    However, the NGS Real-Time User Guidelines (Ver. 2.0.4) is available to the public. Though these guidelines are targeted at classical RTK users (non-RTK network), it contains some solid procedures.

    Also, an interesting study was published recently by Newcastle University Civil Engineering and Geosciences specific to network RTK. Stakeholders in the report include The Survey Association (UK), Ordnance Survey (UK), Leica Geosystems, Trimble, and Royal Institute of Chartered Surveyors. They did some extensive testing and generated basic guidelines:

    1. Configure the rover according to manufacturer guidelines. According to the report, significant deviations from recommended settings can introduce unacceptable errors.
    2. Consider lowering the GDOP (PDOP) mask to 3 instead of 5. Generally, in a clear-sky environment, you’re going to get this anyway and it will increase the robustness of solutions in challenging areas.
    3. Pay close attention to quality indicators on the rover (for example, RMS values). They generally reflect actual performance of the rover. An RMS value more than 10 centimeters generally indicates there is a problem such as loss of ambiguity resolution or other satellite loss of lock. Those positions should not be used. However, in challenging environments (such as obstructed satellite visibility and multipath) quality indicators (especially vertical) maybe be “overly optimistic” by a factor of 3 to 5.
    4. The report commented on occupation times, which I’ve written about in a previous article. Using a 5-second average on topographic will reduce the effect of individual epoch variations.When vertical is important (as in establishing secondary control), two different sessions of at least 180 seconds should be recorded. The report indicated that a time separation between sessions of 20 minutes will yield an accuracy improvement of 10 to 20 percent. A time separation of 45 minutes will yield an accuracy improvement of 15 to 30 percent. A time separation of greater than 45 minutes did not provide “appreciable further improvement. This was very interesting to me as most guidelines I’ve read (including NGS guidelines) dictate a four-hour separation between sessions.
    5. GLONASS improves satellite visibility (thus increasing productivity), but doesn’t necessarily improve accuracy. *
      This conclusion doesn’t surprise me, but I think there needs to be an asterisk here since there are significantly more GLONASS satellites available now than there were a year ago. In a scenario where there are only five GPS satellites and four GLONASS satellites, my guess is that at least the robustness of the solution will be better, and generally the accuracy as well, due to the improved geometry (PDOP).

    Their recommendations make a lot of sense to me. Probably the most controversial is the separation time (45 minutes versus four hours) between sessions. This is against most standard practice that I’ve read, but then again I don’t have empirical data to support it either way, whereas the report does. It is clearly an area that needs a closer look. The time savings in the field could be reduced considerably for setting secondary control if this practice was adopted.

    Question #2: What manufacturers for RTK-network implementation would you recommend?

    Gakstatter: Well, there aren’t many choices. The market is dominated by Trimble and Leica Geosystems, with Topcon on the fringe.

    I don’t know if anyone can say with confidence which one is better from a technology standpoint. I’ve used rovers on all three networks and all seemed to behave as expected.

    Both Trimble and Leica networks have been implemented in large geographic areas (state-wide, country-wide) so they’ve experienced the growing pains and presumably have worked out any major issues.

    There are many issues other than which network software vendor you select. A big one is the information technology (IT) component. Without support from your IT department (or control over IT with a competent IT project manager), getting a network to run smoothly will be a really rough road. I don’t pretend to have gone through the process of setting one up, but I’ve talked to enough people to know this is a common theme among them.

    Trimble VRS

    Leica Spider

    Topcon TopNet

    Question #3: How different is the RTK processing for network versus cluster?

    Gakstatter: A cluster is essentially a group of reference stations set up in a geographic area. The user selects which reference station to use (usually the closest one) and receives corrections just like a user would from a reference station he set up himself. Communications from reference station to user is generally accomplished via UHF/VHF/spread spectrum radio or wireless network (GSM, CDMA).

    With a network, data is collected by all reference stations and sent to a central server where the data is processed; corrections are generated and sent to the user. Sophisticated atmospheric modeling is done and incorporated into the corrections. In theory, this eliminates distance-dependent errors within the network.

    Question #5: Does anyone know of any other published RTN user guidelines?

    Gakstatter: See answer to #1. The Newcastle University report is available here.

    Question #6: Could you talk a little about post-processing?

    Gakstatter: Well, it’s a subject worthy of more space than can be accommodated here, but it certainly has its place in setting primary survey/geodetic control and is the preferred method.

    Also, single-frequency GPS units are still the price leaders for entry-level GPS surveying. Even today, many people use GPS L1 units with post-processing for collecting topo survey data.

    Question #7: We are in Philadelphia and we use the Trimble VRS Network. We download and import a .dc file into Trimble Office. I don’t feel as confident using this network as I did when we got an OPUS solution and adjusted the base station. Procedure-wise, do you have any advice on how to capture the data? We are doing a morning session and an afternoon session and averaging the results.

    Gakstatter: I deferred to Bill Henning who is the RTK network specialist with the National Geodetic Survey. NGS has developed RTK user guidelines. Here is Bill’s opinion:

    “RTK will give you coordinate information and not much else. You can set the data collector to keep covariance records, which will allow you to dump the data in the office program and actually perform a tweaking of the coordinate positions if you have redundancy in some form (another location on the point of interest). I would never use just one RTK location for any significant point — there are too many variables. Any point that you will reuse or that is important in itself to the job should be located redundantly (see the summary table in Section V. of the single base guidelines).  Also, any point whose elevation is important to less than 3 centimeters should be leveled (or produced from a total station shot from a known point, and so on). In another vein, typical RTK accuracies (say 0.03′ horizontal, 0.05′ vertical) can be achieved through a localization to known and trusted passive monuments surrounding the project.

    My recommendation for a project site without existing trusted control would be:

    • Perform two OPUS-RS set-ups on the site control points. These would be 15-minute sessions staggered by 4 hours. Even better (but not usually in the cards), perform the second session on a different day and/or with different weather (still staggered by 4 hours, though). Site control should form a rectangle around the project with additional internal control for large sites.
    • Use the RTN to check values on the OPUS-derived coordinates. This is where the datums and epochs of the RTN come into play! If the RTN is using coordinates aligned to the NSRS within a couple of centimeters, all should be well (to that accuracy). Search for outliers. Evaluate these for the error source (user, OPUS, RTN) and correct or discard.
    • Perform a site “localization” to the site control from the RTN. This will let the user now use the RTN for internal work based on the site control as the “truth.” This is most important for the verticals. All features that require an elevation accuracy RMS less than 0.05′ (say 1.5 cm), should be done redundantly or better, by more precise means such as leveling or total stations.
    • Make sure of the integrity of the site control for future work. Points should be outside of the disturbance area with good stability.

    Question #8: How do you feel about the appropriateness of RTK for “boundary” locations? What QA/QC can be done in the field?

    Gakstatter: Many surveyors I know use RTK for setting boundaries. Some even use single-baseline RTK for this task, which is essentially just a radial survey (no redundancy). I’d say that almost all who I know that are doing this have used their RTK systems enough to understand the limitations. In fact, I think most have run RTK and total stations side-by-side on jobs to gain confidence and understand RTK in the field.

    I’m sure I’ll get blasted by some folks for not downplaying RTK for determining boundary locations, but I don’t think it serves any purpose to ignore what’s actually happening in the field. There is so much pressure, especially in these economic times, to reduce field time and increase efficiency that RTK ends up filling that need.

    At a minimum, I would occupy each point at least twice with the base station set up on two different monuments. If you’re using corrections from an RTK network, I’d occupy twice with a 4-hour separation between occupations (for example, once in the morning and once in the afternoon). I’d even dump the antenna a couple of times with each occupation to get two or three “fresh” measurements.

    The above assumes that you have a clear view of the sky (no blockage by trees or buildings), are tracking at least six GPS satellites, and have a PDOP of 3 or less. If you’re up against a tree line, tracking five satellites, and the PDOP is 5, I wouldn’t accept it even if the RMS indicators looked good.

    I’ll leave at that for now, as I could write a column just on this subject. I certainly would not support someone new to RTK to cut their teeth on boundary locations. I’d suggest building confidence and experience with RTK on applications where there is more wiggle room.

    Question #9: Could you address the ability of the RTK network or cluster to adequately service dynamic surveys verses static?

    Gakstatter: Dynamic is really the issue here. In my experience, there are at least a couple of issues to be aware of.

    1. There’s generally a “lag time” between when you press the button on the data collector and when the measurement is taken. I don’t have any empirical data on this, but it’s something I’ve experienced and I’ve seen that some make and models of equipment do better than others. If you’re moving at 8 mph on a 4-wheeler and the lag time between pressing the data collector button and the actual measurement is 1 second, you will travel approximately 12 feet before the measurement is recorded.
    2. A few years ago, a client of mine wanted to measure the acceleration of a vehicle after it was impacted by another vehicle. We determined that recording data at 1 Hz (one measurement per second) wouldn’t provide sufficient resolution. Nearly all RTK systems come preset to record at 1 Hz. However, most RTK equipment is able to record faster than 1 Hz. We ended up recording at 10 Hz (10 measurements per second).

    Question #10: It is possible to use a single-frequency receiver as a rover in the RTK technique, or it is a limitation?

    Gakstatter: I’ve got just a little experience in attempting to use L1 RTK on an RTK network. It didn’t work very well for me for centimeter-level accuracy, but worked OK for sub-foot accuracy.

    L1 RTK systems generally have some specific needs in order for them to work optimally. For example, some are able to utilize SBAS satellites as observables. RTK networks don’t support this type of observable (at least the ones I know of), so optimal performance from L1 RTK is achieved when the user operates his or her own reference station instead of using an RTK network.

    Question #11: You should discuss the advantages of using PPP if a reference survey monument is not available when setting up/initializing RTK.

     

    lign=”left”>Gakstatter: PPP (precise pointing positioning) is a very interesting subject and I intend to dedicate a column to it in a few months. In the meantime, GPS World Contributing Editor Dr. Richard Langley provided a column on PPP in the April 2009 issue of GPS World.

    Question #12: For the states out west, any challenges you are aware of in collaborating with the PBO on upgrading stations to real time and receiving the raw data?

    Gakstatter: Plate Boundary Observatory (PBO) has a tremendous number of reference stations in the Western United States, I think more than 800. I’ve spoken to a few different RTK network administrators in the Western U.S. who have incorporated PBO reference stations into their RTK networks. The general consensus is that PBO site communications is the major challenge. RTK networks require that the data stream travels from each reference station to the network server and then to the user within two seconds, so reliable communications is very important. PBO sites weren’t designed for this sort of communications in mind so that portion has to be upgraded in order for it to serve in an RTK network.

    For new PBO sites, I’ve talked to an RTK network operator who has collaborated with PBO successfully in building the site and including “RTK-network compatible” communications facilities during site construction.

    Question #13: Do you foresee penetration of GNSS RTK network technology in mass-market applications such as location-based services (LBS)?

    Gakstatter: Not in the near future. LBS are not yet as much about accuracy as they are about applications — mostly navigation, family tracking, and social networking applications but many more are to come. None of these applications require the high degree of accuracy that RTK networks are built for.

    Question #14: What is the estimated number of users in America? Say this year and three years later.

    Gakstatter: I don’t have specific numbers, but I would say that this is one of the fastest growing areas in GNSS. It crosses many different industries such as survey engineering, construction, mining, and agriculture. Also, machine control is expected to grow worldwide at a CAGR of 23%-28% in the next five years and real-time positioning is a critical component for this.

    Question #15: Does latency in cell signals affect accuracy in clusters or networks?

    Gakstatter: Yes, very much so. The industry standard latency ceiling seems to be two seconds from the time the data leaves the reference station, travels back to the server, is processed, then is received by the user. Any hiccup in the communications process will affect accuracy.

    Question #16: Our network recently performed a readjustment. This shifted the H by .08′ and the V by .10′. If you are using the network for real property boundaries, do you want to stay on a current epoch? Or have your property move with the crust, thus forcing recalibration on every readjustment?

    Gakstatter: Again, I deferred to Bill Henning who is the RTK network specialist with the National Geodetic Survey. NGS is developing user and administrator guidelines for RTK networks. Here is Bill’s opinion:

    “What has happened is either the RTN needed to be readjusted to be more accurate — due to new data, perhaps — or the RTN adopted a new realization [say NAD 83(NSRS2007) from NAD 83 (HARN)], or due to significant movement of the stations it was felt the coordinates should be maintained as current rather than at a prior epoch. For whatever reasons, you can see that the metadata on the RTN stations would be critical to consistent positioning. Because as the NGS CORS network is referenced to a particular epoch of time (ITRF 2000 realization of the ITRS at epoch 1997.0 transformed to NAD 83 realized at CORS adjustment 1996 at epoch 2002.0), with velocities supplied in both datums, the user can position from these stations to his epoch of survey by applying the shifts in coordinates produced by applying the velocities. All RTN should do the same.

    “We have been spoiled in most of the U.S.A. by having a datum that moves with us and therefore has little residual movement relative to our position. NGS is now moving towards adopting a true geocentric datum aligned either to a certain epoch of a certain ITRF realization and fixed on a stable North American tectonic plate, or one that will adopt the worldwide velocities referenced in the ITRS datum. To be consistent, surveyors (and all geospatial professionals) should be sure to provide the proper metadata on their work, which will state the coordinate datum basis, source of coordinates, epoch date of the coordinates, estimated velocities as published, and whether the distances reference grid or ground coordinates. They can opt to provide coordinates based on the epoch date of the RTN or they can provide them for the date of survey, but they must provide the metadata for those following afterwards — including planners, designers, engineers, GIS, and future boundary retracers.

    Question #16: Will network RTK win (render obsolete) or improve SBAS?

    Gakstatter:  I don’t think so. SBAS (WAAS, EGNOS, MSAS) was designed and built to serve the aviation community. That is a separate and distinct system that will be stand-alone. Aviation navigation system infrastructure won’t (and shouldn’t) share resources like we do in the commercial sector. Aviation navigation infrastructure needs to be a stand-alone system under full control of the governing aviation authority (for example, in the United States, it’s the Federal Aviation Administration).

    Question #17: Are RTK clusters/networks providing services for users that were once only available through the National Differential GPS stations?

    Gakstatter: Not really. NDGPS is one source of DGPS corrections. WAAS is another source, and there are also commercial DGPS correction providers such as OmniSTAR. RTK networks are one more that can be added to the list.

    Although RTK networks were created to provide centimeter-level accuracy. They are also able to provide DGPS corrections (sub-meter accuracy) like NDGPS, WAAS, and OmniSTAR. But unlike NDGPS and WAAS (which are free), it costs money to utilize an RTK network. Even if a subscription to an RTK network is free, the user still must pay for access to the GSM/CDMA network.

  • Survey Perspectives: RTK Networks: The Wild, Wild West

    What can you say about RTK Networks, except wow! They have popped up everywhere and continue on a path of rapid growth. In the last five years, I’d say it’s clear that two GNSS technologies have changed the survey/construction industry more than any others; machine control and RTK networks.

    As a follow-on to our GNSS Precise Positioning Market Report, Rob Lorimer and I have produced another market research report entitled GNSS Augmentation and Infrastructure. In addition to CORS, SBAS, and other infrastructure, it includes quite a bit of information about RTK networks, growth projections, and technology trends. You can download an abstract here. RTK networks is a very complex subject. A full discussion would much more space than this newsletter can accommodate. In that light, I’m going to keep it as simple as I can make it while touching on the hot points I’ve heard about and experienced.

    RTK Clusters vs. RTK Networks

    RTK clusters are a set of strategically spaced GNSS reference stations set up and operated by an entity within a specific geographic region. They were first conceived for the survey engineering industry as a solution to the headache of operating a reference station. RTK clusters provide single-baseline RTK correctors within that region. It’s worth emphasizing that it is a single-baseline solution similar to when a user operates his own reference station. By single baseline, I’m referring to the rover receiving correctors from the closest reference station in the cluster. If the user moves significantly within the cluster region, he must manually select another reference station. RTK performance in RTK clusters is the same as traditional base-rover RTK configurations, in that position accuracy is subject to degradation (“ppm error”) as the user moves further from the reference station being utilized.

    RTK networks are also a set of strategically spaced GNSS reference stations within a specific geographic region. The advantage of an RTK network over an RTK cluster is that the RTK network utilizes all of the reference stations, included in the network. Unlike RTK clusters, RTK networks are driven by a sophisticated suite of network software (such as VRS, SpiderNET/SmartNet, or TopNET). The network software significantly reduces “ppm error” that is introduced by the ionosphere, troposphere, and satellite orbits the further one travels from a reference station. In essence, if you are working within an RTK network coverage area, the distance from the nearest reference station becomes somewhat of a moot point, certainly much less of an issue than when discussing traditional RTK and RTK clusters.

    The graphic below illustrates a simple RTK network. Data is collected by the reference stations and sent to a central processing server where it is compiled, and correctors are sent to all of the rovers that are subscribed to and logged onto the service. The number of users using the service at any one time can be several hundred or more. In an RTK cluster, the graphic would look similar to below but without the central processing server. The data link to the user wouldn’t be from a central processing server but rather directly from one of the reference stations.


    Source: Trimble Navigation Ltd.

    The National Geodetic Survey published its latest versions of “User Guidelines For Classical Real-Time GNSS Positioning” in September 2008. It’s good reading for anyone using RTK and RTK networks. Appendix A of the document discusses RTK and RTK network testing done by the Vermont Transportation Department in 2006/2007.

    Another notable report that is worthwhile to read was published by The Survey Association (UK) and University of New Castle. It was conducted in 2008. It contains empirical data collected and analysis of RTK network performance. One particular point of interest in the report stated that using GLONASS observations do not improve RTK accuracy. I’ve always subscribed to the notion of “the more observables, the better” for RTK, because it improves productivity (field work is not shut down from lack of satellites). With respect to the accuracy, I think you have to take the above conclusion with a grain of salt. I’m not claiming GLONASS will improve accuracy, but I think we have to be careful using such a statement categorically. For example, would I rather use a five-satellite GPS-only solution up against a tree line vs. a five satellite GPS and three satellite GLONASS solution in the same location? I would choose the latter. Which would fare better with respect to accuracy? Well, satellite positioning accuracy is all about confidence and I’d have much more confidence in an eight-satellite RTK position than a five-satellite RTK position…especially when working up against a tree line.

    Evolution

    Before RTK networks/clusters were developed, all survey/construction RTK users had to manage their own reference stations (setup, manage, protect, etc.). Once this became accepted as mainstream technology, survey/construction managers began to understand the time investment, potential blunders, and risks associated with each crew operating their own reference station. The next logical step was for survey/construction managers to establish permanently (or semi-permanently) mounted reference stations in offices or temporary trailers with the antennas tied to the desired reference datum and a reliable power supply so one could merely “flip the switch” and be broadcasting RTK correctors within minutes. Risk of having a reference station stolen and risk of a blunder in the setup was greatly reduced.

    Permanently and semi-permanently mounted reference stations managed by smaller organizations for their specific application soon morphed into departments of Transportation and other organizations setting up a number of permanently mounted reference stations in highly populated areas that covered entire cities. These were the first RTK clusters. They broadcast RTK correctors similar to the way that traditional base-rover RTK users do…mostly UHF and VHF data radios which have a limited broadcast range. Also, these systems were still subject to “ppm errors” described above. These two factors meant that the permanently mounted reference stations needed to be located a relatively close distance from each other to ensure full coverage of the areas.

    Two technology developments enabled the transition from RTK clusters to RTK networks.

    First of all, mobile phone networks have experienced explosive growth in the past five years. This was critical in overcoming the distance limitations of UHF/VHF radios. Using a mobile phone network, I can log onto an RTK network 1,000 miles away. Granted, the positioning would be useless (way outside of the network) but my point is that it was a huge step forward in RTK communications technology. It’s true that mobile phone networks still don’t provide coverage everywhere that survey/construction people want to work, but they do cover a significant portion of it and, where they don’t, other communication technologies such as RTK bridges are being developed.

    Second, manufacturers such as Trimble, Leica, and Topcon began developing highly sophisticated RTK network software to optimize accuracy and reliability of positioning within the network coverage area regardless (for the most part) of distance to the nearest reference station.

    Who Runs the Networks an Clusters?

    Worldwide there are literally hundreds (maybe more than a thousand) RTK networks/clusters. The growth rate is astounding.

    Today, I would venture to state that all RTK systems setup by survey/engineering-based organizations are RTK networks. For example, departments of Transportation, survey equipment dealers, cooperatives, and even GNSS manufacturers set up and operate RTK networks.

    Here are some examples of RTK networks:

    Ordnance Survey (UK)

    Can-Net (Canada)

    ORGN (USA)

    Geotop (Italy)

     

    RTK clusters still exist. In fact, they are proliferating in the precision agriculture market. There are huge RTK clusters being run by agriculture equipment dealers and agricultural cooperatives. Cost is a major issue why RTK networks have rarely been installed for precision agriculture. RTK network systems are significantly more expensive and technically complex to install and manage than RTK clusters. Farmers are less apt to pay the higher subscription rates charged by RTK network service providers.

    Here are some examples of RTK clusters:

    Tri-State RTK (USA)

    South Plains Precision Ag (USA)

     

    Largely, precision agriculture and survey engineering/construction RTK systems are operated separately and independently. It seems odd that given the significant cost of the infrastructure that this wouldn’t be a shared resource. In many cases, RTK clusters and RTK networks overlap themselves.

    In rare cases, the RTK network owner/operator services both the survey engineering/construction and precision agriculture markets. Here is an example:

    eGPS Solutions (USA)

    Subscription Costs

    What are the costs of subscriptions to RTK networks and RTK clusters?

    The answer to this question varies widely. If the RTK network used public funding, many times there is no cost to subscribe to the network. However, the user must obtain a wireless network (mobile phone) data plan to access the network.

    If the RTK network is operated by a survey equipment dealer, there is a subscription cost that varies with each service provider that can run as much as US $500 per month per receiver.

    Subscription fees to RTK clusters are generally lower than RTK Nnetworks…on the order of US$1,500 per year.

    Where Are We Heading?

    This technology is developing and deploying rapidly and on a worldwide basis. Entire countries such as Croatia and Turkey have invested in nationwide RTK networks.

    I think it’s clear that RTK networks are the foundation of real-time precise positioning in the future. They will replace RTK clusters…or RTK clusters will be upgraded to RTK networks. There are just too many benefits for that not to happen.

    It will be interesting to see how the subscription rates are settled, as well as the competition between public and private networks.

    As I wrote in the beginning, this is a complex subject worthy of words way beyond what is written here. I only hoped to provide a broad view. For those of you who are interested, I’m conducting a webinar on the subject later this month, April 21. You can register here.

    Eric