Questions on Maximizing Radar Measurement Rate (FPS) with QM35 SDK

Wireless Connectivity Ultra-Wideband
, ,
1

Hi Everyone,

I’m starting development with the QM35 SDK and have a couple of questions about optimizing the radar measurement rate.

In the QM35 DK-05 UWB Radar Protocol guide, it mentions that the performance of the Python examples is limited by the script itself:

The minimal achievable burst_period_ms is currently measured to 7 ms… The bottleneck currently comes from the Python script together with the FT4222 adapter… limited by the Python Global Interpreter Lock…

This leads to my questions:

  1. C vs. Python Performance: Based on the documentation, can I expect a significant increase in the measurement rate (i.e., a much lower burst_period_ms) by using the C Cherry API instead of the Python examples?
  2. Firmware Data Protocol: My second question is about the data transmission from the chip. I understand the firmware currently packs the raw CIR data into UCI messages. My experience with other UWB hardware (like the DWM3001CDK) has shown that sending raw, unprocessed bytes can offer higher throughput.
  • At very high speeds (e.g., nearing 1ms intervals), is the on-chip UCI packaging expected to become a bottleneck?
  • Are there any plans for a future firmware release to include a CLI build similar to QM33 that would allow developers to bypass UCI packaging for maximum performance? (Or the source file of the firmware for customization).

Thanks for your help!

2

Hi Qorvo Team,

I am reviewing the cherry_radar_session_create function in the SDK and have a few follow-up questions about its timing parameters.

Here is the function signature from the documentation for reference:

/**
 * cherry_radar_session_create() - Create and configure a Radar session.
 * @ctx: Cherry context.
 * @callback: Callback function to be call for session events.
 * @user_data: Optional pointer to data element managed by the Cherry's client.
 *             It is the pointer that will be put back as argument of radar
 *             event callback.
 * @session_id: Session identifier, any non-zero value.
 * @burst_period_ms: Interval between bursts, in milliseconds.
 * @sweep_period_rstu: Interval between sweeps inside a burst, in RSTU with
 *                     1200 RSTU equal to 1ms.
 * @sweeps_per_burst: Number of sweeps per burst.
 * @samples_per_sweep: Number of samples per sweep.
 * @antenna_set: Antenna set to use for transmit and receive path.
 *
 * This function allocates the session context which must be released using
 * cherry_radar_session_destroy(). Then it setups every needed parameters to
 * prepare the radar session.
 *
 * The sweep and burts parameters has to be consistent:
 *   @burst_period_ms >= @sweep_period_rstu/1200 * @sweeps_per_burst
 *
 * If the rule above is not respected, then the session will report an error
 * event at start.
 *
 * This function returns immediately.
 *
 * Returns: Newly allocated session or NULL on error.
 */
struct cherry_radar_session *cherry_radar_session_create(
	struct cherry *ctx, cherry_radar_cb_t callback, void *user_data,
	uint32_t session_id, uint32_t burst_period_ms,
	uint16_t sweep_period_rstu, uint8_t sweeps_per_burst,
	uint8_t samples_per_sweep, uint8_t antenna_set);

My questions are:

  1. Timing Precision: How precise is the burst_period_ms? When set to 10ms, how much jitter should be expected? Is this timing managed by a hardware timer on the QM35 chip (similar to dwt_starttx(DWT_START_TX_IMMEDIATE) in QM33 SDK), or is it dependent on RTOS scheduling, which could introduce significant jitter at high frequencies?

  2. Parameter Resolution: Since the burst_period_ms parameter is a uint32_t, does this mean the interval must be an integer number of milliseconds? Is there any way to specify fractional intervals (e.g., 10.5 ms)?

  3. Maximum Parameter Values: What are the practical maximum values for burst_period_ms and sweeps_per_burst? For example, what would prevent me from setting a very large sweeps_per_burst like 1,000 with a long burst_period_ms of 10 seconds (for an effective rate of one sweep every 10 ms)? I assume there is a limit based on the amount of on-chip memory available to buffer the CIR data for all sweeps before transmitting them as a single report. Could you clarify what this limitation is?

Any clarification on these parameters would be greatly appreciated. Thanks!