Resource management method of GNSS receiver and corresponding GNSS receiver

Abstract

The invention relates to a resource management method of a GNSS receiver and a corresponding GNSS receiver. The method comprises: determining an epoch of an application of the GNSS receiver, where the epoch defines a first time period t2 during which the application is expected to receive positioning data; determining a number of repetitions n of one or more repetitive tasks for performing a positioning algorithm of the GNSS receiver; during each epoch, a localization algorithm is performed. The execution of the localization algorithm comprises: executing one or more repetitive tasks of the localization algorithm n times, where executing the one or more repetitive tasks n times occupies a first run time t3 dependent on the number of repetitions n; executing one or more non-repetitive tasks of a localization algorithm, where executing the one or more non-repetitive tasks occupies a second run time t5 independent of the number of repetitions n; the updated positioning data is output to the application based on the output of the one or more repetitive tasks and the one or more non-repetitive tasks of the positioning algorithm. The determination of the number n of repetitions makes t3 + t5 < = t2.

Description

Technical Field

[0001] The present invention relates to a resource management method for a Global Navigation Satellite System (GNSS) and a corresponding GNSS receiver configured to perform the resource management method. Background Technology

[0002] Currently, many satellite-based navigation systems are in use. Examples include the United States' Global Positioning System (GPS), Russia's Global Navigation Satellite System (GLONASS), China's BeiDou Navigation Satellite System (BDS), and the European Union's Galileo system. In addition, many other global, regional, and national satellite-based navigation systems are either operational or under development.

[0003] Satellite-based navigation systems enable the determination of a GNSS receiver's position based on the propagation time delay of satellite signals received from one or more satellites in a known orbital constellation. The accuracy of the determined position by a GNSS receiver typically depends on various parameters of the received signals used for positioning. Among other things, these signals encode information about the position of the respective satellite and the time when the signal was transmitted. Both the encoded information itself and the radio frequency (RF) signals used for transmission are prone to error. Generally, the more satellite signals a GNSS receiver considers, the higher the accuracy of the calculated position. However, acquiring, tracking, decoding, and / or processing a large number of satellite signals also places high demands on the processing resources of GNSS receivers. Therefore, resource management for GNSS receivers is generally necessary.

[0004] US 8,164,519 B1 discloses a method for rapidly obtaining the location of a device. The method generally includes the following steps: (A) automatically and repeatedly launching (i) a radio receiver and (ii) a given subset of correlators in some of a plurality of search engines of the device; (B) buffering first data of a plurality of location signals received by the radio receiver during a first time period, each location signal containing a corresponding one of a plurality of code sequences; (C) searching the first data using correlators to find at least one code sequence, each correlator using a search window including a fraction of the code length of the code sequence; and (D) generating an output signal carrying the device location based on the location signal corresponding to the found code sequence.

[0005] The rapid acquisition method disclosed in this paper can be used to support always-on operation of GPS receivers, even in battery-powered handheld devices with very high power consumption (such as cellular phones, digital cameras, and digital camcorders).

[0006] While the fast acquisition method based on the prior art is particularly useful in such low-power applications, it does not provide positioning data at predetermined times and is therefore unsuitable for certain types of applications, including GNSS applications that actively request or expect to receive updated positioning data at a given sampling rate. Summary of the Invention

[0007] Therefore, the present invention provides an improved GNSS receiver resource management method that can flexibly adapt to the requirements of different applications and / or available processing resources (e.g., the CPU power of the GNSS receiver).

[0008] In this context, this disclosure provides a resource management method for a GNSS receiver, comprising: determining an epoch for an application of the GNSS receiver, wherein the epoch defines a first time period t2 in which the application is expected to receive positioning data; determining a repetition number n of one or more repetitive tasks of a positioning algorithm of the GNSS receiver; and executing the positioning algorithm during each epoch. The step of executing the positioning algorithm includes: executing the one or more repetitive tasks of the positioning algorithm n times, wherein executing the one or more repetitive tasks n times occupies a first runtime t3, the first runtime depending on the repetition number n; executing one or more non-repetitive tasks of the positioning algorithm, wherein executing the one or more non-repetitive tasks occupies a second runtime t5, the second runtime not depending on the repetition number n; and outputting updated positioning data to the application based on the outputs of the one or more repetitive tasks and the one or more non-repetitive tasks of the positioning algorithm. The repetition number n is determined such that the sum of the first runtime t3 and the second runtime t5 is equal to or shorter than the first time period t2.

