A GNSS receivers’ function is to output a set of position coordinates after processing the reception of the signal broadcast by a constellation of GNSS satellites. Unofficially, the receiver’s grade used to be delineated by the accuracy that it could produce. A chipset would be capable of 5m CEP at best, while a geodetic class card could be tuned to achieve less than 1cm R95. With the advances in IC manufacturing and other innovations, however, that line is beginning to blur. In this blog post we compare these receiver grades along the signal processing chain, from reception at the antenna to a final position output.

Let’s begin with the antenna. In the geodetic class, the antenna element of the antenna connected to the receiver matters. This is the starting point where “garbage in – garbage out” is most applicable for RF designers. If you ever get the chance to look inside a geodetic class antenna, you may notice a whirlpool or vortex pattern in the element. While the fractal pattern is visually dazzling, the distance between the lines of the swirls is tuned and trialed painstakingly by RF engineers and designers to ensure the most stable phase center (the physical position in space at which the signals are received from the various azimuths and elevations of the satellites). This is the specific point of the coordinate. Manufacturers of such antennas are judged by the repeatability of the PCB routing with low tolerances.  

As for the GNSS antenna in the mobile handset, its design is dictated by the amount of space available in the handset device, trading off phase center stability for meeting signal sensitivity requirements. Stable phase center variation is predominantly wishful in this use case due to radio wavelength physics.  Furthermore, there are additional antennas in the handset that are connected to other transceivers that could interfere with GNSS reception, further fueling the chagrin of antenna designers already constrained by industrial design requirements.

Then there is the ability to track GNSS satellites. Correlation is the technique used to identify and lock onto a satellite. (Interestingly, it works very similarly to a song Identification service like Shazam and Soundhound.) In geodetic receivers, patented techniques are used singularly to lock onto satellites rejecting multipath signals to ensure a direct line of sight measurement. Consumer grade chipsets don’t have the computational resources to perform those advanced techniques and may even use a multipath signal. The shortcomings are mitigated with connectivity. Connecting to GNSS assistance services, like Location.io, to prime the receiver with information about the GNSS satellite’s location to increase its sensitivity in ranging to it.

The next part of the signal processing chain is measuring the distance to those satellites, correcting those measurements and, finally, determining an accurate location.  In the geodetic case, typically two of the exact make and model GNSS receivers with very high measurement fidelity are paired together. One is configured as a reference base station receiver and situated at an optimal vantage point to observe as many satellites as possible and generate corrections for them. These corrections are then delivered via radio modem directly to the rover receiver. The rover applies corrections from the reference base receiver based on the common satellites between them and outputs an accurate corrected position.  

The application of corrections also applies to consumer receivers. Both Geodetic and consumer grade rover GNSS receivers’ position accuracy benefits from corrections. But for consumer grade receiver use a typical user will not bother surveying the position of the base station reference receiver, or finding a survey monument to place the base station over,  let alone configure the radio modem connection. Nor will they buy a reference base station receiver, nor check the matching make and model. The device just needs a source of corrections and, similarly to how GNSS assistance is applied, what the receiver lacks in measurements fidelity is made up for in connectivity. This time, though, they have access to reference networks that supply observations to generate corrections at a wider area scale. Corrections services like Truepoint.io are ready for this.  A single base to single rover pair scales up to a reference receiver network serving many connected GNSS rover receivers.  

At the top of this post, I mentioned the delineation between consumer grade and geodetic grade is getting blurred. Developments in reference network coverage, RF ASIC design, positioning algorithms, network bandwidth and connectivity, have all made it possible for accurate positioning to almost be taken for granted. GNSS chipsets now have comparable measurements to Geodetic grade receivers when connected to assistance and corrections services to deliver an accurate position to whichever app on the handset needs it. This is not to suggest that geodetic grade receivers are outdated. In fact, they play a vital role in reference networks with their configurability and dedicated computational horsepower for the different aspects of tracking a GNSS satellite to ensure integrity. The accuracy produced by consumer grade chipsets will always rely on the observations the geodetic grade receivers produce. Albeit a little blurry, the line delineating a geodetic and consumer grade GNSS receiver turns out to be a connection between them.

