Compression of GPS positioning information

Abstract

Techniques for wirelessly providing Global Positioning System (GPS) data from a vehicle to an entity are presented. The techniques include: obtaining, from a GPS receiver, GPS data for the vehicle, where the GPS data includes data representing at least a latitude of the vehicle and a longitude of the vehicle; generating a packet representing the GPS data, where the packet includes: a latitude data field including latitude data, a field including data representing a length of the latitude data field, a longitude data field including longitude data, and a field including data representing a length of the longitude data field, where the latitude data field and the longitude data field are variable in length among different packets; and sending, wirelessly, the packet to the entity.

Description

COMPRESSION OF GPS POSITIONING INFORMATIONRelated Application

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 611 ,352, entitled, “Compression of GPS Positioning Information,” and filed December 18, 2023.Field

[0002] This disclosure relates generally to a Global Positioning System (GPS) for vehicles.Background

[0003] For any of a variety of applications, a vehicle may share its location on a vehicle-to-everything (V2X) communication channel. Such applications include, for example, usage within a safe self-driving vehicle (e.g., for collision avoidance) and the provision of Advanced Driver Assistance Systems (ADAS) warnings. Typically, the communication channel in the context of V2X communication has limited bandwidth. For example, a vehicle-to-vehicle (V2V) communication channel is typically highly unstable due to the dynamic distance between vehicles. Moreover, raw GPS information is relatively large and can therefore exhaust the bandwidth of a V2X channel quickly.Summary

[0004] According to various embodiments, a method of wirelessly providing Global Positioning System (GPS) data from a vehicle to an entity is presented. Themethod includes: obtaining, from a GPS receiver, GPS data for the vehicle, where the GPS data includes data representing at least a latitude of the vehicle and a longitude of the vehicle; generating a packet representing the GPS data, where the packet includes: a latitude data field including latitude data, a field including data representing a length of the latitude data field, a longitude data field including longitude data, and a field including data representing a length of the longitude data field, where the latitude data field and the longitude data field are variable in length among different packets; and sending, wirelessly, the packet to the entity.

[0005] Various optional features of the above method embodiments include the following. The latitude data may represent the latitude of the vehicle, and the longitude data may represent the longitude of the vehicle. The latitude data may represent a difference between a previous latitude of the vehicle and the latitude of the vehicle, and the longitude data may represent a difference between a previous longitude of the vehicle and the longitude of the vehicle. The GPS data may further include data representing a speed of the vehicle, where the packet further includes: a speed data field including speed data, and a field including data representing a length of the speed data field, where the speed data field is variable in length among different packets, and where the speed data represents the speed of the vehicle. The GPS data may further include data representing a course of the vehicle, where the packet further includes: a course data field including course data, and a field including data representing a length of the course data field, where the course data field is variable in length among different packets, and where the course data represents the course of the vehicle. The packet may further include data representing a course of the vehicle, where the packet further includes data representing a speed of the vehicle, and where the packet is less than 30 bytes long. The latitude data may include a latitude angular measure representedin the packet as a first binary integer, and the longitude data may include a longitude angular measure represented in the packet as a second binary integer. The latitude data may include a first directional datum represented in the packet as a single bit, and the longitude data may include a second directional datum represented in the packet as a single bit. The packet may further include data representing a length of the packet. The packet further may include data representing a checksum of the packet. The sending may include sending point-to-point from the vehicle to a second vehicle.

[0006] According to various embodiments, a system for wirelessly providing Global Positioning System (GPS) data from a vehicle to an entity is presented. The system includes: a GPS receiver; a wireless transmitter; an electronic processor communicatively coupled to the GPS receiver and to the wireless transmitter; and a non-transitory computer readable medium communicatively coupled to the electronic processor, the non-transitory computer readable medium including instructions that, when executed by the electronic processor, configure the electronic processor to perform actions including: obtaining, from the GPS receiver, GPS data for the vehicle, where the GPS data includes data representing at least a latitude of the vehicle and a longitude of the vehicle; generating a packet representing the GPS data, where the packet includes: a latitude data field including latitude data, a field including data representing a length of the latitude data field, a longitude data field including longitude data, and a field including data representing a length of the longitude data field, where the latitude data field and the longitude data field are variable in length among different packets; and sending, using the wireless transmitter, the packet to the entity.