[0009] Among other things, the inventors have discovered that the resource consumption of a localization algorithm can be modeled by dividing the task into one or more non-repetitive tasks and one or more repetitive (or iterative) tasks. Furthermore, by determining the number of repetitions of the one or more repetitive tasks executing the localization algorithm, the overall response time can be controlled, thereby controlling the output rate at which updated localization data is provided to the application. While generally, a higher number of repetitions results in higher accuracy of the output localization data, the resource management method of this disclosure ensures that the time required to execute the localization algorithm does not exceed the first time interval t2 during which the application is expected to receive the updated localization data. Therefore, the updated localization data is output to the application before the end of each epoch or measurement interval.

[0010] Optionally, the one or more repetitive tasks are performed iteratively for up to n GNSS signals from a set of available GNSS signals, and the maximum number of n GNSS signals to be considered is based on the difference between the first time period t2 and the second running time t5. In particular, the disclosed method can take advantage of the observation that the time required to perform non-repetitive tasks is substantially fixed (at least for each epoch), and therefore cannot be used to perform repetition of one or more repetitive tasks.

[0011] Alternatively, one or more repetitive tasks can be executed recursively, with a recursion depth corresponding to n. For example, a recursive algorithm can be executed, where each recursion corresponds to a repetitive task. When the recursion depth reaches the nth level, the recursion can stop, ensuring that at most n iterations of the repetitive task are executed. Of course, if another stopping condition of the recursive algorithm is met, such as a predefined convergence criterion, the recursive algorithm can stop before reaching the maximum recursion depth n.