Rx Networks will be exhibiting at ION GNSS+ this year in Denver, September 19-23.

Throughout the trade show we will be discussing our location.io assistance and truepoint.io accuracy data services.

Engineers will be onsite and available to discuss project and product requirements.

You can find us at booth #507.

Hoping to see you there!

Marshall McLuhan is a Canadian Philosopher and author of the now famous quote “The medium is the message”.  

The point he makes is that with technology being an extension of human functions it has societal impacts that shape the way we interact with the world. We need to watch for this!

Admittedly, having a predominantly technological background it was at first quite difficult for me to grasp this. In the literal sense, a medium carries a message. I was first introduced to this quote when I was studying 4th year engineering. I stared deeply into my Walkman, searching for the message that was the cassette tape. The only message I received then was that a slowdown in playback meant I needed to replace the batteries, or to hit stop immediately after noticing garbled audio because the chromium dioxide tape had become entangled with the strip roller and magnetic head.

Within a few short years I came to realize that the message McLuhan suggested was contained in the cassette tape was portability. Similarly, the CD’s message was digitization. The MP3’s message was distribution. Prior to the cassette, replay was the message in vinyl…opposed to live performance. I think we are yet to see the true message of streaming music services like Spotify, but I am placing one of my bets on it being Artificial Intelligence.

What about positioning and location technology? From a societal perspective, what can we infer is the message Marshall McLuhan would have us observe?

The GNSS receiver itself is an extension of our innate navigation abilities. We have evolved from being within visual range of a landmark and deriving a heading from a clear night sky, to using a receiver ranging to multiple satellites broadcasting their location, at any time and through any weather, and being able to compute an accurate latitude, longitude and height. The message of the receiver is a coordinate location on the planet.

With a coordinate system, and the development of DGNSS and RTK corrections techniques, precision enters the conversation, adding more digits after the decimal in a location coordinate. Many might say that the message of DGNSS and RTK is clearly accuracy, but what would McLuan say?

It’s possible to see that message as interconnection. In both corrections and techniques, the rover receiver is comparing its measurements to the satellites with the base station’s measurements. Since a base station has a better view of the sky, it is considered the reference to generate measurement corrections from. Those corrections are applied to the rover’s measurements to common satellites with the base station generating a differentially corrected position. Connecting the base-rover pair was a radio modem to transfer those corrections from the base to the rover.

In the data sheet of any commercially available GNSS receiver / chipset there is an accuracy listed for Single Point, DGNSS and RTK, where the latter two show much better accuracies than single point. Deeper in the manual you can find instructions for connecting to another receiver for corrections. Considering Assisted GNSS, the receiver needs to connect to a server to download and store predicted ephemeris for the next fast powerup.

Historically, position output from a receiver was always best when connected to an A-GNSS server and corrections network. Now, telecommunications infrastructure has enough coverage and bandwidth with good economics to support multiple GNSS constellations and contemporary corrections techniques like PPP and PPP-RTK.

The interaction between a GNSS receiver and its integrated device has become symbiotic. A GNSS receiver needs a connection to a GNSS data service for a good position and the device itself needs an accurate position to attach to its purpose. Separately, they might not reach their full value potential. They need each other. This is commonly seen in IoT devices integrating GNSS technologies with growing accuracy requirements. This brings us to the next message, which I propose is spatial context.

Coordinates are simply a set of numbers representing a point in space and time. That coordinate aligns with other descriptions and telematics of that point for a fuller picture of what is happening. With additional points connected in the same way we can derive a situational overview in realtime and take informed actions.

Take for instance the decision to purchase a meal from a restaurant visited for the first time. With a few taps on a smartphone a pin appears on a map relative to your position, complete with links to ratings and reviews. A menu and pricing can be accessed, busy times, reservation and sharing options, even recommended modes of transportation to get to the restaurant. You could even access the street view to see what the entrance of the restaurant looks like to determine if you should drive or walk. Today, we have full spatial context. Accuracy in positioning becomes essential.

