Patent Application
20170041688
Field
The subject matter disclosed herein relates to electronic devices, and more particularly to methods, apparatus, and systems for timestamping in a system synchronizing controllers and sensors.
Background
Modern-day mobile devices contain many sensors. Usually, a data processing unit, controller, host device, or master device (hereinafter referred to as simply a controller or a host controller) is provided to receive and process data collected by sensors or slave units (hereinafter referred to a “sensor”). To conserve power, the controller is regularly placed into a sleep state when no data is being transferred from the sensors to the controller.
Two methods of transferring data from sensors to a controller are commonly utilized. In the first method, which is known as the asynchronous method, a sensor with available data to transfer notifies the controller by issuing a signal (e.g., a Data Ready Interrupt (DRI) signal through a dedicated DRI pin for certain known systems), which wakes up the controller, and then the sensor transfers the data when the controller is ready. In the second method, which is known as the synchronous method, the controller wakes up from the sleep state spontaneously at predetermined time intervals, polls the sensors, and receives from the sensors whatever data is present at the sensors. The synchronous method is more energy efficient in a device comprising multiple sensors because data transfers from more than one sensor may be consolidated into a single poll and transfer session.
In systems where multiple sensors or other devices provide periodically sampled data, it is further advantageous to be able to instruct the sensors to collect the data at essentially synchronized times, and for the controller to read the data from several sensors within the same awake time window or system awake period. Ideally, assuming a sensor delivers only the most current results, polling a sensor at a frequency that coincides with the sensor's sampling frequency is sufficient to obtain all the data collected by the sensor. However, because the controller and the sensors do not usually share timing signals and misalignment of the timing signals may therefore result, some sensor data samples may be lost and some sensor data samples may be read twice even when the sensors are polled at their sampling frequencies. The phenomenon is exacerbated by the fact that some sensors have poor clock or timer accuracy (e.g., ±15% deviation over a temperature range and from device to device).
Additionally in particular systems it is known that sensors might provide data on an interface or bus in a random or unexpected manner (i.e., an essentially “asynchronous” manner), whether the system as whole is intentionally being operating in an asynchronous data sampling mode or even is operating in a synchronous data sampling mode where random events might occur on the interface or bus. In such instances, it is desirable for the host controller to be able to acquire accurate time-of-occurrence information of when sensors or slave devices provide data in random or unexpected manners.
According to an aspect, a method for providing a timestamp in a host controller of an interface event on an interface coupled with host controller is disclosed. The method includes detecting a message from a sensor on the interface that identifies the issuance of the interface event caused by the sensor, the interface event occurring at a first time on the sensor. Additionally, the method includes issuing a first event on the interface at a second time after the first time in the response to the received message and starting a first count of cycles of a host controller clock, the start of the first count being concurrent with issuing the first event, and issuing a second event on the interface at third time after the second time. The method also includes receiving a first sensor clock count and a second sensor clock count from the sensor, where the first sensor clock count is a count of cycles of an internal sensor clock from the first time to the second time and the second sensor clock count is a count of cycles of the internal sensor clock from the second time to the third time. The host controller then determines the timestamp of the interface event corresponding to the first time based at least in part on the first count of cycles of a host controller clock, the first sensor clock count, the second sensor clock count, and a host controller timestamp of the second time.
According to another aspect, a host controller device is disclosed that includes a transport medium interface communicatively coupled to at least one sensor via at least one transport medium and at least one processing circuit communicatively coupled to the transport medium interface. The at least one processing circuit is configured to detect a message from the sensor on the interface that identifies the issuance of the interface event caused by the sensor, the interface event occurring at a first time on the sensor. The processor is further configured to issue a first event on the interface at a second time after the first time in the response to the received message and starting a first count of cycles of a host controller clock, the start of the first count being concurrent with issuing the first event, and issue a second event on the interface at third time after the second time. Furthermore, the receive a first sensor clock count and a second sensor clock count from the sensor, where the first sensor clock count is a count of cycles of an internal sensor clock from the first time to the second time and the second sensor clock count is a count of cycles of the internal sensor clock from the second time to the third time. Additionally, the processor is configured to determine the timestamp of the interface event corresponding to the first time based at least in part on the first count of cycles of a host controller clock, the first sensor clock count, the second sensor clock count, and a host controller timestamp of the second time.
According to yet another aspect, a processor-readable storage medium is disclosed, where the medium has one or more instructions which, when executed by at least one processing circuit, cause the at least one processing circuit to receive a message at host controller from a sensor on an interface communicatively coupling the host controller and the sensor, the message configured to identify the issuance of the interface event caused by the sensor and occurring at a first time on the sensor. Furthermore, the instructions cause the processor to issue a first event on the interface at a second time after the first time in the response to the received message and starting a first count of cycles of a host controller clock, the start of the first count being concurrent with issuing the first event, and to issue a second event on the interface at third time after the second time. The instructions also are configured to cause the at least one processor to receive a first sensor clock count (SC1) and a second sensor clock count (SC2) from the sensor, where the first sensor clock count is a count of cycles of an internal sensor clock from the first time to the second time and the second sensor clock count is a count of cycles of the internal sensor clock from the second time to the third time. Also, the instructions are configured to cause the at least one processor to determine the timestamp of the interface event corresponding to the first time based at least in part on the first count of cycles of a host controller clock, the first sensor clock count, the second sensor clock count, and a host controller timestamp of the second time (MREF).
According to still another aspect, a method is disclosed for providing a time of measurement associated with sensor sample data. The method includes determining a beginning time of a present time phase (T_Ph) period in a host controller. Furthermore, the method includes determining a time position of a sensor sample data transmission within a sequence of sensor sample data transmissions within the present phase time period. Yet further, the method includes determining the time of measurement associated with the sensor sample data transmission based on the beginning time of the present phase time period and the time position of the sensor sample data transmission within the sequence of sensor sample data transmissions within the present phase time period.
Aspects of the disclosed methods and apparatus are disclosed in the following description and related drawings directed to specific embodiments. Alternate embodiments may be devised without departing from the scope of the present disclosure. Additionally, well known elements may not be described in detail or may be omitted so as not to obscure the relevant details of the disclosure.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Likewise, the term “embodiments” does not require that all embodiments include the discussed feature, advantage or mode of operation.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “includes” and/or “including”, when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
Further, many embodiments are described in terms of sequences of actions to be performed by, for example, elements of a computing device (e.g., a server or device). It will be recognized that various actions described herein can be performed by specific circuits (e.g., application specific integrated circuits), by program instructions being executed by one or more processors, or by a combination of both. Additionally, these sequences of actions described herein can be considered to be embodied entirely within any form of computer readable storage medium having stored therein a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein. Thus, the various aspects of the invention may be embodied in a number of different forms, all of which have been contemplated to be within the scope of the claimed subject matter. In addition, for each of the embodiments described herein, the corresponding form of any such embodiments may be described herein as, for example, “logic configured to” perform the described action.
The device (e.g., device 100) can include sensors such as ambient light sensor (ALS) 135, accelerometer 140, gyroscope 145, magnetometer 150, temperature sensor 151, barometric pressure sensor 155, red-green-blue (RGB) color sensor 152, ultra-violet (UV) sensor 153, UV-A sensor, UV-B sensor, compass, proximity sensor 167, near field communication (NFC) 169, and/or Global Positioning Sensor (GPS) 160. In some embodiments, multiple cameras are integrated or accessible to a device. For example, a mobile device may have at least a front and rear mounted camera. In some embodiments, other sensors may also have multiple installations or versions.
Memory 105 may be coupled to processor 101 to store instructions for execution by processor 101. In some embodiments, memory 105 is non-transitory. Memory 105 may also store one or more models or modules to implement embodiments described below. Memory 105 may also store data from integrated or external sensors.
Network interface 110 may also be coupled to a number of wireless subsystems 115 (e.g., Bluetooth 166, WiFi 111, Cellular 161, or other networks) to transmit and receive data streams through a wireless link to/from a wireless network, or may be a wired interface for direct connection to networks (e.g., the Internet, Ethernet, or other wired or wireless systems). The mobile device may include one or more local area network transceivers connected to one or more antennas (not shown). The local area network transceiver comprises suitable devices, hardware, and/or software for communicating with and/or detecting signals to/from wireless APs, and/or directly with other wireless devices within a network. In one aspect, the local area network transceiver may comprise a WiFi (802.11x) communication system suitable for communicating with one or more wireless access points.
The device 100 may also include one or more wide area network transceiver(s) that may be connected to one or more antennas. The wide area network transceiver comprises suitable devices, hardware, and/or software for communicating with and/or detecting signals to/from other wireless devices within a network. In one aspect, the wide area network transceiver may comprise a CDMA communication system suitable for communicating with a CDMA network of wireless base stations; however in other aspects, the wireless communication system may comprise another type of cellular telephony network or femtocells, such as, for example, TDMA, LTE, LTE Advanced, WCDMA, UMTS, 4G, 5G, or GSM. Additionally, any other type of wireless networking technologies may be used, for example, WiMax (802.16), Ultra Wide Band, ZigBee, wireless USB, etc.
Additionally device 100 may be a mobile device, a wireless device, a cell phone, a personal digital assistant, a mobile computer, a wearable device (e.g., head mounted display, virtual reality glasses, etc.), a robot navigation system, a tablet, a personal computer, a laptop computer, or any type of device that has processing and/or communication capabilities. As used herein, a mobile device may be any portable or movable device or machine that is configurable to acquire wireless signals transmitted from, and transmit wireless signals to, one or more wireless communication devices or networks. Thus, by way of example, but not limitation, the device 100 may include a radio device, a cellular telephone device, a computing device, a personal communication system device, or other like movable wireless communication equipped device, appliance, or machine. Any operable combination of the above are also considered a “mobile device.”
Furthermore, the mobile device 100 may communicate wirelessly with a plurality of wireless access points (APs), NodeBs, eNodeB's, base stations, etc. using RF signals (e.g., 2.4 GHz, 3.6 GHz, and 4.9/5.0 GHz bands) and standardized protocols for the modulation of the RF signals and the exchanging of information packets (e.g., IEEE 802.11x).
It should be appreciated that examples as will be hereinafter described may be implemented through the execution of instructions, such as instructions stored in the memory 105 or other element, by processor 101 of the device 100 and/or other circuitry of device 100. Particularly, circuitry of device 100, including but not limited to processor 101, may operate under the control of a program, routine, or the execution of instructions to execute methods or processes in accordance with embodiments of the invention. For example, such a program may be implemented in firmware or software (e.g. stored in memory 105 and/or other locations) and may be implemented by processors, such as processor 101, and/or other circuitry of device. Further, it should be appreciated that the terms processor, microprocessor, circuitry, controller, etc., may refer to any type of logic or circuitry capable of executing logic, commands, instructions, software, firmware, functionality and the like.
Further, it should be appreciated that some or all of the functions, engines or modules described herein may be performed by device itself and/or some or all of the functions, engines or modules described herein may be performed by another system connected through I/O controller 125 or network interface 110 (wirelessly or wired) to device. Thus, some and/or all of the functions may be performed by another system and the results or intermediate calculations may be transferred back to the device 100. In some embodiments, such other devices may include a server configured to process information in real time or near real time. In some embodiments, the other device is configured to predetermine the results, for example based on a known configuration of the device. Further, one or more of the elements illustrated in
The data connection may also be a universal asynchronous receiver/transmitter (UART) connection, a Serial Peripheral Interface (SPI) bus, a System Management Bus (SMBus), a Serial Low-power Inter-chip Media Bus (SLIMbus™), a SoundWire bus, a wireless interface, or any other type of connection suitable for transferring data between a processor and a sensor. In some embodiments, sensor 210 may have a Data Ready Interrupt (DRI) pin, which may be connected to controller 205 via a DRI line 240. In embodiments where more than one sensor is present, DRI lines from the multiple sensors may be multiplexed before being connected to processor 101. In some other embodiments, in addition to or instead of a DRI pin, sensor 210 may have a dedicated clock correction pin, which may be connected to processor 101 via a clock correction line 250.
Computing device 100 may comprise a sensor 210 including or coupled to a sensor timer 215 and a host controller 205 including or coupled to a clock or timer 207 to: correct the sensor timer 215 for a first time, transfer data from the sensor 210, and correct the sensor timer 215 for a second time, wherein a time interval between two corrections of the sensor timer 215 may be selected such that the sensor timer 215 is sufficiently aligned with the host controller timer 207 over the time interval.
Two methods of transferring data from sensor 210 to host controller 205 are commonly utilized. In the first method, also known as the asynchronous method, a sensor 210 with available data to transfer may notify host controller 205 by issuing a Data Ready Interrupt (DRI) signal through a dedicated DRI pin, which wakes the processor up from the sleep state, and transfers the data when the processor is ready for the data transfer. In the second method, also known as the synchronous method, host controller 205 may wake up from the sleep state spontaneously at predetermined time intervals, and may poll sensor 210 to receive data. The synchronous method is more energy efficient in a device comprising multiple sensors because data transfers from more than one sensor may be consolidated into a single poll and transfer session.
Ideally, assuming a sensor delivers only the most current result, polling a sensor at a frequency that coincides with the sensor's sampling frequency is sufficient to obtain all the data samples collected by the sensor. However, because host controller 205 and sensor 210 do not usually share a clock or timing signal and misalignment of the timing of respective timers may result, some sensor data samples may be lost and some sensor data samples may be read twice even when sensor 210 is polled at its sampling frequency. The phenomenon may be exacerbated by the fact that some sensors may have very poor timer accuracy (i.e., ±15% deviation over the temperature range and from device to device).
Referring to
The time interval between two sensor timer corrections may be referred to as the Phase Time or Time Phase interval (T_Ph). In particular, the Time Phase interval (T_Ph) may be a period of time provided by a host or master controller 205 that indicates a pre-established time duration that is used by the Slaves or Sensors 210 for adjusting their internal timers and the beginning of a sequence of sampling events. The “T” stands for “time” or “period” and “Ph” for “phase”, referring to the fact that the sequence of sampling events takes place within the same time period and begins at the same moment. In a particular aspect, the T_Ph may be defined in terms of a predetermined number of samples or sampling events in the sequence of sampling events. For example, the T_Ph may be defined in terms of 20 sampling events that occur in each T_Ph period.
By performing operations 310 through 330 repeatedly, the internal sensor timer 215 may be kept sufficiently aligned with the host controller clock. In some embodiments, T_Ph may be a common multiple of sampling periods of sensors present. For example, in an embodiment where three sensors having sampling frequencies of 200 Hz, 100 Hz, and 10 Hz (corresponding to sampling periods of 5 ms, 10 ms, and 100 ms), respectively, are present, 100 ms may be selected as the T_Ph. It should be appreciated that synchronizing a plurality of sensors substantially simultaneously using a T_Ph that is a common multiple of sampling periods of the plurality of sensors present aligns the sensor clocks with each other and therefore allows the processor to obtain all samples with the fewest wake windows with the synchronous method. In the above-mentioned example, if the sensor clocks of the three sensors with sampling frequencies of 200 Hz, 100 Hz, and 10 Hz are not aligned with each other, the processor may have to wake up a total of 310 times per second to obtain all samples in the worst case scenario, where the processor receives a single sample from a single sensor in each wake window (200 times per second for the 200 Hz sensor, 100 times per second for the 100 Hz sensor, and 10 times per second for the 10 Hz sensor). On the other hand, if the sensor timers of the three sensors are aligned as described above, the processor needs to wake up only 200 times every second to obtain all samples: the 200 Hz sensor is polled every time the processor wakes up; the 100 Hz sensor is polled every other time the processor wakes up; and the 10 Hz sensor is polled every 20 times the processor wakes up. Reducing the number of wake windows required is desirable because it conserves power and extends battery life. In some embodiments, T_Ph may be approximately 1 second. T_Ph may also be adjusted at run-time in embodiments where clock-related feedback information is provided by sensor 210.
A number of non-limiting methods for correcting the sensor timer 215 have been contemplated. In some embodiments, sensor 210 may receive information relating to the processor clock or timer, derive the timer or clock correction factor, and apply the timer correction factor. In some embodiments, sensor 210 may send information relating to its internal timer or clock to the host controller 205, receive the timer correction factor derived at host controller 205, and apply the timer correction factor.
For embodiments where timer-related information is exchanged between host controller 205 and sensor 210, a number of non-limiting methods for exchanging clock or timer related information have been contemplated. In some embodiments, the clock or timer information may be transferred using DRI line 240. In some embodiments, the clock or timer information may be transferred using a dedicated clock or timer correction line 250. In yet some other embodiments, the clock or timer information may be transferred using a regular data connection between processor 101 and sensor 210, such as an I2C or I3C bus described above.
In a first group of embodiments, sensor 210 may receive information relating to the processor timer or clock 207, derive the timer correction factor, and apply the timer correction factor when the sensor timer 215 is being corrected.
In one embodiment, when the sensor timer 215 is being corrected, host controller 205 may transmit a burst of pulses consisting of a predetermined number of pulses to sensor 210. The burst of pulses may be derived from the host controller timer and its frequency may be dependent on that of the host controller timer. The burst need last only a relatively short period of time. Here, sensor 210 may be configured a priori with the expected frequency of the burst. Once sensor 210 receives the burst, it may compare the frequency of the burst received with the expected frequency, derive a timer correction factor accordingly, and apply the timer correction factor to correct the internal sensor timer 215.
In another embodiment, when the sensor timer 215 is being corrected, host controller 205 may transmit two pulses to sensor 210, where the pulses are spaced by a predetermined time interval as measured by the processor timer. The time interval is chosen such that it can be reliably used to derive a timer correction factor to correct the sensor timer 215. This time interval may be referred to as the Frequency Time interval (T_Fq). In some embodiments, T_Fq may be in the range of a few milliseconds. In some embodiments, T_Fq is chosen to coincide with the shortest sensor sampling period present. In some other embodiments, T_Fq may be chosen to be as long as T_Ph. For example, T_Fq may be 1 second. Here, sensor 210 may be configured a priori with the predetermined T_Fq. Once sensor 210 receives the two pulses, it may compare the duration of the time interval bookended by the two pulses received, as measured by the sensor timer, with the predetermined T_Fq, also as measured by the sensor timer, derive a timer correction factor accordingly, and apply the timer correction factor to correct the internal sensor timer.
In yet another embodiment, when the sensor timer is being corrected, host controller 205 may transmit timer correction messages to sensor 210 over the data connection between host controller 205 and sensor 210 such that two identifiable significant edges generated during a transmission of timer correction messages are spaced by a predetermined T_Fq, as measured by the processor timer. As described above, the data connection between host controller 205 and sensor 210 may be an I2C bus or I3C bus. It may also be a UART connection, an SPI bus, or any other type of connection suitable for transferring data between a controller and a sensor. The predetermined T_Fq may be the same as described above. Here, sensor 210 may be configured a priori with the predetermined T_Fq. Once sensor 210 receives the timer correction messages, it may compare the duration of the time interval bookended by the two identifiable significant edges included with the timer correction messages, as measured by the sensor timer 215, with the predetermined T_Fq, also as measured by the sensor timer, derive a timer correction factor accordingly, and apply the timer correction factor to correct the internal sensor timer.
For example, in an embodiment where the data connection between host controller 205 and sensor 210 is an I2C or I3C bus, two clock correction messages may be transmitted. These two timer correction messages may be referred to as MS1 and MS2, respectively. T_Fq may be bookended by the falling edge on SDA line 220 in the START condition for MS1 and the falling edge on SDA line 220 in the START condition for MS2, or may alternatively be bookended by the rising edge on SDA line 220 in the STOP condition for MS1 and the falling edge on SDA line 220 in the START condition for MS2. In embodiments where T_Fq is chosen to be as long as T_Ph, only one timer correction message, e.g., MS1, may be required, and the MS1 message may be transmitted by processor 101, for example, at the beginning of each T_Ph. Thus, the time period T_Fq that is equal to T_Ph may be bookended by, for example, in one embodiment, the falling edges on SDA line 220 in the START condition for two consecutive MS1 messages. Of course, the invention is not limited by the examples provided herein. Moreover, the use of the I2C or I3C bus for the purpose of correcting the sensor timer 215 also allows for supplementary error correction procedures, fault detections, and abort commands, etc. For example, sensor 210 may transmit a timestamp or a message including time deviation information and host controller 205 may correct the subsequent streams of data accordingly. By utilizing this procedure, the accuracy requirements of T_Ph may be relaxed. Other ways of exploiting the bi-directional communication abilities of the PC or I3C bus for timer correction purposes have also been contemplated.
In a second group of embodiments, sensor 210 may send information relating to its internal timer to host controller 205, receive the timer correction factor derived at host controller 205, and apply the timer correction factor when the sensor timer 215 is being corrected.
In one embodiment, when the sensor timer 215 is being corrected, sensor 210 may transmit two pulses spaced by a predetermined T_Fq or ODR period as measured by the sensor timer to host controller 205. The predetermined T_Fq may be the same as described above. Here, host controller 205 may be configured a priori with the predetermined T_Fq. Once host controller 205 receives the two pulses, it may compare the duration of the time interval bookended by the two pulses received, as measured by the processor timer, with the predetermined T_Fq, also as measured by the processor timer, derive a timer correction factor accordingly, and transmit the timer correction factor to sensor 210 via the interface 217 between host controller 205 and sensor 210, such as an I2C or I3C bus. Sensor 210 then may receive the timer correction factor and apply it.
In a third group of embodiments, no timer correction factor is used. In these embodiments, the processor timer, or a signal derived from the processor timer, may be provided to sensor 210, and sensor 210 may base the sampling events directly on the processor timer or the signal derived from the processor timer. The processor timer or the signal derived from the processor timer may be transmitted using a dedicated line, a DRI line 240, or may be transmitted within messages transferred on the data connection between processor 101 and sensor 210.
In one embodiment, host controller 205 may generate a sampling timer signal based on the processor timer, and transmit the sampling timer to sensor 210. The frequency of the sampling timer may be the same as the sampling frequency of sensor 210. Sensor 210 may be configured to ignore its internal sensor timer and collect a sample only when it encounters a pulse in the sampling timer signal transmitted by host controller 205.
In one embodiment where multiple sensors are present, the frequency of the sampling timer signal generated by processor 101 may be selected such that the frequency of the sampling timer signal is a common multiple of sampling frequencies of sensors present. For example, for an embodiment where three sensors having sampling frequencies of 200 Hz, 100 Hz, and 10 Hz, respectively, are present, processor 101 may generate a sampling timer signal with a frequency of 200 Hz based on the processor timer and transmit the sampling timer signal to all three sensors. Then, the sensor with the 200 Hz sampling frequency may be configured to collect a sample at every pulse it encounters in the sampling timer signal; the sensor with the 100 Hz sampling frequency may be configured to collect a sample at every other pulse it encounters in the sampling timer signal; and the sensor with the 10 Hz sampling frequency may be configured to collect a sample at every 20th pulse it encounters in the sampling timer signal.
It should be appreciated that because the sampling timer is based on the host controller timer, sampling events of sensor 210 and polling events of host controller 205 may always be aligned. It should also be appreciated that in some embodiments, the sampling timer signal may serve as the polling signal as well at the same time. In another embodiment, the processor timer may be directly provided to sensor 210, and sensor 210 may base the sampling events on the processor timer instead of its internal sensor timer.
By utilizing the exemplary methods for synchronizing sensor timers described herein, a controller may coordinate timer corrections for sensors and receive all sensor data samples from multiple sensors in batches in an energy-efficient synchronous mode, without wasting energy in polling the sensors at a frequency that is higher than necessary.
A method for determining the frequency of re-synchronizing sensors by transmitting a single set of timer correction messages comprising one or more messages from the processor to the sensors has been contemplated. It should be appreciated that the frequency of re-synchronizing sensors is the multiplicative inverse or reciprocal of T_Ph.
According to further embodiments of the present disclosure, methods and apparatus are disclosed that utilize specific hardware (or hardware and software in another example) events for time-controlled synchronizing events. The specific hardware events may depend on the interface used, e.g., the event would differ between different interfaces such as I2C, I3C, SPI, etc. Nonetheless, the events may be identified with specific set of commands and data. In one example, such commands are sent within a same I2C or I3C transaction that is used for an otherwise normal data exchange (e.g., reading data from sensors); as such, the energy required is negligible. The time synchronizing events, in particular, may be sent by a host controller at T_Ph intervals. In an aspect, the time synchronizing event may be chosen among the several start (START) conditions that are known to occur on an interface.
According to another aspect, methods and apparatus are disclosed that allow a host controller to acquire accurate time-of-occurrence information in systems where sensors or other slave devices provide data samples on the interface in a seemingly asynchronous, random, or unexpected manner. For a wide range of applications, several degrees of accuracy are required for such information. Accurate timestamping of such events can be challenging, however, for several reasons such as (1) uncertainties in relation to processing availability either at the host controller side or at the sensor side; (2) asynchronous and non-correlated clocks between the host controller and sensor, which leads to non-correlated timers/counters of the host controller and of the sensor; (3) large clock frequency differences between the host controller and the sensor; and (4) energy efficiency requirements. Thus, the disclosed methods and apparatus provide timestamping at both a sensor and a host controller during instances of asynchronous interface or bus events, and then share the timestamping information from which the host controller can determine an accurate timing based on the information, while also doing so in a more efficient manner.
The disclosed methodology of
According to an aspect, the host controller is configured to send first and second events 414 and 416 to the sensor separated in time on the bus or interface. These events are predetermined or in some similar way mutually identifiable by the sensor and the host controller, and may also be referred to as hardware time synchronization events (known also as HWSE). According to some aspects, the events 414 and 416 may be configured to be edges of already defined events on either SDA or SCL lines, in the example of I2C or I3C interfaces. For example, two successive edges (either rising or falling) of the SCL line may constitute the events as part of a defined sequence of I2C or I3C transactions. In another example, two selected edges of SCL clock on the SCL lines may be predetermined as the identifiable hardware events, such as the first SCL rising edges after an Acknowledgement (ACK) or a transition bit (T-bit) as one particular example. In another example, the interface events could be events that would occur on the bus or interface but are further independently identified as the interface events 414 and 416 by both the controller and the sensor. Based on reception of the events 414, 416, a sensor may transfer relevant time information to the host controller for use by the controller to determine or calculate an accurate time reference.
As indicated before, at the time of the sensor sample 404, the sensor may also issue an interrupt request (IRQ or IBI) as indicated at pulse 408. If the interrupt request is accepted at the host controller, then sensor is configured to record or store the first event 414 against its own timer or counter SC1 as indicated at 418. Also at the same time, the sensor will then start a second count of its internal clock (SCNT2) as also indicated at 418. Additionally, the host controller will record the first event 414 again its internal counter as indicated at 420 on timeline 421 of the host controller. In particular, the host controller records a master reference count (termed “MREF”) against its own clock and then also starts a second count (e.g., MCNT2) of the host controller's clock pulses or cycles 421 at the same time.
At some predetermined time after the first event 414, the host controller issues the second hardware event 416 as shown in timeline 402. As may be also be seen in
Upon issuance of the first event 414, the sensor will capture the count of SCNT1 and store or buffer this first sensor count (termed “SC1” herein, and indicative of the number of the internal sensor clock pulses or cycles occurring between the time of the sensor sample 404 on interface and the first event 414 At the second event 416, the sensor captures or records the second count (SC2) against its own counter as shown at 423 in timeline 406. Additionally, the host controller records a count (MC2) at the occurrence of the second hardware event 416 against its own internal counter as shown at 424 in timeline 414.
It is desirable for the host controller to be able to determine or recover a timestamp for an interface event, such as for sensor sample 404. The present methods and apparatus afford a host controller the ability to determine a timestamp that accurately corresponds to the time of the sensor sample 404, for example, based on the counts that are sent from the sensor (e.g., counts SC1 and SC2, which may sent on the interface or bus through means of the interrupt request, for example, such that the payload of the interrupt request contains counts SC1 and SC2 and is sent by the sensor to the host controller on the interface after the occurrence of the second hardware event 416), as well as the counts in the host controller related to the issued first and second event 414, 416. To this end, the host controller determines a timestamp (illustrated at 412 on timeline 421 of the host controller) corresponding to sensor sample, which is termed herein as a Master Timestamp (MTS) and is expressed in time units of the host controller's internal clock. The determination of the MTS provides the host controller an accurate timing of the sensor sample 404 as it is was known internally by the sensor.
It is noted that the timelines, messages and events illustrated in
In order to more easily visualize the relationships between the timing of each of the counts SC1, SC2, MC1, and MC2,
Since the counts SC1, SC2, and MC2 are known after the second event 416, and the second time period 522 for count SC2 is the same as the count for MC2, and the first time period 422 for count SC1 will the same as the time period for count MC1, the unknown value for the number of host controller counts MC1 can be determined based on the ratios of three known counts SC1, SC2, and MC2. That is, the ratio of MC1 to SC1 will be equal to or proportional to the ratio of MC2 to SC2, again assuming clock stability over the first and second time periods. This is represented by equations (1) as follows:
Accordingly, solving for MC1 yields equation (2) as follows:
MC1=MC2×SC1/SC2 (2).
Equation (2) then provides the count of the host controller's internal clock cycles over the first time period 502, which is represented in terms of the number of host controller clock cycles. Accordingly, because the host controller establishes the master reference timestamp MREF (See 420) at the issuance of the first event 414, the MTS timestamp can be found from the subtraction of the determined count MC1 from the timestamp MREF. Since MC1 can be expressed in terms of MC2, SC1, and SC2 as given in equation (2) above, the MTS timestamp of the sensor event 404 as expressed in the controller's time units, may be calculated using equation (3) as follows:
MTS=MREF−MC2×SC1/SC2 (3).
From equation (3) above, the host controller is then able to determine a timestamp MTS that is the same as the timestamp of the sensor sample event 404 (or any other event where a sensor is configured to timestamp the event and issue a subsequent interrupt request) determined and assigned by the host controller, giving the host controller an accurate accounting of the timing.
Of further note, if the interrupt request (e.g., IRQ or IBI) is not immediately accepted by the host controller, the hardware events 414 and 416 will not issue unless the interrupt is accepted. Nonetheless, a sensor may be further configured to continue counting its own counter and wait for the next opportunity to have the interrupt request accepted. When the interrupt request is finally accepted, the sensor may be configured to proceed according to the processes as described above. It is noted in such case that the count of the first time period may be much greater than the count of the second time period, as the sensor continues counting as it waits for the interrupt request to be accepted and the subsequent hardware events 414, 416 to be issued. Although
According to other aspects, alternate means for retrieving the timestamp data from the sensor beyond a predetermined payload inclusion as part of an interrupt request may include the host controller issuing a directed command or message for retrieving the data from the sensors. In such case, the sensor may be configured to issue a supplementary confirmation that the timestamp data has been collected, to which the host controller may issue the directed command to retrieve that data from the sensor.
Of further note, it will be appreciated that if the count numbers from the sensor are zero, the host controller will assess that no timestamp is assigned to the event, whereas if the count numbers are non-zero, then the host controller will proceed with calculating the real timestamp (MTS) using its own timer counter. Additionally, any suitable clock, either permanent or burst, may be used as the sensor clock, as long as it is sufficiently stable during the first and second time periods 422 and 522. As these time periods are generally short, the sensor clock may in some embodiments be as simple as an RC oscillator or a ring oscillator. Additionally, it is noted that the illustrated frequencies or cycles per unit time of the sensor and host controller's clock signals are merely exemplary, and frequencies of the internal clocks and their frequencies relative to one another are not necessarily limited to those illustrated in the figures.
Because the host controller clock and the sensor clock may have vastly different frequencies, and the length of either the first time period 422 or the second time period 522 may be unpredictable, the sensor timer count values (e.g., SC1 and SC2) may become overly large and take up too much transmission or storage space or exceed the storage space of a timer register, thereby losing data. This is of particular concern in sensor devices as storage or buffering size is usually much less than storage for processor devices such as the host controller. Therefore, according to an aspect of the present disclosure methods and apparatus are disclosed to be able to reduce the count values in the sensors to ameliorate storage conditions for the timer count values, such as SC1 and SC2.
As will be appreciated by those skilled in the art, it is apparent from equations (2) and (3) that even if SC1 and SC2 were decreased by a common factor, such scaling would have no effect on the resultant timestamp calculation for MTS as the ratio SC1/SC2 would remain the same. Therefore, according to an aspect of the present disclosure methods and apparatus are disclosed for scaling timer count values (e.g., SC1 and SC2) in order to limit the size of transmission or storage space required by these timer values.
Turning to
Furthermore, when the count CNT1 reaches the threshold 604 and the rate of counting cycles is halved, the count value CNT1 is divided in half to obtain a lower value (or could be reset to start again at zero after the threshold count 602 in other envisioned aspects). In the present example, if the count threshold 602 is 2048 cycles, the count CNT1 may be divided by two (CNT1/2), as merely one example, and then the count would continue from 1024 at the scaled half rate (i.e., the clock rate divided by two).
At the conclusion of the first time period 422, the content of count storage or timer register is stored as the SC1 value, and the count storage or timer register may be reset to zero to begin the SCNT2 count during time period 522. As shown in
In the illustrated example of
In different embodiments, the SC1 and SC2 values may take up different transmission and storage space. For example, in one embodiment, the SC1 value may be limited to two bytes (16 bits), and the SC2 value may be limited to one byte (8 bits). Therefore, there may be a further limit to the ratio between the SC1 value and the SC2 value. Consequently, depending on the implementation, the size limit of the SC1 value, the interface events (which affect the second time period 522 and thus the SC2 value), and/or the thresholds used for scaling sensor timer values may need to be modified in order for the embodiments of the disclosure to work as intended.
In light of the methodology disclosed in connection with
After the message in the process of block 702 is received by the host controller, the host controller issues a first event on the interface at a second time after the first time in the response to the received message and starts a first count of cycles of a host controller clock where the start of the first count being concurrent with issuing the first event as shown at block 704. In an example, the processes of block 704 may include issuing the first event 414 at the timestamp 418 (i.e., the second time after the first time (e.g., MTS or timestamp 408 or the time of sensor sample 404). In another aspect, the start of the first count in the processes of block 704 may include the start of MCNT2 at timestamp 420 to derive the count MC2. After a prescribed or predetermined time period, the host controller then issues a second event (e.g., 416) on the interface at third time (e.g., timestamp 424) occurring after the second time (e.g., timestamp 420) as shown at block 706.
Method 700 further includes processes shown at block 708 including receiving a first sensor clock count (e.g., SC1) and a second sensor clock count (e.g., SC2) from the sensor, where the first sensor clock count is a count of cycles of an internal sensor clock from the first time to the second time and the second sensor clock count is a count of cycles of the internal sensor clock from the second time to the third time.
As shown at block 710, method 700 further includes determining within the host controller the timestamp of the interface event (e.g., MTS) corresponding to the first time (i.e., the time of the sensor sample 404 in the sensor) based at least in part on the first count of cycles of a host controller clock (MC1), the first sensor clock count (SC1), the second sensor clock count (SC2), and a host controller timestamp of the second time (MREF). As discussed above, the relationship of equation (3) may be utilized to determine the timestamp of the interface event (i.e., MTS) in terms of the host controller's clock or timer based on a reference timestamp at the first event (MREF) in terms of the host controller clock or timer, and the received counts SC1 and SC2 from the sensor. In another alternative, it is also contemplated that the individual counts SC2 and SC2 would not necessarily need to be received by the host controller. Instead, the sensor may be configured to transmit the ratio SC1/SC2 assuming that the sensor possesses arithmetic processing resources to be able to first calculate the ratio.
According to other aspects of method 700, the host controller and the sensor are communicatively coupled via an I2C, an I3C, an SPI, an SMBus, a SLIMbus, a UART, a SoundWire bus, or a wireless interface as well. Additionally as discussed before, each of the first and second events will comprise a predetermined hardware event that is mutually known to both the host controller and the sensor.
According to further aspects, method 700 may also include the received first sensor clock count and second sensor clock count comprising reduced count number values that are reduced by a common factor such that a ratio of the first sensor clock count and the second sensor clock count remains constant regardless of the value of the common factor, as was discussed previously with respect to
After the message is sent according to the process of block 804, the sensor will continue to count the cycles of its internal clock or time at then determine a first count of the sensor clock cycles between the time of the sensor event and a detected first interface event issued by the host controller as indicated at block 806. According to an example, this first count is count SC1, as discussed above. After the detection of the first interface event, the sensor will commence determining a second count of sensor clock cycles between the time of the first interface event and a second interface event issued by the host controller as shown in block 808. According to an example, this second count is count SC2 as discussed above. Finally at block 810, the sensor transmits information indicative of the first and second counts to the controller. As discussed above, in an aspect this information may include messaging from the sensor to the host controller providing the values of counts SC1 and SC2. In another alternative, it is contemplated a value indicative of the ratio of the counts SC1 and SC2 could be provided by the sensor to host controller.
With regard to another embodiment of the present disclosure for reducing timestamp overhead,
It is further noted here that the information used by host controller to indicate the Delay Time period may indicate that the delay period is expressed in approximate 1/n periods of time units of the T_Ph period, where n is the number 2 to some predetermined power. The delay time is measured and transferred using the fractional 1/n units of T_Ph as a measuring unit, which allows truncation of the amount of information needed to be transmitted to communicate the delay time. Accordingly, the delay time can be expressed as a number of such measuring units. Based on the timing of the synchronization message and the information indicative of the Delay Time periods, the sensors/slaves may then determine the expected beginning of new T_Ph periods. As a numerical example, if T_Ph is one (1) second and n=211, this means that the measuring unit is one (1) second divided by 2 to the power of 11 (i.e., 211=2048). The time measuring unit 1/n is, in this particular case, 1 sec/2048, which equals 488 microseconds s). Hence, if the real delay time was 4 milliseconds (ms), for example, then the DT could be expressed by the number 8 as 4 ms/488 μs≈8. Thus, the DT message from the host controller will communicate the number 8 to the sensor/slave. In turn, the sensor/slave can reconstruct the DT based on its own counter/timer that it uses for counting 1 second. If the sensor/slave has a 2 MHz based counter, for example, its total count of cycles for one second is 2,000,000. For the sensor, one DT unit would be 2,000,000/2048=976 counter/timer cycles. The 8 time units communicated by DT message then translates for the sensor/slave's timer to be 976×8=7808 counter/timer cycles of the 2 MHz sensor base clock. Consequently, the sensor/slave will then deduct or subtract 7808 counter/timer cycles from the timestamp that the sensor/slave has recorded for the synchronizing event as indicated by ST, for example. The new number of sensor/slave's cycles is then the correct duration of the T_Ph and will be used for the expected beginning of a next T_Ph period.
In an embodiment, the host controller may determine the sensor sample data measurement time without the sensors transmitting the timestamps, thus reducing timestamp overhead in a system synchronizing controllers and sensors and the additional energy consumed due to the transmission of timestamps. As the first transmission of the sensor sample data 904 within a T_Ph period lags behind the corresponding time of measurement by a Delay Time period as a result of the sensors synchronizing their clocks based on both the ST edges/messages and Delay Time information (e.g., measurements are perfectly aligned with the T_Ph periods, while the actual transmissions may be affected by the Delay Time period), the time of measurement may be determined based on the starting time of the present T_Ph period, the Delay Time period, and the location of the transmission within the sequence of transmissions within the same T_Ph period. As the sample data measurements and transmissions are spaced equally in time as shown by equal time periods 910 (also these periods may be thought of as differences between the sensor data transmission time positions on the timeline) as merely two examples, linear interpolation may be used to determine the data measurement time based on the location of the transmission within the sequence of transmissions within the same T_Ph period, such as those shown in
Referring to
The host controller 1102 also may include a memory or storage medium 1112 coupled with at least the processing circuitry 1104 and include code or instructions for causing the circuitry 1104 to implement or direct the transmitter/receiver circuit 1106 to implement the various methodologies disclosed herein, such as those disclosed in connection with
In another aspect, the host controller 1102 may include a register or some other counter 1114 that performs some or all of the functions of effecting the methods as disclosed in
The transmitter/receiver circuitry 1206 also includes a register or counter 1209 that is used for counting cycles or pulses of the timer/clock circuit 1208 (e.g., pulses 410 shown in
Further, the transmitter/receiver circuitry 1206 also include a transport medium interfacing circuit 1210 configured to interface or communicatively couple the transmitter/receiver circuitry with the physical transport medium interface, which may an I2C or I3C bus or a wireless interface as just a few examples. Furthermore, the transport medium interface may employ at least two lines such as an SDA line and SCL line, but could include further lines as discussed earlier with respect to interface 217 in
The sensor 1202 also may include a memory or storage medium 1212 coupled with at least the processing circuitry 1204 and include code or instructions for causing the circuitry 1204 to implement or direct the transmitter/receiver circuit 1206 to implement the various methodologies disclosed herein, such as those disclosed in connection with
It should be appreciated that aspects of the invention previously described may be implemented in conjunction with the execution of instructions (e.g., applications) by processor 101 of computing device 100, host controller 205, sensor 210, host controller or master 1102, and slave or sensor device 1202 as previously described. Particularly, circuitry of the device, including but not limited to processor, may operate under the control of an application, program, routine, or the execution of instructions to execute methods or processes in accordance with embodiments of the invention (e.g., the processes illustrated by
The processor 1304 is responsible for general processing, including the execution of software/instructions stored on the computer-readable storage medium 1314. The software/instructions, when executed by the processor 1304, causes the processing circuit 1302 to perform the various functions described before for any particular apparatus. The computer or processor readable storage medium 1314 may also be used for storing data that is manipulated by the processor 1304 when executing software, including data decoded from symbols transmitted over the connectors or wires 1310 or antenna 1312. The processing circuit 1302 further includes at least one of the modules/circuits 1308, which may be software modules running in the processor 1304, resident/stored in the computer-readable storage medium 1314, one or more hardware modules coupled to the processor 1304, or some combination thereof. The modules/circuits 1308 may include microcontroller instructions, state machine configuration parameters, or some combination thereof.
In one configuration, the processor readable medium 1314 includes instructions for detecting an interface event, which are configured to cause the processor 1304 to perform various functions including the processes illustrated in block 702 of
The processor 1404 is responsible for general processing, including the execution of software/instructions stored on the computer-readable storage medium 1414. The software/instructions, when executed by the processor 1404, causes the processing circuit 1402 to perform the various functions described before for any particular apparatus. The computer or processor readable storage medium 1414 may also be used for storing data that is manipulated by the processor 1404 when executing software, including data decoded from symbols transmitted over the connectors or wires 1410 or antenna 1412. The processing circuit 1402 further includes at least one of the modules/circuits 1408, which may be software modules running in the processor 1304, resident/stored in the computer-readable storage medium 1414, one or more hardware modules coupled to the processor 1404, or some combination thereof. The modules/circuits 1408 may include microcontroller instructions, state machine configuration parameters, or some combination thereof.
In one configuration, the processor readable medium 1414 includes instructions for determining a beginning of the T_Ph period, which are configured to cause the processor 1404 to perform various functions including the processes illustrated in block 1002 of
Additionally the messages and events disclosed herein may be sent across many different types of interfaces and the methodology disclosed herein is not limited to any one type of interface. In a further aspect the methodology may be used on several or multiple interfaces as well as multiple interface protocols where several sensors may be synchronized against the internal time base of the host controller. It is also noted that the HW events discussed herein may be any number of known events. As an example of a HW event, the Sync Tick message (ST) itself may constitute the agreed upon event in an SPI transport, where the ST message only take 1 microsecond of time altogether, which would be sufficiently short for a synchronizing event. Other examples of HW events may be edges of the pulses on the transport medium. Some HW events may have a supplementary characteristic, such as being the last edge of a defined set of pulses. In wireless systems, the starting of communications on the wireless interface may constitute a HW event. In another example for wireless interfaces, the HW events may be communicated and through the use of special or dedicated communications or communication channels particular to various known wireless protocols.
Methods described herein may be implemented in conjunction with various wireless communication networks such as a wireless wide area network (WWAN), a wireless local area network (WLAN), a wireless personal area network (WPAN), and so on. The term “network” and “system” are often used interchangeably. A WWAN may be a Code Division Multiple Access (CDMA) network, a Time Division Multiple Access (TDMA) network, a Frequency Division Multiple Access (FDMA) network, an Orthogonal Frequency Division Multiple Access (OFDMA) network, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) network, and so on. A CDMA network may implement one or more radio access technologies (RATs) such as cdma2000, Wideband-CDMA (W-CDMA), and so on. Cdma2000 includes IS-95, IS-2000, and IS-856 standards. A TDMA network may implement Global System for Mobile Communications (GSM), Digital Advanced Mobile Phone System (D-AMPS), or some other RAT. GSM and W-CDMA are described in documents from a consortium named “3rd Generation Partnership Project” (3GPP). Cdma2000 is described in documents from a consortium named “3rd Generation Partnership Project 2” (3GPP2). 3GPP and 3GPP2 documents are publicly available. A WLAN may be an IEEE 802.11x network, and a WPAN may be a Bluetooth network, an IEEE 802.15x, or some other type of network. The techniques may also be implemented in conjunction with any combination of WWAN, WLAN and/or WPAN. It should also be appreciated that although embodiments of the disclosure may be described in relation to interfaces/buses such as I2C, and I3C, the methods and apparatus are not limited to use with only these interfaces, and may be used with other interfaces such as SPI, SLIMbus, UART, SoundWire, etc.
Example methods, apparatus, or articles of manufacture presented herein may be implemented, in whole or in part, for use in or with mobile communication devices. As used herein, “mobile device,” “mobile communication device,” “hand-held device,” “tablets,” etc., or the plural form of such terms may be used interchangeably and may refer to any kind of special purpose computing platform or device that may communicate through wireless transmission or receipt of information over suitable communications networks according to one or more communication protocols, and that may from time to time have a position or location that changes. As a way of illustration, special purpose mobile communication devices, may include, for example, cellular telephones, satellite telephones, smart telephones, heat map or radio map generation tools or devices, observed signal parameter generation tools or devices, personal digital assistants (PDAs), laptop computers, personal entertainment systems, e-book readers, tablet personal computers (PC), personal audio or video devices, personal navigation units, or the like. It should be appreciated, however, that these are merely illustrative examples relating to mobile devices that may be utilized to facilitate or support one or more processes or operations described herein.
The methodologies described herein may be implemented in different ways and with different configurations depending upon the particular application. For example, such methodologies may be implemented in hardware, firmware, and/or combinations thereof, along with software. In a hardware implementation, for example, a processing unit may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, electronic devices, other devices units designed to perform the functions described herein, and/or combinations thereof.
The herein described memory or storage media may comprise primary, secondary, and/or tertiary storage media. Primary storage media may include memory such as random access memory and/or read-only memory, for example. Secondary storage media may include mass storage such as a magnetic or solid state hard drive. Tertiary storage media may include removable storage media such as a magnetic or optical disk, a magnetic tape, a solid state storage device, etc. In certain implementations, the storage media or portions thereof may be operatively receptive of, or otherwise configurable to couple to, other components of a computing platform, such as a processor.
In at least some implementations, one or more portions of the herein described storage media may store signals representative of data and/or information as expressed by a particular state of the storage media. For example, an electronic signal representative of data and/or information may be “stored” in a portion of the storage media (e.g., memory) by affecting or changing the state of such portions of the storage media to represent data and/or information as binary information (e.g., ones and zeroes). As such, in a particular implementation, such a change of state of the portion of the storage media to store a signal representative of data and/or information constitutes a transformation of storage media to a different state or thing.
In the preceding detailed description, numerous specific details have been set forth to provide a thorough understanding of claimed subject matter. However, it will be understood by those skilled in the art that claimed subject matter may be practiced without these specific details. In other instances, methods and apparatuses that would be known by one of ordinary skill have not been described in detail so as not to obscure claimed subject matter.
Some portions of the preceding detailed description have been presented in terms of algorithms or symbolic representations of operations on binary digital electronic signals stored within a memory of a specific apparatus or special purpose computing device or platform. In the context of this particular specification, the term specific apparatus or the like includes a general purpose computer once it is programmed to perform particular functions pursuant to instructions from program software. Algorithmic descriptions or symbolic representations are examples of techniques used by those of ordinary skill in the signal processing or related arts to convey the substance of their work to others skilled in the art. An algorithm here, and generally, is considered to be a self-consistent sequence of operations or similar signal processing leading to a desired result. In this context, operations or processing involves physical manipulation of physical quantities. Typically, although not necessarily, such quantities may take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared or otherwise manipulated as electronic signals representing information. It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, data, values, elements, symbols, characters, terms, numbers, numerals, information, or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels.
Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout this specification discussions utilizing terms such as “processing,” “computing,” “calculating,”, “identifying”, “determining”, “establishing”, “obtaining”, and/or the like refer to actions or processes of a specific apparatus, such as a special purpose computer or a similar special purpose electronic computing device. In the context of this specification, therefore, a special purpose computer or a similar special purpose electronic computing device is capable of manipulating or transforming signals, typically represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device. In the context of this particular patent application, the term “specific apparatus” may include a general purpose computer once it is programmed to perform particular functions pursuant to instructions from program software.
Reference throughout this specification to “one example”, “an example”, “certain examples”, or “exemplary implementation” means that a particular feature, structure, or characteristic described in connection with the feature and/or example may be included in at least one feature and/or example of claimed subject matter. Thus, the appearances of the phrase “in one example”, “an example”, “in certain examples” or “in some implementations” or other like phrases in various places throughout this specification are not necessarily all referring to the same feature, example, and/or limitation. Furthermore, the particular features, structures, or characteristics may be combined in one or more examples and/or features.
While there has been illustrated and described what are presently considered to be example features, it will be understood by those skilled in the art that various other modifications may be made, and equivalents may be substituted, without departing from claimed subject matter. Additionally, many modifications may be made to adapt a particular situation to the teachings of claimed subject matter without departing from the central concept described herein. Therefore, it is intended that claimed subject matter not be limited to the particular examples disclosed, but that such claimed subject matter may also include all aspects falling within the scope of appended claims, and equivalents thereof.
It is understood that the specific order or hierarchy of steps in the processes disclosed is merely an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
Those of skill in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
The present application for patent is a Continuation in Part of U.S. patent application Ser. No. 15/251,757 entitled “SYSTEM AND METHODS OF REDUCING ENERGY CONSUMPTION BY SYNCHRONIZING SENSORS” filed Aug. 30, 2016, pending, and assigned to the assignee hereof and hereby expressly incorporated by reference herein, which claimed priority to U.S. patent application Ser. No. 14/304,699, now U.S. Pat. No. 9,436,214, which in turn claimed the benefit of priority of U.S. provisional patent application No. 61/903,243 filed on Nov. 12, 2013. The present application for patent claims the benefit of U.S. Provisional Application No. 62/245,914 entitled “CORRECTION OF SYNC TICK IN A SYSTEM SYNCHRONIZING CONTROLLER AND SENSORS” filed Oct. 23, 2015, U.S. Provisional Application No. 62/245,917 entitled “ACHIEVING ACCEPTABLE CONTROL FOR THE RANGE OF SENSOR CLOCK TIMING IN A SYSTEM SYNCHRONIZING CONTROLLER AND SENSORS” filed Oct. 23, 2015, U.S. Provisional Application No. 62/245,922 entitled “REDUCTION OF TIME STAMP OVERHEAD IN A SYSTEM SYNCHRONIZING CONTROLLER AND SENSORS” filed Oct. 23, 2015, and U.S. Provisional Application No. 62/245,924 entitled “TIMESTAMP FOR ASYNCHRONOUS EVENT” filed Oct. 23, 2015, all of which are assigned to the assignee hereof and hereby expressly incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61903243 | Nov 2013 | US | |
| 62245922 | Oct 2015 | US | |
| 62245924 | Oct 2015 | US | |
| 62245914 | Oct 2015 | US | |
| 62245917 | Oct 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14304699 | Jun 2014 | US |
| Child | 15251757 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15251757 | Aug 2016 | US |
| Child | 15299408 | US |