[0012] Optionally, each repetition of the one or more repetitive tasks occupies a substantially fixed third running time t4, such that t3 = n·t4, and the number of repetitions n is from the range [n min ,n max The selection is made from n. min It is a predefined minimum number of repetitions, specifically n min =4, and n max It is the maximum number of repetitions, calculated as follows: and This is an operation that rounds down to the nearest integer. If one or more repetitive tasks are substantially linearly related to the number of repetitions, the disclosed method can determine the maximum number of iterations allowed for a given sampling frequency based on the above mathematical relationship. A predefined lower bound threshold n min The choice can be based on the computational requirements of the positional algorithm. For example, if each iteration corresponds to the processed signal, then the minimum number of repetitions n... min The value is 4 because calculating the position requires at least four satellite signals. For example, time t4 is or includes the time period for measuring the pseudorange of the corresponding satellite signals. When n is less than n max While the accuracy of the position may be affected, the power consumption of the disclosed method can be reduced.

[0013] Optionally, the number of repetitions n is determined to be the same as the maximum number of repetitions n. max Correspondingly, in this case, the accuracy of the positioning algorithm is optimized by making the most of the available time, i.e., actually processing the maximum number of repetitions and / or signals that can be processed within a given epoch, without jeopardizing the application's update rate.

[0014] Optionally, the one or more repetitive tasks include at least one of tracking GNSS signals and decoding the transmitted data of GNSS signals. Tracking GNSS signals and / or decoding their contents typically takes a fixed amount of time for each GNSS satellite signal considered. While including more GNSS signals generally helps to improve the location of a determined positioning signal, it may be beneficial to avoid tracking or decoding a large number of GNSS signals when available computation time is limited.

[0015] Optionally, the one or more non-repetitive tasks include at least one of sensor processing and message generation. Since these tasks are necessary to obtain positioning data for any GNSS application, they should be performed in each epoch.

[0016] Optionally, in each repetition of the one or more repetitive tasks, input data from one entry in an ordered list of potential input data is processed, such that only the first n entries of the ordered list are processed during an epoch (E). In particular, if it is not possible to process all available input data within the computation time corresponding to the current epoch, it is beneficial to process more relevant input data first (e.g., data corresponding to satellite signals with good properties). Therefore, positioning data with higher accuracy is output compared to positioning data based on input data with lower-level properties.

[0017] The sorting can be based on predetermined or adaptive constraints, or alternatively, only the signals to be considered can be selected, such as the eight best satellite signals. In this way, the desired navigation and update output rate requirements can be met while minimizing the negative impact of discarding some available input data.

[0018] Optionally, the list of potential input data is sorted based on at least one of the following: elevation angle, carrier noise density (C / N), signal-to-noise ratio (SNR), signal loss count, and factor of accuracy (DOP) of the corresponding GNSS signal. The above decision criteria, used individually or in combination, enable the GNSS receiver to output updated positioning data with a relatively low error rate, even over a limited number of considered GNSS signals.

[0019] Optionally, the second runtime t5 varies in a predetermined manner, for example, in a first type of epoch, a first number N1 of non-repetitive tasks of the positioning algorithm are performed, and in a second type of epoch, a second number N2 of non-repetitive tasks of the positioning algorithm are performed, where N1 > N2. Therefore, the second runtime t5 of the first type of epoch is longer than the second runtime t5 of the second type of epoch. This may occur, for example, when certain routine tasks need to be performed at intervals different from the first time period t2 for which the application is expected to receive positioning data (typically longer than the first time period t2).

[0020] Optionally, after each repetition of one of the one or more repetitive tasks, the current processing time is compared with the deadline, and if the expected time period t4 for further repetition of that repetitive task exceeds the difference between the current processing time and the deadline, the repetitive task is stopped. In this way, a relatively simple dynamic planning method for one or more repetitive tasks can be achieved, where n is determined only during the execution of the positioning algorithm.

[0021] Optionally, the number of repetitions n can be dynamically determined during the normal operation phase of the GNSS receiver, for example, during the phase when the positioning algorithm has been initialized and is providing positioning data to one or more applications. In this case, the method may include: measuring at least one of a first runtime amount t3, a second runtime amount t5, and a third runtime amount t4 occupied by one repetition of the one or more repetitive tasks performed in at least one earlier epoch; and determining the number of repetitions n in the current epoch based on the measured first runtime amount t3, the measured second runtime amount t5, the measured third runtime amount t4, and at least one of the number of repetitions n performed in the at least one earlier epoch. By keeping track of the various runtimes and / or number of repetitions of one or more repetitive tasks in one or more earlier epochs, the disclosed method can provide a reliable estimate of how many repetitions n can be performed in the current epoch without exceeding a first time period t2 during which the application is expected to receive positioning data.

[0022] Alternatively, the number of repetitions n can be determined statically or semi-statically based on worst-case estimates of the first runtime amount t3 and / or the second runtime amount t5 during the normal operation phase of the GNSS receiver, respectively, before or during the initialization of the positioning algorithm. For example, the maximum number of repetitions can be statically determined based on an understanding of the GNSS receiver's processing power, and the positioning algorithm can be configured with the maximum number of repetitions by hard-coding or other means during design. Alternatively, or additionally, for example, based on an understanding of the current processing load of the GNSS receiver's processor or the application-specific sampling rate, the maximum number of repetitions can be semi-statically determined during the initialization of the positioning algorithm or during reinitialization of the positioning algorithm when the processing load or sampling rate changes.

[0023] Optionally, in each epoch, at least one of the one or more repetitive tasks is performed before at least one of the one or more non-repetitive tasks; and / or after at least one of the one or more repetitive tasks. The determination of the repetition count n can be adjusted accordingly based on the order in which the corresponding tasks are performed using the localization algorithm, for example, based on estimation or post-analysis.

[0024] This disclosure further provides a GNSS receiver including a processing unit configured to perform any of the methods disclosed above.

[0025] Optionally, the positioning algorithm is configured to determine the number of repetitions n based on the current workload of the processing unit. Specifically, in a multi-processor environment, if other applications besides the positioning algorithm itself are performed by the same processing unit, the workload of the processing unit may depend on these applications. In this case, the GNSS receiver can flexibly respond to the current workload by increasing or decreasing the number of repetitions of one or more repetitive tasks.

[0026] Optionally, the processing unit is further configured to execute an application that is configured to process the positioning data output by the positioning algorithm. In this case, the available processing power of the GNSS receiver can be shared by the positioning algorithm and the corresponding application, and does not exceed a first time period t2 during which the application is expected to receive the updated positioning data. Attached Figure Description

[0027] The various embodiments of this disclosure will now be described with reference to the accompanying drawings. For ease of reference, corresponding reference numerals and variable names are used for different embodiments. In particular, the corresponding time occupied by each part of the localization algorithm is always represented by the same variable names t1 to t5 as described below. However, this does not mean that the corresponding tasks, components, and processing times in the various embodiments are exactly the same.

[0028] Figure 1 A timing diagram is shown of a GNSS receiver performing a repetitive task independent of a given sampling rate of the application.

[0029] Figure 2 The timing diagram shows the GNSS receiver performing a non-repetitive task and several subsequent repetitive tasks.

[0030] Figure 3 The timing diagram shows the GNSS receiver performing several repetitive tasks and subsequent non-repetitive tasks.

[0031] Figure 4 This illustrates an implementation of a GNSS receiver performing a series of different repetitive and non-repetitive tasks.

[0032] Figure 5 An implementation of a GNSS receiver performing a repetitive task the same number of times before one or two non-repetitive tasks is shown.

[0033] Figure 6 An implementation of a GNSS receiver performing a repetitive task with a variable number of repetitions in two different types of epochs, prior to one or two non-repetitive tasks.

[0034] Figure 7 A GNSS receiver configured to perform resource management methods is shown in schematic form.

[0035] Figure 8 The specific processes for initializing and running the localization algorithm are illustrated in the form of a block diagram. Detailed Implementation

[0036] Figure 1 A timing diagram of a GNSS receiver is shown, which processes either a fixed number of GNSS signals or the maximum number of GNSS signals available in the current operating state. For example, according to... Figure 1 The receiver can handle a total of ten GNSS signals.

[0037] like Figure 1 As shown, acquiring, tracking, and decoding ten GNSS signals, and calculating the solution used to generate the first positioning data in the current state of the GNSS receiver, may occupy a total first time period t11 of approximately 205 ms. Thereafter, this process is repeated, with each further update of the positioning data occupying time periods t12, t13, t14, t15… In the example shown, each of the processing times t11, …, t15 is approximately 205 ms long. Therefore, as… Figure 1As shown, the first positioning data PVT1 is available at t11 ​​at 205ms, the second positioning data PVT2 is available at 410ms, and so on.

[0038] In the example above, the application using the location data actively requests or expects to receive updated location data, with a sampling rate r of 5Hz, corresponding to the second time period t2 = 1 / r = 200ms. The second time period t2 is also referred to as an epoch in this disclosure. The epoch time describes the interval at which the application requests updated location data, which corresponds to the position velocity-time (PVT) solution of the location algorithm. Figure 1 The diagram illustrates five epochs, E1 through E5. If the total time period t1 occupied by the GNSS receiver calculating the solution used to provide location data is longer than the expected time period t2 for epochs E1 through E5, the application may fail to receive any location data in time and skip epochs, resulting in a decrease in the application's effective navigation or update rate compared to the sampling rate. This is also true even if the CPU utilization threshold that causes the total processing time t1 to be relatively slow is only slightly exceeded, as shown in the diagram. Figure 1 An example of the fifth location data PVT5 is shown.

[0039] To avoid the aforementioned situations and their related drawbacks, the disclosed resource management method keeps track of various contributions to the total processing time t1, i.e., the various time intervals occupied by the task for the GNSS receiver to calculate the solution used to provide updated positioning data. The following will combine... Figures 2 to 6 This will be described in more detail.

[0040] In this article, the following variables are used to specify the corresponding time intervals:

[0041] t1: The total processing time required for the processing algorithm to output the updated location data to the application.

[0042] t2: The time period during which the application is expected to receive updated location data.

[0043] t3: The total processing time required for all planned repetitions of a repetitive task.

[0044] t4: The processing time for each individual repetition of performing one or more repetitive tasks, and

[0045] t5: The total processing time required to perform one or more non-repetitive tasks.

[0046] Figure 2 A first timing diagram of a GNSS receiver performing a resource management method according to a first embodiment of the present disclosure is shown.

[0047] like Figure 2As shown, the localization algorithm designed to compute solutions for providing updated localization data performs multiple tasks with different temporal behaviors. Specifically, in the first time interval t5, a task is performed only once per epoch E, and its processing power or CPU time requirement is almost constant. Typically, the first time interval t5 is shorter than the time interval t2. Subsequently, in the second time interval t3, another task is performed repeatedly, with each repetition occupying a more or less constant time interval t4. Therefore, the time interval t3 occupied by the repetitive task for a given number of repetitions is almost linearly related to the number of repetitions. Thus, the total processing time can be at least approximately determined as t1 = t5 + n·t4.

[0048] The number of repetitions, *n*, required for a GNSS receiver to perform a task (such as signal tracking or decoding) is not constant, but varies, for example, with the number of GNSS signals considered by the algorithm. Similarly, the calculations of positioning algorithms associated with pseudorange measurements can also be performed in a repetitive manner (e.g., iteratively or recursively). While a higher number of iterations and therefore a greater number of GNSS signals or pseudorange measurements considered by the positioning algorithm generally result in higher accuracy, as mentioned above, this can also lead to a deterioration in the effective navigation or update rate of the application. Figure 2 In the implementation shown, the quantity n should be chosen such that the sum of the processing periods t3 and t5 does not exceed the epoch time t2 of the specific application. That is, n is chosen such that t2 ≥ t5 + n·t4.

[0049] exist Figure 2 In the example shown, this could be achieved, for instance, by first measuring the time t5 taken by the location algorithm to perform a non-repetitive task. Then, the planning component or the location algorithm itself could measure the time t4 taken to perform one or a few iterations of the repetitive task. Then, after each iteration, the planning component or location algorithm could compare the remaining time difference between the current processing time and the end of time t2 (i.e., the deadline C) to determine if the location algorithm can perform another iteration.

[0050] Therefore, the algorithm can ensure that the total processing time t1 for each measurement does not exceed the available epoch time t2.

[0051] Figure 3 A second timing diagram is shown of a GNSS receiver performing a resource management method according to a second embodiment of the present disclosure.

[0052] exist Figure 3In the illustrated implementation, during each epoch time t2, a repetitive task is first performed multiple times within a first time period t3, with each repetition occupying a relatively short time period t4. Subsequently, a non-repetitive task is performed within a second time period t5. As in the previous implementation, the total time t1 for calculating the updated location data is calculated as t1 = t5 + n·t4. However, in this case, since the time period t5 required to perform the non-repetitive task in the current epoch E is unknown during the first interval t3, the time period t5 must be determined in another way to correctly determine the number of repetitions n. For example, t5 can be derived by analyzing one or more previous epochs and measuring the corresponding second time period t5. That is, the value of t5 needs to be determined (i.e., predicted) before or at the start of the current epoch E of the positioning algorithm.

[0053] Figure 4 A third timing diagram is shown of a GNSS receiver performing a resource management method according to a more complex third embodiment of the present disclosure.

[0054] according to Figure 4 In this implementation, the localization algorithm performs at least two different non-repetitive tasks and two different repetitive tasks within each processing interval. Specifically, the localization algorithm begins by performing a first non-repetitive task within a first time interval t5'. Then, within a second time interval t3', the localization algorithm performs a first iteration of n' times on the first repetitive task. Each repetition of the first repetitive task occupies a substantially fixed first processing time t4'. Next, within a third time interval t3'", the second task is repeated a second time n' times. Each repetition of the second task occupies a substantially fixed second processing time t4'. Finally, within a fourth time interval t4', the second non-repetitive task is performed.

[0055] from Figure 4 As can be seen, the length of the first time interval t5' does not necessarily correspond to the length of the fourth time interval t5"; furthermore, the time interval t4' required for each iteration of the first repetitive task does not necessarily correspond to the time interval t4" occupied by the iteration of the second task. The temporal relationships of various processing times are as follows: Figure 2 As shown.

[0056] It is worth noting that, in principle, the first repetition number n' and the second repetition number n" can be determined independently of each other to optimize the output accuracy of the positioning algorithm. However, in specific implementations, the second repetition number n" may not be completely independent of the first repetition number n'. For example, if the first repetitive task involves tracking a corresponding number of GNSS signals, and the second repetitive task corresponds to decoding the tracked signals, then n" is equal to or less than n'. Furthermore, from an efficiency perspective, n' and n" should ideally be the same, such that n = n' = n". In this case, the total time t1 can be calculated as t1 = t5' + n·t4' + n·t4" + t5" = t5' + t5" + n·(t4' + t4"). The above equation can be used to determine the optimal number n. max For example, based on the measurements of t5', t5", t4' and t4" obtained by the GNSS receiver in the previous epoch.

