SEN0628 8×8 mode limited to ~5 Hz over I²C on Raspberry Pi, despite advertised 15 Hz update rate

Hello,

 

I’m integrating the DFRobot SEN0628 8×8 Matrix ToF 3D Distance Sensor into a Raspberry Pi 5 robot running Ubuntu 24.04 and ROS 2 Jazzy.

 

Hardware and firmware

 Sensor: DFRobot SEN0628Sensor IC: VL53L7CXOnboard MCU: RP2040Firmware: SEN0628-V1.3-20250904.uf2Host: Raspberry PiInterface: I²C bus 1Selected address: 0x33Matrix mode: 8×8I²C bus speed: normally 100 kHz Only the SEN0628 is present on this I²C bus

The sensor works and produces believable 64-zone depth matrices. However, I am having difficulty achieving the documented update rate reliably over I²C.

 

Current I²C performance

 

Our ROS driver is configured to request five frames per second.

Measured results:

Requested rateActual complete ROS matrices

5 Hz	approximately 4.63 Hz
8 Hz	approximately 4.38 Hz
10 Hz	approximately 5.03 Hz
15 Hz	sensor initialization/response timeout during the test

This indicates a practical ceiling of approximately five complete 8×8 matrices per second over the current I²C protocol.

 

The DFRobot product information lists a ranging update rate of 15–60 Hz. We assume 15 Hz applies to 8×8 mode and the higher rate may apply to 4×4 mode. Is that correct?

 

Protocol implementation

 

We are using the command protocol found in DFRobot’s reference library:

Request: 0x55, argument_length_high, argument_length_low, command, arguments... Response: status, command, payload_length_low, payload_length_high, payload...

 

Commands used:

 

1 = set matrix mode 2 = get all matrix data

A valid 8×8 response contains 128 payload bytes representing 64 little-endian uint16 distances.

 

We validate the response command, length, full payload, and every distance before publishing a matrix.

 

Earlier reliability problems

 

At the original 100 kHz I²C speed, a longer test produced:

561 attempts 528 accepted frames 33 final errors 5.9% error rate

 

Representative errors included:

 

sensor response timed out implausible response length 32896 response command 130 does not match command 2 response command 129 does not match command 2 8x8 frame must contain 128 bytes, received 192

 

Recurring corrupted values included:

 

32896 = 0x8080 129   = 0x81 130   = 0x82

 

These looked like distance payload bytes being interpreted as response-header bytes, possibly because the RP2040 response stream or FIFO had become misaligned.

 

Reducing the bus speed produced:

I²C speedResult

100 kHz	5.9% final frame errors
50 kHz	2.45% final frame errors
25 kHz	throughput became unusably slow

We subsequently added bounded retries and stream resynchronization. Reliability is now much better. A recent 20-second test accepted 91 of 91 matrices with no final errors, although five transactions required internal retries.

 

The remaining problem is throughput: requesting more than 5 Hz does not produce more than approximately 5 Hz.

 

Official Python example

 

DFRobot’s Raspberry Pi Python example can continuously display matrices, proving that the sensor and basic electrical connection work. However, we observed occasional values greater than the documented 4000 mm maximum, including values such as 34720 and 36768.

Our production driver therefore validates and normalizes every cell.

 

Questions

What is the expected maximum full-matrix rate for 8×8 mode over I²C? Is 15 Hz achievable through the documented get all data command, or does 15 Hz require UART/USB continuous streaming? What I²C bus speed does DFRobot recommend for obtaining 15 Hz? Does the RP2040 support clock stretching or require any delay between: Sending command 2Reading the response headerReading the 128-byte payload? Should one I²C transaction retrieve the complete response, or must it be read one byte/block at a time? Is there an official description of the RP2040 response FIFO and how the host should resynchronize after a partial or timed-out response? Is command 2 queued if the previous response has not been completely consumed? Is there a data-ready register, interrupt, frame counter, or status command that should be used instead of repeatedly polling command 2? Does firmware V1.3 contain any known I²C timing or response-stream issues? Does the 15 Hz specification refer to the VL53L7CX’s internal ranging rate, the RP2040 output rate, or the rate available to an external host? For USB output, is 115200 baud with DTR enabled required for the SEN0628 V1.3 firmware? Is the exact USB/UART framing format documented, including line terminators, matrix order, checksums, and any frame counter?

 

Additional observations

 

The depth data itself is useful. We have successfully produced:

 An 8×8 depth displayA ROS PointCloud2Forward obstacle detectionExperimental floor and cliff detection

 

The bottom matrix rows correctly observe the floor. At the edge of a staircase, those rows show a substantial increase in distance or loss of the expected floor return. This agrees with DFRobot’s Maqueen Plus V3 cliff-detection example.

 

Our main goal is to obtain the highest reliable 8×8 update rate without publishing partial, stale, or misaligned matrices.

 

Any official protocol timing information, known-good Raspberry Pi code capable of 15 Hz, or clarification of the advertised update rate would be greatly appreciated.

 

Thanks

 

Nate