The sensor responds, but some readings are wrong. Your developer lowers the SPI clock and the numbers look better. That is useful progress. Before calling the interface ready for a user trial, though, ask what changed, and which timing requirements the assembled prototype now meets.
An Analog Devices support question from September 14, 2022 describes exactly this uncertainty. ADE7953 readings improved when the author reduced the SPI rate from 5 MHz to 400 kHz, but some remained incorrect. The replies asked for further evidence, including signal captures and checks against a static register. The first improvement did not, by itself, identify the cause.
For a team integrating a sensor into a display or logger, the useful next step is to compare the actual transaction with the device's requirements. Three manufacturers' timing references, for an Intel Arria 10 SPI interface, the ADE7953 and the Murata SCA61T, show why "below the maximum frequency" is only one part of that comparison.
Read the timing picture as a set of appointments
SPI sends data alongside a clock. At a specified clock edge, the receiver takes a sample. The data needs to have settled before that instant and to stay stable afterwards. Those two intervals are setup time and hold time. If a signal changes too close to the sample, the receiver may not reliably capture the intended bit.
There are appointments at the transaction boundaries too. Chip select tells the peripheral when a transfer is active. A device may require time after selection before the first clock, time after the last clock before release, and a pause before the next transfer. These intervals have different jobs; adding a delay in one place does not necessarily satisfy a requirement in another.
The Arria 10 SPI timing table groups these requirements with clock period, duty cycle, output delay and the gap between frames. Its setup expression also depends on a configured receive-sample delay. Use it to recognize the kinds of timing questions to ask, not as a list of numbers for a Pico or another peripheral.
Check the command boundaries as well as the clock rate
The ADE7953 makes the distinction concrete. Its Rev. C datasheet lists a 200 ns minimum clock period and separate 80 ns minimum high and low pulse widths. It also lists input setup and hold intervals of 70 ns and 5 ns. Check the table's operating conditions and its footnote on typical, minimum and maximum values before applying them.
One special case is easy to miss: when writing the COMM_LOCK bit, CS must stay low for at least 1.2 microseconds after the last SCLK edge. That interval comes before CS rises. It is not an instruction to insert the same pause after every transfer, and slowing the clock alone does not explicitly implement this end-of-command requirement.
Other parts have their own boundary rules. Some serial memories, for example, need a fresh chip-select transaction after a write-enable command before the write itself. The practical point carries over: successful bit shifting is not the same as a correctly bounded command.
Ask for the timing diagram and command sequence for the actual fitted device and revision, and keep them beside the driver configuration. Mode, bit order, command length and chip-select behavior need to agree with the peripheral before a speed experiment becomes meaningful.
A gap between transfers is another setting
The SCA61T adds an interval that a clock-frequency setting does not describe: how long CSB stays high between transactions. The Murata Rev. A2 datasheet lists 15 microseconds in general, but 150 microseconds for the RDAX, RDAY and RWTR commands. It separately specifies clock high and low times of at least 1 microsecond each, under the stated load conditions.
This is why a driver can use an apparently conservative clock and still issue transactions too close together. The application may also need enough time for a new measurement to become available. Reading the same valid register repeatedly is not evidence that the sensor produced a new sample each time.
Electrical compatibility comes first. The SCA61T input table specifies a minimum high level of 4 V, so the part is not a candidate for direct connection to 3.3 V GPIO without further design work. These three devices are timing examples, not interchangeable modules; keep that boundary when borrowing an example for a new board.
Turn "slower seems better" into a useful test
Record a repeatable failing operation before changing several things at once. Where the device provides a suitable read-only identification or fixed-value register, compare that read with the changing measurement data. If a configurable register is used instead, choose and restore it deliberately according to its documentation. Avoid writing arbitrary test values into a register that controls the measurement.
Capture clock, select and data together for the failing transaction. A protocol decoder helps inspect bytes and command boundaries; the electrical waveform is needed to investigate edge shape and timing at the receiving device. Record where the signals were probed and the capture settings, so a later reviewer can tell the device's behavior from the instrument's interpretation.
Capture completeness matters too. A Saleae discussion with a September 25, 2026 follow-up reports gaps in digital captures during instrument evaluation. It concerns a particular tool workflow, not proof that your SPI hardware is faulty. Check that the recording includes the transaction you intend to diagnose before explaining a missing decoded byte as a missing device response.
Decide what the next prototype must demonstrate
A reduced rate can be a valid final choice if it meets the product's response needs and the complete interface satisfies its requirements. The work is to establish that result, not to maximize the MHz number. Repeat the relevant operations with the intended board connections and other features active, and document the conditions and errors observed.
Before a small batch, ask for:
- the selected clock and SPI mode;
- the device-specific select and spacing rules, and where the driver implements them;
- evidence from the assembled arrangement, including a capture of a passing transaction.
If changing the wiring, firmware or interface circuit was necessary, keep the before-and-after captures. That gives the team a reason for the fix and a test to repeat on later revisions. We report no new timing measurement here; the figures above come from the manufacturers' documents.