[0057] Alternatively, the deadline C between the second time period t3' and the third time period t3" can be determined by a planning or positioning algorithm. Then, the number of repetitions n' and n" can be determined independently of each other, as described above for... Figure 2 and Figure 3 As stated above.

[0058] Figure 5 and Figure 6 A timing diagram covering several epochs is shown for a GNSS receiver performing a resource management method according to different embodiments of the present disclosure. In this context, it should be noted that although the amount of processing time t5 occupied by performing one or more non-repetitive tasks in each epoch is generally not dependent on the number of repetitions n of performing one or more repetitive tasks, the time period t5 may still vary from one epoch to the next.

[0059] In particular, such as Figure 5 As shown, during the first epoch E1, two different non-repetitive tasks can be performed in the first sub-interval t5' and the second sub-interval t5" of the second time interval t51. In the following epoch E2, only the first non-repetitive task corresponding to the first sub-interval t5' is performed, and the second non-repetitive task is not performed at all. Therefore, the corresponding time interval t52 of the second epoch E2 is shorter than the time interval t51 of the first epoch E1. The second non-repetitive task performed in t5" may include one or more internal tasks of the positioning algorithm, which are performed at a fixed frequency independent of the epoch time t2, for example, greater than the epoch time t2. For example, in a GNSS receiver that outputs positioning data at an output rate of 5 Hz, some tasks may be performed only once per second, that is, once every five epochs. To avoid exhausting time in the epochs where additional tasks are performed, in the estimation Figure 5The worst-case scenario at time t5, corresponding to the second time interval t51 of the first epoch E1, can consider all non-repetitive tasks. In other epochs, for Figure 5 The second type of epoch E2 shown has a corresponding portion of the processing time remaining unused.