[0007] Various optional features of the above system embodiments include the following. The latitude data may represent the latitude of the vehicle, and the longitude data may represent the longitude of the vehicle. The latitude data may represent adifference between a previous latitude of the vehicle and the latitude of the vehicle, and the longitude data may represent a difference between a previous longitude of the vehicle and the longitude of the vehicle. The GPS data may further include data representing a speed of the vehicle, where the packet further includes: a speed data field including speed data, and a field including data representing a length of the speed data field, where the speed data field is variable in length among different packets, and where the speed data represents the speed of the vehicle. The GPS data may further include data representing a course of the vehicle, where the packet further includes: a course data field including course data, and a field including data representing a length of the course data field, where the course data field is variable in length among different packets, and where the course data represents the course of the vehicle. The packet may further include data representing a course of the vehicle, where the packet further includes data representing a speed of the vehicle, and where the packet is less than 30 bytes long. The latitude data may include a latitude angular measure represented in the packet as a first binary integer, and the longitude data may include a longitude angular measure represented in the packet as a second binary integer. The latitude data may include a first directional datum represented in the packet as a single bit, and the longitude data may include a second directional datum represented in the packet as a single bit. The packet may further include data representing a length of the packet. The packet may further include data representing a checksum of the packet. The sending may include sending point-to-point from the vehicle to a second vehicle.

[0008] Combinations, (including multiple dependent combinations) of the abovedescribed elements and those within the specification have been contemplated by the inventors and may be made, except where otherwise indicated or where contradictory.Brief Description of the Drawings

[0009] Various features of the examples can be more fully appreciated, as the same become better understood with reference to the following detailed description of the examples when considered in connection with the accompanying figures, in which:

[0010] Fig. 1 illustrates a use case for a method of wirelessly providing Global Positioning System (GPS) data from a vehicle to an entity, according to various embodiments;

[0011] Fig. 2 is a flow diagram of a method of wirelessly providing GPS data from a vehicle to an entity, according to various embodiments;

[0012] Fig. 3 is a flow diagram of a method of wirelessly providing GPS data from a vehicle to an entity, according to various embodiments; and

[0013] Fig. 4 is a schematic diagram of hardware suitable for implementing a system for wirelessly providing GPS data from a vehicle to an entity, according to various embodiments.Description of the Examples

[0014] Reference will now be made in detail to example implementations, illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts. In the following description, reference is made to the accompanying drawings that form a part thereof, and in which is shown by way of illustration specific exemplary examples in which the invention may be practiced. These examples are described in sufficient detail to enable those skilled in the art to practice the invention and it is to be understood that other examples may be utilized and that changes may be made withoutdeparting from the scope of the invention. The following description is, therefore, merely exemplary.

[0015] V2X communication may include transmission of location data, as well as course data and / or velocity data, from a vehicle to another vehicle or other entity. Internal to a vehicle, location, course, and velocity information can be obtained from a Global Positioning System (GPS) receiver. GPS receivers currently predominantly support the NMEA 0183 specification. This specification utilizes ASCII encoding, a text-based format. However, the ASCII encoding is limited to 127 characters, with each character occupying a maximum of seven bits. Consequently, when transmitting GPS information in bytes in which each byte contains data representing one ACS 11 character, every ASCII character wastes one bit of space. Further, GPS data primarily includes numerical values and directional data values. A four-byte signed integer can adequately represent numbers ranging from -2,147,483,648 to 2,147,483,647 (inclusive). Yet further, a four-byte ASCII string can only represent numbers from -999 to 999. Directional data, such as “North” versus “South,” or “East” versus “West,” can be represented with a mere one bit. However, in ASCII encoding, such directional data consumes a full byte.

