Patent Description:
Document <CIT> discloses a sensor to determine, based on two or more synchronization signals provided by a control device, an expected time for receiving an upcoming synchronization signal. As the sensor has identified when the third sync signal is expected, the sensor may determine a time point at which to trigger the sensor operation such that third sensor data is ready for transmission at the time point at which the third sync signal is received.

A sensor as defined in claim <NUM> and a method as defined in claim <NUM> are provided. The dependent claims define further embodiments.

In some implementations, a sensor includes one or more components to determine a time interval between a time of reception of a first trigger to selectively transmit or sample first sensor data and a time of reception of a second trigger to selectively transmit or sample second sensor data; determine, based on the time interval, a predicted time of reception of a third trigger to selectively transmit or sample third sensor data; initiate a set of sensor tasks based on the predicted time of reception of the third trigger, the set of sensor tasks being initiated to cause the third sensor data to be ready for transmission at the predicted time of reception of the third trigger; receive the third trigger; determine a delay latency value associated with an amount of time from completion of the set of sensor tasks to an actual time of reception of the third trigger; calculate a deviation of the delay latency value from a target delay latency; and transmit a data frame including an indication associated with the deviation of the delay latency value from the target delay latency.

In some implementations, a sensor includes a sensor algorithm component; and an interface implementation component, comprising: an internal trigger generator to: monitor a counter value, and trigger the sensor algorithm component to perform a set of sensor tasks based on a determination that the counter value is greater than or equal to an internal trigger level value; a trigger detector to: receive a trigger to selectively transmit or sample the sensor data, and forward the trigger to a trigger level calculator and a protocol encoder; the protocol encoder to transmit a data frame based at least in part on receiving the trigger; and the trigger level calculator to: determine an adjusted internal trigger level value, and provide the adjusted internal trigger level value to the internal trigger generator.

In some implementations, a method includes determining, by a sensor, a delay latency value associated with an amount of time from completion of a set of sensor tasks to an actual time of reception of a trigger to selectively transmit or sample sensor data; calculating, by the sensor, a deviation of the delay latency value from a target delay latency; and transmitting, by the sensor, a data frame including an indication associated with the deviation of the delay latency value from the target delay latency.

In some implementations, a method includes transmitting a first plurality of triggers to a sensor operating in a synchronous mode, wherein a time interval between triggers of the first plurality of triggers is a first period that corresponds to a first frequency; transmitting a second plurality of triggers to the sensor operating in the synchronous mode, wherein a time interval between triggers in the second plurality of triggers is a second period that corresponds to one-half of a second frequency, wherein the second frequency is higher than the first frequency; and transmitting a third plurality of triggers to the sensor operating in the synchronous mode, wherein a time interval between triggers in the third plurality of triggers is a third period that corresponds to the second frequency.

In some sensor systems, one or more sensors may be configured for operation in a mode in which the sensor performs a set of sensor tasks based on receiving a trigger. Such a mode is referred to as an on-demand mode. Generally, while operating in the on-demand mode, a sensor performs a set of sensor tasks, such as sampling a sensor signal, calculating sensor data based on sampling the sensor signal, transmitting the sensor data, or the like, in response to receiving a trigger (e.g., a request for sensor data) received from an electronic control unit (ECU) of the sensor system. One disadvantage of the on-demand mode is that a delay between a trigger being transmitted by the ECU and sensor data responsive to the trigger being received by the ECU may be undesirably long (e.g., because the ECU has to wait for an internal processing time of the sensor in addition to a bus transmission time before receiving the sensor data) and that this delay might further be subject to significant jitter (e.g., because the ECU trigger frequency differs from the internal processing frequency of the sensor). This delay and jitter in the on-demand mode is not acceptable in some applications, such as applications that use a pulse width modulation (PWM) frequency of <NUM> kilohertz (kHz) or higher, because sensor data values will be missed during operation.

To reduce such delays in a sensor system, one or more sensors may be configured for operation in a synchronous mode. Generally, while operating in the synchronous mode, a sensor predicts a time point at which a trigger from the ECU will be received and performs a set of sensor tasks based on the prediction (e.g., such that the sensor preprocesses the sensor data) so that the sensor data is ready at the time point of receiving the trigger. The prediction therefore allows the sensor data to be transmitted to the ECU immediately upon receipt of the trigger (i.e., without a delay caused by internal sensor processing time, as occurs in the on-demand mode). However, a precondition for effective operation in the synchronous mode is a deterministic trigger being transmitted by the ECU (e.g., to allow the sensor to accurately predict a time point of reception of a trigger) and to have minimal jitter of the predicted time point to avoid additional errors caused by the jitter.

In some applications, an ECU of a sensor system can vary a PWM frequency as part of a strategy for controlling the sensor system. Notably, PWM frequency variation does not impact performance of the sensor system while sensors are operating in an on-demand mode. However, PWM frequency variation leads to a non-deterministic trigger behavior for the sensor system and, therefore, degrades performance of the sensor system when one or more sensors are operating in the synchronous mode.

Some implementations described herein provide techniques and apparatuses for adaptation to a PWM frequency variation in a sensor system comprising one or more sensors operating in a synchronous mode.