Back in the day, most of us would have given up the search after discovering the page listing the restaurant address and phone number had been torn out of the phone book. Only the truly committed would search out another phone booth with an undamaged directory, only to then search the address on a spiral bound city street map that was likely out of date. Choosing the restaurant by name alone was certainly a gamble. Almost as risky as trusting a brand new cassette in a hungry Walkman.

Before I type anything more that might give away my age, I’ll end this post with another of McLuhan’s profound quotes: “We shape our tools and thereafter the tools shape us.”

Touché

Choosing between more or less accuracy has never been much of a consideration (or an option), historically.  The specified requirement has predominantly been “The most! Our device requires the most precise accuracy available.” But today, considering the options, it’s fair to ask: how much accuracy does your device or application need, really?

With RTK came the phrase “addiction to accuracy”. Establishing the subsequent adoption of GNSS receivers to commercial applications – 1cm accuracy was achieved. The forecast benefits for agriculture were immediately realized. Successive swaths over crops no longer had overlap or underlap, improving precision while saving time and diesel fuel. Tractor tires and steering could be guided between crop rows, allowing for seeds to be planted closer together, increasing the crop yield. Pest management programs improved with the adoption of spot treatments (over a blanket approach), ultimately saving costs, with the more precise management of expensive pesticides.

GNSS as a utility was then further developed. Depending on the positioning technique that a positioning engine or GNSS receiver used, accuracies were described by horizontal spread in centimeters, and 2cm accuracy became the golden standard, written into the requirements of many applications. But for a pedestrian use case, what is the technical return on investment for accuracy and what is considered overkill? With the technology and infrastructure,  it is arguable to say accuracy worse than 5 meters in most cases is dismissed as being as good as 100 meters.” Instead of asking  how much accuracy is really needed, perhaps a better question would be “How would you use more accuracy?”

Take the classic  GPS experience: “You have arrived at your Destination”, for example. These GPS devices served us well (for the most part), navigating us through unknown neighborhoods and alleviating our minds of recalling the exact order of left and right turns ahead. GPS allowed drivers to concentrate on driving, and getting lost was no longer an excuse for being late. Even if we missed the turn, the friendly voice let us know it was “recalculating” the route, making the navigational transgression solvable on the fly. Spontaneous trips into an unfamiliar city or neighborhood were now made confidently, and comfortably. But on its inception, this GPS technology delivered accuracies of just tens of meters. Arrival was declared a little late or early and, at worst, there may have been some critical moments when notified to make a turn…immediately.  

Tens of meters of accuracy? How were we still successful with this? Well, our built-in human resources were relied on to take care of the finer details of the trip. Once we could see the destination we could simply park or walk over to it. The two positions relative to each other were the vehicles and the locations. Did it matter if the position said we were at the entrance gate even though we still had about 25 steps to get there? Not really. We still got there. 

Then, on the other hand, there’s surveying. Identifying the exact point on the surface of the planet where the corner of a large building should be located brought legal implications with right of way, and boundary disputes between adjacent neighbors. Land ownership was quantified by boundaries established. The Certified Land Surveyor made this boundary physical with an iron property stake driven into the ground within 2.5 centimeters.  With an Iron stake actually being ~ 2.5cm in Diameter, there is little point (pun intended) in 1mm accuracy.

How about lane level accuracy…a term used to describe the accuracy needed for autonomous vehicles and other vehicle tracking applications? The two objects that need to be positioned relative to one another are the car and the lane it’s intended to be traveling in. The average width of a car is 6.5 ft or 2m. The average width of a highway car lane is 12ft, or approximately 4m. To keep this error budget example simple, assume these figures apply to all cars and all roads. Given these parameters we can estimate the car’s position may have a cross-track error of 1m, assuming the GNSS antenna on the car is right in the middle of it. Knowing that we are safely in the lane (need) is different from knowing where we are in the lane or where we are in the car in the lane (could be more of a want than a need).  