[0016] Consequently, to transmit GPS data efficiently within the limited bandwidth of a V2X communication channel, reduction of the size of the data may be used.

[0017] However, as described in detail presently, existing data compression techniques are unsuitable for GPS data sent over a V2X communication channel. There are many existing general-purpose compression algorithms, such as Gzip, Zip and B roti i. These algorithms are based on Huffman coding, which may introduce some overhead. As a representative example, Gzip is a widely used compression algorithmon the web. It contains a ten byte header and an additional eight bytes trailer, so it always contains 18 bytes fixed overhead, which is about the size of an entire message according to some embodiments. Moreover, compression algorithms based on Huffman coding will not significantly reduce message size if there are few repeated patterns in the message due to its overhead. Further, the GPRMC message of the NMEA 0183 specification takes a maximum of 82 bytes, which is too short for Huffman coding. As a result, the space saved by Huffman coding cannot compensate for the overhead.

[0018] Some embodiments, in contrast to ASCII encoding, utilize a specialized binary format for encoding GPS messages, significantly reducing the required space. Some embodiments are fundamentally different from general-purpose compression algorithms, because they do not rely on Huffman coding. Because the algorithm according to some embodiments is specially designed for the V2X (including V2V) communication, it can use a shorter header instead of the lengthy header and trailer necessary for Huffman coding. According to some embodiments, e.g., in a V2V scenario, the information size can be further diminished by sending complete location and velocity data initially, and subsequently transmitting only the update information in subsequent network packets. According to some embodiments, each GPS message occupies a maximum of 20 bytes.

[0019] These and other features and advantages are shown and described presently in reference to the figures.

[0020] Fig. 1 illustrates a use case 100 for a method of wirelessly providing Global Positioning System (GPS) data from a vehicle 110 to an entity 120, according to various embodiments. As shown in Fig. 1 , the vehicle 110 provides GPS data to, by way of non-limiting example, another vehicle 120. However, according to variousembodiments, the vehicle 110 may transmit 112 GPS data to any entity, not limited to another vehicle. For example, according to various embodiments, the vehicle 110 may transmit 112 GPS data to a receiver at a fixed location. Note further that although one recipient vehicle 120 shown in Fig. 1 , embodiments are not so limited. For example various embodiments may broadcast GPS data to multiple recipients, whether in motion, stationary, or a combination thereof.

[0021] According to various embodiments, the vehicle 120 may transmit 112 GPS data to the vehicle 120 in a variety of ways. For example, according to some embodiments, the vehicle 110 may transmit 112 the GPS data directly to the vehicle 120 using a point-to-point protocol such as, by way of non-limiting examples, the direct transmission mode of the C-V2X standard or the IEEE 802.11 WiFi standard. As another example, according to some embodiments, the vehicle 110 may transmit 112 the GPS data to the vehicle 120 using a cellular network protocol such as, by way of non-limiting example, the cellular transmission mode of the CV2X standard. According to this example, the vehicle 110 may transmit 112 the GPS data to by way of one or more cellular towers 150.

[0022] According to various embodiments, the vehicle 110 may transmit GPS data sporadically, periodically, on demand, or with any other timing or initiation. By way of non-limiting example, some embodiments may transmit full GPS data periodically at a first interval and update GPS data periodically at a second, shorter interval. Either the first or the second interval may be on the order of one second, two seconds, five second, ten seconds, etc. Other timing of the transmissions is possible and within the scope of various embodiments.

