Inside GNSS Media & Research

MAY-JUN 2018

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

Contents of this Issue

Navigation

Page 58 of 67

www.insidegnss.com M A Y / J U N E 2 0 1 8 Inside GNSS 59 coordinates are sent is approximately 1-2 bytes, 1 kB for a small NMEA, and 5 kB for a large NMEA. We can clearly see that the GNSS module typically is the largest consumer of a conventional GNSS IoT sensor (Figure 1(a)), even for hot and assisted starts by an order of magnitude in comparison with the MCU and up to four orders of magni- tude in contrast with the communica- tion and memory modules. For the cloud GNSS IoT sensor (Fig- ure 1(b)), the same procedure has been applied, but the GNSS module has been substituted with only a GNSS RF front- end, also including an ADC. In this sense, the GNSS RF front-end must be carefully chosen to avoid compromis- ing the energy-efficiency of the cloud GNSS IoT sensor (Figure 1(b)), as it will not only contribute to its own energy consumption, but also in the energy consumed by the other components as they are directly dependent on the packet size. Indeed, the size of the data to be transferred to the cloud can be expressed as L = T sl bFs rx , where L is the packet size in bits, T sl is the captured GNSS signal length in seconds, b is the quantization bits of the ADC, and Fs rx is the sampling frequency of the RF front- end. erefore, there are three alterna- tives in order to work with small-sized packets: reduce the sampling frequency, work with a low quantization level, or capture a signal of short length. In this study case, with the objective of achiev- ing low energy consumption, the RF bandwidth is set to 2 megahertz, enough to capture the main lobe of the GPS L1 C/A signal, and the sampling frequency is set to 4 megahertz. On the other hand, the ADC uses 1 bit to digitize the GNSS signal. According to state-of-the-art components, the current consumption of a GNSS RF front-end with such char- acteristics is approximately 5 mA. A comparison between the energy consumed by the cloud and the conven- tional GNSS IoT sensor (Figure 1) with different starts is addressed in Figure 4 . In order to implement a fair com- parison, the energy consumption of the conventional GNSS IoT sensor (Figure 1(a)) for different starting modes has been obtained for a packet with size 2 FIGURE 3 Expected energy consumption of each of the components of a conventional GNSS IoT sensor (see Figure 1(a)) with regard to the size of the data packet transmitted through the communication module; TTFF for hot, assisted, warm, and cold starts of 44.34, 20.52, 2, and 0.5 seconds, respectively Coordinates Small NMEA Large NME A Energy (J) 10 -5 10 -4 10 -3 10 -2 10 -1 10 0 10 1 GNSS receiver - Hot start GNSS receiver - Assisted start GNSS receiver - Warm start GNSS receiver - Cold start Communication module MCU Memory sensor (Figure 1(a)) is shown. It can be seen that the energy consumption of the GNSS module depends on the operation mode (i.e., hot, assisted, warm, cold), and hence depends on the TTFF. In contrast, the rest of the sensor components such as the MCU, memory, and communication modules have an energy consumption directly dependent on the packet to be handled and transmitted to the cloud. Indeed, the MCU must stay in active time until the data (i.e., PVT output) is sent to, for example, a central node. e size of the packet to be transmitted through the communication module when only the FIGURE 4 Expected energy consumption of a cloud and a conventional GNSS IoT sensor with respect to the signal length; TTFF for hot, assisted, warm, and cold start of 44.34, 20.52, 2, and 0.5 seconds, respectively Signal length (ms) 10 0 10 1 10 2 10 3 Energy (J) 10 -3 10 -2 10 -1 10 0 10 1 Cloud GNSS IoT sensor Conventional GNSS IoT sensor - Hot start Conventional GNSS IoT sensor - Assisted start Conventional GNSS IoT sensor - Warm star t Conventional GNSS IoT sensor - Cold start 24 ms 46 ms

Articles in this issue

Links on this page

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