[0060] Figure 6 Another implementation of the resource management method is shown. The processing time requirements of the positioning algorithm are similar to those mentioned above. Figure 5 The descriptions are basically the same. However, with Figure 5 The situation is reversed. In the second epoch E2, the additional time available because the second non-repetitive task within the second sub-period t5" was not executed is used to perform one or more further iterations of the repetitive task within the first sub-period t32. In other words, in the first type of epoch (e.g., in the first epoch E1), only the first repetition number n', such as 9 times, is executed. In the first type of epoch (e.g., in the second epoch E2), a second larger repetition number n" can be executed, such as ten times.

[0061] It is worth noting that the resource management method described above is applicable to various GNSS receivers and positioning algorithms. In particular, almost all known positioning algorithms contain both inherently non-repetitive processing components and repetitive processing components, where the CPU power or time consumption for performing repetitive tasks increases monotonically with the number of repetitions, typically in a linear fashion. Therefore, the resource management method described is applicable to a wide range of positioning algorithms.

[0062] As mentioned earlier, reducing the number of GNSS positioning signals considered directly reduces processing time. However, to optimize the accuracy of the generated positioning data, the GNSS signals selected for tracking and decoding should not be chosen randomly. Preferably, those GNSS signals most likely to contribute significantly to the accuracy of the calculated positioning data should be selected. In other words, GNSS signals that have little or no impact on receiver performance should be discarded. This results in minimizing the sacrifice of position accuracy while prioritizing the navigation data output rate of the GNSS receiver.