In some implementations, as described herein, a sensor operating in a synchronous mode may be capable of adjusting a sampling point (e.g., a time point at which a sensor signal is sampled) to account for a variation of a PWM frequency. For example, in some implementations, the sampling point can be adjusted incrementally (e.g., at a configurable increment, within a configurable window, or the like) to adapt to the PWM frequency variation, thereby allowing the sensor to adapt to the PWM frequency variation without a loss of sensor data values. Additionally, in some implementations, the sensor may determine and transmit latency compensation information (e.g., an indication of a delay time between completion of a set of sensor tasks and reception of a trigger from the ECU, information indicating a deviation from an expected sampling point, or the like), thereby enabling the ECU to compensate for latency without any additional jitter.

In some implementations, as described herein, a sensor operating in the synchronous mode may be capable of configuring prediction of a trigger point (e.g., a time point at which a trigger is received from the ECU). In some implementations, the prediction of the trigger point can be configured so as to account for a variation in a PWM frequency. For example, in some implementations, the sensor may measure an amount of time between consecutive triggers received by the sensor. Here, upon receipt of a given trigger, the sensor may adjust a reference time associated with predicting receipt of triggers from the ECU. In some implementations, the repetitive or continuous update of the reference time enables the sensor to adapt to a PWM frequency change while maintaining synchronization during operation in the synchronous mode.

In some implementations, as described herein, an ECU may be configured to temporarily increase a PWM frequency above a target PWM frequency, after which the ECU may decrease the PWM frequency to the target PWM frequency. In some implementations, the temporary over-increase of the PWM frequency prevents a sensor operating in the synchronous mode from missing sensor data values that could otherwise result from an increase directly to the target PWM frequency. Additional details regarding the above-described implementations are provided below.

<FIG> is a diagram of an example sensor system <NUM> in which techniques and apparatuses described herein may be implemented. As shown in <FIG>, sensor system <NUM> may include one or more sensors <NUM> (e.g., sensors <NUM>-<NUM> through <NUM>-N (N ≥ <NUM>)) connected to an ECU <NUM> via a sensor interface bus <NUM> (herein referred to as bus <NUM>).

A sensor <NUM> includes a housing associated with one or more components of a sensor for measuring one or more characteristics (e.g., a speed of an object, a position of an object, an angle of rotation of an object, an amount of pressure, a temperature, an amount of current, and/or the like). As shown, the sensor <NUM> includes a sensing device <NUM> and a transceiver (Tx/Rx) <NUM>. In some implementations, the sensor <NUM> is remote from the ECU <NUM> and, thus, is connected to the ECU <NUM> via the bus <NUM> (e.g., via a wired connection). Additionally, or alternatively, the sensor <NUM> may be a local sensor (e.g., such that the sensor <NUM> is connected to the ECU <NUM> via a short connection, is integrated with the ECU <NUM> on a same chip, and/or the like). In some implementations, the sensor <NUM> is capable of operation in a synchronous mode of operation, as described herein.

Sensing device <NUM> includes a device capable of performing a sensing function (e.g., sampling a sensor signal, calculating sensor data or otherwise determining sensor data based on sampling the sensor signal, or the like). In some implementations, sensing device <NUM> is capable of performing operations associated with adapting to a PWM frequency variation during operation in a synchronous mode, as described herein. In some implementations, sensing device <NUM> may include one or more sensing elements, an analog-to-digital converter (ADC), a digital signal processor (DSP), a memory component (e.g., a non-volatile memory), a digital interface, and/or one or more other components that enable performance of the sensing function and/or enable operations described herein.

Transceiver <NUM> includes a component via which a device (e.g., the sensor <NUM>, the ECU <NUM>) may transmit and receive information. For example, transceiver <NUM> may include a differential line transceiver, or a similar type of device. In some implementations, transceiver <NUM> includes a transmit (Tx) component that allows the sensor <NUM> to transmit information (e.g., sensor data, information related to the sensor data, latency compensation information, diagnostic information, or the like) to the ECU <NUM> via the bus <NUM>, and a receive (Rx) component that allows the sensor <NUM> to receive information (e.g., trigger signals, read commands, or the like) from the ECU <NUM> via the bus <NUM>. In some implementations, transceiver <NUM> may include a line driver for enabling the Tx component to transmit information or the Rx component to receive information at a given time. In some implementations, the sensor <NUM> may not include transceiver <NUM>. For example, the sensor <NUM> may not include transceiver <NUM> when the sensor <NUM> is a local sensor and/or when a length of a connection between the sensor <NUM> and the ECU <NUM> is relatively short (e.g., as compared to an application where the sensor <NUM> is a remote sensor).

The bus <NUM> includes a sensor interface bus for carrying information between the one or more sensors <NUM> and the ECU <NUM>. In some implementations, the bus <NUM> may comprise a connection (e.g., including one or more wires and connectors) via which the sensor <NUM> is connected to the ECU <NUM>. In some implementations, the bus <NUM> may include a set of connections, each associated with one or more sensors <NUM> connected to the ECU <NUM> (e.g., when multiple sensors <NUM> are connected to the ECU <NUM> via one or more buses <NUM>). In some implementations, a given connection may be capable of carrying a signal from the ECU <NUM> to the sensor <NUM> and carrying a signal from the sensor <NUM> to the ECU <NUM> (e.g., via a same wire or via a different wire).