[0023] By way of non-limiting example, various embodiments are described in detail presently in reference to compressing the information in a GPRMC message. Asan initial consideration, the length of each field in a GPRMC message is analyzed, and this information is used to determine how to configure the fields in GPS data messages sent by various embodiments. The length of each field of a GPRMS message may differ. For the following analysis, the length of each field is analyzed according to the maximum value that the field can contain, as well as its range of values.

[0024] The latitude, longitude, and course data of a GPRMC message are represented by text and have a fixed number of digits. For these fields, the position of the decimal point is fixed. Therefore, the data from these fields may be represented as integers according to various embodiments.

[0025] However, the number of digits of the speed data field is variable. Nevertheless, the length of the speed data field may be approximated. The maximum speed of the fastest car in the world is about 558.67 km / h. This is about 301 .65 knots. Therefore, this speed can be represented by the integer 30165.

[0026] Similarly, various embodiments can represent the course data using integers. The course data in a GPRMC message ranges from 0° to 360°. If two decimal places are retained, the range after representing these values as integers is 0 to 36000

[0027] The following formula (Equation (1 )) may be used to estimate the length of each field in binary digits (bits), by way of non-limiting example:(1 ) Length = ceil(log2(MaxValue- MinValue) + 1)

[0028] According to this formula, the length of each data field may be provided as follows, by way of non-limiting example:Table 1 : Data Field Lengths

[0029] Because the length of each data field may differ, if the vehicle is not moving, the length of the speed data field, for example, is 0. Therefore, in constructing a GPS data packet according to various embodiments, the length of the speed data field (and other data fields whose lengths may vary) may be included in the packet. Thus, according to various embodiments, a GPS data packet may include one or more fields that include data representing the length of one or more other corresponding data fields. Thus, for example, a GPS data packet may include a field that includes data representing the length of the speed data field, as well as the speed data field, where the speed data field includes data representing the speed. Each field that includes data representing another field length is referred to herein as a “field length field.” The various field length fields themselves have lengths, which can be provided as follows, by way of non-limiting example:Table 2: Field Length Field Lengths

[0030] According to various embodiments, the length of each field length field in the GPS data packet is fixed, whereas the length of each data field is variable and specified by the data in the corresponding field length field. Compared with the standard data type, e.g., 22 bit integers and 64 bit integers, the variable length datafields according to various embodiments can save a lot of space and only include a small amount of unused little space in some rare extreme cases. The maximal length of latitude and longitude are 36 bits and 33 bits, which is much less than 64 bit and a little bit larger than 32 bit. Therefore, some embodiments are superior to techniques that utilize either a 32 bit integer or a 64 bit integer for these data.

[0031] The maximal length of the course and speed data fields is 12 bits. This is too large for an 8-bit integer and too small for a 16-bit integer. However, embodiments that use 4 bits as the respective field length fields of each of the course and speed data do not waste space, because the maximal length of them is 16 bit, which is the same as the length of 16 bit integer. Therefore, some embodiments are superior to techniques that utilize either an 8 bit or a 16 bit integer for these data.

[0032] With the data fields and the field length fields as described above, a GPS data packet may be configured as follows, by way of non-limiting example.Table 3: Packet Construction

[0033] According to the non-limiting packet construction of Table 3, the minimal length of a GPS data packet according to various embodiments is 8 + 8 + 6 + 6 + 5 +4 + 16 = 53 bits. Therefore, such a packet may occupy seven bytes. The maximal length of a GPS packet according to various embodiments is 8 + 8 + 6+ 36 + 6 + 33 +5 + 17 + 4 + 16 + 16 = 155 bits. Therefore, such a packet may occupy 20 bytes. Because the packet length is between seven and 20 bytes, a single byte is enough to represent the length of the entire packet.

[0034] The packet length and packet type may be considered the header of the GPS data packet. According to the header, the receiver can know the boundary of the GPS data packet and properly handle the packet according to the packet type. The design of the packet may be changed by adding and specifying a new packet type.

