Inside GNSS Media & Research

MAY-JUN 2018

Issue link:

Contents of this Issue


Page 54 of 67 M A Y / J U N E 2 0 1 8 Inside GNSS 55 (NMEA) protocol, producing a file that contains information regarding the posi- tion of the sensor, visible satellites, mea- surements, pseudoranges, etc., whose size is in the range from 1 to 5 kilobytes (kB). In order to reduce the amount of data to be transferred from the IoT sen- sor to the central node (uplink transmis- sion), the NMEA is processed on-board and just the location of the sensor is delivered in the end, hence reducing the output to a few bytes. During the time the GNSS module is in active mode, it essentially switches between acquisi- tion and tracking state. In the acquisi- tion state, the GNSS module is search- ing and acquiring GNSS signals until it is capable of providing a position fix. is is the maximum power-consuming state of the GNSS module. Aerwards, it switches to a tracking state that pro- vides position fixes with the already acquired satellite signals and searches for signals of new visible satellites. e tracking state is considerably less power- consuming than the acquisition state. Nevertheless, it is difficult to measure the power consumption of a GNSS mod- ule as it varies depending on the work- ing conditions. For instance, a satellite with low Carrier-to-Noise ratio (C/N0) would require a longer coherent or non- coherent integration at the acquisition stage, thus needing a larger amount of computational resources which implies an increase in the power consumption. Hence, one of the goals most Mass- Market (MM) GNSS chipset vendors have (in addition to achieving lower power consumptions) is to reduce the active time until providing a reliable position fix, also known as Time-To- First-Fix (TTFF). e TTFF depends on the starting mode at which the GNSS module initiates when it is switched from sleep to active mode. ere are four different starting modes: cold, warm, assisted, and hot (F. Van Diggelen). In a cold start, all the possible frequency and code delays are searched and the ephem- eris and broadcast time are decoded. In a warm start, only the broadcast time and ephemeris are decoded, as the frequency and code delays are held as prior information. In a hot start, frequency and code delays, broadcast time, and ephemeris data are already known. Novel GNSS modules include assisted start, which allows download- ing ephemeris and broadcast time infor- mation from private servers or GNSS Data Centers (GDC) in order to achieve a faster TTFF, but requires a downlink internet connection. Aer downloading the assistance data, the GNSS module is able to perform an assisted start. The TTFF estimates of a GNSS module for cold, warm, assisted, and hot starts (GPS L1 C/A only) are approximately 44.34, 20.52, 2 and 0.51 seconds, respectively (M. Anghileri et alia). However, larger TTFF may be achieved in harsh environ- ments due to the difficulties in decod- ing the broadcast message or ephemeris, larger acquisition times, etc. The emergence of IoT positioning applications has sparked the interest of several MM GNSS vendors. Indeed, one manufacturer provides Assisted GNSS (A-GNSS) services to their GNSS modules at system start-up to minimize the TTFF. Similarly, another operates a worldwide reference network to provide A-GNSS data to its users, thus boosting the TTFF speed and accuracy. Fur- thermore, novel GNSS modules from another vendor includes two Power Save Modes (PSMs) to reduce the aver- age power consumption: Cyclic Tracking (PSMCT) for short update periods (1-10 seconds) and On/Off (PSMOO) for long update periods (larger than 10 seconds). Of particular interest is the PSMOO which is suitable for IoT applications with long update periods (typically from hours to days). Nonetheless, the use of the PSMOO may provide significant error in the position fix. Similar power modes are available in one company's GNSS modules: the GNSS Low Power (GLP) and the periodic mode, analogue to the PSMCT and PSMOO modes pro- vided by another MM GNSS vendor, respectively, with the latter being the most suitable for IoT applications. See Additional Resources for more informa- tion on all of these vendors. To sum up, MM GNSS chipsets offer power saving configurations oriented to IoT applications. However, a tradeoff is faced between accuracy and power con- sumption, which varies depending on the application or use. Additionally, the use of power save modes leads to a deg- radation in the accuracy performance of GNSS chipsets. Together with a reduc- tion in power consumption, diminish- ing the TTFF becomes mandatory in order to minimize the amount of time the GNSS chipset is in active mode. To do so, vendors provide A-GNSS ser- vices so the GNSS module can imple- ment an assisted start. Therefore, the IoT positioning sensor would require a downlink channel for downloading the GNSS assistance data, whose size is in the range of 1 to 3 kB per constella- tion. Note that IoT sensors do not typi- cally use the downlink channel as they are already pre-configured to switch between states beforehand, and hence this feature is only occasionally used. Cloud GNSS Receiver In the previous section we discussed power-hungry GNSS modules and how their accuracy performance is jeopar- dized as power consumption is reduced. We now propose a cloud GNSS receiver that performs the GNSS signal process- ing tasks in a cloud server instead of on the sensor itself, thus facilitating the computational resources required by the IoT positioning sensor and hence reducing its power consumption without compromising the accuracy. In addition, the cloud GNSS receiver paves the way for innovative and more advanced appli- cations due to the amount of available computational resources in the cloud servers: secure and authenticated GNSS positioning, crowdsourcing GNSS signal processing, pay-per-use insurance, etc. e cloud GNSS receiver is consid- ered a Software as a Service (SaaS), a remote application that can be used by any user or machine while it is complete- ly transparent to him. at is to say, its services can be used without having any kind of knowledge of the soware, algo- rithms, and computing resources used in the back-end. In this work, the cloud computing resources and services used are provided by Amazon Web Services (AWS) due to their wide range of cloud solutions, functionalities, and configura- tion options, along with their openness, flexibility, and low cost.

Articles in this issue

Links on this page

view archives of Inside GNSS Media & Research - MAY-JUN 2018