# Compression of GNSS Data with the Aim of Speeding up Communication to Autonomous Vehicles
## 6 Experiments  
Data was collected by traveling on many roads in several vehicles with the same receiver (smartphone). First, for data collection, the following NMEA LOGGER application was utilized during the trips [52]. This application allowed us to record NMEA data in raw form and transfer the data file to a computer for analysis and further analysis. The application is intended for use on smartphones using the Android operating system from Google Play. In our research, the NMEA LOGGER application version 2.3.35 was used on a Samsung S20 ULTRA device (Samsung, Seoul, South Korea) running the Android operating system. Aiming at analyzing information and collecting data, we incorporated urban and intercity routes and interspersed long and short ranges. This application can create a large log file with all the GNSS data and sub-protocols. We did not need some of the data for this study, so we filtered it for only the relevant data. Nowadays, a filtering method before analyzing results or performing actions is prevalent in many applications, as in [53]. Several short and long samples have been extracted and are shown in the tables that appear in the Results section. The shortest trip was about 50 km in 20 min, and the longest was about 4.5 h and 300 km, which included driving on a highway and standing in urban traffic jams. In Figure 11 in Appendix A, we see many information lines not relevant to the content that we want to compress. For us it is a sort of noise that we have filtered out. The content of the desirable protocols has been extracted. The extracted protocols are:  
* GPGGA
* GPGSV
* GPGSA
* GPRMC  
The contents of the desired protocols are extracted. After the filtering out of this noise, a new text file was built and through it, repeating patterns within each line of each protocol were examined. An example of a filtered file can be seen in Figure 12 in Appendix A, which includes only the four protocols mentioned above. For example, one of the methods tried in the research was calculating differences between rows' values in each block. This shows very good compression data, but it is very difficult to recover information, so we rejected this method. Sometimes the vehicle sends or receives incorrect satellite information, which can happen for many reasons. For example, the vehicle enters an underground parking lot or tunnel, or a momentary malfunction occurs in the reception of GNSS satellites [54; 55; 56]. During the first step, it was decided to remove incorrect information. In Figure 13 in Appendix A, we see noises in both the GPGSA and GPRMC protocols, which are incorrect data. These noises cause an omission of most of the information block that includes additional protocols, as seen, for example, in the GPRMC protocol when its third value is the V value, which means the information is incorrect. Also, incorrect information can be detected in the GPGSA protocol when the third parameter is 1 (Mode: 1 = Fix not available). If there is incorrect information for any reason, the algorithm will delete most of the block with the incorrect information, as exemplified in Figure 13 in Appendix A. We suggest calculating differences between the rows with the same protocol like it is done in the H.264 method. For example, in each block there are k rows where:  
* \(5\leq\) k \(\leq\) 13. * GPGGA is a 1-line message. * GPGSV is 1-9 lines of messages. * GPGSA is 2-lines of messages. * GPRMC is a 1-line message. The example in Figure 1 demonstrates how it works:One of the difficulties was with GPGSV. The challenge emerges when in certain blocks in the GPGSV protocol, we have a certain number of lines, and then after a few iterations, a block appears with the GPGSV protocol with a different number of lines (more lines or less). Figure 10 in Appendix A shows a case with a different number of GPGSV lines. In iteration 4 (line 22-29), the GPGSV lines are not the same as the GPGSV lines of iteration 1 (line 1-7).