[0063] This can be ensured, for example, by prioritizing a list of available GNSS signals. In principle, a GNSS signal is available if it is accessible to a GNSS receiver (e.g., visible above the horizon at a sufficiently high angle) and is transmitted within the transmission band supported by the receiver. Prioritization can be based on signal strength (e.g., C / N or SNR) or signal error (e.g., signal loss count), as GNSS signals with higher signal strength have associated lower errors, and vice versa. Alternatively, or additionally, prioritization can also be based on the Factor of Precision (DOP) or Geometric Factor of Precision (GDOP) values, which are based on the corresponding signals' relative positions to each other. For example, a signal from a group of visible navigation satellites that are far apart in the sky provides more accurate calculated positioning data than a signal from a group of visible navigation satellites that are closer together in the sky. Generally, for prioritization, the GNSS signals considered should have the lowest possible DOP value.

[0064] Figure 7 A GNSS receiver 10 configured to perform one or more of the planned resource management methods according to the prior embodiments is shown schematically.

[0065] The GNSS receiver 10 includes an antenna 11 connected to one or more receiver circuits 12a to 12r configured to receive one or more RF signals or signal bands associated with a corresponding GNSS satellite or satellite constellation. The GNSS receiver 10 also includes a processing unit 13, such as a microcontroller or general-purpose CPU, which runs one or more applications or processing blocks, each containing one or more tasks.