[0035] The latitude, longitude, course, and speed may be considered the body of the GPS data packet. According to some embodiments, the field length field precedes the corresponding data field. Thus, the length of the data fields may be dynamically adjusted. According to various embodiments, the binary integers are big- endian with a sign at their end. Finally, a checksum field may be included in the GPSdata packet. According to various embodiments, the checksum algorithm may be CRC-16. The checksum field is optional and may be omitted, e.g., if a lower layer protocol guarantees the integrity of the message.

[0036] Fig. 2 is a flow diagram of a method 200 of wirelessly providing GPS data from a vehicle to an entity, according to various embodiments. The method 200 may be consistent with the use case 100 as shown and described herein in reference to Fig. 1 and with the method 300 as shown and described herein in reference to Fig. 3. The method 200 may be practiced using hardware as shown and described herein in reference to Fig. 4.

[0037] At 202, the method 200 may begin. After 202, control passes to 204.

[0038] At 204, the method 200 includes setting an offset to a maximum interval value. In general, the offset may be implemented as an electronically stored variable that is used to count how many packets have been sent. By way of non-limiting example, the method 200 may send ten packets per second, with the first packet including full information and the rest of the packets including update information. According to such embodiments, the maximum interval value may be set to ten. However, in various embodiments, other maximum interval values may be used. After 204, control passes to 206.

[0039] At 206, the method 200 includes receiving a GPRMC message, e.g., from a GPS receiver onboard the vehicle. After 206, control passes to 208. The actions of 206 may include the actions of 302 of Fig. 3.

[0040] At 208, the method 200 includes saving at least the current course and velocity data as determined from the GPRMC message. After 208, control passes to210.

[0041] At 210, the method 200 includes determining whether the offset is equal to the predetermined maximum interval value. If the offset is equal to the maximum interval value, then control passes to 212. Otherwise, if the offset is not equal to the maximum interval value, then control passes to 222. Note that due to the actions of 204, control will pass to 212 the first time that the actions of 210 are executed after initialization of the method 200.

[0042] At 212, the method 200 includes constructing a packet using at least the current course and velocity data. A detailed description of such construction appears herein in reference to 304 of Fig. 3. After 212, control passes to 214.

[0043] At 214, the offset is reset to 0. This block is utilized to reset the offset and initiate a new cycle. In the subsequent iteration, the outcome of condition block 210 will be “no,” directing control to block 222 to send update packets instead of a full packet until the offset value equals the max interval value again. After 214, control passes to 216.

[0044] At 216, the method includes sending the packet. The packet may be sent wirelessly as shown and described herein in reference to 306 of Fig. 3.

[0045] Concerning the branch of the method 200 for generating and sending an update packet, at 222, the method 200 includes determining update data for the course and velocity data of the vehicle. A description of such calculation is presented herein in reference to 304 of Fig. 3. After 222, control passes to 224.

[0046] At 224, the method 200 includes incrementing the offset. After 224, control passes to 216, which is executed as described above. After 216, control passes to 218.

[0047] At 218, the method 202 includes determining whether the system is running. If not, then control passes to 226, where the method 200 may end. Otherwise, if the system is running, then control passes to 220.

[0048] At 220, the method 200 includes waiting for a delay. The delay may be implemented in order to ensure that a predetermined number of packets are sent each second, for example. By way of non-limiting example, the delay may be 100 millisecond. After 220, control reverts to 206.

[0049] Fig. 3 is a flow diagram of a method 300 of wirelessly providing GPS data from a vehicle to an entity, according to various embodiments. The method 300 may be consistent with the use case 100 as shown and described herein in reference to Fig. 1 and with the method 200 as shown and described herein in reference to Fig. 2. The method 300 may be practiced using hardware as shown and described herein in reference to Fig. 4.

[0050] At 302, the method 300 includes obtaining, from a GPS receiver, GPS data for the vehicle. The GPS data may include data representing at least a latitude of the vehicle and a longitude of the vehicle. The GPS data may further include data representing a course of the vehicle and / or data representing a speed of the vehicle. The data may be obtained from a GPRMC message from the GPS receiver.

