Inside GNSS Media & Research

MAY-JUN 2018

Issue link:

Contents of this Issue


Page 57 of 67

58 Inside GNSS M A Y / J U N E 2 0 1 8 shot-based GNSS receiver with a C/N 0 sensitivity down to 15 dBHz (J. Lopez-Salcedo et alia). e HS-GNSS SwRx core is based on the extensive use of FFT processors and implements long integration times up to several seconds using advanced non-coherent integrations. In addition, different AWS solutions are used to build the back-end: Elastic Cloud Computing (EC2), Simple Queue Ser- vice (SQS), Batch, Relational Database Service (RDS), Elastic Container Service (ECS), and Simple Storage Service (S3). EC2 provides re-sizable and scalable computing resources (i.e., RAM, CPU, storage, etc.) in the cloud as instances (virtual machines) that act as a physical computing machine. ere is a wide range of available virtual machine types, each of them suitable for different uses. SQS is a message queuing service to communicate different modules and systems within the cloud infrastructure. Batch enables us to optimally compute jobs on AWS resources (i.e., EC2) based on its computing requirements (e.g., CPU, RAM). RDS is used to store and manage the data- base of the cloud infrastructure which includes information such as users, PVT results, job configurations, etc. ECS allows for the launch and scale of Docker containers on AWS when a job is received. A Docker container includes the HS-GNSS SwRx and all the necessary soware for the processing of the raw GNSS sample file. S3 provides secure, durable and highly- scalable object storage and is used to store the data uploaded from the sensor, which is then downloaded in an EC2 virtual machine in order to be processed. us, when a cloud GNSS IoT sensor (Figure 1(b)) launches a request, it first has to upload the raw GNSS sample file and the configuration data (i.e., JSON) to the S3 repository and send a request by means of a message to the SQS queue. When the SQS message is read by the resource manager, a new job is generated, inserted into the database by its identification num- ber, and then managed by Batch, which will start a given EC2 instance type depending on the computing resources required by the job, and launch a Docker container from the ECS service. Once the container is launched, it automatically downloads the data regarding to the identification number of the job (i.e., raw GNSS sample file, JSON) from S3 and the HS-GNSS SwRx is launched. Finally, the output results are stored in the database from which it can be retrieved through the API or web page. is workflow is depicted in Figure 2. Energy Consumption As we have previously seen, instead of locally processing the GNSS data, the cloud GNSS IoT sensor (Figure 1(b)) only has to transfer it to a cloud server. is simple process is expected to be more energy efficient than conventional IoT positioning approaches where the PVT is computed on-chip. Nevertheless, it is known that data transmission is one of the most energy consuming stages of an IoT sensor. Depending on the appli- cation, it is even higher than performing the computational tasks locally in the device itself. In the cloud GNSS receiver, the size of the data (i.e., raw GNSS sample file) to be transmit- ted from the sensor to the cloud is directly proportional to the signal length (in time), the sampling frequency of the reception RF front-end, and the quantization of its ADC. erefore, a trade-off is met between the size of the data to be transmit- ted and the energy consumed by the cloud GNSS IoT sensor (Figure 1(b)). Furthermore, the signal length is also related to the sensitivity of the GNSS receiver, as increasing the coherent or non-coherent integration time allows for the detection and acquisition of weaker GNSS signals. Hence, another trade-off is met between the sensitivity of the GNSS receiver and the size of the data to be transferred. In order to properly compare the expected energy consump- tion of both the conventional and cloud GNSS IoT sensors (Fig- ure 1), we have to address the energy consumed by each of the components they comprise (V. Lucas-Sabola et alia, 2017). First, the energy consumption of a conventional GNSS IoT sensor (Figure 1(a)) performing a position fix is discussed. Basically, the required energy by a component can be obtained by its current consumption in active mode, the amount of time in active mode, and the supply voltage. For this study case, the supply voltage is set to 3.3 V. e current consumption has been obtained from datasheets of state-of-the-art components (Table 1 ). Regarding the current consumption of the compo- nents, the reader should note that the communication mod- ule also consumes an additional amount of energy due to the release of power from the antenna during transmission, and the GNSS module current consumption may vary depending on the working conditions of the sensor (e.g., open, mild, or obstructed environment). The active time of the different components have been obtained as follows: the MCU is active from the time the sen- sor is switched on and begins capturing the GNSS signal until the PVT is sent; the active time of the memory and communi- cation module is directly dependent on the size of the packet to be stored and transmitted, respectively (a few bytes in this study case); and the GNSS module active time is equal to the TTFF for each of the four different starts: 44.34, 20.52, 2, 0.5 seconds for cold, warm, assisted, and hot, respectively (TTFF for assisted depends on the downlink latency). Note that the acquisition time may vary depending on the working condi- tions, i.e., larger in harsh environments and hence increasing the energy consumption. In Figure 3 the expected energy consumption of the dif- ferent components of a conventional GNSS IoT positioning WORKING PAPERS Component Manufacturer Model Current consumption GNSS module u-blox MAX-M8W 32 mA (Acquisition) [20] GNSS module u-blox MAX-M8W 8.9 (Tracking) [20] MCU module Texas Instruments CC1310 1.9-2.5 mA [18] Communication module Texas Instruments CC1310 11.2 mA [18] Memory module Atmel AT25M02 5 mA [2] Table 1 Current concumption of the components of a conventional GNSS IoT sensor (Figure 1a)

Articles in this issue

Links on this page

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