RTN-­101: Communications -­ Making that First Rover Connection (Part 3)

A 722Kb PDF of this article, with images, is available by clicking HERE 

 

The many interlocking parts of an RTN (reference stations, rovers, central processing center), to truly work together in real-time; require consistent and reliable communications in… well… real-time…

The passages of signal, observations, corrections, almanacs, positions ­ the lifeblood of RTN ­ must be transmitted, received, processed, re-broadcast, received again, and in some configurations re-processed in a matter of seconds; all with the barest minimum of data lost or compromised.

Good news. This is not as complex as it first appears, or at least it does not have to be.

While the operators and administrators of the RTN infrastructure will be more concerned with the reference-station-tocentral-processing-center (CPC) links (which may range from simple and direct to convoluted and perplexing), field users will be concerned with the link most critical to them ­ the one in their hands.

An RTN serves to generate corrections for the field rovers (or provide data to be further processed by the rover). An RTN can generate many flavors and can deliver in several modes: purely broadcast (for one-direction link), or receive and process custom requests (for a bi-directional link). Establishing that link is often the first and most difficult step for a new RTN user (which is why we are covering this subject early in this series).

Making that first connection would be simple enough subject to summarize (in a few thousand words) if there were only one way to connect a rover to an RTN, but there are likely more than a hundred, so short of a several hundred thousand word tome (wouldn’t that be a fun read?), I will step through a common scenario, as a means to shed light on others.

But first a step back. This RTN 101 series was envisioned by editor Marc Cheves as a way to present nice, bite-sized aspects of Network-Corrected-Real-TimeG N SS, or Real-Time-Networks (RTN), as a service to those new to the subject, or those considering development or implementation of RTN. If you have not read the two-part introduction in the September 2006 and November 2006 issues, please do so first.

Many new subjects are not easy to grasp in a purely theoretical manner; imagine trying to learn to type without a keyboard. One could get caught up in the math, theory, understandable skepticism, and some of the unfortunate pseudo-science circulating about RTN, but actually seeing it hands-on, even for a short time, puts many of these considerations into perspective.

For the most part, our field surveying universe revolves around elements in the immediate vicinity of the job site, or data from elements that we set up and control ourselves (e.g., targets, control, base stations, and base radios). This (admirable) autonomy is burned deep into the psyche of land surveyors, so the notion of relying on an external service like an RTN and the complex nature of the many interlocking parts requires a great leap of faith. The initial attempts to connect to an RTN are often a surveyor’s first foray into the world of "mobile data" (something our kids are growing up with). Once successfully connected, curiosity can take over; the inevitable experimentation and exploration will begin and other aspects of RTN will reveal themselves.

Those who are familiar with RealTime-Kinematic (RTK) and DGPS are familiar and possibly comfortable with the transmission and reception of real-time corrections from the reference station (base) via radio (broadcast). RTN could work in exactly the same manner, but RTN seeks to take advantage of multiple stations spaced more widely over a broader region. Broadcast radios typically utilized in single-base RTK have limited ranges. Since the effectiveness of corrections from an RTK base is typically in the range of 10-20km (okay, longer in some cases, or so we are told) the point is moot as the radio range is often well below that, and radio is susceptible to the effects of terrain, and other external `factors’ like FCC rules.

If one had enough radios to spread around a wide region, he or she could perhaps overcome the hazards of `frequency stomp’ (like when someone else also has a bunch of radios), or FCC limitations (try getting a frequency next to the Canadian border). Apart from these hurdles there would need to be links among all of the radios and all of the reference stations; only then could an RTN operate utilizing radio alone. Few of the 200+ RTN in the world are configured in this manner, though many utilize radios in specific situations. Instead, RTN typically uses a "network" of "radios" (so to speak) established by others: cellular infrastructure, a "data-network-in-your-pocket", for the price of a monthly subscription.

Yes, it is true that cellular will not work everywhere, but it does work in enough places to make RTN use cost-effective, though it can be a challenge to reconcile the actual availability of cellular services with the "coverage" maps on the cell providers’ websites (Figure 1). For areas with limited (or no) cell service there are other means to send and receive corrections, and these will be covered in a future article (watch for a title like "How to Use RTN in a Cellular Challenged Area").

Let us concentrate first on how to connect via cellular (as this is likely how you will first experience RTN). This is a good way to make that first connection and learn more about RTN, and you can go through many of the motions, for training purposes, even if there is no RTN in your immediate vicinity.

One could get buried in the options for hardware and services. There are many acronyms to wade through ­ GSM, GPRS, 1XRTT ­ to name a few. But do not fret too much about those right now. The main thing you need a cellular service to do, regardless of what acronyms apply, could be stated simply as, "How do I get my rover connected to the Internet?", or more specifically, "How can my device speak IP, or Internet Protocol?"

Sure, there are ways to use a cell phone to "dial" another phone or device to send or receive reference station data or rover corrections (nice, if you are dealing with a single station and rover, or a limited number). Maybe you could expand the number of possible connections with banks of modems, but what you are still dealing with is a dial-up operation (and that can often involve pricey per-minute charges). As RTN have evolved from the single-base era to true network corrected real-time, the access methods have migrated more towards IP-based solutions. The cellular phone, card, or device stops being a phone and simply becomes a conveyance for packet-data, via IP, that utilizes the cellular infrastructure for wireless transmission.

For the very-techie, all of this may be an oversimplification, but it must be viewed as such (and especially described as such) when dealing with the cellular service providers. If you call up a cellular provider and mention the Internet (or worse still, GPS) you may be pressed to purchase a complex PDA that is set up for direct Internet browsing or with applications to utilize built-in GPS capabilities. Just say NO! There is nothing wrong with these wonderful consumer gadgets and services, but what you might really only need is just a way to simply "get your rover connected to IP". The phone, card, or cell device can be reduced to a "dumb modem". You can add data service to an existing phone that is set up for voice, or just use one for data only.

