Patent Description:
Combining navigation information provided by one type of navigation system together with navigation information provided by another, different type of navigation system can bring substantial advantages over stand-alone navigation systems. These include improved accuracy and reliability and thus an increased level of navigational safety for many applications.

GNSS is a satellite navigation system which utilizes signals transmitted from a constellation of satellites orbiting the earth. The user interface to this navigation system comprises GNSS receivers configured to receive the satellite signals and process them to determine the user position, velocity and precise time (PVT). Typically GNSS receivers achieve this by processing the received satellite signals to generate code and carrier phase measurements which are forwarded to a filter to derive the navigation solution. GNSS has proven to be highly accurate. However, because GNSS signals are electromagnetic, they can be blocked or degraded by objects such as mountains, tall buildings, and dense foliage and by interference. Hence, stand-alone GNSS does not provide continuous and reliable navigation information all of the time.

Another type of navigation system that is widely used is an inertial navigation system (INS). INS uses sensors that detect acceleration and rate of rotation information which is used to estimate, by employing dead reckoning, relative position and velocity over time. The sensors may be included in an inertial measurement unit (IMU). An IMU measures linear and angular motion using integrated inertial sensors such as accelerometers and gyroscopes. Although INS can provide continuous information on position and velocity without interruption, it has the disadvantage that errors tend to accumulate over time resulting in the position and velocity estimates deviating from their correct values.

Combining GNSS and INS not only provides an efficient way of limiting the errors of INS, it also allows the possibility of determining position and velocity during periods of GNSS signal outage. A further advantage of combining GNSS and INS is that the time required to initially acquire position and velocity can be significantly reduced.

There are a number of ways in which the independent measurement data from GNSS and INS can be combined and processed. Most methods perform sensor fusion, i.e. fusing of the measurements from the GNSS receiver with the measurements from the IMU, using either a Kalman filter or a least-squares (LSQ) filter implemented by a processor. However, for the sensor fusion to be successful, measurements need to correspond essentially to the same point in time.

When a sensor fusion filter compares the outputs of two different navigation systems, i.e. GNSS and INS, it is important to ensure that those outputs correspond to the same time of validity (i.e. time at which the measurements were made). Otherwise, differences in the navigation system outputs due to the time lag between them will be falsely attributed by the filter to the states of the filter, thereby corrupting the estimates of those filter states.

Existing approaches to the problem of synchronizing measurements from two independent navigation systems rely on using some sort of timing reference signal output by the GNSS receiver and feeding this signal to the IMU. For instance, in addition to position and velocity, many GNSS receivers also provide at their output a one pulse-per-second (1PPS) signal which is synchronized to GNSS time. The GNSS receiver calculates and updates pseudo-ranges, pseudo-range rates, carrier phases, carrier ranges, etc. upon the leading edge of the <NUM> PPS signal. This reference signal may be fed to the IMU and subsequently used to timestamp or synchronize the IMU data to GNSS time. However, these approaches require an IMU that can be synced to an external signal or require at least the introduction of an additional component, e.g. an integration processor, from which the IMU measurement outputs can be synchronized with the 1PPS or a stable frequency reference from the GNSS receiver. In either case, an additional connection to the IMU is required which increases complexity and cost.

<CIT> discloses techniques for synchronizing data received from multiple sensors of a device having an application processor configured to function based on an operating system and a co-processor configured to receive the sensor data and generate a timestamp in response thereto. <CIT> discloses an inertial system for gravity difference measurement that uses a GNSS receiver in combination with a strapdown IMU on an airborne platform to measure differences in the earth's gravitational field.

Therefore, an improved method of synchronizing GNSS and INS data is needed so that they can be combined and processed by the filter.

The present invention provides a navigation receiver, a navigation system and a method of time stamping asynchronous sensor measurements. In accordance with an embodiment, a method of time-stamping one or more asynchronous sensor measurements in a global navigation satellite system receiver is provided. Sensor measurement data is received at a first port. A signal pulse is received at a second port. The signal pulse represents a time of measurement according to a first time domain of the received sensor measurement data. Based on the received signal pulse, a timestamp according to a second time domain is generated. The generated timestamp is associated in the second time domain with the received sensor measurement data.

In accordance with a further embodiment, a global navigation satellite system receiver is configured to time-stamp one or more asynchronous sensor measurements. The receiver has a first port that is configured to receive sensor measurement data from at least one sensor. The receiver additionally has a second port configured to receive a signal pulse. The signal pulse represents a time of measurement according to a first time domain of the received sensor measurement data. A circuit of the receiver is configured to generate, based on the received signal pulse, a timestamp according to a second time domain. A processor of the receiver is configured to associate the generated timestamp in the second time domain with the received sensor measurement data.