In each of the examples discussed here GNSS data corrections may have been needed for the device to compute the required position accuracy. There is a critical level of accuracy that contributes to the intended outcome.  This level is indeed different based on what the positioning is used for.  After this point, the extra accuracy may not be making any other technical contributions to the overall solution. Given that the complexity of the corrections service has a direct impact on accuracy and cost, hopefully this post helps in identifying the right corrections service to be streamed into your receiver.

Dual Frequency GNSS is considered a giant leap forward in the evolution of GNSS technology. It overcomes ranging errors generated in the Ionosphere, where a storm of electrons bend a single frequency line of sight to the satellite, adding length to the range (for the spatial thinker) or delay (for the frequency time thinker). When you observe two frequencies from the same satellite, the difference between their measured behavior and their known theoretical behavior in the vacuum of space  indicates the ranging error being caused by the Ionosphere.

A logical step forward on the path to ruling out Ionospheric ranging errors further is the introduction of a third frequency into the mix. At the time of writing, GNSS hardware manufacturers are betting on triple frequency GNSS technology lending even more clarity to the Ionospheric effect. If economics were not a constraint in building an ideal infrastructure focused solely on supporting absolute positioning performance, a gold standard like octuple GNSS frequencies would make ranging to a satellite through the Ionosphere equally as accurate as ranging to that satellite through a vacuum….Though the challenges of getting all parties to agree on how to accomplish this could dwarf the economic constraints.

But that is not the focus of this blog post…exactly. What about all of the fielded L1-only receivers deployed since GPS hit the commercial mainstream? Does Single Frequency still make sense today?  

Dual and triple frequency GNSS shipments are projected to have double-digit compound annual growth into 2025.  But the vast majority of GNSS Chipsets out there are Single Frequency L1, and dual frequency L1L2 or L1L5. Triple frequency GNSS shipments are a comparative 1.8 % sliver of the more than 2.2 billion Receivers forecasted to ship in 2025.   

Granted, these forecasts were made before the Covid pandemic and the ensuing supply chain instability that continues to plague the manufacturers of all things electronic. Certainly, there is good reason to make the most of what we have in hand now. Namely, the single frequency receiver. So, let’s examine the case for this humble yet widely fielded positioning device.

A single frequency receiver calculating an autonomous single point position can achieve an accuracy of 5m CEP, and DGNSS accuracy 1m CEP.  With PPP corrections supplied to innovative positioning algorithms, 50 cm accuracy can be established easily in under 30 seconds. With RTK Corrections—within 3km of your local base station—2 cm is possible. Comparing these figures to a multi–Frequency receiver, the expected Single point, DGNSS, PPP and RTK accuracies that are achievable are respectively 1.2m, 50 cm, 20 cm and 1 cm (with the part per million RTK baseline not degrading accuracy until you were 40 km away).  There is no question that including more frequencies helps with positioning performance. And with more satellite observations, positioning becomes more robust.

As a caveat to any GNSS performance specification, there is no way to account for every adversity in the environment. Therefore, every manufacturer of GNSS receivers can only post test results obtained in perfect conditions, with no obstructions or reflective surfaces from horizon to horizon, in all directions, using a geodetic grade antenna, and a perfectly tuned RF cable network connected to the receiver.  Testing is repeated and monitored over months to satisfy the savviest in statistical position punditry. 

The critical point here is that across all positioning techniques single frequency receivers also produce better positioning accuracy when fed corrections their positioning algorithms can consume. Obstructions to direct line of sight affect all receivers, regardless of frequency capabilities, and are mitigated with the ability to track more constellations, increasing the probability of a satellite tracking in a direct line of sight. While justifiable for some applications and even negligible to implement multi frequency, a good bet for products with integrated single frequency receivers could be an update to their firmware for better positioning by connecting to the best corrections possible.  

If the humble single frequency GNSS receivers out there can consume corrections and can be connected to the internet, there is still positioning performance to be realized.  Should your product or service fall within this category, please contact us for an expert consultation on how Rx Networks’ assistance data services can boost the performance of your current positioning engine.

