A 872Kb PDF of this article is available by clickingHERE
Tips and Tricks (Confessions of an RTN Support Dude)
Optimal use of an RTN demands solid user support. Typically, the equipment vendors support the users on equipment configuration and field use, the RTN administrators handle inquiries about network status and account administration, the user can also tap web-based information and tools, and professional associations and academia provide training on field procedures and the underlying geodesy.
Okay, I am dreaming as I write, but for the most part this model is working well. As RTN is a new tool, particularly for those of us in the U.S., in many ways this is the first day of school for all of us. The distribution of support and expertise to tap is not as well defined (or executed) as it could be.
Roles get muddled in the beginning, and more often than not, the network administrators take the brunt of the support load ("blame the network" is the mantra). In some ways this is a good thing, as the respective support staff can start to accumulate a knowledge base of user inquiries, conundrums, crises, and angst; good educational experiences for both user and support staff.
Support people have to put themselves into the shoes of the users, who have possibly made a substantial investment in equipment, stuck their necks out, and possibly put their jobs on the line in proposing the use of this new utility to their bosses. A little bit of panic may be detectable in the support call. The job of the support person is firstly to calm the user, then to step through a logical process of elimination to solve the issue. If this is done well, then the user will simply follow these steps independently in the future.
Every network needs a "Dave" (or "Davette"), the calm support lead who can provide consistent service even in the face of some of those "DEFCON 4" level support calls. As an example, we would like to introduce one of those Daves (who incidentally is named Dave, or "The Dave" as some call him). Dave Hildahl has been the primary support dude for the Washington State Reference Network, an RTN cooperative of 50+ stations and 300+ user accounts. Dave has been compiling some of his favorite user tips and tricks (and a few for network administrators). He’ll even impart on you the internationally acclaimed "Dave Method"…
User Calming Techniques
Besides the obvious of keeping a level tone, it’s best to remember that the person is frustrated (duh) mostly because he or she has been trying for some time to get the system working before calling you. Usually by this point callers are ready to toss the whole idea of RTN out the window and pull out a chain (with which they might possibly consider choking you or the folks that sold them the equipment). Getting them to relax can be difficult, but I usually make small talk while I access the network administrative interface. Letting them know you’re doing this is a good idea, too, as is sometimes joking about the wonders of technology. Treat the situation seriously and act in a professional manner without the humor if you have to. They may get foul with you, but it is not personal.
Communications
Cell phones work when they want to work. You can have a dedicated data phone or one that does both voice and data. I like to carry more than one carrier’s phone so that if I can’t get good signal strength from one I have a good chance the other carrier will have better signal strength. I also use maps downloaded from the Internet that show a carrier’s "general" area of coverage, I say "general" because in a major metropolitan it can be quite accurate, but out in the more rural areas they tend to be a little optimistic as to how well they cover a given area. It is a good idea to research some of the other options like satcomm, radio relays, cell cards, Wi-Fi, Wi-Max, other wireless Internet, etc.
Accounts & Access
Some of the trouble that comes up in this area is simple confusion as to where to put the user name and password on the data collector. More times than not I have a user who puts the user name and password in when asked by the respective communications connection login. Some cell carriers do require a user name and password, but this is generally a one time input done at setup. The other item is letter case. Many surveyors are used to inputting data in uppercase. Add to that the fact that the system is case sensitive, and we simply put their user names and password in uppercase. (When I get a help call, one thing I ask is, "Are you typing that in upper or lowercase?") And even though we like to secure our identities today, don’t make the username and password too complex. Although it might keep "the bad guys" from figuring them out, odds are you will forget the clever Fibonacci sequence you dreamed up months before.
Rovers
Like many other administrators, I may only be familiar with a limited number of brands and models of rover gear (remember, that is supposed to be the responsibility of the folks that sell you the gear). Or, I may have only used a limited number of cell carriers or other communications methods, but login and account problems we run into with rovers are fairly universal. The single biggest point of failure with rovers has nothing at all to do with the network, accessing the network, accounts, or any hardware; it is the tenuous relationship the operating systems of the data collectors have with the communications devices. Is the Bluetooth connected? Is the cable secure? Did the port get released last time you disconnected? Is there actually a live connection to the Internet (open a browser on the data collector and see if you can hit a web page). There are too many variables and nuances pairing devices, carriers, and linkages to list.
The good news is that if you can quickly narrow down the problem to that particular point of failure (which is the case more than 90% of the time) you may only need to develop one area of additional expertise in troubleshooting.
Is your rover the village bicycle? If your company/organization/village share the units or components, the chance is very good that someday somebody will change your settings. This can be more of a headache than you can imagine; tracking down the problem can take time. I usually advise a quick set of checks any time you pick up the unit: start with the antenna setting, followed by real time setting (has the unit been set to single base?) then see if the unit has a preset user name and password. This is where screen shots of the rover setup help. There are inexpensive utilities you can buy off the web for many of the operating systems of the data collectors to help you do screen shots. The screen shots from the user manuals are very generic; ones of your own specific settings are golden.
Network Status
The respective network software suites have canned reports (e.g., atmospheric conditions and projections, geometric quality, station reports, satellite tracking) that are invaluable for the user. Look them up before you leave for the field, or call back to the office and interrupt some office toad’s coffee break to have them look online for you. Also, since many of these networks utilize the NTRIP protocol for some if not all of the access for corrections, then you can simply type the full IP and port of the network into a web browser and see the full list of mount points (this is great ready indication of the availability of network services). In addition, it is a good idea to have the free NTRIP client (downloadable from http://igs.ifag.de) installed on a workstation in the office to test logins and network sources. Using this nifty application, "GNSS Internet radio" you can log directly into the network and request corrections directly to your PC, even requesting network corrected solutions by inputting a lat/long (this application is also used in any number of correction relay scenarios, but we’ll cover that in later installments).
Much about network status is moot as network failure is typically the least likely point of failure. Our own network has availability rates of over 98% (this includes planned outages for maintenance). Network status is the quickest and easiest element to verify; even testing connection speeds is a good indicator of network (and space weather) conditions. The old RTK advice to break initialization by shutting everything off and going through the whole process again can be done by holding your hat over the antenna long enough to break link, then let it re-initialize, which should all take less than a minute.
Site Considerations
The same rules apply as you may be familiar with from past days of looooong static campaigns. The ante has been upped; if the time required for observations has been shortened, so may be the expectations for rapid setup. You will not have the time to make the old sky plots, or sit and jaw for awhile, musing over the possible sources of multipath, cosmic rays, or that mean-looking livestock over there.
To some degree, the new rovers make some of the decisions for you. The whole process of getting and applying a network correction is so full of QA/QC elements that these units seem downright picky and unforgiving. If the process does not like certain conditions, it will not bequeath you a result. Basically, you will need five or more satellites in good position (use the onboard sky plot screen), and you will want to steer clear of serious multipath.
Trees are the enemy! They block signals, and some will sometimes spill organic and otherwise unsavory things onto your gear. Buildings, walls and towers can cause multipath, so avoid them as much as possible. It may take substantial field time to develop the steely-eyed instantaneous site-evaluation superpower, but in the interim you may want to take multiple shots at the same location to test how much variance questionable conditions may create. You can take a lot of shots in a minute or two.
Check Before You Click
Like the old adage "Measure twice, cut once," nothing has caused me more grief than trying to get something to work, be it a rover setup, or trying to figure out why a station in the network won’t settle down, only to find out that I had transposed a coordinate or IP address. On the rover this will be particularly annoying (it takes a bit of time to figure it out) and an incorrect setting will keep you from initializing. On the network administration side it can be more serious. Like I mentioned before, a seriously out-of-sync station could affect a whole region of a network, so take care. And it’s a good idea to have someone cross-check your settings.
Heads Up
How’s the sky? Not the weather, but the Space Weather. Though an RTN models out much of the atmospheric delays, solar storms can (on rare occasion) mess with your initialization times and quality. Lots of websites have space weather reports and warnings (NASA, NGS, NAVCEN, etc.), but one person’s solar storm warning is another person’s annoying news bite; that is, until you see for yourself just how much (or little) some of these "events" have on your results, these warnings can spark fear in the hearts of your crews. When you see one of these warnings on a website (or get an alarmist e-mail) then check your local RTN website and see if reports like predicted ionospheric error concur. Try an initialization during the peak of one of these events and see if it actually does take longer.
Find out if you are going to have a "bad satellite day" in advance. There are a lot of online resources and (sometimes free) downloadable applications for viewing the predicted orbits. This will be readily familiar to those who have had to plan static campaigns in the past, but there are an increasing number of users that have never had to post process, and maybe never will… scary as that sounds. Remember back in the day when CAD was first introduced and folks were adamant that one could not be an effective drafter unless they had used pencil or ink? The same thing applies: there may someday be a majority of RTK/RTN-only folks (like it or not); they just need to learn good habits.
New or Potential User
In most cases the typical user on your network will be somebody who is versed in GPS, however he or she may not be familiar with RTN-specific considerations (and points of pain like cellular communication, et al). There might be expectations of "plug & play", and if the user can’t get into the network at first try, the initial complaint is "What’s wrong with the network?" That’s when the fun phone calls begin. Calls could be from scientific or technical/mapping field folks who are unaware of the advantage to field data collection RTN gives (or maybe so resigned to the low accuracies once synonymous with the old term "mapping grade" that the prospects of higher accuracy might seem wholly implausible).
Folks tend to be either open-minded or closed-minded to the concept. If open minded then your job is a whole lot easier, if closed-minded, then you have a Skeptic on your hands.
Skepticism
The biggest thing I find in a skeptic is the disbelief of the quality of the data. Skeptics may have been post processing all of their data and the idea of the "five second shot" seems like heresy. They may have heard negative things about the RTN from somebody who once had initialization troubles or bad rover settings. Or maybe they’ve just had a bad day, who knows? But what they do have is a mindset that the RTN won’t work or may only work sporadically and that they won’t get good data… I deal with this by simply firing up the rover and showing them it works. And a tip to you equipment vendors: show, don’t sell!
Tips & Prep
Make sure the rover works before you leave the office, batteries are all charged up, data phones are working. Another thing to do is to have a set point that you can check into with the rover, say a known point outside of your office, that way you can tell if the rover is calibrated before heading out to the job site. Bring along any documentation you have regarding setup and operating the rover. Hit that point in the parking lot on the way in as well.
The "Dave Method"
"Smoke `em if ya got `em." Not literally (neither this author nor publication directly endorse smoking to solve your problems). This is not a new concept, but your ability to get away from a problem and calm down for a moment directly correlates to your chances of solving the problem. Sometimes we get moving too fast and become less tolerant of little delays or problems. Remember, when this thing is working well, it can save so much time and money that a few bumps in the road won’t be felt through that fat wallet….
Dave Hildahl is the support lead for the Washington State Reference Network. He has worked as a civil engineering technician, drafter, utilities coordinator, and surveyor for over 20 years, and has taught RTN field techniques at national conferences. Gavin Schrock is a surveyor in Washington State where he is the administrator of the regional cooperative real-time network, the Washington State Reference Station Network.
A 872Kb PDF of this article is available by clickingHERE