In accordance with another embodiment, a global navigation satellite system receiver is configured to time-stamp one or more asynchronous sensor measurements. The receiver has a first port configured to receive sensor measurement data from at least one sensor. The receiver has a second port configured to receive a signal pulse. The signal pulse represents a time of measurement according to a first time domain of the received sensor measurement data. A processor of the receiver is configured to generate, based on the received signal pulse, a timestamp according to a second time domain and to associate the generated timestamp in the second time domain with the received sensor measurement data.

The invention is defined by independent claims <NUM> and <NUM>. Any further aspect of the invention is defined exclusively according to the dependent claims.

The present invention is described with respect to particular exemplary embodiments thereof and reference is accordingly made to the drawings in which:.

References will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise specified. The implementations set forth in the following disclosure are consistent with aspects related to the invention as recited in the appended claims.

The present invention provides a global navigation satellite system (GNSS) receiver, a navigation system and a method of time stamping asynchronous sensor measurements or sensor measurement data. Because the sensors can operate independently from the GNSS navigation receiver and in many cases are external to the GNSS receiver, the sensor measurements are not necessarily generated according to the time base of the GNSS receiver, i.e. they are asynchronous. Unlike prior approaches, the present invention solves the problem of data synchronization between GNSS and other sources of navigation data, e.g. an inertial navigation system (INS) by accomplishing synchronization at the GNSS navigation receiver.

The sensor measurements or, more particularly, sensor measurement data, may be obtained from one or more sensors. The one or more sensors can be, for example, part of a sensor system, such as an inertial measurement unit (IMU) of an inertial navigation system (INS). Other examples of inertial sensors that can be used in connection with the present invention include, for example, an angular rate sensor, a gyroscope or an accelerometer. The methods set forth hereunder are equally applicable to measurements or measurement data originating from other types of sensors, e.g. a wheel counter or odometer, and a speedometer. The sensor measurements are initially in the time domain of the sensor producing the measurements, e.g. the time domain of the IMU, wheel counter, odometer, etc. According to aspects of the present invention, the sensor measurements are synchronized in time with the measurements made from GNSS satellite signals by receiving at the GNSS receiver an electrical timing signal from the sensor. This timing signal may be generated by the sensor and contains signal pulses that indicate that new sensor measurement data is available. These pulses in the electrical timing signal are used to timestamp the sensor measurements in the time domain of the GNSS receiver, i.e. a local receiver time. The GNSS receiver accomplishes this by using the signal pulses in the timing signal to generate a timestamp in the time base of the GNSS receiver for attributing to the received sensor measurements. The sensor measurements and the GNSS navigation signals can thereafter be fused together, for example, using either a Kalman filter or a least-squares (LSQ) filter implemented by a processor in accordance with known sensor fusion methods.

The sensor can obtain sensor measurements or measurement data independently and autonomously with respect to the GNSS navigation receiver. For example, the sensor or sensor system itself may control the times at which measurements are taken. Alternatively, the sensor or system may be prompted to take measurements by some other external device or source. In either case, an electrical timing signal generated by the GNSS receiver is not required to prompt the sensor or sensor system to provide measurement information. This is because the GNSS navigation receiver is informed, e.g., by the sensor or another source, that new sensor measurement data is available. The GNSS navigation receiver is also informed of the time that the measurement was taken.

More particularly, some sensor systems, e.g. commercially available IMUs provide a signal which indicates when new data from measurements taken by the sensor is ready at the IMU output. Measurements made by the on-board accelerometers and gyroscopes are fed to the IMU output. The new measurement data may be stored in a register in the IMU and a separate "data ready" signal may be output at a pin provided by the IMU. For example, the BMI160 IMU available from Bosch Sensortec GmbH provides, in addition to physical type of interrupts, several low-latency data driven interrupts at pins on the IMU. One such interrupt is the "data ready" interrupt which is triggered every time a new data sample from the on-board accelerometers and gyroscopes is available.

The inventors of the present invention have recognized that such a "data ready" signal can be used to timestamp asynchronous sensor measurements directly at the GNSS receiver without the need for feeding a synchronization signal, e.g. 1PPS or some other reference signal, routed from the GNSS receiver to the sensor or sensor assembly, e.g. IMU.