During the CES 2021 keynote, Verizon CEO Hans Vestberg discussed the eight currencies of Verizon’s 5G network vision.  He touched on throughput and service deployment, mobility and connected devices, latency and data volume, and energy efficiency and reliability. This list struck a chord with Rx Networks. In the world of GNSS corrections there are many parallels and, considering that devices now require location awareness, they need corrections to achieve that awareness. Therefore, it begs the question: What are the currencies of GNSS corrections?

Accuracy potential

On the data sheet of most if not all GNSS receivers, accuracy specifications are listed for the different types of corrections streams that can be served to the receiver.  The single point, or autonomous no correction solution, is roughly 1m and improves with a corresponding correction type, implying that every GNSS receiver needs to have corrections to achieve its true accuracy potential.  Accuracy is really up to how the correction is applied in the positioning engine, whether it be in the cloud, edge or onboard, calculating a latitude Longitude and height. The receiver needs to be connected to a correction source.

Convergence time

This currency is two dimensional, as it refers to an acceptable accuracy within a certain amount of time.  The extremities of these two dimensions go from having a very inaccurate position instantly to converging to 1cm solution in hours.  As a note RTK does solve the negatives of both of these extremes, but scalability then becomes an issue. (More on that later.) For now time and accuracy are a trade off, sacrificing one for the other.

Bandwidth constraints

Two main points here. First, corrections need to be delivered through telecommunications equipment and, secondly, very few devices have unlimited connectivity and computing horsepower to process corrections. For some applications, the complete corrections package is broken up into the essentials for the application to ensure delivery. A complete corrections package will cover every conceivable source of error when determining the distance between a GNSS antenna and satellite. Innovations in satellite tracking, GNSS signal integrity and the growing number of constellations put further pressure on telecommunications throughput to deliver this growing package of corrections and assistance data.

Coverage, Reference Network Density and Scalability

This currency is all about the number of receivers in any given area being served the corrections they require. In the smallest network case, a surveyor GNSS RTK base station has a dedicated radio modem connection to a rover, where the distance between the two is never greater than 3km in order to achieve a 1cm accurate position. Here’s where scalability enters the equation. While this network case achieves accuracy instantly, it becomes the antithesis of scalability just as quickly. With the rapidly growing number of users needing accurate positioning, there is a requirement for these GNSS reference networks to become denser over an area. The more dense the network, the better accuracy you will achieve when locating within the proximity of that reference station network.

Compatibility

The diversity of applications along the location dimension are growing exponentially. With diversity comes integration and transformation work to deliver the applied location solution to market. Proprietary formats may add extra value above the traditional universal corrections formats and further benefits can be experienced when served into a receiver and/or positioning engine.

Reliability

Reliability is most simply defined as being there the moment you need it. This is particularly important in a deployed scenario where redundancy, response time, and resilience are key pillars of reliability.  As the saying goes, two is one and one is none, alluding to the criticality of relying on a single system. Resilience refers to the network’s ability to continually deliver through adverse events. Response and repair time for when the system goes through an unforeseen adversity. And 99.999% is the typical requirement for carrier grade service level agreements, where penalties are often stipulated for failure to deliver.

Every positioning application will determine some corrections currencies to be more valuable than others. It is a matter of finding balance for those applications. When evaluating a corrections provider, identifying a demonstrable track record and their protocols for delivering on the corrections currencies discussed here would make for a great start to a thorough review.

Hello (again).  We’re Back!

It is 2022 and we thought it was high time we restarted our blog, beginning with an explainer video on how our GNSS data services, Location.io and TruePoint.io, enable the best positioning performance on the GNSS Chipset integrated with your device. 

Some examples of devices containing GNSS chipsets include:

• Smart phones
• Asset Trackers
• Sports and outdoor Wearables
• Drones
• Robotic Lawn Mowers
• Micro-Mobility devices
• Ride sharing and Delivery mobile phone Apps
• Telecom infrastructure
  
  …etcetera!
   

The video below expresses the process of positioning in simplified visual geometry, and highlights many of the benefits of adding GNSS data services to your connected device. While we do make reference to complex algorithms and mathematical formulas, fear not, there won’t be a test at the end of the video   