[0051] At 304, the method 300 includes generating a packet representing the GPS data. The packet may include at least: a latitude data field that includes latitude data representing the latitude of the vehicle, a field that includes data representing a length of the latitude data field, a longitude data field that includes longitude data representing the longitude of the vehicle, and a field that includes data representing a length of the longitude data field. Note that the latitude data field and the longitude data field may be variable in length among different packets.

[0052] In general, the actions of 304 may include any, or a combination, of the following. First, convert the latitude and longitude (as well as possibly the course and / or speed) values from the GPRMC message to integers by removing the decimal points. Second, if sending an update packet, calculate the differences between the current and previous data values. Otherwise, use the complete integer values. Third, determine the required number of bits for the integers and add the bit count to the respective field length fields, e.g., by prepending to the respective data fields. Fourth, calculate the length of the packet and assemble the packet by including the data values, the field length values, the packet length, and the packet type. Fifth, compute the checksum of the packet and include it in the packet, e.g., by appending it at the end of the packet.

[0053] An example is disclosed presently to illustrate the actions of 304, according to a non-limiting embodiment. By way of non-limiting example, the example is presented in reference to the following GPRMC message, which may have been obtained per 202:$GPRMC, 161229.487, A, 3723.2475, N, 12158.3416, E, 0.13, 309.62, 120598,11.0, E,A*0D

[0054] According to the NMEA 0183 specification, this message contains the following data:Table 4: Example GPRMC Message

[0055] For purposes of illustration in reference to the ongoing non-limiting example, the GPS data to be provided will be the location and velocity (i.e. , speed and course) information. Therefore, the data extracted from the GPRMC message includes the latitude (3723.2475), longitude (12158.3416), course (309.62) and speed (0.13). Removing the decimal points results in the following four integers: 37232475, 121583416, 30962, and 13. Using Equation (1 ), binary digits are needed for 37232475, 28 binary digits are needed for 121583416, 16 binary digits are needed for 30962 and 5 binary digits are needed for 13. The resulting data in binary may be represented as follows.Table 5: Example Packet Contents and Description

[0056] The final binary representation of the packet according to the ongoing example is:00010001000000000110111000111000000111110101101100111001110011111100 11011100111000010000111100011110010001011101000000000100100101000100

[0057] If a CRC16 checksum is appended, the final packet in byte array format may be expressed as:[17, 0, 110, 56, 31 , 91 , 57, 207, 205, 206, 16, 241 , 228, 93, 0, 73, 68]

[0058] The total length of the example GPS data packet is 18 bytes.

[0059] The packet illustrated according to the example is a full GPS data packet, as opposed to an update packet. The structure of an update packet is analogous to that of a full GPS data packet, except as follows. The value of the packet type will be1 , as opposed to 0 (or vice versa, according to preestablished convention). Further, when an entity receives a transmitted update packet, it will add (or subtract) the respective data to the current GPS data, where the included sign indicates addition or subtraction.

[0060] At 306, the method 300 includes sending, wirelessly, the packet to the entity. By way of non-limiting example, the packet may be sent using a point-to-point protocol or a cellular protocol, e.g., as shown and described here in reference to Fig. 1 .

[0061] Once the receiving entity receives the packet, it can decode it to obtain the transmitted GPS data and take any of a variety of actions, including, by way of nonlimiting example, using the data within a safe self-driving vehicle (e.g., for collision avoidance) or providing an ADAS warning.