The sensor measurements may be in a format that is native to the sensor or sensor system which produced the measurements. However, some GNSS receivers may require the sensor measurement data to be in a predetermined format in order for it to be processed by the GNSS receiver. In accordance with an embodiment of the present invention, a pre-processor may be provided that is configured to convert the native format of the sensor measurement data into a predetermined data message format that is compatible with the GNSS receiver. The messages may, for example, be formatted in accordance with a proprietary protocol supported by the GNSS receiver, for example a UBX-ESF message format supported by u-blox's GNSS receivers. In addition to a payload, the formatted messages may comprise one or more of a synchronization character in the message preamble, a message identification (ID) string, a length byte indicating the length of the payload and a checksum appearing at the end of the message for error correction. The skilled person will recognize that such a formatted message could be constructed in different ways.

<FIG> illustrates a block schematic diagram of a GNSS navigation receiver <NUM> for time stamping asynchronous sensor measurement data in accordance with an embodiment of the present invention. The navigation receiver <NUM> includes a processor <NUM> that is configured to perform processing functions described herein.

As shown in <FIG>, the GNSS receiver <NUM> includes a port <NUM> which is configured to receive a timing signal <NUM>. This timing signal <NUM> (e.g., the "data ready" signal described above) may be generated by a sensor or sensor system, such as an IMU for example. The navigation receiver <NUM> also includes a port <NUM> which is configured to receive sensor measurement data <NUM> from the sensor or sensor system. Thus, the GNSS receiver <NUM> has at least two inputs including the port <NUM> and the port <NUM>. The port <NUM> is configured to receive an indication (e.g. a pulse or signal level transition in the signal <NUM>) that indicates new sensor measurement data is available. This also indicates a time that the measurement was taken according to the time domain of the one or more sensors. The port <NUM> is configured to receive the sensor measurement data <NUM>. The port <NUM> for receiving the timing signal <NUM> may, for example, be connected to a single pin of an integrated circuit of the receiver <NUM>. Alternatively, the port <NUM> may include a differential signal input port. The port <NUM> for receiving the sensor measurements <NUM> may be in the form of, for example, a serial port interface (SPI), RS232 serial port or USB port.

A signal pulse or, more particularly, a signal level transition appearing on the electrical timing signal <NUM> as received by the receiver <NUM> is used by the processor <NUM> to timestamp the incoming asynchronous sensor measurements or measurement data. A relationship in frequency and phase between a clock signal used internally by the processor <NUM> and GNSS time will be known to the processor <NUM>. This is because the processor <NUM> may also be used by the receiver <NUM> to process the GNSS satellite signals and derive position, velocity and GNSS time. Therefore, the timing signal pulse may be detected by the processor <NUM> and converted into a timestamp in absolute time or GNSS time for the corresponding sensor measurement data. Alternatively, the timing signal pulse may be detected by the processor <NUM> and thus generate a timestamp in a time domain corresponding to the local time of the GNSS receiver, i.e. local receiver time. Since it will be known how the local receiver time relates to GNSS time, the timestamps in GNSS time may be later derived during sensor fusion.

As described in more detail below, the processor <NUM> of the receiver <NUM> associates the timestamp generated from the signal pulse received at the port <NUM>, together with the corresponding sensor measurement data received at the port <NUM>. Generated timestamps and corresponding measurements may be stored, for example, in association with each other in memory (not shown) at the receiver <NUM>.

<FIG> illustrates a block schematic diagram of a navigation system <NUM> for time stamping asynchronous sensor measurement data in accordance with another embodiment of the present invention. As shown in <FIG>, the system may include one or more sensors <NUM> that can generate the timing signal <NUM> and the measurement data <NUM>, as are also shown in <FIG>. The generation of timestamps for sensor measurement data received by the navigation system <NUM> is carried out in a similar manner as described above in connection with <FIG>. The one or more sensors <NUM> of <FIG> may include an angular rate sensor, a gyroscope, an accelerometer, a wheel counter or odometer, and/or a speedometer. The sensor(s) <NUM> may, for example, include a sensor system such as an IMU or the sensor(s) <NUM> can be integrated within an IMU. The one or more sensors <NUM> may be external to the GNSS receiver <NUM> or may alternatively be integrated into a GNSS module containing the receiver <NUM>.

Also shown in <FIG> is an optional pre-processor <NUM>. The one or more sensors <NUM> may generate sensor measurement data <NUM> in accordance with a format that is native to the sensor(s) <NUM>. The pre-processor <NUM> is configured to format this sensor measurement data to produce formatted sensor measurement data <NUM> that is compatible with the receiver <NUM>. For example, formatted sensor measurement data <NUM> generated by the pre-processor <NUM> may be in accordance with a pre-determined data message format that the receiver <NUM> is configured to receive. Because a timestamp is associated with each such message after the message is received by the receiver <NUM>, the messages themselves do not need to contain timing information representative of any time of measurement of the sensor measurement data <NUM>. The formatted sensor measurement data <NUM> is delivered to the receiver <NUM> via the port <NUM>.

