Beebee Chiang
| Picture | Part Number | Manufacturer | Stock | Action |
|---|---|---|---|---|
 | LSM6DSO32TR | STMicroelectronics | 3,810 | |
 | LSM6DSV16XTR | STMicroelectronics | 3,570 |
No. In the supplied external-clock relationship, actual ODR is the nominal setting multiplied by the reference frequency divided by 32,000 Hz. A 32.768 kHz reference therefore produces 1,024 samples per second from the nominal 1 kHz setting.
No. It can improve control of the timebase, but gyro bias, scale factor, noise, alignment, filtering and sample handling remain separate error sources. The worked integration example isolates interval error and is not a complete accuracy prediction.
The pin has selectable INT2, FSYNC and CLKIN functions. Allocate its intended function during schematic design and check the corresponding register configuration. A frequency reference and a synchronization event serve different purposes.
No. Their interpretation depends on clock configuration and TMST_RES. External-clock modes use the documented frequency-dependent conversion or clock-period units. Match the conversion and rollover handling to the field actually read.
Category: ComponentSelection&Alternatives
Author: Beebee Chiang
ICM-42688-P deserves a closer look when an inertial measurement system needs a controlled sampling timebase, not simply a high output data rate. Its external clock input can tie sensor timing to a chosen reference, but the clock frequency also scales the actual ODR. A nominal 1 kHz setting becomes 1.024 kHz with a 32.768 kHz clock. Selection and firmware therefore have to agree on clock frequency, timestamps, filtering and sample handling before the feature improves the system.
A processor can read an IMU rapidly without knowing exactly when each measurement was taken. That distinction matters in a robot estimating orientation, a stabilization loop responding to motion, or a logger aligning inertial samples with another data stream. Bus transactions have their own timing. Sensor conversion, digital filtering and FIFO storage have another. A high bus frequency does not make those timelines identical.
An external sensor clock is useful when control over the sampling timebase addresses a measurable requirement. Perhaps integration error is dominated by uncertainty in sample intervals. Perhaps multiple data streams need a common frequency reference. Perhaps the system must retain predictable timing over temperature. In each case, the clock feature earns its place through a defined requirement and a verification method. Choosing it merely because the datasheet advertises a high ODR misses that reasoning.
This article uses the supplied DS-000347, Revision 1.6, dated June 20, 2021, including its electrical tables, signal path, FIFO descriptions and register map. The current TDK product page lists a Revision 1.9 datasheet, but that download was not retrievable during this review. Consequently, the register discussion below is a traceable explanation of the supplied revision, not a claim that Revision 1.6 is the latest release. Retrieve and reconcile the current document before freezing production firmware. .
No. Filter group delay, FIFO servicing and host processing also affect latency. Select useful bandwidth and acceptable delay together, then verify the complete path rather than comparing maximum ODR alone.
They are scoped to the supplied DS-000347 Revision 1.6. The current official page lists Revision 1.9, whose PDF was not retrievable during this review. Reconcile the current document before freezing production firmware.
The useful decision is still clear from the adopted document: ICM-42688-P combines a six-axis sensor with an external clock option, configurable filtering and timestamped FIFO data. Those features form a timing chain. None can be evaluated properly in isolation from the others.
Table 1: Device identity and the boundaries of the timing decision
| Item | Supplied ICM-42688-P information | Selection consequence |
|---|---|---|
| Measurement functions | Three-axis gyroscope and three-axis accelerometer | Define separate range, bandwidth and sample requirements for each sensor |
| Package | 14-terminal LGA, 2.5 × 3.0 × 0.91 mm | Shared package dimensions do not establish another sensor's pin compatibility |
| Supplies | VDD and VDDIO from 1.71 to 3.6 V | Clock and host logic must satisfy the actual I/O supply conditions |
| Operating temperature | −40 to +85 °C | Evaluate the reference clock and the complete signal path over the required range |
| External clock input | 31 to 50 kHz on the shared INT2/FSYNC/CLKIN pin | Allocate the pin and calculate actual sampling rates before layout |
| Highest listed ODR | Up to 32 kHz, subject to sensor and mode restrictions | Maximum ODR alone does not specify useful bandwidth or end-to-end latency |
The electrical and digital details deserve equal weight. The document gives typical low-noise gyro performance of 2.8 mdps/√Hz at the stated frequency and conditions. That number does not make the integrated angle equally accurate under all motion, temperature or mounting conditions. A more stable sample interval can remove one source of error while leaving bias, scale factor, vibration response and alignment unchanged.
The supplied datasheet defines an external-clock relationship that is easy to overlook: actual ODR equals the nominal ODR selected in the register multiplied by the external clock frequency divided by 32,000 Hz. A clock that is accurate at 32.768 kHz is therefore not interchangeable, in software arithmetic, with a 32.000 kHz reference.
For a nominal 500 Hz selection, a 32.000 kHz reference yields 500 Hz, whereas 32.768 kHz yields 512 Hz. At a nominal 1 kHz selection, the corresponding rates are 1,000 and 1,024 samples per second. The 2.4% difference is intentional scaling, not a sensor defect. It persists even if the external oscillator has excellent frequency tolerance.
Table 2: Illustrative ODR scaling from the supplied clock relationship
| Register's nominal ODR | Assumed external reference | Calculated actual ODR | Calculated sample interval |
|---|---|---|---|
| 500 Hz | 32.000 kHz | 500 Hz | 2,000 µs |
| 500 Hz | 32.768 kHz | 512 Hz | 1,953.125 µs |
| 1,000 Hz | 32.000 kHz | 1,000 Hz | 1,000 µs |
| 1,000 Hz | 32.768 kHz | 1,024 Hz | 976.5625 µs |
| 1,000 Hz | 50.000 kHz | 1,562.5 Hz | 640 µs |
These are calculations using nominal reference frequencies and the documented scaling law. They are not measured frequencies, oscillator tolerance guarantees or approval of a particular board clock. The last row illustrates the arithmetic at the stated external-input upper frequency; other mode and system constraints still require review.
Consider an idealized rate signal of 90 degrees per second over one second. Assume the nominal ODR setting is 1 kHz and the external reference is exactly 32.768 kHz. The actual sample rate is then 1,024 Hz. With the correct interval of 1/1,024 second, the accumulated angle is 90 degrees.
If firmware instead multiplies all 1,024 samples by 1/1,000 second, it reports 92.16 degrees. The resulting 2.16-degree error comes entirely from the wrong time interval in this deliberately simplified example. No sensor bias, noise, scale-factor error or lost sample is included. Increasing ODR without fixing the interval would not remove the underlying mistake.
Now suppose the chosen reference has an illustrative 50 ppm frequency error. Over one second that corresponds to about 50 microseconds of timebase error. At the same ideal rate, the associated angle contribution is about 0.0045 degree. This arithmetic explains why reference quality can matter, but 50 ppm is an assumed oscillator property here, not a guaranteed standalone specification of the IMU or the finished system.
The internal-clock specifications also need careful reading. The electrical table and the explanatory clock section use different conditions and figures. The former gives initial and temperature-related tolerances for internal modes; the latter discusses representative improvement with an external reference. Do not compress those passages into one universal internal-clock error number, or advertise the external example as the total orientation accuracy.
Figure 1: An external reference affects the sampling and timestamp interpretation chain. This original editorial diagram describes relationships; it is not a measured timing trace.
The external clock does not arrive on an otherwise unused pin. Pin 9 is shared among INT2, FSYNC and CLKIN. Selecting CLKIN changes what that terminal can do for the application. A schematic that simultaneously labels it as an external sampling clock and an independent frame synchronization input has left a real resource conflict unresolved.
FSYNC and CLKIN address different needs. A synchronization event can mark an association with an external event, while a clock controls the sensor's timing reference. Neither should be casually described as guaranteeing simultaneous physical measurements across unrelated devices. The system still needs a definition of phase, event capture, filter delay and the time assigned to each output sample.
INT1 remains a separate interrupt resource, but that does not make interrupt planning trivial. Decide whether the host will respond to data-ready, a FIFO watermark or another enabled event. Then check pulse width, polarity, latching behavior and the processor's wake-up capability. At high sample rates, a host that occasionally misses an interrupt can still recover through a correctly managed FIFO; a host that confuses interrupt time with measurement time creates a different problem.
The supplied timing table allows an external input from 31 to 50 kHz and specifies clock high time and edge timing under stated electrical conditions. Route and drive the input as a clock signal that must meet those conditions at the sensor. The nominal oscillator frequency alone cannot prove compliance. Supply sequencing, amplitude at the selected VDDIO, edge integrity and behavior during host sleep all belong in the review.
It is also worth deciding what happens when the reference disappears. The supplied material should not be treated as a guarantee of seamless failover for every configuration. If the product can gate, switch or lose its reference, reproduce that state deliberately and define how firmware detects invalid timing, stops integration and restores a known configuration. Avoid building a safety or navigation assumption on an undocumented transition.
Two sensors driven from a common frequency reference can still attach their samples to different phases or apply different filter delays. The shared clock removes one source of relative frequency drift; it does not by itself prove that a particular accelerometer sample and a particular external image frame describe the same instant. Define what the application means by synchronization before choosing the wiring.
For a logger, the requirement may be that timestamps can be transformed into one timeline after capture. For a feedback controller, the age of the newest usable measurement may matter more. For sensor fusion, a known and stable delay can sometimes be compensated, whereas an unobserved, variable delay is harder to handle. These are different acceptance tests even when the same oscillator feeds the board.
Keep clock frequency tolerance separate from short-term timing variation. A long capture can establish average packet rate, but it may conceal occasional service delays or packet loss. A short trace can reveal edge quality and interrupt behavior while being too brief to measure small frequency error. Use both kinds of evidence and state the observation interval. A smooth plot of processed orientation alone is not a sufficient timing test.
In the supplied Revision 1.6 register map, the pin function and the clock mode are configured separately. PIN9_FUNCTION appears in INTF_CONFIG5 in bank 1, address 0x7B. The CLKIN function uses the documented field value of binary 10. RTC_MODE is a separate field in bank 0 at address 0x4D. The bank distinction is part of the operation, not a formatting detail.
That address also contains other configuration fields. A whole-byte write chosen only to set RTC_MODE can inadvertently alter clock selection or another setting. A driver should preserve the intended values of unrelated bits and verify the result through readback where appropriate. Example hexadecimal bytes copied from an unrelated project are weak evidence unless their complete field meanings and device revision have been checked.
The clock-selection field has its own internal-source behavior, including a recommended selection that uses the gyro PLL when available and otherwise the RC oscillator. It should not be confused with selecting the external function of pin 9. Treat the device's clock configuration as a small state machine with explicit preconditions, rather than as one bit that makes every timing result accurate.
Configuration changes also interact with sensor operating state. The supplied instructions distinguish changes permitted during operation from those that require the sensor to be turned off. They specify a delay after moving from OFF to ON and a minimum gyro ON period. Reset, startup settling and the time at which data becomes meaningful are related but different intervals. Preserve those distinctions in the initialization routine and its test plan.
For production software, keep a human-readable configuration record beside the driver: adopted datasheet revision, bank, address, field, intended value, rationale and readback result. This makes the current Revision 1.9 reconciliation a bounded engineering task. It also makes a later regression easier to isolate than a long list of unexplained register writes.
A FIFO timestamp is useful only after the host knows its units. In this device, external-clock operation and TMST_RES change the interpretation. A raw increment is not automatically one microsecond in every configuration. Using the right ODR with the wrong timestamp conversion simply moves the timing error to another part of the driver.
For the external-clock configuration described in the supplied document, TMST_RES set to zero uses the raw value multiplied by 32.768 divided by the external frequency expressed in kilohertz to obtain microseconds. With a 32.000 kHz reference, the factor is 1.024. With a 32.768 kHz reference, the factor is one. These conversions must remain linked to the actual reference selected in hardware.
With TMST_RES set to one, the raw value represents periods of the external reference. Thirty-two counts correspond to 1,000 microseconds at 32.000 kHz and 976.5625 microseconds at 32.768 kHz. Both descriptions can represent the same sample timeline when interpreted correctly. Neither permits firmware to assume that every timestamp count is one microsecond.
Table 3: Timestamp interpretation in the adopted document
| Clock configuration | Resolution selection | Conversion principle | Main firmware check |
|---|---|---|---|
| External clock enabled | TMST_RES = 0 | Raw value × 32.768 / reference frequency in kHz gives microseconds | Use the fitted reference frequency, not an assumed 32 kHz constant |
| External clock enabled | TMST_RES = 1 | Raw value × external clock period | Keep units explicit before accumulating elapsed time |
| Internal clock configuration | TMST_RES = 0 | Supplied document applies a 32/30 microsecond conversion factor | Do not reuse the external-clock conversion blindly |
| Internal clock configuration | TMST_RES = 1 | Supplied document applies 16 × 32/30 microseconds per count | Revisit both scaling and rollover handling |
| Delta timestamps selected | TMST_DELTA_EN enabled | Timestamp represents time since the previous ODR event | Distinguish interval data from an absolute running counter |
The FIFO timestamp field and the full timestamp register path also have different widths and access rules. Code that extends a counter across rollover must use the width of the field it actually reads. A 16-bit FIFO field should not inherit rollover assumptions from the 20-bit timestamp registers. Test the boundary explicitly, including any long pause that could span more than one wrap.
A useful validation record contains the raw timestamp bytes, decoded header, conversion mode, clock frequency and resulting interval. Keep that raw record while bringing up the driver. If only the final floating-point time is logged, it becomes much harder to distinguish a byte-order problem from a mode error, missing packet or incorrect scale factor.
A maintainable driver should expose enough configuration information for the application to interpret its samples. At minimum, retain the selected sensor modes, nominal ODR codes, external reference frequency, timestamp resolution and conversion scale. If an application receives only three angular-rate numbers and an undocumented nominal interval, later clock changes can silently invalidate its integration.
Decide how configuration changes become visible to downstream processing. One defensible approach is to stop accumulation, drain or discard data according to a defined policy, apply the new configuration through the documented sequence, and restart with a new timing record. That is an engineering workflow to validate, not a manufacturer-prescribed universal routine. The essential requirement is that samples from two timing configurations cannot be combined as though their intervals were identical.
The same record helps diagnose field logs. An apparent motion discontinuity near a power transition may be a valid sensor response, stale data, a lost packet or a timestamp conversion change. Capturing configuration identity with the data lets engineers test those explanations without reconstructing the entire firmware history from memory.
ODR determines how frequently output samples are produced. Filter bandwidth determines which motion and noise components are retained. Group delay describes part of the timing relationship between input motion and filtered output. Host servicing adds further delay. A purchasing comparison that reduces all four to a single kilohertz figure is likely to select the wrong tradeoff.
For example, the supplied first-order filter table at a nominal 1 kHz ODR lists approximately 227.2 Hz bandwidth and 1.8 ms DC group delay for one bandwidth code. A narrower setting lists approximately 23.9 Hz and 8.1 ms. Those are documented filter characteristics for the stated settings, not measured end-to-end delay on an application board. They show why a sensor delivering frequent samples can still respond slowly to relevant motion.
Choose bandwidth from the useful motion spectrum, aliasing risk and acceptable delay. Then choose a supported operating mode and ODR that allow that filter choice. Low-power and low-noise operation do not expose identical ranges or signal-processing behavior. The notch and anti-alias filters described in the device are associated with low-noise operation; their availability should not be silently transferred to every power mode.
The high-resolution FIFO format deserves the same scrutiny. The advertised 20-bit packet representation contains 19 useful gyro bits and 18 useful accelerometer bits under the specified format, with lower bits fixed accordingly. The supplied document ties that format to the ±2,000 dps gyro and ±16 g accelerometer ranges. A narrow full-scale register setting does not automatically yield a high-resolution FIFO record with the same narrow-range conversion.
At an actual 1,024 samples per second, a 20-byte combined packet produces 20,480 bytes per second before bus overhead. A 16-byte packet produces 16,384 bytes per second. These are illustrative payload calculations, not complete bus-utilization figures. Commands, headers, arbitration, other devices and processor scheduling consume additional resources. The nominal 2 KB FIFO should not be treated as an unlimited cure for a host that cannot keep up.
FIFO parsing must also handle invalid or repeated information during startup, mismatched sensor rates and mode changes according to the configuration. Reading a data register twice does not prove that two independent conversions occurred. Similarly, a packet containing both sensor fields does not establish that both fields were freshly generated at the same rate. Header interpretation and a clear invalid-sample policy belong beside the numerical conversion.
Figure 2: A staged validation sequence separates clock configuration, packet decoding, interval arithmetic and motion performance. No completed hardware test is implied.
A useful alternative list includes devices that challenge the selection, not four ordering suffixes of the same sensor. The following models were checked against manufacturer product or orderable records. They represent different routes through the range, architecture and timing decision. The table does not establish pin, register or software compatibility.
Table 4: Four distinct comparison candidates
| Exact model | Evidence-backed reason to compare it | What must be resolved before substitution |
|---|---|---|
| ICM-42686-P | TDK lists an external RTC input and wider ±4,000 dps / ±32 g ranges | Confirm noise, range conversion, clock behavior and register differences for the required mode |
| ICM-42605 | A distinct TDK six-axis IMU; the supplied family comparison distinguishes its timing features from ICM-42688-P | Do not assume the same external-clock capability merely because the family name is similar |
| LSM6DSO32TR | ST lists a six-axis device with accelerometer ranges extending to ±32 g and an exact orderable record | Review synchronization semantics, FIFO format, pin mapping and driver architecture independently |
| LSM6DSV16XTR | ST identifies a device with separate processing channels and embedded motion-processing functions | Decide whether its processing architecture addresses the application better than the selected clock feature |
Sources: TDK ICM-42686-P, TDK ICM-42605, ST LSM6DSO32, and ST LSM6DSV16XTR.
Start the comparison with a short requirement sentence. For a high-dynamic-range application, saturation may be more damaging than a modest difference in timebase control. For a low-bandwidth orientation logger, firmware simplicity and calibrated bias behavior may carry more weight than maximum ODR. For synchronized acquisition, the exact relationship among clock, event input and timestamp may be decisive.
Then compare the complete implementation cost. An external reference occupies board area, draws current and introduces a signal that must remain valid in relevant power states. A different sensor architecture may reduce host processing while requiring a new driver or a different calibration strategy. None of those consequences appears in a one-line ODR comparison.
Keep procurement evidence separate from engineering evidence. A manufacturer product record establishes an identifiable model and its documented characteristics; it does not establish stock, authorized shipment provenance or an approved replacement on a particular assembly. Use the full orderable code in the bill of materials and retain the qualification record for any change.
Bring-up should begin with a stationary, reproducible configuration and raw logging. Confirm the identity response, supply levels, configured bank and relevant register fields. The supplied WHO_AM_I value of 0x47 is a device identity response; it is not the I²C bus address. Mixing those concepts can consume debugging time before any timing question is reached.
Measure the external reference at the device and compare packet production with the calculated actual ODR. A counter or capture instrument that shares the same imperfect timebase as the source cannot independently prove its absolute accuracy. For relative synchronization it may still be useful, but the test report should say which property was measured.
Table 5: Evidence to collect before accepting the clock advantage
| Verification stage | Evidence to retain | Failure it helps distinguish |
|---|---|---|
| Electrical bring-up | Supply levels and CLKIN frequency, amplitude and edges at the sensor | A nominally correct source that violates input conditions |
| Configuration | Datasheet revision, bank/address/field record and readbacks | Wrong bank, whole-byte overwrite or incomplete initialization |
| Sampling | Packet counts against an independent elapsed-time reference | Nominal-versus-actual ODR confusion or dropped data |
| Timestamp decoding | Raw bytes, field width, resolution mode and converted intervals | Wrong units, byte order or rollover extension |
| Motion validation | Known motion profile, filter settings and error decomposition | Timing improvement being confused with bias or filter-delay improvement |
| Power-state recovery | Reset, sleep, reference interruption and restart captures | Stale configuration or invalid data accepted after a transition |
After the raw path is credible, introduce known motion and compare results with the timing model. Run at least two supported clock or ODR configurations that should produce predictable interval changes. If the reconstructed angle changes by the same ratio as the clock scaling, inspect the integration interval before blaming the sensor's noise performance.
Finally, repeat the relevant checks across the product's temperature and operating states. An accurate room-temperature oscillator and a correct desktop calculation are valuable starting points, but they do not establish behavior during sleep, bus congestion or power recovery. The strongest reason to choose ICM-42688-P is that its clock feature solves a verified timing requirement with a driver that preserves that benefit. The practical next step is to reconcile the latest datasheet, fix the timebase contract in firmware and test the entire chain from reference edge to integrated result.