[0062] Fig. 4 is a schematic diagram of hardware 400 suitable for implementing a system for wirelessly providing GPS data from a vehicle to an entity, according to various embodiments. As shown in Fig. 4, the hardware includes an electronic processor 402, a persistent electronic memory 404, a GPS receiver 406, and a wireless transceiver 408. The persistent electronic memory 404 may store instructions that, when executed by the electronic processor, configure the electronic processor to perform a method as disclosed herein, e.g., the method 400 as shown and described in reference to Fig. 4. The GPS receiver 406 may be a GPS module, which utilizes a GPS protocol to obtain GPS data as described herein. For example, the GPS receiver 406 may receive data from one or more GPS satellites, derived GPS data, and format the GPS data as a GPRMC message. The wireless transceiver 408 may transmit a packet representing at least some of the GPS data as disclosed herein. The wireless transceiver 408 may transmit the packet wirelessly using a point-to-point protocol, acellular protocol, an 802.11 IEEE protocol, or a different wireless protocol, according to various embodiments.

[0063] Certain examples can be performed using a computer program or set of programs. The computer programs can exist in a variety of forms both active and inactive. For example, the computer programs can exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats; firmware program(s), or hardware description language (HDL) files. Any of the above can be embodied on a transitory or non-transitory computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Exemplary computer readable storage devices include conventional computer system RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), flash memory, and magnetic or optical disks or tapes.

[0064] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented using computer readable program instructions that are executed by an electronic processor.

[0065] These computer readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the electronic processor of the computer or other programmable data processing apparatus, create means for implementing thefunctions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0066] In embodiments, the computer readable program instructions may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, statesetting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the C programming language or similar programming languages. The computer readable program instructions may execute entirely on a user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.

[0067] As used herein, the terms “A or B” and “A and / or B” are intended to encompass A, B, or {A and B}. Further, the terms “A, B, or C” and “A, B, and / or C” are intended to encompass single items, pairs of items, or all items, that is, all of: A, B, C, {A and B}, {A and C}, {B and C}, and {A and B and C}. The term “or” as used herein means “and / or.”

[0068] As used herein, language such as “at least one of X, Y, and Z,” “at least one of X, Y, or Z,” “at least one or more of X, Y, and Z,” “at least one or more of X, Y,or Z,” “at least one or more of X, Y, and / or Z,” or “at least one of X, Y, and / or Z,” is intended to be inclusive of both a single item (e.g., just X, or just Y, or just Z) and multiple items (e.g., {X and Y}, {X and Z}, {Y and Z}, or {X, Y, and Z}). The phrase “at least one of” and similar phrases are not intended to convey a requirement that each possible item must be present, although each possible item may be present.

