Inside GNSS Media & Research

MAY-JUN 2018

Issue link: https://insidegnss.epubxp.com/i/987551

Contents of this Issue

Navigation

Page 59 of 67

60 Inside GNSS M A Y / J U N E 2 0 1 8 www.insidegnss.com bytes (see Figure 3). It can be seen how as the signal length to be captured by the cloud GNSS IoT sensor (Figure 1(b)) is moderately small, the cloud GNSS receiver offers a more energy efficient positioning solution than conventional approaches. For instance, compared to a conventional sensor with hot start, the cloud sensor provides energy sav- ings up to one order of magnitude for small signal lengths (i.e., a few ms) and is more energy efficient by using a signal length up to 24 ms (bear in mind that a PVT can be obtained with just 1 or 2 ms of signal). Notwithstanding, the GNSS module cannot implement a hot start every time it provides a position fix, as the stored information expires (range from 30 minutes to 4 hours). MM GNSS chipsets usually download or try to decode ephemeris data (as in cold start) every 30 minutes with the objective of having recent ephemeris and navigation data and then provide a higher position accuracy. Likewise, in contrast with an assisted start, the cloud GNSS IoT sensor (Figure 1(b)) can capture and transfer up to 46 ms of GNSS data and still con- tinue to be more energetically efficient. Finally, in comparison with the warm and cold starts, whose TTFF and hence the amount of time in active mode is significantly high (i.e., 30-40 seconds), the cloud GNSS IoT sensor (Figure 1(b)) remains active for some milliseconds (up to 600 and 800 ms, respectively), and thus energy efficiency can reach up to 2.5 orders of magnitude. Performance of the Cloud GNSS Receiver In this section we will brief ly discuss the accuracy performance of the cloud GNSS receiver by means of an experi- mental test. To do so, a synthetic signal was generated with a GPS/Galileo sig- nal generator simulating a static out- doors open-sky scenario at the School of Engineering of Universitat Autònoma de Barcelona (UAB). A low-cost RTL-SDR V3 USB front-end was used to capture the GPS L1 C/A signal with a sampling frequency of 2.048 MHz and generate the raw GNSS sample file, which is then transferred to the cloud GNSS receiver together with the required JSON con- figuration file. e visible satellites have been configured with a C/N 0 of roughly 46 dBHz. e obtained results for GPS L1 C/A with different coherent integration times are provided in Figure 5 . For a small sig- nal length (i.e., 1 to 4 ms) a position error of tens of meters is obtained. How- ever, as the coherent integration time is increased (i.e., 10 and 20 ms), and hence the amount of signal captured and sent to the cloud GNSS receiver is also larger, the positioning accuracy is enhanced to a few meters. In contrast to conventional GNSS IoT positioning approaches where the sensor must be in active mode for a long period of time to calculate the PVT (from a few seconds up to minutes, depending on the working conditions), in a cloud-based approach the sensor must be in active mode for just a few milliseconds, enough time to capture the desired GNSS signal and forward it to the cloud servers. Therefore, it is shown that the cloud GNSS receiver becomes an energy-efficient IoT posi- tioning solution without compromis- ing the obtained accuracy, particularly for those IoT applications that do not require precise positioning. Economic Cost of GNSS Signal Processing in the Cloud Processing the raw GNSS sample file in cloud servers instead of in the sen- sor itself as in conventional approaches implies the added cost of hiring cloud computing resources. Among the dif- ferent AWS services used in the cloud GNSS receiver infrastructure, the service that implies a significant cost is the EC2 service. AWS offers three ways to pay for its services: on-demand, reserved, and spot. On-demand services are paid per hour use as they are opened and closed with a fixed cost. Reserved services, which are paid in advance, are suited for applications with predictable usage and offer discounts up to 75% in contrast with on-demand services. Moreover, we can bid for EC2 spot services whose cost may decrease up to 90% in comparison with on-demand (their fluctuating price varies depending on the supply and demand of EC2). Additionally, the price of different services may vary depend- ing on the selected region of use, i.e., the geographic area where the EC2 servers are hosted. For this test set-up, c3.xlarge ( Table 2 ) have been selected to compose the cloud back-end for processing the raw GNSS sample files with signal length between FIGURE 5 Accuracy performance of the cloud GNSS receiver in a static outdoor clear-sky sce- nario with different coherent integration times Instance type c3.xlarge vCPUs 4 RAM 7.5 GB SSD 2x40 GB Region Frankfurt (EU) On-demand price (taxes excluded) $0.258 per hour Reserved price (taxes excluded) $0.11 per hour Spot price (taxes excluded) $0.0472 per hour Table 2 Experimental set-up for the economic cost of cloud services: EC2 characteristics WORKING PAPERS

Articles in this issue

Links on this page

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