GPS World

Blog

  • My First-Hand Experience with the Waldo Canyon Wildfire and GPS

    By Don Jewell

    Tuesday, the 26th of June, started off as a beautiful day in Colorado Springs, if you ignored the towering plume of smoke to the west from the Waldo Canyon Wildfire.

    image001

    The wildfire started three days before in the popular Waldo Canyon hiking area in the Rocky Mountains just off Highway 24. While people in the Colorado Springs area were concerned, there were currently eight other wildfires raging in the state of Colorado and over the past month arsonist(s) were suspected of starting up to 20+ wildfires. So, many had become inured to the sight and smell of smoke. Only one serious wildfire was known to be currently out of control in Colorado at the time, so concerns in the Colorado Springs community could be described as moderate.

    Then, at 1630, that’s 4:30 P.M. for my non-military readers, the wildfire displayed its true personality. Driven by what meteorologist later described as “a perfect storm of weather conditions” and howling winds exceeding 65 miles per hour out of the West, the fire spread eastward toward Colorado Springs at an alarming rate.

    image003

    The dark black roiling smoke blotted out the sun, which was suddenly no more than an angry red disc in the sky providing little illumination. The suddenly disobedient wildfire began marching, indeed running and leaping, relentlessly eastward voraciously consuming homes and lifetimes of memories. My wonderful wife of 32 years and I had all of five minutes to leave our comfortable foothills home, amid swirling, stinging, cloying black smoke, flying embers, and flames that danced over 100 feet high. It was simply a terrifying event. As we fled the wildfire with quickly gathered pictures, important papers, and little more than the clothes on our backs, neither of us thought we would ever see our home of 22 years or anything inside intact again.

    image005
    Fox 21 file photo of the Waldo Canyon Fire in Colorado Springs, June 26, 2012.

    Evacuation

    The wildfire and smoke turned a now-indelible drive down familiar streets into an alien landscape. Visibility was limited to less than ten feet and premature night had fallen in a fiery, smoky, unbreathable pall on more than half of Colorado Springs. In the end more than 32,000 people were evacuated, 11,000 homes were threatened in several nearby communities, and approximately 350 homes were lost in the Mountain Shadows neighborhood in the foothills of the Rocky Mountains. Firemen tell me the heat was incredibly intense, and homes that were lost were quickly turned into nothing more than smoky white ash. It was a truly devastating turn of events but without all the capabilities generated by and enabled by GPS, the results could have been much worse. Mayhem was avoided, and I have no doubt that GPS units of various descriptions guided thousands of people to safety that unforgettable day. Thousands of people, who suddenly and unexpectedly found themselves to be evacuees, followed voice and visual commands from small electronic GPS units that eventually led them to safety and safe havens all around the state of Colorado.

    Heroes

    Firefighters and support agencies from around the U.S. responded. When the fire broke out and wreaked havoc in the Rocky Mountain foothills, there were ~423 firemen fighting the fire. After the breakout and at the height of the fire, there were firefighting assets from every source available including the DoD and the National Guard. They totaled more than 1500 in number, and in my book they are all heroes. Case in point, as we were fleeing down the mountain from our home in a billowing preternatural darkness, along with thousands of others just like us that just wanted to get out safely, the brave men and women of Fire Station #12, at the end of our street, were racing up the mountain to confront the fire and save our homes and our neighborhood. In this regard I hold them and all firefighters in the same regard as U.S. Marines, who when shots are fired run toward the sound of gunfire, not away from it. Our courageous local firefighters, joined by a thousand more from across our nation, were running toward the fire, not away from it. Their bravery brought tears to your eyes that had nothing to do with the smoky atmosphere.

    We Survived

    All this occurred less than two weeks ago — as I write this column from my home, which was fortunately spared, albeit with a slightly smoky bouquet. We certainly consider ourselves to be blessed as the fire was stopped just a few hundred feet from our neighborhood.

    When we finally and gratefully returned home and were able to fire up our computers, I discovered several testimonials from readers, first responders, firemen, and GPS users extolling the virtues first of the firemen and then of the GPS equipment that played such an important role in averting a total catastrophe.

    One note from a couple who had only been in the local area for a couple of months described their experience fleeing before the raging wildfire in an only vaguely familiar neighborhood suddenly plunged into darkness, with air that was difficult to breathe and street signs that were unreadable. However, they movingly wrote, “Our brand new Garmin, that led us across country, also led us to safety during the WC wildfire and it was extremely comforting to know that the GPS knew the way…it eventually led us safely to a hotel outside the evacuation area…we had no idea which way to go and were totally dependent on our Garmin…we had a map but in all the confusion and panic it was of very little use…we could not read the map in the sudden darkness…we just listened to that small little voice that said…prepare to turn right in 400 feet…it saved our lives.”

    USAFA under Attack by the Waldo Canyon Wildfire.
    USAFA under Attack by the Waldo Canyon Wildfire.

    Another shining example of bravery in firefighting came from the various agencies and firefighters that joined the firefighters from the United States Air Force Academy (USAFA). A USAF Colonel went on local television and declared that they had evacuated the academy and then established what they hoped was an impenetrable several-mile-long firebreak with bulldozers and heavy equipment, and although their numbers were limited, they would not allow the fire to penetrate the USAFA beyond that line and hold the line they did. These brave men and women were not all trained and certified wildfire firefighters, but they had the courage of their convictions and they held the line. The fire did not penetrate the USAFA beyond that firebreak. There are many more examples of true heroism that are too numerous to mention.

    Firefighters from across the Nation

    I spoke with many first responders — as I said, eventually 1500+ were fighting the fire — from as far away as California and Utah, who knew nothing about Colorado Springs or the Rocky Mountains to the west when they arrived on the scene, but who efficiently navigated the fiery wasteland with their map reading skills and various official and commercial/civil GPS units, both stand-alone and embedded units. And again Garmin units were almost always mentioned in the conversation — from sophisticated Garmins using elaborate forestry and military grid systems used by military and Forest Service first responders, in vehicles and aircraft, to wrist Garmins that simply allowed users to immediately locate their positions on a local area map.

    At the height of the WC Wildfire, which as I write this is 98% contained but most certainly not under control, there were firefighters and first responders from the Forest Service, U.S. Army, U.S. Air Force, National Guard (Army and Air Force), the U.S. Air Force Academy, and numerous federal agencies to include C-130 MAFF (Modular Airborne Fire Fighting System) units from Peterson AFB, in Colorado Springs (the 302nd) and from a National Guard Unit in Wyoming. The majority of the firefighters were not from the local area; consequently, most all of them were using an incredible array of various GPS devices to locate and navigate. And in most all cases there was some reference to an external map. Local television stations, which covered the fire exclusively for the first five days, all had different and multiple maps and many were frankly almost indecipherable. What was interesting is that in almost every case there was a definite and clearly visible unfamiliarity by the participants with both the maps and even the local area. It seems that except for certain branches of the military and those who use maps daily in their profession, map reading and orienting skills have fallen by the way side, if indeed there was ever any initial proficiency. It is a skill we all need to relearn.

    Maps and GPS

    A very close friend and business colleague of mine, Robert Rosenberg (Maj Gen USAF Retired), once ran what was then known as DMA or the Defense Mapping Agency and is now known as NGA or the National GeoSpatial Intelligence Agency. NGA specializes in maps and may be the best in the world at gathering the necessary data and producing them. Indeed, some of the NGA maps are simply amazing and true works of art. However, the sad fact is they are utterly useless if you don’t know how read and utilize them properly.

    Historically, some of the inaccuracies wrongly attributed to the GPS were actually map errors. I personally observed an incident where Dr. Ivan Getting, a possible father of the GPS, whom I have written about previously, determined the exact geographical coordinates of his home from a long integrated GPS position, but which DMA maps showed to be in the middle of a lake. Obviously the map was several hundred meters in error, and this was a common occurrence in the “old” days. However, modern map-making techniques and accuracies today are such that this is no longer the case. But even the best and most accurate map in the world today is useless if we don’t know how to make use of it — we must learn to orient ourselves, accurately locate our position on a map, and generally make use of the features all modern maps provide. It is time to stop blaming the maps and map makers and start learning to use the phenomenal maps and PNT tools at our disposal.

    Now, please don’t misinterpret my comments or take them out of context. After all, this is GPS World magazine and there is not a greater proponent of GPS anywhere than yours truly; however, I have also always been a proponent of developing simple map reading skills as well, which to some seems to be anything but simple.

    Dwindling Skillsets

    Like many of you, I have read passionate and somewhat inaccurate articles bemoaning the use of GPS for the navigation and situational skills that are lost by blindly following GPS dictates, and certainly I have received numerous letters from and responded to those who prefer to navigate using granddad’s old Texaco map in the glove compartment. However, unlike many uninformed critics of the GPS and proponents of map reading skills, I do not believe the two are mutually exclusive. In fact, one of the features I most appreciate about the GPS navigation system in my Audi is the traffic avoidance feature that when potential routes are blocked, or conflicts arise, automatically reroutes, without ever broadcasting that most irritating word “recalculating.” The other feature is the map display zooms out and displays more map features and alternate routes, so if I wish I may manually choose an alternate route. I have, just as you do, the option of blindly trusting the GPS, picking my own route on the map display or, as I most frequently do, using a combination of both map-reading skills and PNT automation.

    In the grand scheme of things, map-reading skills are not difficult to develop and the basics are simple; however, it does take some practice — practice that can be gained every day by choosing different routes to work or common destinations and challenging yourself and your map reading skills when you travel. And here is a novel idea — actually read the instructional/operators manual that came with your GPS — learn all its secrets and built-in capabilities. You might be surprised by what you will learn and the skills GPS can help you develop.

    Plethora of PNT Equipment

    I had the enviable opportunity to speak with representatives from many of the more than 20 agencies that responded to the Waldo Canyon Wildfire and get a brief look at some of their PNT equipment. The equipment in general ranges from high end and highly sophisticated official first responder units with built-in communications capabilities to Garmins, iPhones, and iPads. The Garmins were equally split between vehicle-mounted, aircraft-mounted, and portable units, while the more sophisticated units were large and considered more appropriately as portable units with communication capabilities than as true handhelds. By far the most noticeable and prevalent units, other than Garmins, were Apple iPads, especially the new iPad IIIs with retina displays and ruggedized with Otterbox and Otterbox-like enclosures. There are numerous mapping and GPS/GIS applications that run on the iPad and other portable display devices, and in the future I will be reviewing the best mapping applications to assist you in choosing the one that is best for your situation. However, regardless of the application or device it would behoove us all to learn a bit more about maps and the devices we have on hand to display them, to include becoming familiar with that old Texaco map in the glove compartment, even if it is a last resort.

    Tragically two souls perished in the Waldo Canyon Wildfire, as they were unable to evacuate their home before the fast moving wildfire overcame them. The Waldo Canyon Wildfire is truly a catastrophic event that will long be remembered in Colorado, and from which we can all learn a valuable lesson. And I wholeheartedly believe that many lives were and will continue to be saved by GPS/PNT devices in these types of catastrophes. We simply owe it to ourselves and our loved ones to learn how to best use our GPS/PNT equipment now, so it will be second nature when a catastrophe occurs. Take it from me, you life may depend on it. When you are fleeing for your life, you need all the help and good fortune available — it is not the time to figure our how your GPS/PNT device really functions.

    God bless our firefighters and first responders.

    Until next time, as Tennessee Ernie Ford said, “God willin’ and the creek don’t rise,” happy navigating and remember to read your GPS/PNT equipment owners manual.

     

     

     

  • GEO Huntsville: The Rocket City Spreads its Geospatial Wings

    By Art Kalinski, GISP

    Several weeks ago I attended the kick off press conference of “GEO Huntsville.” What is GEO Huntsville? It’s one of three economic development and jobs initiatives spawned by Huntsville, Alabama, Mayor Tommy Battle. It’s lead by Joe Francica, who has been a long-time leader in the geospatial community and the editor-in-chief and vice publisher of Directions Magazine. Directions Magazine is part of Directions Media, a leading online publishing group for location technology and Geographic Information Systems (GIS). So when Joe gets an idea, people listen.

    Joe has been a long-time resident of Huntsville, and has seen the city grow into a strong center of geospatial activity. After receiving his MBA, Joe worked for GIS firms Tydac and Intergraph. In the early ’90s he originated the column “GIS in Business” published by GIS World Magazine, which is how I met Joe. He soon became the editor of Business Geographics magazine, and then went on to his current position at Directions Magazine. No one I know has as broad an understanding of the geospatial community as Joe. He always has his finger on the pulse of the geospatial community and feels that Huntsville will be a major player in the next 10 years.

     

    Huntsville is unique in that the then small city received a big boost in technology when the WWII German rocket scientists, led by Wernher von Braun, moved there after the war. Huntsville, the location of the U.S. Army’s Redstone Arsenal, soon became known as “Rocket City” and the home of the U.S. Space and Rocket Center and NASA’s Marshal Space Flight Center. It has been estimated that there are more Ph.D.s and college graduates per capita in Huntsville than any other U.S. city.

    Huntsville is now home to more than 50 geospatial firms, including major players such as AutoDesk, Bentley Systems, Boeing, several Intergraph divisions, Northrop Grumman, SAIC, and dozens of mid-sized and smaller companies. In addition to state, local, and higher education GIS operations, Huntsville is also home to a growing number of military commands moved to the area through the Defense Base Closure and Realignment Commission (BRAC). BRAC alone is responsible for 27,000 people moving to the area and joining established geospatial operations at commands located on the Redstone Arsenal such as the Missile and Space Intelligence Center (MSIC), the Army’s Materiel Command, and U.S. Army Corps of Engineers.

    MSIC is the largest C4ISR organization in the area and shows signs of considerable growth. MSIC’s mission is to support field commanders, weapons systems developers, and policy makers with scientific and technical all-source intelligence on surface–to-air missiles, short-range ballistic missiles, anti-tank guided missiles, missile defense systems, and directed energy weapons. Additionally they provide information on space programs and relevant command, control, communications, computers, intelligence, surveillance, and reconnaissance systems. Their analysis is provided not only to the Department of Defense but other agencies such as DHS and the FBI.

     

    Additionally, the National Geospatial Intelligence Agency (NGA) provides on-site direct support and analysis through a working relationship between NGA and MSIC. This support benefits both agencies and ties in NGA assets and support worldwide.

    The Army’s Redstone Arsenal uses the full array of geospatial tools and resources to manage the base, including compliance with the DOD Spatial Data Standards for Facilities and Installations (SDSFIE). The U.S. Army Corps of Engineers — Engineering Support Center provides specialized geospatial support nationwide.

    The kick-off meeting for GEO Huntsville was held in a large conference room at Intergraph. The surprise was the attendance. The room was fine for the expected attendance of about 40 but with more than 110 attendees it was standing-room only. Mayor Battle commended Joe Francica’s efforts and explained the reason for GEO Huntsville.

    Citing the Department of Labor listing geospatial as one of the 13 high-growth professions and the estimate of 180,000 new geospatial jobs over the next 10 years, the Mayor said Huntsville was well positioned to see many of those jobs placed in the region. He further explained that the collaborative effort of firms and organizations in the region will work to establish Huntsville as major corridor for geospatial excellence by:

    • Promoting economic incentives.
    • Serving as a geospatial information clearinghouse.
    • Sharing research and best practices.
    • Promoting Huntsville’s economic, cultural, educational quality of life.

    The Mayor further explained the tie in with two existing workforce initiatives: Energy Huntsville and Cyber Huntsville. Both have geospatial components using maps and 3D models to improve government energy management and the use of location tools to counter cyber attacks. He also cited efforts to place Huntsville as one of six cities that will help set policy for the Federal Aviation Administration (FAA) for integrating Unmanned Aerial Systems (UAS) into the National Airspace System (NAS).

     

    Showcasing current geospatial technology, Intergraph demonstrated new developments in merging different geospatial data sets including photo realistic 3D models and a most impressive video integration system. The system was able to take video feeds from aircraft flying over a site and geo-reference or “pin” the video to a base map or ortho image. This registration was maintained even though the video was constantly changing position angles due to the movement of the aircraft. This could help significantly in indexing and cataloging the flood of intel video that is being collected in-theater.

    So why should you even care about GEO Huntsville? The geospatial community is growing, many new positions and opportunities will be located in Huntsville, and if you are early in your career you may need to relocate. In my travels I sometimes a see a bit of a preconceived attitude about Alabama not founded in fact. During my naval career I had a chance to travel all over the world. I could have retired (semi-retired) in almost any U.S. location, but I picked the mountain lakes region near Huntsville as the ideal combination of factors for me. To quote a colleague from upstate New York after his first visit, “I thought I was in the Finger Lakes of New York.” So if you get a chance to relocate to Huntsville, jump on it. Many geospatial opportunities and a nice quality of life await you.

  • GPS Business Outlook, GNSS Industry Future Assessment

    GPS World magazine has opened the first State of the Industry Survey for completion by GNSS industry members; the interactive form is found at env-gpsworld-integration.kinsta.cloud/industrysurvey. The results of the Survey, compiled and analyzed, will appear in the September issue of the magazine, as the very first State of the Industry Report, accompanied by an economic study titled “GNSS and the Economy: Scenarios for the World and Some Implications for the Industry.”

    Participation in the survey is open to all members of the GNSS community; however, it is necessarily focused on industry, not academia or government.  Its core questions address business outlook, issues of business concern, revenue ranges, and GNSS products supplied, specified, or purchased. 

    The State of the Industry report in the September issue will draw from the survey to cover such topics as:

    The global economy and how it affects business in each GNSS sector: Customers’ availability of capital to invest is top-of-mind for most industry professionals, whether designers, manufacturers, integrators, suppliers/dealers, or end users.

    Industry confidence in the road ahead: is the prolonged recession over, or still ongoing? Are customers expanding aggressively or proceeding cautiously?

    Investment for return: how are suppliers implementing their business outlook? What priority do they allocate to cutting expenses, maintaining current sources of revenue, increasing sales to core clients, developing new customers, R&D for new products or services, exploring mergers or acquisitions or IPOs — or something else?

    Issues of concern: to what extent do industry leaders take into account pricing and competion; GNSS jamming, spoofing, other RF interference; compatibility or interoperability issues among GNSSs; funding for satellite system development or modernization; funding for application development; Manufacturer readiness for coming new GNSS constellations; and compatibility/interoperability issues with open-architecture non-GNSS positioning systems.

    The State of the Industry survey is now live at env-gpsworld-integration.kinsta.cloud/industrysurvey. It will remain live until July 31.

    The State of the Industry Report will receive wide distribution, to the full subscription base of both print and digital magazine, and bonus distribution at ION-GNSS in Nashville, Tennessee (September), InterGeo in Hanover, Germany (October), and other outlets.

    Prize Drawing. Incentives for participation in the survey include entry into a drawing for an iPad3, a pair of tickets to GPS World’s Leadership Dinner in Nashville during ION-GNSS, a surprise offering, and coffee-shop gift cards. A majority of the questions must be answered to qualify for the prize drawing. As the survey is business-focused, some non-industry community members in academia or government may find that they cannot answer many of the questions. Their participation is still encouraged, even if they do not qualify for the drawing.

  • Navilock Offers New u-blox-Based GLONASS Receivers

    Navilock, a trademark of Tragant Handels- und Beteiligungs GmbH, announces a new family of GLONASS receiver products including the NL-662U USB-based receiver, equipped with a u-blox GLONASS chipset.

    Since the end of 2011 the Russian satellite navigation system GLONASS has been available worldwide. Similar in functionality to the US-NAVSTAR GPS system, GLONASS satellites transmit positioning data over distinct frequencies (Frequency Division Multiple Access, or FDMA, versus GPS which uses Code Division Multiple Access, or CDMA).

    The new GLONASS receiver products have internal patch antenna in various configurations to serve different installation requirements. Four housing variants with USB or serial MD6/TTL interfaces are available for installation on vehicles or boats.

    The u-blox GLONASS chipset features high accuracy to support precision location-based applications such as navigation, datalogging or tracking.

    The products provide -158-dBm signal sensitivity with extremely low power consumption to insure reliable performance and long battery life. The u-blox GLONASS chipset facilitates hot starts in less than 3 seconds.

    For more information, visit Navilock’s website and click on “new products.”

  • Mobile GIS Webinar Follow-up and the New Google Nexus 7 Tablet

    Thanks to those able to attend the June 21 webinar titled “Mobile GIS: What’s the New Normal? Windows, Android, iOS, Open Source?” If you weren’t able to attend and would like to listen to it, you can by registering here. It’s a fascinating discussion about the direction that mobile GIS devices are taking in the future. To top it off, two days after the webinar, Google announced its own tablet computer, the Nexus 7.

    I conducted three live audience polls during the webinar. One audience member noted that by asking the poll questions after presenting slides on the subject that I may have skewed the results. I guess it’s possible, but I think most audience members already had some idea of which direction they were going even before attending the webinar. However, I do agree that by presenting information the audience may not have been aware of (such as Microsoft’s commitment to support Windows Mobile until at least 2019), that this may have caused audience members to reconsider or change their answers based on new knowledge, but isn’t that what the webinar is supposed to do? Provide timely and current information for more informed decision-making?

    Followng are the poll results from the webinar.

    Poll #1: For Mobile GIS work, which type of device do you prefer?

    Poll1

    Gakstatter comment: The audience results don’t surprise me. Some might expect that smartphones would be higher, but as one audience member noted, “The screen is too small and who wants to risk using their phone?” Also, there are a very limited number of mobile GIS apps available for smartphones running Android or iOS. But, I think the fundamental issue is risk. Yes, for lightweight mobile GIS, a smartphone may be very useful, but if you’re tasked with an all-day intensive mapping project, would you really use a smartphone for this? It’s a valid question.

    Poll #2: Which Mobile device operating system do you foresee using in the future for Mobile GIS?

    Poll2

    Gakstatter comment: This is interesting, but not completely surprising. The dominance of Android makes sense because the vast number of Android-based devices being introduced, from smartphones to tablets. I expected the iOS number to be higher, but I think what’s hurting iOS is the lack of apps for mobile GIS and the inability of iPads/iPhones to interface (Bluetooth) with external sensors (such as GPS, lasers, cameras, etc.). Another interesting point is the high number of “Don’t Know yet” responses (27.4%). With the lack of powerful mobile GIS apps for Android and iOS and the user community’s uncertainty about Microsoft’s intentions with Windows Mobile, there’s a lot of “wait and see” going on. My gut tells me that Windows Handheld will garner the largest share of the “Don’t know yet” audience. It’s going to take quite some time before mobile GIS Android apps are developed, introduced, debugged, etc. Plus, there are so many versions and variations of Android that I think developers will have to target certain devices to support. It’s not a “one-size-fits-all” thing. An app developed for Android doesn’t mean it’s going to run properly on all Android devices.

    Poll #3: In the future, do you think your organization will be using cloud-based mobile GIS apps or standalone mobile GIS apps?

    Poll3

    Gakstatter comment: I have to say, this is the most confusing webinar question I’ve ever asked. During the webinar, I noted this and asked the audience to respond Yes for cloud-based apps and No for standalone apps. If you understood it that way and responded accordingly, the results seem reasonable. Either way, there’s no doubt about the huge interest in working with cloud-based apps. It’s going to be interesting to watch where the cloud-based apps go. It’s not like a small consulting company or local government agency can deploy cloud-based mobile GIS apps easily. They would need a whole level of back-end support (hardware and software) to do this. In that case, maybe there’s companies that will offer SaaS (Software as a Service) for these folks to use? That starts to make sense. But, where are they? Is ArcGIS for Android/iOS and Google for Android as good as it’s going to get? One segment where I have seen some traction is local governments offering mobile GIS SaaS from companies like Accela and CitySourced.

    If I haven’t said it enough, what’s hindering Android and iOS in mobile GIS is the lack of apps. Esri will never have ArcPad (arguably the world’s most popular mobile GIS software) rewritten to Android or iOS, that’s pretty clear. Esri’s successor for ArcPad is ArcGIS for Windows Mobile, in which they just released version 3.0. It’s a hybrid standalone/cloud app so you can use it when your not connected to the Internet, but it still doesn’t have some of the useful features that ArcPad (and others) have like supporting related tables and direct support for raster imagery, CAD, and shapefiles that don’t have to be “pre-processed” in ArcGIS. There’s really nothing similar for Android or iOS.

    Due to the lack of apps for Android and iOS apps, I’m not so quick to write off Windows Mobile devices as many people have. As poorly as Microsoft has communicated its intentions, they have committed to supporting Windows Embedded Handheld (essentially, the same as Windows Mobile) until at least 2019. That’s plenty of time to let Android mature and settle (or even some other operating system to emerge), which it needs to do in order to not drive software developers insane. Android ships in many flavors today, from version 2.3 to the new Google Nexus 7 tablet running version 4.1. Since Android is an open operating system, you can have so many variations and nuances that it will be nearly impossible for app software to run flawlessly across so many different hardware devices and operating system versions.

    On the flip side, Apple (iOS) has a highly-controlled app registration process, so other than varying screen sizes, apps will largely run across the iOS hardware platforms. The highly controlled environment seems to work well in ensuring smooth running apps. I’m told that Apple does this to ensure the “best user experience.” However, in some areas, notably Bluetooth connectivity, the proprietary nature of Apple rears its head in a not-so-flexible way. For example, for those of you waiting for the day you can use Bluetooth to connect your high-precision GPS, camera, or laser rangefinder to the iPad or iPhone, don’t hold your breath. If it wasn’t specifically made to Bluetooth to iOS, it’s not going to work. For example, following is a Bluetooth GPS receiver (XGPS150) that works with iPads/iPhones as well as other non-Apple Bluetooth hosts. Note the “Mode” toggle switch where the user must select between Apple and non-Apple products.

    Dual XGPS150 (Source: Dual)
    Dual XGPS150 (Source: Dual)

    The Dual XGPS150 is your typical consumer-grade GPS receiver. It has value for pilots, auto nav, and other apps where the users need to place the GPS antenna in a different location than the iPad/iPhone. However, none of the professional-grade Bluetooth GPS receiver manufacturers have designed “Apple Bluetooth” into their systems, so there’s no way to connect your iPad/iPhone to a high-precision GPS/GNSS receiver via Bluetooth, unless you jailbreak the Apple Bluetooth stack.

    With iOS devices “out” for the forseeable future, that leaves the battle between Android and Windows Mobile devices for the most flexible and powerful GIS data collection devices.

    Google’s New Nexus 7 Tablet Computer

    Just two days after Mobile GIS webinar, Google introduced its Nexus 7 tablet computer.

    Google Nexus 7
    Google Nexus 7

    Even though Google says it’s not meant to target the Apple iPad, it may be better suited for geospatial apps than the iPad. One of the apps it was built for is gaming, so it’s got a pretty strong processor, a 1.3GHz quad-core CPU backed by 1 GB of RAM. Given that, dealing with raster imagery efficiently may not be an issue, although storage might. The Nexus 7 comes in 8-GB and 16-GB versions, with no memory expansion slot. That’s a lot of storage, but we like our SD cards.

    Of course, the “7” in the Nexus 7 name matches the display size, 7 inches, with 1280 x 800 pixel resolution, which is higher-res than the first two iPads. The Nexus 7 weighs in at 12 ounces, which is ligher than a Kindle Fire and half the weight of an iPad (although the iPad has a larger 9.7″ display). It reportedly works fine in direct sunlight, which is a must for geospatial users.

    It’s 4300-mAh Li-Ion battery will run it 9+ hours and I’d probably buy the $20 protective case for it since it’s not built for outdoor use any more than a notebook computer is. Ruggedness is always the rub with using consumer electronics devices outdoors, and the Nexus 7 is no different.

    By the way, the Nexus 7 is actually an ASUS Transformer Prime tablet that Google has rebranded. This is a good thing because the hardware bugs have likely been flushed out. Gizmodo rated the ASUS unit its favorite Android-based tablet.

    The Nexus 7 is one step closer to bringing consumer tablet computer technology to professional geospatial users. Although it has a built-in GPS receiver and 1.2-megapixel cameras, we need better geospatial tools. If various Bluetooth geospatial devices like high-precision GPS receivers, cameras, laser rangefinders, etc. can be interfaced to the Nexus 7, it’s a better match for geospatial apps than the iPad.

    Running Android’s latest 4.1 operating system, it’s going to suffer from a lack of geospatial apps, for now. But maybe this is the sort of hardware that developers need to see to get them excited.

    Did I mention the price?

    $200 bucks. If you want to splurge, $250 for the 16-GB model.

    This is getting interesting, very interesting.

    Thanks, and see you next time.

    Follow me on Twitter here.

  • Mission Accomplished for Galileo’s Pathfinder GIOVE-A

    Artist's impression of GIOVE-A in orbit. (Photo by ESA - P. Carril)
    Artist’s impression of GIOVE-A in orbit. (ESA, P. Carril)

    With the initial satellites of the Galileo constellation working well in orbit, it has been decided to end the mission of ESA’s pioneering GIOVE-A navigation satellite, reports the European Space Agency.

    Launched on December 28, 2005, this first experimental satellite performed the vital task of securing the radio frequencies provisionally set aside for Galileo by the International Telecommunications Union.

    It also flight-tested Galileo atomic clocks and other equipment in space for the very first time and investigated the radiation environment of medium-altitude orbits, never used before by a European mission.

    ESA formally ended GIOVE-A’s mission at the end of June, although it will go on being operated for now by prime contractor Surrey Satellite Technology Ltd of Guildford, UK, to gather radiation data and performance results from a GPS receiver.

    “GIOVE-A had a design life of only 27 months, so to continue operating for 78 months is impressive,” said Valter Alpe, managing GIOVE activities for ESA.

    “In August 2009, the satellite was moved into a graveyard orbit around 100 km above its normal 23,222 km to make way for the Galileo validation satellites.

    “The first two of these were launched on 21 October 2011 and are performing well, so while GIOVE-A has served ESA well it no longer has a job to do.”

    Built to a tight deadline by SSTL, GIOVE-A carries a rubidium atomic clock accurate to three seconds in a million years.

    On 27 April 2008 it was joined by GIOVE-B, built by an Astrium-led consortium, which carries an even more accurate passive hydrogen maser clock — the first to be flown in space for navigation, accurate to one second in three million years — as well as a second rubidium clock. Operational Galileo satellites carry two pairs of both kinds of clock, for redundancy. They are very different missions in other ways too. The GIOVEs were modified from existing satellite platforms: a prototype geostationary minisatellite for GIOVE-A, and a commercial French Proteus platform typically used for Earth observation for GIOVE-B.

    Galileo satellites are based on an entirely new platform and improved payload, specifically engineered for extremely high reliability, only intended to go into safe mode for a few days over their planned 12 years of operation thanks to a robust design based on reconfigurable redundancy.

    Even when entering ‘intermediate safe mode’ they can continue to supply navigation signals, although without the usual service guarantee. GIOVE-B, with an orbital lifetime of 50 months and counting, will be used in payload fine calibration tests this summer with the two Galileo satellites.

    Then, in September, it will be manuvered into a graveyard orbit 300 km higher. At this point, GIOVE-B’s own mission will end.

    “Early October will see the launch of the next two Galileo satellites by Soyuz rocket from Europe’s Spaceport in French Guiana,” added Valter.

    “This will be an important step forward because four satellites are the minimum to perform navigation measurements, so Galileo system testing can proceed.” A follow-up batch of full operational capability Galileo satellites is being built by Germany’s OHB and SSTL, with initial Galileo services forecast to be available by 2014.

  • UPDATE: Launch of EGNOS Satellite Delayed until Monday

     

    News courtesy of CANSPACE Listserv.

    Roscosmos is conducting further tests on the launch vehicle for the SES-5 satellite, and have postponed the launch for two days. The new launch date is Monday, July 9, with an approximate launch time of 18:24 UTC.

    The launch of SES-5 from the Baikonur Cosmodrome, originally scheduled for June 18, was first rescheduled to July 7 due to a problem with a first stage subsystem on the Proton launch vehicle.

    SES-5 is also known as Sirius 5 stemming from the development of the Sirius satellite constellation by Nordic Satellite AB, now ownded by Luxembourg's SES. The satellite carries a transponder for the European Geostationary Navigation Overlay Service (EGNOS). The transponder is intended to eventually replace or supplement one of those on the currently used EGNOS satellites (Inmarsat 3-F2 at 15.5 degrees west using PRN 120, Inmarsat-4-F2 at 25 degrees east using PRN 126, and Artemis at 21.5 degrees east using PRN124, and designated for industry tests).

    Unlike the present L1-only EGNOS satellites, SES-5 will have transponders on both the L1 and E5 frequencies similar to the setup on the Wide Area Augmentation System satellites, which broadcast on L1 and L5.

    SES-5 is to be stationed at 5 degrees east longtiude. A second SES satellite with EGNOS transponders is under construction. The SES Astra 5B satellite is scheduled for launch in the second quarter of 2013 and will be positioned at SES Astra's 31.5 degrees east orbital position.

  • Luch-5A Relay Satellite Arrives at New Position

    News courtesy of CANSPACE Listserv.

     

    The Russian SBAS satellite, Luch-5A, has been repositioned so that its sub-satellite longitude is 95 degrees east. The satellite had been drifting from its original geostationary position at 58.5 degrees east longitude since about May 30.

    The orbital slot of 95 degrees east had been previously announced for Luch-5B, so perhaps Luch-5A is switching positions with Luch-5B, which is scheduled for launch on August 30, although a recent Roscosmos presentation indicates the launch might not happen until October.

    Luch-5A is the first of a set of three geostationary satellites being launched to reactivate Roscosmos’s Luch Multifunctional Space Relay System. The system will be used to relay communications and telemetry between low-Earth-orbiting spacecraft, such as the the Russian segment of International Space Station, and Russian ground facilities.

    The satellites also carry transponders for the System for Differential Correction and Monitoring (SDCM), Russia’s satellite-based augmentation system. The transponders will broadcast GNSS corrections on the standard GPS L1 frequency using C/A PRN codes assigned by DoD’s Global Positioning Systems Directorate. Luch-5A was assigned PRN 125; Luch-5B, PRN 140; and Luch-5V (previously called Luch-4), PRN 141.

    Luch-5A was launched on December 11, 2011.

  • The System: British Patent Filings Threaten GPS III and Galileo Progress

    Two British technologists backed by the U.K. Ministry of Defense have filed patents on the future interoperable GPS and Galileo signal designs that severely disrupt modernization plans for both systems and suddenly, unexpectedly place receiver manufacturers in a highly uncertain and unfavorable situation. Some of the patents have been granted in the U.K. and in Europe, and applications are pending in U.S. patent court, with a ruling expected at any time.

    Companies in the United States and outside the country are being approached and asked to pay royalties, on the basis of the patent filings, for use of the European E1 Open Service signal and the modernized GPS L1C signal. Should such initiatives prevail, costs would presumably be passed along to end users of GPS and Galileo — the same taxpayers who have already paid once for the systems.

    The purveyor of the royalty solicitations is Jim Ashe, vice president for sales and intellectual property at Ploughshare Innovations Ltd., Hampshire, UK. The patents, if successfully used to collect fees from satellite manufacturers or receiver manufacturers, would have a chilling effect on the use of the new interoperable signals that all parties have labored so hard, for so long, to design. They could quite possibly lead to a return to a BOC(1,1) structure for these signals, losing the benefits of MBOC.

    “There’s quite an argument going on,” said one person familiar with the controversy. “Some of the methods of arguing have not been too kind.”

    The Background. A great deal of work was accomplished cooperatively between the United States and the European Union (EU) to develop the landmark 2004 signal agreement that emerged from the Galileo Signal Task Force, formalizing cooperation on satellite navigation between the United States and more than two dozen European countries, including the U.K. Part of that agreement concerned a common signal structure (spectrum) for the civilian signals for both the E1 Open Service (OS) signal — the Galileo equivalent of GPS L1 — and the new U.S. GPS L1C signal to be implemented on the GPS III satellites, coming as early as 2015.

    The EU said during that process, in effect, “Even though we have agreed on this, Europe wants to be able to optimize the E1 OS signal beyond the agreement on that civilian signal being a binary offset carrier BOC(1,1) signal.” Both international entities had agreed that would be the waveform or the spectrum of the new signal.

    The Europeans began to evaluate methods of optimizing their signal. They had some designs called composite binary coded symbols (CBCS), a mechanism of putting a higher frequency componenent into the signal structure, and also a version called CBCS*, meaning that they found there was a bias generated by that extra signal, and so they had to invert every other one of its repetitions.

    The signal structure that they were playing with was centered on a plus and a minus 5-MHz component. (Actually five times 1.023, because of the inherent clock of GPS, you can think of it as 1.023 MHz. Everyone in doing compatible or interoperable signals agreed upon that; when reference is made to 5 or 10 MHz, or an even 5 or an even 10, it means that number multiplied by 1.023).

    The Europeans were were putting an additional BOC signal on top of the BOC 1,1, and it would have plus or minus 5 MHz as the centers of those two BOC peaks, and then some kind of waveform to modulate that.

    The United States pushed back against that to some degree, and proposed adoption of the so-called MBOC waveform, in which case the U.S. signal was equally optimized with a concept called time-multiplexed BOC (TMBOC). The Europeans used the CBOC approach. So, very different ways of doing this. In the European way, they transmitted a continuous but very low-power BOC(6,1) term. The U.S approach transmits four BOC(6,1) chips out of every 33 chips of code (see “Future Wave” sidebar).

    A chip in this case means a part of the spreading code, so each signal has its spreading codes, just like the C/A code is a spreading code, meaning a pseudorandom code modulating the carrier. L1C and E1 OS have a pseudorandom spreading code.

    The U.S. approach does not put BOC(6,1) components onto the data; that’s what is commonly called MBOC. The U.S. approach is TMBOC, on the pilot carrier only, not on the data component. The European system is like two separate signals, the BOC(1,1) signal having both pilot and data, and a BOC(6,1) signal having both pilot and data. They’ve put the (6,1) into both data and pilot components.

    Cue the Antagonists. Part of the task force from Europe and the United States considering the future signals’ make-up were Tony Pratt and John Owen, who works for the U.K. Ministry of Defense and whose office sponsored Pratt’s work. The two participated heavily in all these signal discussions. They stated in early meetings they planned to file patents in some areas.

    “Frankly,” states one source, “people should have paid more attention when they said that, and asked ‘What do you mean, and how’s it going to work, etcetera?’ And secondly, there probably should have been a written agreement between parties that nobody will take advantage or patent any of these ideas that we are developing.”

    Pratt and Owen filed a number of patents domestically, in the U.K., and and in the European Union, in 2003 and in 2006, and in other places around the world, such as Japan, Canada, and in the United States as well. Some of the U.K. and European patents have been granted. The first of some of those U.S. patents may be issued in the near future.

    The original patent filings were later amended to include new claims. The new claims were much more specifically oriented toward TMBOC and CBOC, whereas the original claims were more generally oriented toward modulated methods. The claims have been modified over the years; this is fairly standard patent practice.

    As a result, the original 2003 patent doesn’t necessarily read on a particular signal, but its early filing date has precedence. The claims have been updated and modified, and if the patent office issues those, as a true patent, then the new claims apply. Plenty of big patent battles have been fought over just such issues.

    Once the patent is issued, a satellite or receiver  manufacturer must assume that it is valid, and has only two responses to make, other than acquiescing to royalty claims. The manufacturer can either say, if building a product, “No, my product does not infringe, and I will prove that it doesn’t.’” The other choice for manufacturers is to go back into the patent office and sue the patent filer (and grantee) in the patent courts and prove that the patent was invalid in the first place that the patentee should not have been granted it.

    The United States and others were taken off-guard when the U.K. company Ploughshare, which is owned and controlled by a part of the British MoD called Defense Science and Technology Laboratory (DSTL), started making claims on manufacturers. The DSTL is similar to the U.S. Defense Advance Research Products Agency (DARPA), which is credited with inventing the Internet. If taxpayer money goes into something new and interesting, it is considered in some circles legitimate to file patents on those and attempt to recover taxpayer money through royalties on that taxpayer investment. That concept is not being challenged. Questions as to whether the patents are legitimate are very much in discussion.

    Ploughshare has contacted companies, saying, “If you use these signals coming from either the European satellites or the U.S. satellites, we will go after companies using these signals.” There are different patents issued, one by the European Patent Office, applying to most of the EU countries, that applies directly to the TMBOC signal, the E1 OS signal, and possibly also to Europe’s E5 signal, which is E5a and E5b; and there is also a patent for GPS III, the L1C signal.

    The Devil. For details on the various patents, see Application 10594128 and Application 12305401. See also European patent specification EP 1 664 827 B1, and International Application WO2007/148081. These are examples; there are other applications as well. It is to be argued in some future court as to how those patents are to be interpreted.

    “If you take the patent that hits TMBOC, and you take the broadest possible interpretation of that patent against receiver companies, it says: if you bring into your antenna and process that signal, whether you use all parts of it or not, for instance if you use the BOC(1,1) and not the BOC(6,1) part — then you infringe the patent. Others argue that if you don’t use both components, you don’t infringe.

    “But the claim is written broadly enough that it would apply to any receiver receiving and processing the signal. Nobody says what processing means. The patent says if you receive and process the TMBOC signal, as defined in the prior claim, you infringe the patent.

    “There is confusion as to whether that will apply or not apply — some people expect that it doesn’t and some people think that it might. That’s up in the air.”

    George Is Getting Upset. Various factions in the United States are upset by and trying to figure out what to do about the impasse. From a government point of view, there are three paths that the U.S. government can follow:

    • Put pressure on the U.K. diplomatically. That would be up to the State Department to put pressure on the EU or the U.K. in particular. The EU and the continental Europeans are equally furious at the British for doing this, as far as parties in the U.S. understand. This can’t be stated as a fact but is widely understood and thought to be the case. The diplomatic approach has its limits, obviously.
    • Go into Europe and fight the patents in European patent court and try to prove them invalid, to invalidate the patents. Companies could do the same thing, go into various courts, whether they be U.S. or European or Japanese, and say: “Our receivers don’t infringe,” and then have to prove that to the court; or say “The whole patent should not have been allowed, and I’ll fight the legitimacy of the patent.”
    • Some believe — and there is controversy and anger on this point — that, just as Galileo’s IOV satellites have the capability to transmit without the BOC(6,1) component, the United States should be able to do that with the GPS III satellites as well. Because if the signal is not there, and if the receivers are therefore not designed to process the signals that are not there, then the patent no longer has any relevance.

    “If we are to turn off the BOC(6,1) term for a period of time until the legal or diplomatic or other approaches worked, then we would be able to turn the BOC(6,10) term back on again, and return to the original agreed MBOC and TMBOC signals. That requires some coordination between the United States and Europe, and it requires some work to make that possible in the GPS III satellites, putting a switch in the GPS III satellites to permit the operators to turn that (6,1)BOC on and off. This is being hotly debated.”

    Some parties object, stating that L1C is too important a signal to mess with, and this proposal runs the risk of slowing down the program, and/or making it more expensive. They believe strongly that the off/on switch is not the best or most far-sighted option: why should the United States be forced to change its signal design due to an illegitimate patent, and in the end wind up with a less capable system?

    It is not publicly known whether the Air Force is or is not looking into that option.

    During the week of June 25 there was Working Group-A meeting in Washington D.C. followed by a plenary meeting between the EU and United States. The patent controversy was presumably discussed in some fashion, but whether formally addressed or lurking in the background is unknown at this time.

    “There is some naivete around this,” said the magazine’s soure. “It’s a serious threat. People think maybe they’ll only go after the high-end receivers, and maybe the royalties won’t be so bad. Ploughshare is trying to lull people into a false sense of security. The impact of this will be great unless it is defeated.”

    Future Wave

    Excerpted from the “Future Wave” article on L1C, GPS World, April 2011:

    “The L1C waveform originally was to have been a pure BOC(1,1) (a 1.023 MHz square wave modulated by a 1.023 MHz spreading code). Negotiations between the U.S. and the European Union (EU) at that time resulted in an agreement that both GPS and Galileo would use a baseline BOC(1,1) signal. However, the EU reserved the right to further optimize their signal within certain bounds. Some of the optimization proposals were known as CBCS and CBCS*. However, in further EU/US discussions it was decided that L1C and the Galileo E1 open service signal should have identically the same spectrum. This was a significant challenge because of different baseline signal structures and existing designs.

    “The breakthrough came when [U.S. representative] John Betz proposed what is called MBOC. The MBOC waveform has 10/11th of its power in BOC(1,1) and 1/11th in BOC(6,1). However, L1C and E1 OS achieve this result in very different ways. The Galileo technique is called CBOC. The GPS technique is called TMBOC. Whereas Galileo has a 50/50 power split between pilot and data and includes the BOC(6,1) component in each, GPS includes the BOC(6,1) waveform only in the pilot component by modulating four of every 33 spreading code chips with a 6 MHz square wave and 31 chips with a 1 MHz square wave. With 75 percent of the power in the pilot, the result is 3/4 x 4/33 or 1/11, as required. It is likely the BOC(6,1) signal component will be ignored by consumer-grade GNSS receivers where a narrow RF bandwidth is preferred. Fortunately that is a loss of only 12 percent (0.56 dB) of the L1C pilot power. However, for commercial and professional grade receivers, the extra waveform transitions (wider Gabor bandwidth) can be used to improve code tracking signal-to-noise ratio, and with certain advanced techniques it should be possible to improve multipath mitigation. This final point depends on careful control or calibration of the transmitted code timing and symmetry.”

    EGNOS and Galileo IOV Satellites Shift Right

    The next EGNOS satellite, originally scheduled for a June 18 launch, now has a rise date of July 7 from Baikonur Cosmodrome in Kazakhstan. The launch was delayed by a problem with a first-stage subsystem on the Proton rocket. SES-5 is also known as Sirius 5, stemming from the development of the Sirius satellite constellation by Nordic Satellite AB, now owned by Luxembourg’s SES.

    The satellite carries a transponder for the European Geostationary Navigation Overlay Service (EGNOS). The transponder is intended to eventually replace or one of those on the currently used EGNOS satellites (Inmarsat 3-F2 at 15.5 degrees west using PRN 120, Artemis at 21.5 degrees east using PRN124, and Inmarsat-4-F2 at 25 degrees east using PRN 126 and designated for industry tests).

    Unlike the present L1-only EGNOS satellites, SES-5 will have transponders on both L1 and E5 frequencies similar to the Wide Area Augmentation System satellites, which broadcast on L1 and L5.

    SES-5 is to be stationed at 5 degrees east longtiude.

    A second SES satellite with EGNOS transponders is under construction. The SES Astra 5B satellite is scheduled for launch in the second quarter of 2013 and will be positioned at SES Astra’s 31.5 degrees east orbital position.

    Role Switch. On March 22 and 23, Inmarsat-4-F2 at 25 degrees east using PRN126 and Artemis at 21.5 degrees east using PRN124 switched roles. PRN126 became an EGNOS operational signal-in-space satellite, while PRN124 became the test satellite, transmitting message type 0. PRN120 and PRN126 returned to service around 17:00 UTC on Tuesday, June 26.

    According to an EGNOS service announcement dated April 3, the switch was due to the aging state of the Artemis satellite.

    Galileo October Birds. According to a usually reliable source, the launch date for the second set of Galileo IOV satellites, previously announced as September 28, has been pushed back a couple of weeks to October 12.

  • The Business — July 2012

    Download the PDF.

  • Real-Time Extended GNSS Positioning: A New Generation of Centimeter-Accurate Networks

    A new method brings together advantages of real-time kinematic (RTK) and precise point positioning (PPP) in a technique that does not require local reference stations, while still providing the the high productivity and accuracy of RTK systems with the extended coverage area of solutions based on global satellite corrections. The real-time centimeter-level accuracy without reference-station infrastructure is suitable for many market segments — and is applicable to multi-GNSS constellations.

     

    By Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka

    Real-Time eXtended (RTX) positioning is a technology produced by combining a variety of innovative techniques, which together provide users with centimeter-level real-time position accuracy anywhere on or near the Earth’s surface. This new technique is based on the generation and delivery of precise satellite corrections (that is, orbit, clocks, and others) on a global scale, either through a satellite link or the Internet. The innovative aspects of the new solution can be divided into different categories, which directly relate to the areas that have previously limited the provision of global high-accuracy positioning:

    • Integer-level ambiguities derivation;
    • Real-time, high-accuracy satellite corrections generation;
    • Data transmission optimization;
    • Positioning technology.

    Because of various new aspects of the technique, RTX differs from both differential RTK and precise point positioning as currently understood by the general GNSS community.

    System Overview

    RTX technology is used to provide centimeter-level GNSS positioning through the CenterPoint RTX service. Figure 1 shows the general infrastructure of the system.

     

    Data from monitoring stations distributed around the globe are collected and transmitted via the Internet to operation centers at different locations. The complete operation centers (enclosed by the red dashed square) are redundant in order to assure the very high (~100 percent) availability of the system. In case it is needed, the correction stream source might change between operation centers and/or processing servers within centers. These operational changes are handled in a deterministic way by all parts of the system including the user receiver. Inside the operation centers, redundant communication servers relay the network observation data to the data processing servers, which host the network processors that produce precise orbit, clock, and observation biases valid for any place on the globe.

    After being generated, the precise satellite data are compressed in messages compliant with the CMRx format, specially developed for compact transmission of satellite information. The messages are finally routed to either a satellite uplink station or made available for Internet connection access by the users.

    The CenterPoint RTX tracking network currently consists of around 100 stations, distributed across the globe, as shown in Figure 2. The CenterPoint RTX service is currently offered in North and South America, via satellite link, as indicated in Figure 3. Today the CenterPoint RTX service has been made available globally for all those with Internet access.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 2. CenterPoint RTX tracking network distribution. (Click to enlarge.)
    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 3. CenterPoint RTX L-band satellite service coverage in the Western hemisphere.

    Limiting Factors

    To understand the limiting factors associated with global high-accuracy positioning, it is helpful to consider the simplified basic GNSS observation equations for carrier-phase and code measurements:

    Φi=ρ+c(dT−dt)+T−Ii+λi Ni,
    +Ai−ai+λi(WΦ−wΦ)+BΦ,i−bΦ,i+MΦ,i+nΦ,i
    and
    Pi=ρ+c(dT−dt)+T+Ii,
    +Ai−ai+BP,i−bP,i+MP,i+nP,i

    where:

    Φi    is the carrier-phase measurement for frequency i in meters;
    ρ    is the geometric distance between the antennas of the receiver and satellite in meters;
    c    is the speed of light constant in meters per second;
    dT    is the receiver clock error in seconds;
    dt    is the satellite clock error in meters per second;
    T    is the slant neutral atmosphere delay in meters;
    Ii    is the ionospheric delay for frequency i in meters;
    λi    is the carrier-phase wavelength for frequency i in meters;
    Ni    is the integer carrier-phase ambiguity for frequency i in cycles;
    Ai    is the combined receiver antenna offset and directional variation correction for frequency i in meters;
    ai    is the combined satellite antenna offset and directional variation correction for frequency i in meters;
    WΦ    is the receiver antenna phase wind-up effect, in cycles;
    wΦ    is the satellite antenna phase wind-up effect, in cycles;
    BΦ,i    is the carrier-phase receiver bias for frequency i in meters;
    bΦ,i    is the carrier-phase satellite bias for frequency i in meters;
    MΦ,i    is the carrier-phase multipath for frequency i in meters;
    nΦ,i    is the carrier-phase observation noise and other un-modeled effects for frequency i in meters;
    Pi    is the pseudorange measurement for frequency i in meters;
    BP,i    is the pseudorange receiver bias for frequency i in meters;
    bP,i    is the pseudorange satellite bias for frequency i in meters;
    MP,i    is the pseudorange multipath for frequency i in meters;
    nP,i    is the pseudorange observation noise and other un-modeled effects for frequency i in meters.

    The feasibility of high-accuracy absolute positioning relies on the assumption that phase and code measurements on the different frequencies or on specific observation combinations are modeled quite reliably. This ultimately means that the parameters (or certain combination of them) of the two equations given are known very precisely, that is, with an accuracy of better than a few centimeters.

    Having a global system where every component of the un-differenced GNSS observational model is well known requires advanced understanding and modeling of the involved GNSS-related effects. This is a general achievement of the RTX system.

    (An extensive section here, encompassing satellite orbits and clocks, receiver clock error, antenna phase center odeling, phase wind-up effects, neutral atmosphere delay, and ionospheric delay, appears in the online version of this article, at env-gpsworld-integration.kinsta.cloud/rtx.)

    Real-Time Network Processing

    As previously stated, the RTX system works based on precise satellite information generated at processing centers and broadcast to users. The precise information employed by the systems comprises satellite orbits, satellite clocks, satellite biases, and other auxiliary information.

    The requirements for the satellite orbits to be used in the global RTX system can be summarized as accuracy, continuity, robustness, and reliability. The satellite positions have to be accurate for obvious reasons, including the fact that orbit errors have direct impact on rover-position determination quality. Furthermore, because the RTX network process algorithms use ambiguity resolution, the reliability of the ambiguity determination is highly affected by the satellite orbits quality due to the distances between reference stations in the tracking network. The continuity requirement is put in place to avoid the need of handling observation modeling inconsistency over time for both network and rover processing.

    For the same reason, the overall system employs techniques to properly handle switches between redundant orbit-processing servers without degradation of position quality. As one would expect, network processors have to be, in general, robust against the eventuality of poor data entering the system for various reasons. The RTX network processors employ a variety of quality-control techniques to ensure that only data with the highest expected quality is used for the computation of end products.

    Finally, reliability is a very important factor for real-time orbit processing. At the current stage, the RTX real-time orbit processors are able to run for several months with virtually zero intervention from operators, while handling events such as satellites going through unhealthy periods and satellite maneuvers (during unhealthy period or not).

    There are at least two strong reasons for justifying the need of implementing and running an RTX proprietary orbit processing server. The first one is simply the need of reliably meeting the above-mentioned requirements. The second one is that from an operational perspective, the RTX system is conceived in such a way that it does not rely on any external source of information to run at its full accuracy capability. Figure 4 shows the achieved orbit errors provided by IGS ultra-rapid products during two weeks of March 2011, where IGS rapid orbit products are used as truth. The ultra-rapid orbits are evaluated using the initial portion of the predicted arc, thus making use of the most reliable part of the predicted arcs as the products become available in real-time. In that case, neither accuracy nor continuity requirements for RTX processing are completely met.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 4. IGS ultra-rapid orbit errors, as compared to IGS rapid orbit products.

    Orbit Estimation. The orbit estimation in the CenterPoint RTX system is based on a combination of a UD-factorized Kalman filter estimating satellite position, satellite velocity, troposphere states, integer ambiguities, solar radiation pressure parameters, harmonic coefficients, and Earth-orientation parameters. The prediction step in the filter uses a numerical integration of the equations of motion in connection with a dynamic force modeling. Forces considered in the approach are: the Earth’s gravity field, lunar and solar direct tides, solar radiation pressure, solid earth tides, ocean tides, and general relativity.

    In RTX orbit processing carrier phase integer ambiguities are resolved in real-time. Also, the satellite orbit states are truly estimated in real-time and continuously adapted over time to better represent the current reality. This means that the satellite positions that are evaluated by the user have prediction times of no more than a few minutes since the last orbit processing filtering update, providing negligible loss of accuracy. Figure 5 shows the orbit errors obtained from the RTX orbit processor. Similarly to the previous figure, IGS rapid orbit products are used as reference. The time span is also the same as in the previous figure. The RTX real-time orbit components have a typical overall accuracy of around 2.5 centimeters (cm), and a 3D error accuracy of around 4 cm, considering IGS rapid products as truth.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 5. RTX real-time orbit errors, as compared to IGS rapid orbit products.

    Clock Estimation. Satellite clock estimation forms an essential part of the RTX system. It plays a fundamental role on positioning performance due to a number of reasons. Satellite clocks map directly into line-of-sight observation modeling, yielding into a one-to-one error impact from clocks into GNSS observables modeling. Due to the same strong relationship, it is of fundamental importance that clocks are generated in a way to facilitate ambiguity resolution within the positioning engine. The processing speed of a clock processor is also of critical importance, due to the fact that any delay in computing satellite clocks is directly translated into correction latencies when computing real-time positions on the rover side. For that matter, one should keep in mind that regardless how late satellite corrections get to the GNSS receiver in the field, positions have to be provided to the user as soon as the rover GNSS measurements are available. Therefore latencies typically introduce errors into the final real-time position. In this article, we define real-time positioning as the computation of positions at the time when the rover observables are available, regardless of the latency of the correction stream. This is a necessary concept in order to support dynamic rover GNSS positioning.

    The RTX clock network processor was designed around the requirements discussed earlier. It computes clocks that are compatible with ambiguity resolution on the user receiver. As a matter of fact, the clock network processor itself employs ambiguity resolution for the generation of the RTX clocks. The processor architecture is based on an innovative design that allows processing data of several hundreds of reference stations, including all necessary steps such as data quality control, ambiguity resolution, and the final clock generation, within a fraction of second. The processing time of this kind of real-time network processor has to be minimized as much as possible in order to allow the processor to operate at 1 Hz, and to minimize the final correction latency at the rover end. Note that the final latency of the correction stream is a composition of three basic components: the time for the network data to arrive at the network processing server; the network processing time; and the correction transmission time to reach the final user. Figure 6 shows the typical total correction latency for the RTX system, when corrections are broadcast through a satellite link.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 6. Typical RTX correction stream latency. The dashed green line represents the latency at 50 percent (3.7 s), and the dashed red line represents the latency at 99 percent (5.6 s).

    Unlike satellite orbits, satellite clock solutions are more difficult to compare directly. This is because different clock solutions might have offsets between each other, as well as behave differently due to differences in their GNSS reference time realization process as well as in their observation modeling approaches. That said, one way of verifying the quality of satellite clocks is to quantify how well it can be used to model actual receiver observation data. This can be in general achieved by applying satellite orbit and clock correction onto GNSS data and verifying the remaining residuals. Other quantities such as receiver coordinates have to hold their correct values for the residuals to be meaningful. In this case, the combined satellite orbit and clock error are assessed, and not just the satellite clock alone. For our purposes this is perfectly fine, since this is the way orbits and clocks are employed in rover positioning as well. Figures 7 and 8 show typical combined satellite orbit and clock errors at line-of-sight for different satellites. Figure 7 shows the ionospheric-free phase modeling error for GPS satellites, while Figure 8 is for GLONASS. Note that observations of a reference satellite (highest elevation at the time of observation) were reduced from the others. This was done in order to remove the receiver clock errors from the residuals. For both GPS and GLONASS cases, the observation modeling error after using RTX orbit and clock corrections is on average at the 1 cm level, with values typically less than 2 cm. The GPS satellite with outlying behavior in the plot below was setting at that time, and the increased amplitude of the residuals is mostly due to receiver observation errors such as multipath.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 7. RTX clock quality (GPS) by means of corrected ionospheric-free phase measurements.
    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 8. RTX clock quality (GLONASS) by means of corrected ionospheric-free phase measurements.

     

    Communication and Positioning

    Once all satellite information is available, it must be compressed in a message that can be broadcast to the user in the field. The transmission of global corrections can be done in different ways, such as via Internet, in case the user has access to it, or using a satellite link. In the latter it is customary that corrections sufficient to cover the transmission satellite footprint are broadcast, rather than corrections complete enough to cover the globe. Firstly, because it is expected that users operating inside the satellite footprint will use the corrections only for that region, and secondly because bandwidth restrictions usually play a role in message design for satellite-based communication. The bandwidth restrictions not only enforce maximum bandwidth utilization below a certain limit, but also require that the utilization over time is homogeneous to ensure optimal usage of the satellite channel.

    Furthermore, satellite signals are typically susceptible to frequent message-packet losses depending on the user environment, such as when a receiver is running under canopy. To mitigate packet losses, the message must be built in such a way as to allow the rover to continue operations with minimum loss of availability. In that case not only the message design has to foresee this type of situation, but also the message decoding, usage, and positioning algorithms have to be optimized to most favorably couple with the received messages. All these factors have been taken into account in RTX system communication design. A new message format was created to carry information on satellite orbits, clocks, observation biases, and other auxiliary information. The new RTX CMRx satellite messages deliver 1-millimeter resolution for satellite orbits and clocks.

    The RTX positioning engine inherits several technological aspects from Trimble’s pre-existing RTK engine. This aspect makes the RTX positioning mode, and traditional RTK positioning modes (for example, single base, virtual reference station) easy to co-exist. Among other things, the new engine has been thoroughly tested and optimized for challenging tracking environments. In these scenarios the engine is presented with observation data collected with a high level of multipath and low signal-to-noise ratio, often producing cycle slips and gaps in the data. As previously mentioned, at the same time the correction stream also suffers packet losses and the correction data might not be completely available during certain masking conditions.

    Positioning Performance. The RTX engine delivers typical final accuracies at 1–2 cm level for horizontal positioning, and 2–4 cm for vertical, 1-sigma. The final convergence of the system is achieved in 10 to 45 minutes after receiver startup. The time to converge might depend on several aspects, including satellite geometry and multipath conditions.

    To overcome the increased convergence time as compared to traditional RTK systems, a number of features have been implemented as part of the RTX positioning engine, two of which are worthy of mention here. The Fast Restart feature allows users to power up or place the receiver at a known location and immediately obtain a converged solution. This is also applicable when users have not moved their equipment since the last RTX solution. This feature is quite valuable in agriculture applications, where the user typically does not move the tractor between RTX-steered field work activities, thus avoiding in the majority of cases the need to wait through a new convergence period before starting work, one or more days after the last system usage.

    The second feature is also related to avoiding system re-convergence. The Bridging feature, an outage recovery capability, enables the RTX positioning engine to immediately recover from a complete constellation outage with loss-of-lock during any dynamic activity. This prevents the system from entering a new convergence phase in case the receiver loses track of up to all satellites in view, coupled with outages of up to a couple of minutes, such as when running behind a tree line, or under a bridge.

    Accuracy

    Horizontal position error obtained in real time in a receiver acquiring the RTX correction data through the satellite link in North America is shown in Figure 9. The receiver was running continuously for several days, and was located in Ames, Iowa. As displayed, the horizontal RMS was 1.4 cm, with a 95 percent horizontal error of 2.4 cm. These are typical values for satellite-based RTX horizontal performance.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 9. RTX real-time horizontal positioning performance. Results obtained from a receiver operating in Ames, Iowa.

    Figure 10 shows the vertical performance for the same receiver and time period: the vertical RMS was 2.8 cm, with 95 percent vertical error of 4.4 cm.

    Time to Achieve Convergence. Convergence is directly connected to the level of productivity that can be achieved for actual field applications. In the following example a continuously powered RTX receiver was used to show an assessment of the RTX (re-)convergence capability. The receiver’s tracking of all satellites was disabled every hour by an antenna switch. Each outage lasted three minutes, during which times no GNSS satellites were tracked.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 10. RTX real-time vertical positioning performance.Results obtained from a receiver operating in AMES, Iowa, US.

    This procedure was repeated hourly for several days in order to gather enough performance runs to derive meaningful statistics. Figure 11 shows the resulting performance of this assessment. The standard cold-start re-convergence performance is indicated with blue lines, where the solid lines represent 90-percent performance and the dashed line represents 68-percent performance.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 11. RTX re-convergence performance results.

    As the figure shows, the RTX system converged to better than 5 cm horizontal error after 20 and 25 minutes for 68 percent and 90 percent of the runs, respectively. Convergence time is correlated with a number of aspects, including satellite geometry and multipath environment. Because of these variations, the claimed RTX convergence time is between 10 and 45 minutes for full accuracy achievement.

    The red lines in Figure 11 indicate performance obtained with a second receiver, connected to the same antenna, and thus subject to the exactly same GNSS signal outages. This second receiver had the Bridging functionality enabled, and thus is expected to bridge the outages and phase cycle slips without resetting the positioning solution. The red lines confirm that the desired behavior is achieved. To better visualize what happens over time in this case, Figure 12 shows a few hours of the real-time results obtained with the receiver running with the Bridging functionality activated.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 12. RTX outage recovery real-time performance.

    Figure 13 gives an example of Internet protocol (IP)-based RTX performance. This is a single run where the system converged to better than 5 cm (horizontal) in approximately 15 minutes. Figure 14 shows how the L1 ambiguities of individual satellites in view during that time converged.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 13. RTX IP-based run example.
    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 14. Example of ambiguities convergence during an RTX IP-based run.

    In these two plots, positioning convergence is, as expected, highly correlated with the ambiguities convergence to their final integer values in cycles. Note that satellites that come in after the overall solution is converged (for example, in light blue) achieve their final ambiguity values much quicker than during the position convergence phase, also as expected. The proprietary algorithms used for ambiguity resolution and validation in RTX allow the ambiguities to reliably converge to their integer values. Arbitrary integer number of cycles have been removed from the original ambiguity values to allow better simultaneous visualization of the ambiguities for several satellites.

    Optimizing the RTX system to work under different scenarios was necessary because the multipath and signal availability levels are reasonably different between running an antenna with a reference station setup and the actual user environment, where the data tracking conditions impose additional challenges on making high-accuracy positioning effective on a global basis, in a productive manner. Therefore, an extensive field test campaign was conducted during the pre-release phase of the RTX system. The next example shows RTX in-field performance for an precision agriculture application in Illinois. The setup is typical for agricultural use, with the antenna and receiver mounted on a tractor that ran for about 103 minutes. Figure 15 shows theactual track of the tractor; RTX corrections were received via satellite link.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 15. RTX tractor field test track in Illinois.

    The horizontal positioning performance for that field test can be seen Figure 16. The overall 2D RMS was 2.3 cm and the 95 percent horizontal error was 4.2 cm. Note that this position difference plot is between the RTX solution and a short-range single baseline (SBL) RTK solution providing truth. Therefore the numbers and plot actually show a combination of errors between the global RTX solution and the SBL solution to the local reference station.

    Photo: Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka
    FIGURE 16. Horizontal positioning results for a real-time RTX tractor field test in Illinois.

    Nevertheless the error magnitudes achieved lie within the same range as in the previous assessments shown here.

    Summary

    RTX positioning brings together the advantages of positioning techniques that do not require local reference stations while providing the productivity of RTK positioning. Its deployment introduces innovations in GNSS network processing, as well as advancements in the rover global positioning algorithms.

    RTX employs ambiguity resolution on a global scale for both network and rover processing, including GPS and GLONASS satellites in the solution. The delivery of this new technology is achieved through the CenterPoint RTX positioning service, capable of providing world-wide real-time centimeter-level accuracy without the direct use of a reference station infrastructure.

    A longer version of this article was presented at the 2011 ION-GNSS conference in Portland, Oregon.

    Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka are members of the Trimble Engineering Team in Höhenkirchen, German

  • Expert Advice: Mobile Computing on the Rise

    This discussion of current trends in location-enabled mobile devices takes as its foundation the different operating systems (OSs) for those devices. Why? For GPS/GNSS hardware units to be useful, there have to be software applications — apps — also riding on those units. Apps are totally dependent on the operating system. An analogy is that the operating system is the foundation of a house and the app is the house itself. The type of foundation you have drives what type of house you can build.

    For example, no one is going to write an app today for Palm OS because that OS is essentially dead. While that’s an obvious one, a not-so-obvious one is Microsoft Windows Mobile. Most apps written for professional users are written in Windows Mobile, but Microsoft hasn’t done a good job of communicating its intentions regarding Windows Mobile, so users and developers think Microsoft may abandon it.

    On the other hand, Android is gaining so much momentum. Will developers rewrite their apps from Windows Mobile for Android? Or for Apple’s iOS? Can they afford to? Can they afford not to? If they don’t, that would mean that fewer professional apps will be available for Android and iOS users. Will that mean Windows Mobile will be the OS for professional GPS/GNSS users, and conversely, will Android/iOS be the OS for consumer-level GPS/GNSS users? Taking it to a practical conclusion, according to the type of mobile computing device that you purchase, what kind of location application will you be able to use?

    Photo: Apple
    Smartphones. Apple iOS’s new Maps app will likely be the largest scale crowd-sourced app ever introduced.

     

    PNDs Out-Smarted

    For the past decade, GPS personal navigation device (PND) sales have burned white-hot. In 2007, Garmin experienced double- and triple-digit growth, selling more than 10 million units. TomTom grew from zero to hero and sold more than 9.5 million units in that same year. During that brief golden era, every consumer electronics company who was anyone took a stab at introducing a PND to get a piece of the action. As unlikely as it seems, Garmin and TomTom stayed on top, fighting off consumer electronic giants like Sony, Panasonic, Hewlett-Packard, and Philips, all orders of magnitude larger. PNDs ruled the GPS world during that era.

    Credit: GPS World
    Download a PDF of our Mobile Computing Product Showcase.

    At the height of that period of explosive GPS PND growth, Apple introduced a new generation of smartphone, the iPhone, in January 2007. At that time, there were approximately 17 million smartphones on the market. Nokia with its Symbian operating system led the pack at 63 percent of worldwide market share, Blackberry was the rising smartphone of choice, while Microsoft Windows Mobile operating system captured 18 percent. Google’s Android operating system had not yet debuted.

    It’s amazing how a mass-market technology, so personal to us all, can change so quickly. Today, Google’s Android operating system dominates the smartphone market (roughly144.4 million smartphones were sold in Q1 alone of 2012, according to Gartner Research) with a 56.1 percent share. Apple’s iOS follows at 22.9 percent; Symbian (Nokia) has fallen from leader to bit player at 8.6 percent, and keeps company in the low rungs with RIM/BlackBerry (6.9 percent), Samsung’s Bada (2.7 percent), and Microsoft Windows (1.9 percent).

    The trend is clear. Android and iOS are cleaning up at the expense of all the others. Is it any coincidence that these two are the ones making the most of their maps and nav? More on this in a moment.

    By the way: every one of the 144.4 million smartphones that shipped in the first three months of 2012, no matter what operating system it ran on, carried a GPS receiver inside, typically a chipset from Broadcom, CSR/SiRF, u-blox, Qualcomm, or Texas Instruments. That spells trouble for Garmin and TomTom. Google and Apple are doing to Garmin and TomTom what Microsoft did to NetScape with Internet Explorer.

    Even with GPS PND prices at an all-time low, Google’s Navigator, with high-quality, PND-like turn-by-turn street navigation, is included on Android smartphones free of charge. Apple is following suit. Just last month, Apple introduced the Maps app for turn-by-turn street navigating as well as real-time traffic information. With more than 100 million iPhones behaving like traffic sensors, Apple’s Maps app will likely be the largest scale crowd-sourced app ever introduced.

    What does this mean to Garmin and TomTom? The numbers don’t lie. In February 2012, TomTom reported a 40 percent decrease in GPS PND sales for Q4 2011 compared to Q4 2010.

     

     

    Tablet Computers

    For another wild ride, take a look at the tablet-computer market. The tablet has been around for many years. I remember playing with them in the 1990s when they were horribly expensive ($3,000–$5,000). The price, a limited outdoor-viewable display, and power usage all combined to squash unit sales. Only a few manufacturers such as Fujitsu had the determination to stay. That all changed in 2010 when Apple introduced the iPad.

    Prior to the iPad rollout, tablet computer sales were limited primarily to business users. Healthcare provided a particular arena for Fujitsu and others to focus on, and there were a few other markets that were not very price-sensitive, and so receptive to the tablet. The iPad blew away that $3–5K price point (iPad 2, $629) and brought the tablet experience to the average consumer. The result? Roughly 67 million units sold since its introduction, far surpassing all tablet computer unit sales in history in just two years. Apple hit a sweet spot, for sure.

    The iPad catalyzed the tablet industry for two reasons:

    • It opened the eyes of the consumer to the applications of a tablet computer.
    • It drove the price-point expectation of all tablets down.

    Of course, the iPad has its limitations. It runs Apple’s proprietary operating system, iOS, so you are limited to the number of apps written for that platform. It also lacks horsepower to run more challenging programs that an Intel or AMD-based computer can breeze through. From a GPS/GNSS perspective, certain models of the iPad sport a GNSS chipset (from Broadcom) similar to mobile phones; however, because of the way the GPS functionality is designed into the system, accuracy is limited to a few meters at best. Power GPS/GNSS users would love it if Apple would implement serial port profile (SPP) in its Bluetooth software. Then, GPS/GNSS users could attach any Bluetooth-compliant GPS/GNSS receiver they like, even RTK-capable receivers for centimeter-level accuracy. But Apple doesn’t seem interested.

    As in the mobile-phone market, Google is making a strong tablet play with its Android operating system. Google’s device-agnostic operating system is attracting tablet hardware makers in droves with iPad-like tablet computers, notably Samsung Galaxy (with GPS) and Amazon Kindle Fire (no GPS). Also, there’s an interesting link between mobile phones and tablets. Gartner reports that 40 percent of user apps run on both mobile phones and a corresponding tablet computer. This is significant because the operating system may well drive the tablet purchase. For example, a person with an iPhone is more likely to buy an iPad than a Samsung Galaxy, which runs Google Android.

    However, Android has not achieved the dominance in the tablet computer space that it has in smartphones. iOS (iPad) held 67 percent market share in 2011, falling to 61 percent in 2012,but still retaining the pole position. Android is a strong second with 29 percent in 2011, rising to 32 percent in 2012, according to Gartner. No other operating system even comes close.

    Gartner forecasts show that Android will eventually approach iOS in market share, and my guess is that it will overtake iOS within five years. Apple’s proprietary system will catch up to it. While GPS/GNSS chipsets aren’t as widely integrated in tablets as they are in mobile phones, that will change as GPS/GNSS use becomes even more ubiquitous. Further, there are plenty of ways to add GPS to a non-GPS model via Bluetooth, PCMCIA, and USB.

    Android supports Bluetooth SPP, or a derivation of it, so you can connect any Bluetooth SPP-compliant GPS receiver that you like and not be limited to the receiver chipset the tablet engineer decided to design into the system.

    ]Although PDAs have an embedded receiver, they are lower-precision systems, in the 1- to 5-meter range, largely due to poor antennas. For higher precision requirements, these are used as field data collectors connected to an external antenna and/or a high-precision GPS/GNSS receiver.Handheld PDAs

    Handheld personal digital assistants (PDAs) were all the rage 10 years ago when Compaq Computer Corp. introduced the iPAQ H3100 running Microsoft’s PPC2000 (Pocket PC) operating system, the precursor to Microsoft’s Windows Mobile operating system. The iPAQ made a strong run through 2009, with the last models running Windows Mobile 6 before smartphones became powerful enough to negate the purpose of the PDA.

    While we probably will never see another introduction of a new iPAQ-branded PDA, it was a useful device and an inexpensive handheld for interfacing to GPS/GNSS receivers. Albeit a niche market, there’s still a demand for such handhelds for field data collection.

    According to the nature of capitalism, where there’s a demand, suppliers will show up. Since the iPAQ has faded, and smartphones aren’t yet well-suited as field data-collection devices, a new breed of semi-rugged and rugged PDAs has emerged in the past year from small, niche-oriented companies. Examples include the SXPad from Geneq, Juno 3 series from Trimble, and the Mesa/Rampage 6 from Juniper Systems/SDG Systems.

    These devices, with GPS/GNSS receivers embedded, are not built for the average consumer. Their prices are higher — but coming down — and they are more rugged; some are water-resistant, some waterproof.

    In a nutshell, PDAs went professional, targeting organizations that need maximum data-collection productivity from field personnel. Although they have an embedded receiver, they are lower-precision systems, in the 1- to 5-meter range, largely due to poor antennas. For higher precision requirements, these are used as field data collectors connected via Bluetooth to a high-precision GPS/GNSS receiver.

    Although the professional PDA market is not immune to the operating-system wars we’ve seen in mobile phones and tablet computers, it’s a bit stickier. Professional data-collection apps have been written almost exclusively around the Microsoft Windows Mobile operating system. These niche software programs are written for relatively small audiences (compared to the mass-market apps on smartphones), and it can be economically tough to justify porting the apps to iOS or Android. Therefore, the professional PDA market has been slower in adopting iOS and Android.

    Microsoft hasn’t helped the cause. It stopped certifying new products with the Windows Mobile operating system, creating confusion in the user community. Is Microsoft exiting the mobile device business? Not according to the company. It appears that it has split the mobile device business into two operating systems. Smartphones will run Windows Phone, and other mobile devices will run Windows Embedded Handheld, which is compatible with Windows Mobile.

    The problem, the confusion, and the frustration come from the fact that the Windows Phone operating system is not compatible with Windows Mobile (or Windows Embedded Handheld). Microsoft split the market between smartphones and other Microsoft-driven mobile devices. Given Gartner’s research that 40 percent of users’ smartphone apps also run on a tablet device, this means that Microsoft is going to either change that dynamic or suffer the consequences.

    No matter which direction mobile devices take, be it phone, handheld, or tablets running Android, iOS, Windows, or something we haven’t yet seen, embedded GPS/GNSS functionality will remain the centerpiece of location technology in all mobile devices. Even more exciting are the new GNSS signals and constellations in the next five years that will bring unprecedented accuracy to all mobile devices, driving the development of a tremendous number of new apps to exploit the improving accuracy.

    Eric Gakstatter is contributing editor for survey at GPS World magazine and the editor of Geospatial Solutions. He has spent the past 20 years in the GPS survey/mapping industry, using many brands of GPS equipment and software. He is a non-partisan advocate for the GPS user community, and a frequent speaker at user and technical conferences.