[0069] The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function]...” or “step for [performing [a function]...”, it is intended that such elements are to be interpreted under 35 U.S.C. § 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. § 112(f).

[0070] While the invention has been described with reference to the exemplary examples thereof, those skilled in the art will be able to make various modifications to the described examples without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method can be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.

Claims

What is claimed is:1 . A method of wirelessly providing Global Positioning System (GPS) data from a vehicle to an entity, the method comprising: obtaining, from a GPS receiver, GPS data for the vehicle, wherein the GPS data comprises data representing at least a latitude of the vehicle and a longitude of the vehicle; generating a packet representing the GPS data, wherein the packet comprises: a latitude data field comprising latitude data, a field comprising data representing a length of the latitude data field, a longitude data field comprising longitude data, and a field comprising data representing a length of the longitude data field, wherein the latitude data field and the longitude data field are variable in length among different packets; and sending, wirelessly, the packet to the entity.

2. The method of claim 1 , wherein the latitude data represents the latitude of the vehicle, and wherein the longitude data represents the longitude of the vehicle.

3. The method of claim 1 , wherein the latitude data represents a difference between a previous latitude of the vehicle and the latitude of the vehicle, and wherein the longitude data represents a difference between a previous longitude of the vehicle and the longitude of the vehicle.

4. The method of claim 1 ,wherein the GPS data further comprises data representing a speed of the vehicle, wherein the packet further comprises: a speed data field comprising speed data, and a field comprising data representing a length of the speed data field, wherein the speed data field is variable in length among different packets, and wherein the speed data represents the speed of the vehicle.

5. The method of claim 1 , wherein the GPS data further comprises data representing a course of the vehicle, wherein the packet further comprises: a course data field comprising course data, and a field comprising data representing a length of the course data field, wherein the course data field is variable in length among different packets, and wherein the course data represents the course of the vehicle.

6. The method of claim 1 , wherein the packet further comprises data representing a course of the vehicle, wherein the packet further comprises data representing a speed of the vehicle, and wherein the packet is less than 30 bytes long.

7. The method of claim 1 , wherein the latitude data comprises a latitude angular measure represented in the packet as a first binary integer, andwherein the longitude data comprises a longitude angular measure represented in the packet as a second binary integer.

8. The method of claim 1 , wherein the latitude data comprises a first directional datum represented in the packet as a single bit, and wherein the longitude data comprises a second directional datum represented in the packet as a single bit.

9. The method of claim 1 , wherein the packet further comprises data representing a length of the packet.

10. The method of claim 1 , wherein the packet further comprises data representing a checksum of the packet.11 . The method of claim 1 , wherein the sending comprises sending point- to-point from the vehicle to a second vehicle.

12. A system for wirelessly providing Global Positioning System (GPS) data from a vehicle to an entity, the system comprising: a GPS receiver; a wireless transmitter; an electronic processor communicatively coupled to the GPS receiver and to the wireless transmitter; anda non-transitory computer readable medium communicatively coupled to the electronic processor, the non-transitory computer readable medium comprising instructions that, when executed by the electronic processor, configure the electronic processor to perform actions comprising: obtaining, from the GPS receiver, GPS data for the vehicle, wherein the GPS data comprises data representing at least a latitude of the vehicle and a longitude of the vehicle; generating a packet representing the GPS data, wherein the packet comprises: a latitude data field comprising latitude data, a field comprising data representing a length of the latitude data field, a longitude data field comprising longitude data, and a field comprising data representing a length of the longitude data field, wherein the latitude data field and the longitude data field are variable in length among different packets; and sending, using the wireless transmitter, the packet to the entity.

13. The system of claim 12, wherein the latitude data represents the latitude of the vehicle, and wherein the longitude data represents the longitude of the vehicle.

14. The system of claim 12, wherein the latitude data represents a difference between a previous latitude of the vehicle and the latitude of the vehicle, and wherein the longitude data represents a difference between a previous longitude of the vehicle and the longitude of the vehicle.

15. The system of claim 12,wherein the GPS data further comprises data representing a speed of the vehicle, wherein the packet further comprises: a speed data field comprising speed data, and a field comprising data representing a length of the speed data field, wherein the speed data field is variable in length among different packets, and wherein the speed data represents the speed of the vehicle.

16. The system of claim 12, wherein the GPS data further comprises data representing a course of the vehicle, wherein the packet further comprises: a course data field comprising course data, and a field comprising data representing a length of the course data field, wherein the course data field is variable in length among different packets, and wherein the course data represents the course of the vehicle.

17. The system of claim 12, wherein the packet further comprises data representing a course of the vehicle, wherein the packet further comprises data representing a speed of the vehicle, and wherein the packet is less than 30 bytes long.

18. The system of claim 12, wherein the latitude data comprises a latitude angular measure represented in the packet as a first binary integer, andwherein the longitude data comprises a longitude angular measure represented in the packet as a second binary integer.

19. The system of claim 12, wherein the latitude data comprises a first directional datum represented in the packet as a single bit, and wherein the longitude data comprises a second directional datum represented in the packet as a single bit.

20. The system of claim 12, wherein the packet further comprises data representing a length of the packet.21 . The system of claim 12, wherein the packet further comprises data representing a checksum of the packet.

22. The system of claim 12, wherein the sending comprises sending point- to-point from the vehicle to a second vehicle.

Images