Be sure to visit again mid month when we plan to explore and simplify additional GNSS data services topics and definitions.  And, as always, please do not hesitate to contact us for more information on this video, or on any of Rx Networks’ services.
 

This month, I’m introducing Coder`s Corner, a new series of articles focused on the challenges and best practices when integrating location support in new mobile devices. Over the coming months, the series will explore topics ranging from GNSS and A-GNSS assistance handling, real-time and autonomous Wi-Fi positioning, sensor integration. The series will also cover tools and special OS aspects, as well as best practices for the smooth integration of multiple positioning technologies under the hood of modern mobile devices.

With a focus on location, I’ll share insights and tips along the following key principles:

• How to write portable code that just works: How to support Windows, Linux, Android, QNX and other OSes. Tools and IDE.
• Don’t reinvent the wheel: How to take advantage of a modern OS’ Abstraction Layer and Modular Coding support.
• Making it easy for the client: How to set up and exploit Frameworks and Reusable Code, for example, when working with RINEX data.
• Evolution of Languages: Comparing C, C++ and Java, exploring their relative benefits and optimal fit in mobile and embedded systems.

The ability to determine one’s location anywhere on Earth is truly a technological marvel of our modern age. It has enabled countless location based services, which have become so pervasive in our daily lives, that the underlying technology is rarely given any thought. So, let’s take a minute to understand the history of global navigation satellite systems, as a basis for a global reference network.

While not the first, the most recognizable global navigation satellite system (GNSS) is the Global Positioning System (GPS), a project established in 1973 by the United States Department of Defense. This network of satellites (32 today) orbit the Earth while broadcasting navigation messages toward the planet. These navigation messages are comprised of the following:

• The clock status of the satellite, as well as its individual health/status.
• Precise orbital information of the satellite, called the ephemeris.
• Coarse orbit and status information of all satellites in the constellation, called the almanac.

Despite the slow transmission rate by today’s standards (50 bit/s), these messages travel at the speed of light on the radio spectrum, reaching the surface of the planet in under 7/100ths of a second. From the ground, a receiver with line-of-sight to the satellites, performs calculations based on the reported locations of the visible satellites and determines its location via a process of trilateration and clock validation. While the applications that this technology has enabled are virtually limitless, from missile guidance to the future of self-driving cars, there are limitations to underlying technology itself.

As unimpeded line-of-sight to the overhead satellites is required in order to receive the navigation messages, getting a location fix in obstructed areas like skyscraper laden city streets can be time consuming and frustrating to the end user. To supplement traditional GNSS, a range of assistance protocols were created to improve the time to first fix (TTFF) and enhance the ongoing location experience; this is where a global reference network comes in to play.

So what is a global reference network?

• global   /ˈɡləʊb(ə)l/    Relating to the whole world; worldwide.
• reference   /ˈrɛf(ə)r(ə)ns/    The use of a source of information in order to ascertain something.
• network   /ˈnɛtwəːk/    A group or system of interconnected people or things.

With a little bit of help from our friends at the Oxford English Dictionary, a global reference network is a group of interconnected GNSS ground stations, distributed around the globe which are used to ascertain the location of GNSS satellites. In contrast to an end-user device, which uses the navigation messages to determine its own location in relation to the satellites, a ground station’s primary function is to determine the location of each satellite that it can see overhead. Given enough globally distributed ground stations, all satellites in a GNSS constellation can be observed in their orbits in real-time.

Each one of the GRN sites are capable of relaying the satellite navigation messages to centralized data centers which can be distributed to customers across a range of verticals, including chipset manufacturers, OEM’s, telecommunications providers and location based service suppliers. This data can be structured in multiple different ways, from a real-time broadcast ephemeris stream, to processed predictions known as extended ephemeris, which calculate the location of the satellites in space and time for weeks into the future.

Given that mobile devices are capable of receiving information via the data network at hundreds of thousands of times the satellite transmission rate of 50 bit/s, this assistance data can be continually updated in the background to enhance the core GNSS layer. This results in a significantly faster TTFF compared to traditional GNSS, as well as the ability to receive a location fix in obstructed environments where non-assisted devices might never be able to determine their location.

The Rx Networks global reference network is capable of supporting a range of global and regional constellations, including:

• GPS – United States
• GLONASS – Russia
• BeiDou / BeiDou-2 – China
• Galileo – European Union
• QZSS – Japan

With the data derived from the global reference network, Rx Networks offers two distinct product lines, under the GPStream banner, GRN and PGPS. GPStream GRN is offered as a real-time stream or request based broadcast ephemeris service, which is used extensively in the E-911 space. As such, the service takes advantage of multiple levels of redundancy and is backed by a carrier grade, 99.999% SLA uptime guarantee. GPStream PGPS is Rx Networks’ prediction product, which enables mobile devices to generate high accuracy extended ephemeris for weeks into the future, without the need for continual access to a data network. This empowers devices to receive significantly faster and more accurate fixes in obstructed locations while roaming or in areas without cellular coverage.

In the next issue of Points of Interest, I will be discussing the logistics of designing and deploying a global reference network, starting with the base set of requirements:

• Political stability – Is it safe to make an investment in the country which will be hosting the site?
• Power/network stability – Will the site be highly available? Can near real-time data be assured?
• Unobstructed views of the horizon – Will the site be able to see all available satellites in the sky?

Stay tuned!

One of the core principles of Rx Networks location technologies is the ability to run on any hardware platform and operating system. Products such as our XYBRID RT (cellular and WiFi location lookup service) can be as simple as a HTTP GET request, while our GPStream PGPS A-GNSS solution interfaces with a GNSS chipset, schedules download of new data, generates Extended Ephemeris (EE) from seed data or Broadcast Ephemeris (BCE), and stores data locally on the device. While we can pass the responsibility of developing all this code to the customer, it is not attractive solution for our customers or ourselves as both parties must commit additional development and support resources to complete the integration.

The smartphone market is dominated by ARM based hardware running Android and iOS, while the wearable gadgets, M2M, and PND markets have a greater diversity of hardware and OS options. Having customers in all these industries provides a development challenge; is it possible to write software that can run on such a variety of hardware and software platforms?

Part of the solution is to develop software using the C programming language. Dennis Ritchie developed the C language and C was used to implement the Unix operating system in the early 1970s at Bell Labs.

C is a function oriented low-level programming language as opposed to an object oriented language like C++ or Java. In programming abstraction C lies in between Assembly and C++. Code written in C has a smaller footprint and is more portable while C does not directly support high level abstraction concepts like polymorphism and inheritance which makes code easier to extend and reuse. It is possible to develop an application with a combination of C and C++ code, but  while a device that has a C++ compiler, will definitely have a C compiler, the opposite may not be true, this is why C code is more portable on a larger variety of hardware and software platforms than C++.

Leveraging the function oriented nature of the C language the integration software is designed as an event driven state machine. The state machine is responsible for:

1. Verifying and maintaining an accurate system time
2. Obtaining a list of cellular and WiFi access points and using XYBRID RT to obtain a location
3. Monitoring the data connectivity of the device and taking appropriate actions when a data connection is available
4. Processing downloaded data and incoming Broadcast data from a GNSS chipset, and applying the PGPS algorithm to generate up to 14 days worth of Extended Ephemeris
5. Supplying the GNSS chipset with AGNSS data to improve Time to First Fix (TTFF)

Each state has a set of procedures to verify and complete, before the state machine initiates to the next state. This allows for each possible state outcome to be unit tested and helps to ensure consistent behavior across all platforms.

The integration code has been commercially integrated on devices with hardware architectures such as ARM, MIPS and x86 and on operating systems such as Android, Linux, Windows, QNX and other proprietary OSes. Having one unified integration that runs and behaves consistently on all our customers platforms has helped to ensure a timely integration of Rx Networks location technologies while reducing the overall development and resources commitments.

In the next following articles we will cover more details of developing an event driven state machine and examples of how to structure and write hardware and OS portable code.