The ECU <NUM> includes one or more devices associated with controlling one or more electrical systems and/or electrical subsystems based on sensor data provided by the sensor <NUM>. As shown, the ECU <NUM> may include a transceiver <NUM> and a controller (µC) <NUM>. In some implementations, controller <NUM> may be capable of calibrating, controlling, adjusting, or the like, the one or more electrical systems and/or electrical subsystems based on sensor data transmitted by the sensor <NUM>. For example, in some implementations, controller <NUM> may include an electronic/engine control module (ECM), a powertrain control module (PCM), a transmission control module (TCM), a brake control module (BCM or EBCM), a central control module (CCM), a central timing module (CTM), a general electronic module (GEM), a body control module (BCM), a suspension control module (SCM), or another electrical system or electrical subsystem of a vehicle. In some implementations, the controller <NUM> may be capable of selecting, varying, or otherwise controlling a PWM frequency in association with obtaining sensor data from the one or more sensors <NUM> for use in controlling the one or more electrical systems and/or electrical subsystems.

Transceiver <NUM> may be similar to transceiver <NUM>, and may include a component via which a device (e.g., the sensor <NUM>, the ECU <NUM>) may transmit and receive information. In some implementations, transceiver <NUM> includes a Tx component that allows the ECU <NUM> to transmit information (e.g., trigger signals) to the sensor <NUM> via the bus <NUM>, and an Rx component that allows the ECU <NUM> to receive information (e.g., sensor data, diagnostic information, and/or the like) from the sensor <NUM> via the bus <NUM>. In some implementations, transceiver <NUM> may include a line driver for enabling the Tx component to transmit information or the Rx component to receive information at a given time.

The number and arrangement of apparatuses shown in <FIG> is provided as an example. In practice, there may be additional devices and/or components, fewer devices and/or components, different devices and/or components, or differently arranged devices and/or components than those shown in <FIG>. For example, in some implementations, sensor system <NUM> may include multiple sensors <NUM>, each connected to the ECU <NUM> via one or more associated buses <NUM>. Furthermore, two or more devices and/or components shown in <FIG> may be implemented within a single device and/or component, or a single device and/or a single component shown in <FIG> may be implemented as multiple, distributed devices and/or components. Additionally, or alternatively, a set of devices and/or components (e.g., one or more devices and/or components) of <FIG> may perform one or more functions described as being performed by another set of devices and/or components of <FIG>.

<FIG> and <FIG> are diagrams associated with operation of a sensor <NUM> in a synchronous mode. In the synchronous mode of operation, as illustrated in example <NUM> of <FIG>, for a given cycle, the sensor <NUM> initiates a set of sensor tasks (e.g., sensor signal sampling and calculation of sensor data) such that sensor data is ready for transmission at a time point at which a trigger is received by the sensor <NUM> (e.g., such that the sensor data is ready at a time point at which a read command is received in a request from the ECU <NUM> on the bus <NUM>). As noted above, the synchronous mode of operation reduces latency time associated with reception of sensor data by the ECU <NUM> and, additionally, improves utilization of the bus <NUM> (e.g., when multiple sensors <NUM> are connected to the bus <NUM> or if multiple registers of one or more sensors <NUM> have to be read out within a given time frame). In some implementations, as described above and as indicated by <FIG>, the sensor <NUM> in the synchronous mode is configured to predict reception of the trigger and, therefore, anticipates the time point at which to initiate the set of sensor tasks such that the sensor data is ready for transmission at the time point at which the sensor <NUM> receives the trigger. In some implementations, the sensor <NUM> may transmit, in a data frame comprising the sensor data, information indicating a status of this timing control loop (e.g., an indication of whether synchronization of the sensor <NUM> is maintained).