[0066] In this embodiment, processing unit 13 executes three different processing blocks. The first processing block executes location algorithm 14. The second processing block executes application 15, which receives location data provided by location algorithm 14. The third processing block executes a planning or resource management algorithm 16, which can monitor the available resources of processing unit 13 and allocate them to different processing blocks or applications. Specifically, resource management algorithm 16 can analyze the CPU time budget available for location algorithm 14 before application 15 is expected to receive updated location data.

[0067] Among other things, the planning component 16 receives a sampling rate r or a corresponding epoch time t2 associated with the application 15, which the application 15 intends to use to receive updated positioning data. This information may be hard-coded, retrieved from a configuration file of the GNSS receiver 10, or transmitted via a corresponding interface between the application 15 and the resource management algorithm 16. Based on the received sampling rate r, the planning component 16 determines the number of repetitions n of at least one repetitive task of the positioning algorithm 14 to ensure that the positioning algorithm 14 can provide updated positioning data to the application 15 at the sampling rate r.

[0068] Figure 8 The specific processes for initializing and running the localization algorithm are illustrated in the form of a block diagram.

[0069] In step S10, a first time period t2 corresponding to the epoch time is determined, during which the application 15 is expected to receive updated location data. Specifically, t2 can be calculated as t2 = 1 / r. t2 or r can be received from the corresponding application or user interface, or retrieved from the configuration file of the GNSS receiver 10. Alternatively, t2 can be measured as the time interval between requests to receive updated location data from the application.

[0070] In step S20, some initial values ​​for the timing behavior of the positioning algorithm 14 are obtained. For example, initial values ​​for t4 and t5 are obtained. The initial values ​​for t4 and t5 can be hardcoded into the positioning algorithm 14 or retrieved by the planning component 16 from the configuration file of the GNSS receiver 10.

[0071] Following this initial configuration, the actual positioning algorithm 14 runs in a continuous loop and / or restarts at the beginning of each epoch E.

[0072] In step S30, the number of repetitions n is determined. For example, n can be calculated based on the initial values ​​provided during initialization in steps S10 and S20.

[0073] Subsequently, in step S40, one or more repetitive tasks are performed n times. For example, n GNSS signals can be tracked and decoded in the corresponding iteration number of the corresponding task for each GNSS signal. The positioning algorithm 14 and / or the planning component 16 can determine the execution time of this activity, for example, by keeping track of the start and end times of each repetition.

[0074] In step S50, the updated timing interval for performing repetitive tasks is determined. For example, based on statistical analysis of the runtime of each previous execution time of the repetitive task, the updated average or maximum value of t4 can be determined.

[0075] In step S60, one or more non-repetitive tasks are performed. It should be noted that step S60 may be performed before and / or after steps S30 to S50, depending on the needs of the application logic. For example, sensor processing may be performed before step S40, while message generation may be performed after step S40. Alternatively, or additionally, all or part of step S60 may be performed in parallel with any of steps S30 to S50. Similarly, the positioning algorithm 14 and / or the planning component 16 may determine the execution time t5 of this activity by, for example, by keeping track of the start and finish times of each non-repetitive task.

[0076] In step S70, the updated timing interval t5 for performing non-repetitive tasks is determined. For example, based on statistical analysis of the runtime of non-repetitive tasks within each epoch, the updated average or maximum value of t5 can be determined.

[0077] In step S80, the updated location data is output to application 15 before the end of the current epoch. Afterward, the process continues with step S30 for the next epoch until location algorithm 14 or application 15 is stopped (e.g., by the user).

[0078] Depending on the hardware and software configuration of the GNSS receiver 10, the planning component 16 can be part of the positioning algorithm 14, i.e., executed in the same address space; or it can be a separate component, i.e., executed in a different address space. For example, the planning component 16 can be part of the resource management layer of a protected operating system or software stack, while the positioning algorithm 14 and application 15 can run as ordinary user tasks or applications.

Claims

1. A resource management method for a GNSS receiver (10), the resource management method comprising determining an epoch (E) of an application (15) of the GNSS receiver (10), wherein the epoch (E) defining a first time period t2 during which the application (15) is expected to receive positioning data; determining a number of repetitions n of one or more repetitive tasks of a positioning algorithm (14) of the GNSS receiver (10) to be performed; and during each epoch (E), performing the positioning algorithm (14), comprising: performing the one or more repetitive tasks of the positioning algorithm (14) n times, wherein performing the one or more repetitive tasks n times takes a first amount of running time t3 which depends on the number of repetitions n; performing one or more non-repetitive tasks of the positioning algorithm (14), wherein performing the one or more non-repetitive tasks takes a second amount of running time t5 which does not depend on the number of repetitions n; and outputting updated positioning data to the application (15) based on outputs of the one or more repetitive tasks and the one or more non-repetitive tasks of the positioning algorithm (14); wherein the number of repetitions n is determined such that a sum of the first amount of running time t3 and the second amount of running time t5 is equal to or shorter than the first time period t2.