As time progresses, a number of pairs of timestamps and associated sensor measurements can be stored in memory. This stored information can be retrieved from memory and used to combine, e.g., by performing sensor fusion, the inertial measurements with the GNSS satellite signals for the same time of validity so as to generate resulting navigation information. This resulting navigation information <NUM> (e.g., one or more of global position, velocity and GNSS time, collectively referred to as PVT") can be available at an output of the receiver <NUM>.

As shown in <FIG>, the navigation receiver <NUM> is configured to receive GNSS satellite signals from GNSS satellites via an antenna <NUM>. The receiver <NUM> is further is configured to process the received GNSS satellite signals to generate a navigation solution <NUM>. The navigation solution generated by the receiver <NUM> may include the calculated position and velocity of the receiver <NUM> as well as a determination of precise GNSS time.

The processor <NUM> may perform these processing functions. More particularly, the receiver <NUM> receives satellite signals from one or more GNSS constellations and processes these signals to provide GNSS measurements such as pseudo-ranges, carrier phases, rates of pseudo-ranges, etc. to a navigation filter. The processor <NUM> may, for example, implement the filter, e.g. a Kalman filter or a least-squares (LSQ) filter, which is used to determine the navigation solution based on the GNSS measurements.

<FIG> illustrates a timing diagram for time-stamping asynchronous measurement data in accordance with an embodiment of the present invention. <FIG> shows a relationship between a timing signal <NUM> and formatted data messages <NUM> containing sensor measurement data. More particularly, as shown in <FIG>, the timing signal <NUM> may comprise a normally low-voltage level (e.g.. logic "zero"), which transitions to a high-voltage level (e.g.. logic "one") upon the sensor measurement data being ready at the one or more sensors <NUM> (<FIG>) and then, after a short period, i.e. duration of the signal pulse, the timing signal <NUM> returns to the low-voltage level. This is represented in <FIG> by synchronization pulses <NUM> appearing in the timing signal <NUM>. In an embodiment, the leading edge of each signal pulse <NUM> coincides with the availability of the sensor measurement data. Although <FIG> shows the timing signal <NUM> as normally comprising a low-level voltage when no sensor measurement data <NUM> is available, the skilled person will quickly recognize that a high-voltage level (e.g. logic "one") could equally be used for the timing signal <NUM>, in which case the signal <NUM> transitions to a low-level voltage (e.g. logic "zero") when new measurement data <NUM> is available at the sensor(s) <NUM>. In other words, an inverted timing signal to that shown in <FIG> may alternatively be used.

The formatted data messages <NUM> will typically be available after a delay due to processing time of the pre-processor <NUM> (<FIG>). Accordingly, the signal pulses <NUM> of the timing signal <NUM> (or leading edges thereof) may indicate that new sensor measurement data was obtained a short time before the corresponding formatted data message <NUM> is available to the receiver <NUM>. The receiver <NUM> uses the signal pulses <NUM> of the timing signal <NUM> (e.g., the leading edge of the pulses) for generating the timestamp and subsequent processing as each pulse <NUM> indicates the time that a corresponding measurement was taken by the one or more sensors <NUM>.

In embodiments without a pre-processor <NUM>, each signal pulse <NUM> may also arrive slightly before the corresponding measurement data <NUM> arrives at the receiver <NUM>. Thus, in most situations, regardless of whether a pre-processor <NUM> is employed or not, each timing pulse <NUM> from the sensor <NUM> will arrive at the receiver <NUM> slightly before the corresponding measurement data <NUM> (<FIG>) or formatted measurement data <NUM> (<FIG>) and thus the processor <NUM> will associate, i.e. link the most-recent received signal pulse <NUM> with the next received sensor measurement data <NUM> or formatted measurement data <NUM>. However, the present invention may also be configured to associate the received signal pulse <NUM> with simultaneously received sensor measurement data <NUM> or formatted sensor measurement data <NUM>. The present invention may also be configured to associate a later received pulse <NUM> with earlier received sensor measurement data <NUM> or formatted measurement data <NUM>.

As described herein and shown in <FIG>, the timing signal <NUM> is generated by the sensor <NUM>. It will be apparent, however, that the timing signal <NUM> may be generated by another means. For example, the pre-processor <NUM> may generate the timing signal <NUM> provided to the receiver <NUM>. The pre-processor <NUM> may accomplish this by generating a signal pulse each time new measurement data <NUM> is received from the sensor(s) <NUM>. Alternatively, some other circuit or device may generate the timing signal <NUM> by monitoring the measurement data <NUM> generated by the sensor <NUM> and generating a pulse each time a new measurement data is available. Persons skilled in the art will understand that generation of the timing signal <NUM> and signal pulses <NUM> contained therein may be accomplished in various ways and by various means.

Multiple different embodiments of the GNSS receiver described herein may be implemented. <FIG> illustrates an embodiment of a GNSS navigation receiver <NUM> comprising an interrupt and timing system of a processor <NUM> internal to the receiver <NUM> for time stamping asynchronous sensor measurements in accordance with the present invention. This embodiment exploits an interrupt and a timestamp counter (TSC) present in many modern processors. Accordingly, this embodiment has the advantage of requiring minimal additional hardware other than such a processor. Thus, in this embodiment, the time-stamping is implemented using a combination of software and commercially available hardware.

As shown in <FIG>, a processor <NUM> includes an arithmetic logic unit (ALU) <NUM>, a controller <NUM> and a register bank <NUM> which includes a timestamp counter (TSC) <NUM>. The TSC <NUM> is a register for which the counter value stored therein is incremented on every clock cycle of the processor <NUM>. The clock signal may be, for example, a <NUM> clock signal generated by a clock <NUM> connected to the processor <NUM>. Because this clock signal is used to increment the TSC <NUM> and thus indicates time associated with the processor <NUM>, the TSC <NUM> may therefore provide the highest resolution timing information available to the processor <NUM>. The TSC <NUM> may be used to timestamp the sensor measurement data <NUM>, <NUM> using synchronization pulses <NUM> as they are received via the timing signal <NUM>. And, because the processor <NUM> may be the same processor used to process the GNSS satellite signals, the relationship in frequency and phase between the clock signal and GNSS time will be known to the processor <NUM>. Thus, the processor <NUM> is able to provide a timestamp in the GNSS time base. If needed, the value from the TSC <NUM> may be converted into the timestamp, for example, if the fusion process requires the timestamp to be in a particular format different from that generated by the time TSC <NUM>.

As shown in <FIG>, the receiver <NUM> also includes one or more memory units <NUM> used by the processor <NUM> for various functions described herein, including for storing software, pairs of timestamps and corresponding measurements, as well as temporary values from various calculations for performing sensor fusion. The register bank <NUM> may also be used to temporarily store sensor measurement data <NUM>, <NUM> received from one or more sensors and to make this measurement data available to the processor <NUM> for storing the sensor measurement data with the corresponding timestamps in memory <NUM> and for performing sensor fusion.

In accordance with the embodiment shown in <FIG>, the timing signal <NUM> may be applied to an interrupt input (e.g. a pin) of the processor <NUM> which is then received by the processor controller <NUM> to trigger interrupts. An interrupt is generated in response to a signal pulse <NUM> or, more particularly, a leading edge or falling edge thereof, in the timing signal <NUM>. The processor <NUM> then runs an appropriate interrupt service software routine (i.e. an "interrupt handler") according to a memory location vector accessed in response to the interrupt. The interrupt handler prioritizes interrupts and saves them in a queue if more than one interrupt is waiting to be handled.

The action on the interrupt input which triggers an interrupt on the processor controller <NUM> may be set using an interrupt mode of the particular interrupt being monitored by the controller <NUM>. For example, a "RISING" interrupt mode activates an interrupt on a rising edge appearing at the interrupt pin. However it is also possible to set the interrupt mode to "FALLING" which activates an interrupt on a falling edge appearing at the pin. The interrupt mode may be selected depending on the nature of the timing signal generated by the sensor.

The processor controller <NUM> is configured to run the interrupt service routine each time the interrupt condition is met. This software may be written in assembly code, C, C++ or a combination thereof. The interrupt service routine may contain code that causes the counter value in the TSC <NUM> to be copied to a register of the register bank <NUM> or to the memory <NUM>. This stored counter value may then be used as a timestamp for the corresponding asynchronous sensor measurement data <NUM> or <NUM> received at the port <NUM> of the receiver <NUM>. Alternatively, the stored counter value can be converted to the timestamp. The program may also cause the corresponding sensor measurement data <NUM> or <NUM> to be retrieved from the register bank <NUM> and for this measurement to be stored in association with the corresponding timestamp, e.g., in memory <NUM>. The measurement data and corresponding timestamp may therefore be stored together in memory <NUM> for later processing by an additional software program that combines the GNSS measurements with the sensor measurement date, e.g., by performing sensor fusion. Such a software program may be also stored in the memory <NUM>.

In another embodiment of the GNSS receiver, the time-stamping in accordance with the present invention may be implemented using an application specific integrated circuit (ASIC) that interfaces between the internal processor of the receiver and the one or more sensor(s), e.g., the IMU. <FIG> illustrates an embodiment of a navigation receiver <NUM> configured to perform time stamping of asynchronous sensor measurement data using an ASIC <NUM> in accordance with an embodiment of the present invention.

As shown in <FIG>, the ASIC <NUM> and processor <NUM> may be integrated into the GNSS receiver <NUM> together with a memory <NUM> and a clock <NUM>. The ASIC <NUM> preferably comprises a dedicated input, which may be an input/output (IO) pin configured to receive an external signal such as the timing signal <NUM>, one or more edge-detection circuits, hereafter edge detectors, 504A, 504B, a timer counter <NUM> and one or more counter registers 508A, 508B.

The dedicated input of the ASIC <NUM> may be implemented as a general-purpose input output (GPIO) pin and is coupled to an input of the one or more edge detectors 504A, 504B. This input is configured to receive the timing signal <NUM> from the one or more sensor(s), e.g. IMU. In this case, the port <NUM> may comprise the dedicated input of the ASIC <NUM>. Each edge detector 504A, 504B may, for example, be implemented using two latches arranged in a master-slave setup to provide a flip-flop circuit. Although not explicitly shown in <FIG>, the skilled person will appreciate that the flip-flop circuit or latches may be clocked with a clock signal. Thus the edge detector 504A, 504B may, in one embodiment, be clocked with a signal from clock <NUM>. In one embodiment, the edge detector 504A may be configured to detect a rising edge of a signal pulse <NUM> in the timing signal <NUM>, while the edge detector 504B may be configured to detect a falling edge of a signal pulse <NUM> in the timing signal <NUM>. Thus, the ASIC <NUM> is preferably compatible with sensors such as inertial sensors and IMUs that generate data ready pulses whose leading or falling edge essentially correspond to the time instant of availability of measurement data. An output of the edge detector 504A is coupled to a counter register 508A while an output of the edge detector 504B is coupled to a counter register 508B. The counter <NUM> may essentially be a register whose stored value is incremented upon each cycle of a clock signal. The counter registers 508A, 508B may be used for storing a current counter value from timer counter <NUM> which may serve as the timestamp for the corresponding sensor measurement data received by the GNSS receiver <NUM>. Upon detection of a signal pulse <NUM> in the timing signal <NUM> by one of the edge detectors 504A or 504B, the current counter value of the counter <NUM> is copied into one of the registers 508A or 508B. This copying may be triggered on a rising or falling edge of the signal pulse arriving on the timing signal <NUM>.

The counter <NUM> may essentially be a register whose stored value is incremented upon each cycle of a clock signal. The clock signal used by the counter <NUM> is preferably, though not necessarily, the same clock signal used by the processor <NUM> of this embodiment and, thus, it is a measure of local time of the processor <NUM>. As in the embodiment of <FIG>, this may be a <NUM> clock signal generated by the clock <NUM>. If the same processor is also used to process the GNSS satellite signals, the relationship of GNSS time to the local time of the GNSS receiver will be known. If needed, the value from the timer counter <NUM> can be converted into the timestamp, for example, if the fusion process requires the timestamp to be in a particular format different from that generated by the time counter <NUM>. The counter <NUM> can be implemented in hardware, software or combination thereof. Each edge detector 504A and 504B is not only connected to the counter <NUM> but also to a corresponding register. The connection to the counter <NUM> triggers copying the value in the counter <NUM>, the other connection tells the ASIC <NUM> where the copy of the counter value should be stored (e.g., among the registers 508A and 508B).

Similarly to the embodiment of <FIG>, the processor <NUM> of <FIG> may include a processor controller <NUM> which is configured to control operation of the receiver <NUM> of <FIG>, by executing software programs and routines. The processor <NUM> may also include one or more memory units <NUM> which may be used by the processor <NUM> for various functions described herein, including for storing software and temporary values from various calculations for combining the GNSS measurements derived from the satellite signals with the sensor measurement data, e.g. by performing sensor fusion as described herein. The processor <NUM> of <FIG> may also include a register bank <NUM>. The register bank <NUM> may be configured to receive sensor measurement data <NUM> or formatted sensor measurement data <NUM> from one or more sensors and to make this measurement data available to the controller <NUM>.

When a new measurement arrives to the GNSS receiver <NUM> via port <NUM>, this can trigger the processor <NUM> to collect the timestamp from the ASIC <NUM>. In this case, the processor <NUM> can continuously monitor the port <NUM> for new sensor measurement data. In the case of the sensor measurements being formatted (e.g., as UBX-ESF messages), information contained in the formatted message can trigger a function call which causes the processor <NUM> to save the measurement and associated timestamp in memory <NUM>. In this case, an IO task monitors the input buffers connected to port <NUM> and processes the data therein in order and based on the input message contents in order to trigger an appropriate message handling function.

Alternatively, depending on the configuration of the interface port <NUM>, e.g. universal serial bus (USB), the fact of a message arriving on the port <NUM> can trigger the processor <NUM> to retrieve and process the message. In this case, the arrival of the message acts essentially as an interrupt to the processor <NUM> to retrieve and process the measurement data from the port <NUM>. Another manner in which the processor <NUM> may be informed when a new timestamp (and measurement) is ready to be retrieved is by implementing a software event which is triggered by one of the edge detectors 504A or 504B. More particularly, every time a signal pulse is detected by the edge detector, this triggers a software event which informs the processor <NUM> to retrieve the timestamp (and measurement).

Once the processor <NUM> is notified of the new sensor measurement, the controller <NUM> runs a software program, which causes the sensor measurement data <NUM>, e.g., contained in the register bank <NUM>, and the corresponding timestamp contained in the counter register 508A or 508B to be retrieved. Each measurement and corresponding timestamp are preferably stored in association with each other, e.g., together in the same location in memory <NUM>. The measurements and corresponding timestamps are therefore available for later processing by further software that performs sensor fusion.

The processor <NUM> needs to know from which of the registers 508A or 508B it should retrieve the current timestamp. In one embodiment, the processor <NUM> is so informed because the formatted messages received at port <NUM> and containing the sensor measurements may also contain a designated field that indicates whether the expected signal pulse is a rising edge or falling edge. As shown in <FIG>, the register 508A corresponds to a rising edge while the register 508B corresponds to a falling edge. In this way, the processor <NUM> is informed which of the registers contains the corresponding timestamp for the received measurement data. For instance, if the designated field in the formatted message <NUM> indicates that a signal pulse <NUM> with a falling edge corresponding to the sensor measurement data <NUM> is expected, the processor <NUM> will be directed to retrieve the timestamp from register 508B.

While two registers 508A and 508B are shown in <FIG>, there could be more such registers. For example, there could be two pairs of edge detectors, where one pair of edge detectors 504A, 504B is connected to a first pin (e.g. port <NUM>), as shown in <FIG>. A second pair of edge detectors (not shown) may be connected to another input pin (e.g. port not shown). The structure of the port <NUM>, edge detectors 504A, 504B and registers 508A, 508B is essentially duplicated. Therefore, there could be, for example, a total of four such registers with each register triggered by a respective edge detector. In this case, the processor <NUM> may so informed because the formatted messages received at port <NUM> and containing the sensor measurements may also contain a designated field identifying the pin (e.g. port <NUM>) on which the signal pulse arrives. This port identification, along with the indication of whether the expected signal pulse is a rising edge or falling edge, can be used to identify a particular one of the registers that contains the corresponding timestamp for the received measurement data.

Alternatively, the timestamp may be selected from an appropriate one of the registers based on the register whose value changed last. Thus, the processor <NUM> can monitor all timestamp registers (e.g. 508A, 508B in <FIG>) and the selection of which register the timestamp should be retrieved is based on which register was last updated.

When the sensor measurements along with the associated timestamps are brought together with the GNSS measurements for fusion, the timestamps (i.e. counter values) can be converted into a format that is compatible with the GNSS measurement timestamps. This conversion can be performed before or after the timestamps are stored together with the sensor measurements.

In one embodiment, both the processor <NUM> and the ASIC <NUM> are clocked by the same clock signal generated by the clock <NUM>. In this case, the GNSS measurements are processed by the processor <NUM> according to this same clock signal, i.e. local processor time of the GNSS receiver. Thus, the time domain of the sensor measurement data <NUM> is converted directly to the time domain of the processor <NUM> using the timestamp generated by the counter <NUM>. Since the relationship between the local time of the GNSS receiver and GNSS time will be known, the processor is able to relate the generated timestamps for the sensor measurement data to GNSS time. In another embodiment, the processor <NUM> and the ASIC <NUM> are clocked by different clock signals, e.g. clock <NUM> and CLK2 (not shown in <FIG>). In this case, the GNSS measurements are processed by the processor <NUM> according to its own clock signal. Thus, the time domain of the sensor measurement data <NUM> is first converted to the time domain of the ASIC <NUM> according to the timestamp generated by the counter <NUM>. This timestamp however then needs to be converted to a third time domain, i.e., the time domain of the processor <NUM> and the GNSS measurements. This may accomplished, for example, by a synchronization structure between the registers 508A, 508B and the processor <NUM> or by software running on the processor <NUM> (or a combination of both). Persons skilled in the art will understand that this synchronization between the two clocks, e.g. clock <NUM> and CLK2 (not shown) in the GNSS receiver <NUM> may be accomplished in various ways and by various means.

In the embodiments illustrated in <FIG> and <FIG>, the processor <NUM> associates the generated timestamp with the received sensor measurement data as described herein. The processor <NUM> may also perform GNSS fusion in which the timestamps and associated sensor measurement data are fused with the GNSS measurement data. Alternatively, the GNSS fusion can be performed by a different processor. In this case, the timestamps may need to be converted to a time domain of the additional processor. For example, the timestamps may be converted from the time domain of the processor <NUM> to the time domain of the additional processor.

In both embodiments illustrated in <FIG> and <FIG>, the storing of the timestamp in memory may occur before or after the corresponding sensor measurement data is received by the GNSS receiver. Regardless of the order in which they are stored in memory, the timestamp and corresponding measurement data are associated with each other. This may be accomplished by storing both the timestamp and corresponding measurement data in memory together at the same or adjacent memory locations or in some other manner that maintains a logical connection between the timestamp its corresponding measurement data. For example, the generated time stamps in the time domain of the receiver <NUM> may be embedded into the sensor measurement data <NUM>, <NUM> and then stored in the memory <NUM>.

Also in both embodiments illustrated in <FIG> and <FIG>, association of the generated timestamp with the sensor measurement data <NUM>, <NUM> may occur for sensor measurement data received before the signal pulse <NUM> of the timing signal <NUM>, after the signal pulse or even for sensor measurement data <NUM>, <NUM> received at the same time as the signal pulse.

The software that is used to control the processor <NUM> of <FIG> and <FIG> to perform the functions described herein may be written in assembly code, C, C++ or any other suitable programming language or combination thereof.

<FIG> illustrates a flow diagram of a method <NUM> of time stamping one or more asynchronous sensor measurements in a global navigation satellite system receiver in accordance with an embodiment of the present invention. The method <NUM> may be performed, for example, by any of the embodiments illustrated in <FIG> and <FIG>. As shown in <FIG>, in a step <NUM>, sensor measurement data <NUM>, <NUM> is received. The sensor measurement data may be received at a first port (e.g., port <NUM>). In a step <NUM>, a signal pulse <NUM> is received. The signal pulse may be received via the timing signal <NUM> received at a second port (e.g., port <NUM>). The pulse in the timing signal represents a time of measurement according to a first time domain of the sensor measurement. The first time domain may be that of one or more sensors, e.g. inertial sensors or a sensor system, e.g. IMU that carries out the measurement. The time of measurement may be represented by a leading or falling edge transition of the signal pulse. In a step <NUM>, a timestamp is generated based on the received signal pulse according to a second time domain. The second time domain may correspond to GNSS time. In a step <NUM>, the timestamp generated in the second time domain in step <NUM> is associated with the sensor measurement data received in step <NUM>.

In a further, optional step, the timestamp generated in the second time domain may be stored in a memory in association with the corresponding sensor measurement data. The sensor measurement data may optionally be pre-processed to generate at least one formatted sensor measurement data message containing the sensor measurement data.

Claim 1:
A global navigation satellite system receiver (<NUM>) configured to time-stamp one or more asynchronous sensor measurements, wherein the receiver comprises:
a first port (<NUM>) configured to receive sensor measurement data (<NUM>, <NUM>) from at least one sensor (<NUM>);
a second port (<NUM>) configured to receive a signal pulse (<NUM>), wherein the signal pulse (<NUM>) represents a time of measurement according to a first time domain of the received sensor measurement data (<NUM>, <NUM>);
a circuit (<NUM>) configured to generate based on the received signal pulse (<NUM>) a timestamp according to a second time domain; and
a processor (<NUM>) configured to associate the generated timestamp in the second time domain with the received sensor measurement data (<NUM>, <NUM>).