<FIG> is a flow chart <NUM> illustrating operations of the sensor <NUM> to initiate operation in the synchronous mode. As shown in <FIG>, at start-up (e.g., when the sensor system <NUM> is powered on, the sensor <NUM> enters an on-demand mode of operation. In some implementations, the on-demand mode may be configured as a default mode of operation for the sensor <NUM>. Here, if the synchronous mode is selected in a communication configuration register of the sensor <NUM>, then the sensor <NUM> may initiate a sequence for commencing operation in the synchronous mode based on a first trigger being received from the ECU <NUM> (e.g., when the ECU <NUM> broadcasts the first trigger on the bus <NUM> to a designated address, such as address 0x00). Based on receiving the first trigger, the sensor <NUM> with the synchronous mode enabled initiates a time interval measurement and operation in a pre-synchronous mode, as shown in <FIG>. Here, the sensor <NUM> may be configured to, in response to the first trigger, transmit most recent sensor data available on the sensor <NUM> along with an indication that the sensor <NUM> is out of synchronization (e.g., by indicating an out-of-sync condition in a status register). A second trigger broadcasted by the ECU <NUM> (e.g., to the designated address) enables the sensor <NUM> to measure the time interval between the first trigger and the second trigger. The time interval can then be used by the sensor <NUM> for predicting a time point at which the sensor <NUM> will receive a third trigger, and the sensor <NUM> can commence operation in the synchronous mode, accordingly. In some implementations, if the sensor <NUM> experiences a synchronization failure, the sensor <NUM> may return to the on-demand mode of operation and repeat the above-described steps in order to return to the synchronous mode of operation.

In some implementations, as described above, the sensor <NUM> may measure a time interval between triggers received from the ECU <NUM> and may predict timing of a next trigger based on the time interval in association with operating in the synchronous mode. In some implementations, the sensor <NUM> may be configured with a delay latency counter (DLC) to measure an amount of time between a time of completion of a set of sensor tasks (e.g., a time at which the sensor data is ready for transmission) and a time of reception of the next trigger (e.g., a next synchronization command, a next read command, or the like). <FIG> depicts a timing diagram <NUM> and a corresponding timeline <NUM> associated with use of the DLC and a comparison of a DLC value to a DLC target. In some implementations, the DLC can be used in association with adjusting a prediction of a time point at which upcoming triggers will be received by the sensor <NUM>. In some implementations, as indicated in <FIG>, the sensor <NUM> starts the DLC upon completion of the set of sensor tasks. As further indicated in <FIG>, the sensor <NUM> may in some implementations stop the DLC upon reception of a next trigger (e.g., upon receiving a request from the ECU <NUM>).

In some implementations, the sensor <NUM> compares the value of the DLC at the time of reception of the next trigger to a high DLC threshold (e.g., a maximum allowable DLC value). Here, if the value of the DLC is greater than or equal to the high DLC threshold, meaning that the trigger is received later than predicted by some (configurable) amount of time, then the sensor <NUM> may determine that the sensor data is expired. In such a case, the sensor <NUM> may transmit the data frame including the sensor data and an indication that the sensor data is expired. Similarly, the sensor <NUM> in some implementations compares the value of the DLC at the time of the receipt of the next trigger to a low DLC threshold (e.g., a minimum allowable DLC value). Here, if the value of the DLC is less than or equal to the DLC low threshold, meaning that the trigger is received before the sensor earlier than predicted by a configurable amount of time or even before the sensor data is ready for transmission, then the sensor <NUM> may transmit the data frame without including sensor data or, alternatively, may transmit the data frame including old sensor data along with an indication that the sensor data is not ready.

Further, in some implementations, based on receiving the next trigger, the sensor <NUM> calculates a deviation of an actual delay latency (e.g., indicated by the value of the DLC at the time of receipt of the next trigger) from a target delay latency (e.g., a DLC target). In some implementations, the sensor <NUM> transmits an indication of the deviation from the target delay latency (referred to as latency compensation information), along with the sensor data, to the ECU <NUM>. In some implementations, the latency compensation information may be carried in one or more bits of the data frame designated for advanced latency compensation (ALC) information. In this way, the ECU <NUM> may receive the sensor data and the latency compensation information and, therefore, may compensate for an unexpected delay latency associated with the sensor data. In some implementations, if the value of the DLC is greater than or equal to the DLC high threshold (e.g., when the next trigger was received later than anticipated) or is less than or equal to the DLC low threshold (e.g., when the sensor data is not ready upon receipt of the next trigger), then the sensor <NUM> may indicate the data frame transmitted by the sensor <NUM> as expired. <FIG> is a diagram illustrating a schematic representation of an example implementation <NUM> of the sensor <NUM> capable of operating in the synchronous mode as described in association with <FIG>.

In some implementations, the sensor <NUM> may compare a DLC value at a time point of reception of a trigger and a DLC target for reception of a trigger from the ECU <NUM>. In some implementations, depending on a result of a given comparison, a sampling time point (e.g., a time point at which the sensor <NUM> samples the sensor signal) for a next cycle can be adjusted (e.g., by a configurable amount). In some implementations, adjustment of the sampling time point in this manner enables adaptation of the sensor <NUM> to clock drift or an intended change of PWM frequency, while avoiding a loss of synchronization.

As indicated above, the DLC value indicates an amount of time between the completion of the set of sensor tasks (e.g., starting from a time of completion of calculation of the sensor data) and reception of a next trigger from the ECU <NUM>. Ideally, timing of reception of the next trigger coincides with the DLC target, as described above. However, due to jitter effects, the time at which the trigger is received may deviate from the DLC target. In some implementations, the sensor <NUM> may indicate the deviation (e.g., a positive deviation or a negative deviation) of the DLC value from the DLC target in latency compensation information (e.g., by ALC information carried in one or more bits) transmitted in the data frame carrying the sensor data. In some implementations, the sensor <NUM> may adjust a sampling point (e.g., a time point at which the sensor <NUM> samples the sensor signal in a given cycle) based on the deviation of the DLC value from the DLC target. <FIG> and <FIG> are diagrams illustrating examples <NUM> and <NUM>, respectively, associated with adjustment of a sampling point based on a DLC value and a DLC target.

In some implementations, as illustrated in <FIG> and <FIG>, the sensor <NUM> may be configured with a sample adjustment value (Sampleadjust) that defines a sample adjustment range (e.g., a range between -Sampleadjust and +Sampleadjust as indicated in <FIG> and <FIG>). In some implementations, the sample adjustment value is configurable on the sensor <NUM>. In operation, if the sensor <NUM> determines that the DLC value is outside of the sample adjustment range (i.e., that the deviation of the DLC value from the DLC target satisfies a sample adjustment threshold), then the sensor <NUM> may adjust the sampling point for the next cycle by a particular amount, such an amount of time corresponding to the configured sample adjustment value.

In some implementations, if the DLC value is greater than or equal to the DLC high threshold or is less than or equal to the DLC low threshold, then the data frame is considered expired and the sensor <NUM> may perform a resynchronization (e.g., over a next three cycles). In some implementations, a resolution of the ALC (e.g., a DLCprotoMask), a maximum for the sample adjustment value, the DLC target, and/or the DLC high threshold are configurable and, therefore, can be configured depending requirements in a given application.

<FIG> illustrates an example associated with adjusting and compensating for a comparatively larger deviation of the DLC value from the DLC target, while <FIG> illustrates an example associated with adjusting and compensating for a comparatively smaller deviation of the DLC value from the DLC target.

In some implementations, the ECU <NUM> may vary the PWM frequency during operation of the sensor <NUM> in the synchronous mode, as described above. In some implementations, the sensor <NUM> may adapt to the variation in the PWM frequency without losing synchronization. In some implementations, a sample adjustment time based on which the sensor <NUM> can adapt to the frequency variation is configurable. In some implementations, the sample adjustment time is in a range between from, for example, <NUM> nanoseconds (ns) to <NUM> microseconds (µs).

In some implementations, with a variation in timing of the trigger (e.g., a difference between the DLC value and the DLC target) that is larger than the sample adjustment time, a sampling point associated with a next cycle is changed based on the sample adjustment time to support the PWM frequency change. This procedure can be repeated until the desired frequency has been reached. In some implementations, a speed at which the adjustment can be achieved depends on the sample adjustment time.

<FIG> is a diagram illustrating an example <NUM> of adaptation to a change in PWM frequency based on a configurable sample adjustment time. In example <NUM>, the PWM frequency is to be changed from <NUM> kilohertz (kHz) (corresponding to a period TPWM of <NUM>) to <NUM> (corresponding to a period TPWM of <NUM>). In the example shown in <FIG>, the sample adjustment time Δt is <NUM>. As shown in <FIG>, the sensor <NUM> can adapt to the frequency variation from <NUM> to <NUM> over <NUM> cycles, which corresponds to <NUM> in absolute time. Notably, an ALC value in this example should cover a maximum PWM jitter (e.g., ±<NUM> ns), and a DLC protocol mask should be set to a value which enables the maximum benefit for the prediction calculation in the ECU <NUM>.

In some implementations, as described above, the sensor <NUM> may predict a time point at which a next trigger is received based on measuring an amount of time between time points at which two received triggers are received. In some implementations, the sensor <NUM> may perform such measurements repeatedly in order to continuously update the time point at which to initiate performance of a set of sensor tasks. For example, the sensor <NUM> may maintain a reference time value based on measured time intervals between triggers, and may utilize the reference time value in association with predicting when the sensor <NUM> will receive a next trigger.

<FIG> is a diagram illustrating an example implementation for the sensor <NUM> capable of performing operations associated with maintaining a reference time value in association with predicting time points of receiving triggers from the ECU <NUM>. As shown in <FIG>, the sensor <NUM> may include an interface implementation component <NUM> and a sensor algorithm component <NUM>. As shown, the interface implementation component <NUM> may be connected (e.g., via relevant circuitry, such as a Schmitt trigger, a pad driver, or the like) to input/output pins of the sensor <NUM> in order to enable communication with the ECU <NUM>. As further shown, the interface implementation component <NUM> may also be connected to the sensor algorithm component <NUM> with at least an internal trigger wire and a sensor data interface (e.g., associated with transferring data values Di).

<FIG> is a diagram illustrating an example of the interface implementation component <NUM>. As shown in <FIG>, the interface implementation component <NUM> may include a trigger detector <NUM>, a trigger level calculator <NUM>, a protocol encoder <NUM>, a counter <NUM>, and an internal trigger generator <NUM>.

In an example operation, the trigger detector <NUM> detects a trigger received from the ECU <NUM> and forwards an indication that a trigger was detected (e.g., external trigger signal) to the trigger level calculator <NUM> and the protocol encoder <NUM>.

In some implementations, upon receiving the external trigger signal from the trigger detector <NUM>, the trigger level calculator <NUM> obtains a counter value from the counter <NUM> and resets the counter <NUM>. Next, the trigger level calculator <NUM> may compare the counter value to a reference time value (e.g., by the trigger level calculator <NUM>). Here, if a difference between the counter value and the reference time value satisfies a threshold (e.g., the absolute value of the difference is greater than or equal to a threshold value), then the trigger level calculator <NUM> may signal the protocol encoder <NUM> that the difference between the counter value and the reference time value satisfied the threshold (i.e., that the trigger was received "off target"). In some implementations, the trigger level calculator <NUM> subtracts a DLC target value (e.g., stored or otherwise accessible by the trigger level calculator <NUM>) from the counter value, and stores a result of the subtraction as internal trigger level value (trg). In some implementations, the DLC target value corresponds to an amount of time needed for the sensor algorithm component <NUM> to perform a set of sensor tasks (e.g., plus a margin time used to accommodate, for example, jitter). In some implementations, the trigger level calculator <NUM> provides the internal trigger level value to the internal trigger generator <NUM>. Notably, the counter <NUM> counts from <NUM> and should be sufficiently dimensioned such that a maximum specified external trigger period without overflow can be supported.

In some implementations, as shown in <FIG>, the internal trigger generator <NUM> also monitors the counter value from the counter <NUM>. Here, the internal trigger generator <NUM> triggers the sensor algorithm component <NUM> (e.g., via an internal trigger signal), when the counter value of the counter <NUM> is greater than or equal to the internal trigger level value stored on the internal trigger generator <NUM> (e.g., an internal trigger level value received from the trigger level calculator <NUM> at an earlier time). Upon receiving the internal trigger signal from the internal trigger generator <NUM>, the sensor algorithm component <NUM> computes sensor data (Di). In some implementations, computation of the sensor data can include, for example, triggering analog-to-digital conversions, fetching data from ADCs, filters, or registers, compensating for sensor or ADC non-idealities (e.g., offset, amplitude, phase, orthogonality compensation, or the like), calculating related values (e.g., an angle or a linear position via, for example, an arctan function call, a CORDIC evaluation, or the like), or compensating the related value for non-idealities (e.g., using look-up table compensation), among other examples.

In some implementations, upon receiving the indication that the trigger from the ECU <NUM> was detected, the protocol encoder <NUM> prepares and transmits a data frame to the ECU <NUM>. Here, if no valid sensor data value Di has been received from the sensor algorithm <NUM>, the lack of sensor data is indicated in the data frame (e.g., using a value such as "nd"). In a case in which the sensor data value Di is "off target" - as indicated by the trigger level calculator <NUM> in the manner described above - this information is indicated in the data frame (e.g., a warning indicating that the delay of the sensor data is different than in the nominal case).

<FIG> is a diagram illustrating an example <NUM> of the timing and signal flow associated with operation of the sensor <NUM> in a scenario in which a time interval between triggers from the ECU <NUM> is constant over a period of time.

In some implementations, if a rate at which the ECU120 transmits, and the sensor <NUM> receives, triggers is constant, then the reference time value remains unchanged over time, and no updates are needed. However, as described above, the rate at which the ECU <NUM> transmits, and the sensor <NUM> receives, triggers may vary (e.g., due to a PWM frequency variation or due to variations of a clock reference of the sensor). In some implementations, the sensor <NUM> may be capable of maintaining synchronization even when the rate at which the ECU <NUM> transmits, and the sensor <NUM> receives, triggers varies.

One scenario in which the rate of the triggers varies is when the ECU <NUM> decreases a PWM frequency. <FIG> is a diagram illustrating an example <NUM> of the timing and signal flow associated with operation of the sensor <NUM> in a scenario in which the ECU <NUM> decreases a PWM frequency. In the example shown in <FIG>, the ECU <NUM> is to decrease the PWM frequency from fsA to fsB during operation of the sensor <NUM> in the synchronous mode such that a request period is increased from period TsA (TsA = <NUM>/fsA) to period TsB (TsB = <NUM>/fsB). As further shown, and in accordance with the operation described above with respect to <FIG> and <FIG>, the sensor algorithm <NUM> calculates the sensor data D2 when a value of the counter <NUM> reaches a first internal trigger level value trgA. The internal trigger level value trgA is an internal trigger level value determined while the period between triggers is the period TSA. As indicated in <FIG>, a result of the PWM frequency decrease is that the sensor data D2 is out of synchronization with the next received trigger by some finite amount of delay. In some implementations, the sensor <NUM> may include an indication that the trigger was received off target in the data frame (indicated by the "!" in <FIG>). Further, the sensor <NUM> can indicate the delay in the data frame to, for example, enable the ECU <NUM> to perform latency compensation as described above. In a case in which the PWM frequency decrease was initiated by the ECU, the ECU has knowledge of the additional delay (i.e., the delay difference from the target value). The additional delay is the difference of the trigger periods before and after the PWM frequency change. Thus, even if the sensor does not explicitly transmit an indication of the delay difference from the target value, the ECU is able to compensate for the latency. As further shown, after the cycle associated with the sensor data D2, the sensor <NUM> updates the reference distance value based on the corresponding period TsB, and the internal trigger level value is updated such that the internal trigger level value trgB is used to trigger the sensor algorithm <NUM>. In this way, synchronization to the trigger pulses of the ECU <NUM> can be restored, and a next item of sensor data D3 will be on time.

Another scenario in which the rate of the triggers changes is when the ECU <NUM> increases a PWM frequency. <FIG> is a diagram illustrating an example <NUM> of timing and signal flow associated with operation of the sensor <NUM> in a scenario in which the ECU <NUM> increases a PWM frequency. In the example shown in <FIG>, the ECU <NUM> is to increase the PWM frequency from fsA to fsB during operation of the sensor <NUM> in the synchronous mode such that a request period is decreased from period TsA (TsA = <NUM>/fsA) to period TsB (TsB = <NUM>/fsB). As further shown, and in accordance with the operation described above with respect to <FIG> and <FIG>, the sensor algorithm <NUM> calculates the sensor data D2 when a value of the counter <NUM> reaches a first internal trigger level value trgA. The internal trigger level value trgA is an internal trigger level value determined while the period between triggers is the period TSA. As indicated in <FIG>, a result of the PWM frequency increase is that the sensor data D2 is not ready for transmission when the next trigger is received from the ECU <NUM>. In some implementations, the sensor <NUM> may transmit, in the data frame, an indication that the sensor data was not ready, and that the data frame does not include sensor data (indicated by the "nd!" in <FIG>). As further shown, after the cycle associated with the sensor data D2, the sensor <NUM> updates the reference distance value based on the corresponding period TsB, and the internal trigger level value is updated such that the internal trigger level value trgB is used to trigger the sensor algorithm <NUM>. In this way, synchronization to the trigger pulses of the ECU <NUM> can be restored, and a next item of sensor data D3 will be on time.

Notably, in example <NUM>, the ECU <NUM> "misses" one sensor data value as a result of increasing the PWM frequency. In some applications, missing a sensor data value is undesirable. For example, in an electric main drive of a vehicle, the PWM frequency is increased when accelerating (i.e., when a high torque is generated). Under such conditions, missing a sensor data value is undesirable because of a consequent reduction in energy efficiency. Thus, in some implementations, the ECU <NUM> may be configured to prevent a sensor data value from being missed as result of an increase in the PWM frequency.

In some implementations, rather than increasing the PWM frequency from a current PWM frequency to a target PWM frequency, which leads to missed sensor data, the ECU <NUM> may temporarily increase the PWM frequency to twice the target PWM frequency for two triggers, after which the ECU <NUM> may decrease the PWM frequency to the target PWM frequency. In this way, the sensor <NUM> may transmit, and the ECU <NUM> may receive, sensor data values needed by the ECU <NUM> (i.e., such that no sensor data values are missed).

<FIG> is a diagram illustrating an example <NUM> of the timing and signal flow associated with operation of the sensor <NUM> in a scenario in which the ECU <NUM> temporarily increases a PWM frequency to twice a target frequency. In the example shown in <FIG>, the ECU <NUM> is to increase the PWM frequency from fsA to fsB during operation of the sensor <NUM> in the synchronous mode such that a time interval between triggers is decreased from period TsA (TsA = <NUM>/fsA) to period TsB (TsB = <NUM>/fsB). As shown in <FIG>, rather than changing the PWM frequency from PWM frequency fsA directly to PWM frequency fsB, which would result in a missed sensor data value (as illustrated in example <NUM>), the ECU <NUM> changes the PWM frequency temporarily to twice the target frequency (e.g., to <NUM>*fsB, such that the period between triggers is a period TsB/<NUM>). Here, the sensor <NUM> cannot provide the sensor data value associated with a next trigger (e.g., a trigger received at a time TsB/<NUM> after the PWM frequency increase) because the sensor data is not ready. As further shown, the sensor <NUM> updates the reference distance value based on the corresponding period <NUM>*TsB, and the internal trigger level value is updated such that the internal trigger level value trgC is used to trigger the sensor algorithm <NUM>. Here, the ECU <NUM> expects to receive a "data not ready" warning in response to the first trigger after the PWM frequency increase and can discard the data frame accordingly (e.g., since the ECU <NUM> does not need the sensor data value at time TsB/<NUM> after the PWM frequency increase). Since the sensor <NUM> adapts the internal trigger level value, the sensor <NUM> expects another trigger at a time <NUM>*TsB/<NUM> after the PWM frequency increase, and prepares and transmits the sensor data D2 accordingly.

Next, after the ECU <NUM> transmits the second trigger (e.g., at the time <NUM>*TsB/<NUM> after the PWM frequency increase), the ECU <NUM> reduces the PWM frequency to the target frequency fsB (e.g., such that the time interval between triggers is period <NUM>/TsB). Here, due to the PWM frequency decrease from <NUM>*fsB to fsB, a next sensor data value D3 transmitted by the sensor <NUM> will show an increased latency (e.g., since the set of sensor tasks is triggered based on internal trigger level value trgC). However, this latency can be indicated and compensated for as described above for the case of the ECU <NUM> decreasing the PWM frequency. After the cycle associated with the sensor data D3, the sensor <NUM> updates the reference distance value based on the corresponding period TsB, and the internal trigger level value is updated such that the internal trigger level value trgB is used to trigger the sensor algorithm <NUM>. In this way, synchronization to the trigger pulses of the ECU <NUM> can be restored, and a next item of sensor data D4 will be on time.

<FIG> is a flowchart of an example process <NUM> associated with operation of a sensor described herein. In some implementations, one or more process blocks of <FIG> may be performed by a sensor (e.g., sensor <NUM>).

As shown in <FIG>, process <NUM> may include determining a delay latency value associated with an amount of time from completion of a set of sensor tasks to an actual time of reception of a trigger to selectively transmit or sample sensor data (block <NUM>). For example, the sensor may determine a delay latency value associated with an amount of time from completion of a set of sensor tasks to an actual time of reception of a trigger to selectively transmit or sample sensor data. For example, in some implementations, the trigger may cause the sensor to either transmit previously sampled sensor data (e.g., on a bus). As another example, in some implementations, the trigger may cause the sensor to sample sensor data.

As further shown in <FIG>, process <NUM> may include calculating a deviation of the delay latency value from a target delay latency (block <NUM>). For example, the sensor may calculate a deviation of the delay latency value from a target delay latency, as described above.

As further shown in <FIG>, process <NUM> may include transmitting a data frame including an indication associated with the deviation of the delay latency value from the target delay latency (block <NUM>). For example, the sensor may transmit a data frame including an indication associated with the deviation of the delay latency value from the target delay latency, as described above.

In a first implementation, process <NUM> includes adjusting timing of initiation of the set of sensor tasks based on a determination that the deviation satisfies a threshold.

In a second implementation, alone or in combination with the first implementation, the timing is adjusted in association with adapting to a variation of a PWM frequency associated with operation of the sensor.

In a third implementation, alone or in combination with any of the first and second implementations, process <NUM> includes determining that the delay latency value satisfies a delay latency high threshold, and transmitting the data frame comprises transmitting the indication to indicate that the sensor data is expired.

In a fourth implementation, alone or in combination with any of the first through third implementations, process <NUM> includes determining that the delay latency value satisfies a delay latency low threshold, and transmitting the data frame comprises transmitting the indication to indicate that the sensor data is not ready.

In a fifth implementation, alone or in combination with any of the first through fourth implementations, the indication associated with the deviation of the delay latency value from the target delay latency includes latency compensation information to be used for compensating for the deviation.

<FIG> is a flowchart of an example process <NUM> associated with adaptation to a pulse width modulation frequency variation for a sensor operating in a synchronous mode. In some implementations, one or more process blocks of <FIG> are performed by an ECU (e.g., ECU <NUM>).

As shown in <FIG>, process <NUM> may include transmitting a first plurality of triggers to a sensor operating in a synchronous mode, wherein a time interval between triggers of the first plurality of triggers is a first period that corresponds to a first frequency (block <NUM>). For example, the ECU may transmit a first plurality of triggers to a sensor operating in a synchronous mode (e.g., a sensor <NUM>), wherein a time interval between triggers of the first plurality of triggers is a first period that corresponds to a first frequency, as described above.

As further shown in <FIG>, process <NUM> may include transmitting a second plurality of triggers to the sensor operating in the synchronous mode, wherein a time interval between triggers in the second plurality of triggers is a second period that corresponds to one-half of a second frequency and the second frequency is higher than the first frequency (block <NUM>). For example, the ECU may transmit a second plurality of triggers to the sensor operating in the synchronous mode, wherein a time interval between triggers in the second plurality of triggers is a second period that corresponds to one-half of a second frequency and the second frequency is higher than the first frequency, as described above.

As further shown in <FIG>, process <NUM> may include transmitting a third plurality of triggers to the sensor operating in the synchronous mode, wherein a time interval between triggers in the third plurality of triggers is a third period that corresponds to the second frequency (block <NUM>). For example, the ECU may transmit a third plurality of triggers to the sensor operating in the synchronous mode, wherein a time interval between triggers in the third plurality of triggers is a third period that corresponds to the second frequency, as described above.

Although <FIG> shows example blocks of process <NUM>, in some implementations, process <NUM> includes additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in <FIG>.

As used herein, satisfying a threshold may, depending on the context, refer to a value or its corresponding absolute value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

As an example, "at least one of: a, b, or c" is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same item.

Claim 1:
A sensor (<NUM>), comprising:
one or more components (<NUM>) configured to:
determine a time interval between a time of reception of a first trigger to selectively transmit or sample first sensor data and a time of reception of a second trigger to selectively transmit or sample second sensor data;
determine, based on the time interval, a predicted time of reception of a third trigger to selectively transmit or sample third sensor data;
initiate a set of sensor tasks based on the predicted time of reception of the third trigger, the set of sensor tasks being initiated to cause the third sensor data to be ready for transmission at the predicted time of reception of the third trigger;
receive the third trigger;
determine a delay latency value associated with an amount of time from completion of the set of sensor tasks to an actual time of reception of the third trigger;
characterized in that the one or more components are further configured to:
calculate a deviation of the delay latency value from a target delay latency; and
transmit a data frame including an indication associated with the deviation of the delay latency value from the target delay latency.