2. The resource management method according to claim 1, wherein the one or more repetitive tasks are performed in an iterative manner for up to n GNSS signals from a set of available GNSS signals, and a maximum number of n GNSS signals to be considered is based on a difference between the first time period t2 and the second amount of running time t5.

3. The resource management method according to claim 1 or 2, wherein, Each repetition of the one or more repetitive tasks occupies a substantially fixed third amount of runtime t4, such that t3 = n-t4, and the number of repetitions n is chosen from the range [n min ,n max ], where n min is a predefined minimum number of repetitions, in particular n min = 4, and n max is a maximum number of repetitions calculated as and is an operation rounding down to the nearest integer.

4. The resource management method according to claim 3, wherein, The repetition number n is determined to correspond to a maximum repetition number n max max.

5. The resource management method according to claim 1 or 2, wherein the one or more repetitive tasks comprise at least one of tracking GNSS signals and decoding transmission data of GNSS signals; and / or the one or more non-repetitive tasks comprise at least one of sensor processing and message generation.

6. The resource management method according to claim 1 or 2, wherein, in each repetition of the one or more repetitive tasks, processing input data from one entry of an ordered list of potential input data such that only a first n entries of the ordered list are processed during an epoch (E).

7. The resource management method of claim 6, wherein, the list of potential input data is ordered based on at least one of an elevation angle, a carrier-to-noise density C / N, a signal-to-noise ratio SNR, a signal loss count and a dilution of precision DOP of corresponding GNSS signals.

8. The resource management method according to claim 1 or 2, wherein, the second amount of running time t5 varies in a predetermined manner, in particular, in a first type of epoch (El), a first number N1 of non-repetitive tasks of the positioning algorithm (14) is performed, and in a second type of epoch (E2), a second number N2 of non-repetitive tasks of the positioning algorithm (14) is performed, with N1>N2, such that a second amount of running time t5’ of the first type of epoch is longer than a second amount of running time t5” of the second type of epoch.

9. The resource management method according to claim 1 or 2, wherein, after each repetition of one of the one or more repetitive tasks, comparing a current processing time with a deadline (C) and stopping the one repetitive task if an expected time period t4 for performing a further repetition of the one repetitive task exceeds a difference between the current processing time and the deadline (C).

10. The resource management method according to claim 1 or 2, wherein, determining the number of repetitions n dynamically during a normal operation phase of the GNSS receiver (10), including: measuring at least one of a first amount of run time t3, a second amount of run time t5 and a third amount of run time t4 taken for performing a repetition of the one or more repetitive tasks in at least one earlier epoch; and determining the number of repetitions n for a current epoch based on at least one of the measured first amount of run time t3, the measured second amount of run time t5, the measured third amount of run time t4 and the number of repetitions n performed in the at least one earlier epoch.

11. The resource management method according to claim 1 or 2, wherein, determining the number of repetitions n statically or semi-statically before or during initialization of the positioning algorithm (14) based on a worst case estimate of the first amount of run time t3 and / or the second amount of run time t5 during a normal operation phase of the GNSS receiver (10), respectively.

12. The resource management method according to claim 1 or 2, wherein, in each epoch, performing at least one of the one or more repetitive tasks before at least one of the one or more non-repetitive tasks; and / or performing at least one of the one or more repetitive tasks after at least one of the one or more non-repetitive tasks.

13. A GNSS receiver (10) comprising a processing unit (13), wherein the processing unit (13) is configured to perform the method according to one of claims 1 to 12.

14. The GNSS receiver (10) according to claim 13, wherein the positioning algorithm (14) is configured to determine the number of repetitions n based on a current workload of the processing unit (13).

15. The GNSS receiver (10) according to claim 13 or 14, wherein the processing unit (13) is further configured to execute an application (15) configured to process positioning data output by the positioning algorithm (14). the processing unit (13) is further configured to execute an application (15) configured to process positioning data output by the positioning algorithm (14).

Images