Dumb modem, FAX-modem ­ whatever folks call it ­ all it really needs to do is connect to the cellular network, and connect to your rover. This could be a "data capable" digital cell "phone", a dedicated &qu
ot;cellular modem", or another device that has a cellular "card" built into it. The GNSS equipment manufacturers are accommodating this trend with built-in or easily connected mobile data capability on their receivers, data collectors, or combination devices (Figure 2). Some have cell cards built-in that just require the user to insert the SIM card that comes with the cellular service. They may have slots to slip in cellular modems, or PC slots for cell cards. Many also include Wi-Fi capability, but unless you have city-wide Wi-Fi, or you turn your survey vehicle into a mobile Wi-Fi hotspot, or do all of your work within the immediate vicinity of a chain-coffee-house, range can be a limiting factor.

Apart from the cellular phone or device hardware, when you get a cellular service what you are essentially paying for is that little SIM card, which is often hidden behind the battery in the phone. A SIM card (Subscriber Identity Module), also known as USIM in newer generation devices, carries the codes and data that authorizes your phone or device to access the cellular network, and often can be utilized in a wide variety of compatible devices. Whether you add data capability to your current cellular account, or purchase a data-only account, if the rover you intend to use has a built-in cellular device, you can insert the SIM card. If not, there are ways to connect external cellular devices (be that phone, modem, or other) via serial cables, USB cables, or a short-range wireless capability called "Bluetooth" (quite common in most newer mobile devices to "eliminate troublesome cables"). My advice: always carry a cable just in case ­ a "Plan B" is always a good idea with any component.

If you have a newer rover, almost regardless of brand, its data collector will likely have an operating system that enables the device to connect to the Internet. If you have a data capable cellular device that can connect to the data collector (even easier if that cellular capability is built-in to the data collector or receiver), then you can go through some basic steps (similar on most operating systems) to make that test connection.

Here is a simple exercise: grab a mobile device (PDA, laptop, or data collector) that runs a fairly common operating system (OS) like Windows CE, Microsoft Mobile, or Pocket PC (for devices with less common or proprietary OS, get a user guide or "cheat-sheet" from the manufacturer).
1. Using your sample OS listed above, pick "Start", "Settings", and "Network Connections" (or find the same under "Control Panel").
2. Select "Make a New Connection" (or "New Connection Wizard")
3. Select "Connect to the Internet", "Set-Up Connection Manually", and "Dial-up Modem" (remember, you are simply treating your cellular device as modem). (For most devices you can pick "Hayes Compatible Modem COM1", or "Bluetooth DUN" if your devices are set up for that.
4. Subsequent prompts will ask about country code and area code (unless you go into advanced settings it will ignore these since, in all but a few instances, long-distance does not apply).
5. You will need to get a data access number from the cellular service provider (these look more like a code than a phone number (for example, S=2, or *99#, or 777# and vary by provider).
6. Many providers do not require a username/password. Ask if these are needed, and if not then leave those blank.
7. Once the connection is created, with a handy name you have assigned, you can attach the cable or make sure the Bluetooth is activated on both devices and they recognize each other (consult manuals!) and then click on that connection.
8. The device will go through the connection process, showing progress in a sequence like "Dialing", "Connecting", "Authenticating", and "Connected". You are in!
9. Now, test your connection. It is a good idea to do this before you actually try to access an RTN to avoid spinning your wheels if you cannot first verify Internet connectivity. Open up Internet Explorer on your device, then open up a website (news, sports, whatever). Note: pick a site with content that changes frequently as you may be just viewing a page that is stored in memory, even if you failed to connect.

Folks always wonder what level of cellular data account they should purchase. The accounts are either "metered" by data volume, or an all-you-can-eat type. The amount of data you will transmit and receive can vary depending on what flavor of correction solution you accessing (more about that in later installments). A good recommendation is to start with an all-you-can-eat (or unlimited) style. After a month or so you should be able to determine how much you will use the rover in a typical month (the stats are usually on your bill, or call the provider for that info) and how much data you have transferred (5Mb per, 10Mb per, etc.) to see if a less expensive plan might work. You may end up preferring to keep the unlimited plan (which is not that much more than the metered plans) as many have discovered other advantages to their operations of this mobile data link (for example, you may want to review a fascinating session at a recent user conference on how to turn your data collector into a "mobile office").

For the new user, or when dealing with recently acquired equipment or components, trying to answer the question "Why am I not receiving corrections or data from the RTN?" can be very frustrating. A likely culprit is the mobile connection. Although these processes and components have gotten much easier to deal with, cellular outages are less common, and many of the steps are now automated, this can still be the most common point of failure. But rest assured, it gets easier.

Once your rover can see the Internet, the next step is to talk to an RTN via IP. In the next installment of this series, we will outline how to connect to some sample "mountpoints" (or RTN correction and data sources) that you can use to test some of the functionality of RTN. The example RTN may be far from where you are, and even if you are successful in initializing, the results may be laughable. At least this will walk you through the motions. In later installments we’ll also outline how receivers connect to the Internet and RTN as reference stations (and maybe how to set up your own for testing).

Gavin Schrock is a surveyor in Washington State where he is the administrator of the regional cooperative real-time network, the Puget Reference Station Network. He has been in surveying and mapping for more than 25 years and is a regular contributor to this publication.

A 722Kb PDF of this article, with images, is available by clicking HERE