AWR2944EVM: Best practice for modifying the demo source code.

Tool/software:

Hi,

I'm working on the AWR2944EVM Out-of-Box demo and would like to integrate on chip STFT (and later Matching Pursuit) into the DPC. I plan to start with STFT, as it's conceptually simpler.

From my understanding, the AWR2944EVM does not internally capture complex IQ data, but rather only real ADC samples. The radar data cube reflects the classical layout, but over fast time the range FFT has already been computed. Please correct me if this is inaccurate!

In prior work with the AWR1843BOOST (which does offer IQ data), my post-processing STFT computation looked like this:

#—————— Creating slow-time sequence over which the STFT will be computed ——————
#Go over each rx to build later on the non-coherent sum
for rx_idx in range(N_rx):
    slow_time_data_rx = []

    #If the stft mode is fixed then go over set number of frames at a constant range bin
    if stft_mode == 'fixed':
        for frame_idx in range(start_frame, stop_frame):

            if adc_sampling_mode == 'complex':
                frame_data = iq_data[frame_idx, rx_idx, :, :]
            elif adc_sampling_mode == 'real':
                frame_data = i_data[frame_idx, rx_idx, :, :]

            #Let's test the behaviour of STFTs taken on windowed data, this code isn't DRY but it for demo purpose only!
            range_window = np.hanning(N_samples)
            frame_dat_win = frame_data * range_window[np.newaxis, :]

            range_fft = np.fft.fft(frame_dat_win, axis=1)
            bin_data = range_fft[:, range_bin]

While ideally unwindowed data would be used, I understand the HWA applies a window during range FFT computation, thus the radar Cube consists of already windowed data - which is alright. Now I want to implement the same functionality on chip for the AWR2944EVM. My implementation idea is as follows:

• Within the main DPC call DPC_objectDetection_execute, add - directly after formatting the radarcube with DPU_RangeProcHWA_process - a custom function called fixedSTFT_execute placed in a new classificationdpu.c file together with functions for allocating buffer spaces etc. fixedSTFT_init()
• This also requires modifying several other files than just the objectdetection.c housing the DPC_objectDetection_execute, in particular one would need to add new classification handles which in turn means modifying objectdetection.h and objectdetectioninternal.h to change the definition of the ObjDetObj struct. Apart from this it will be necessary to add new accessors ot the STFT_handle within init and deint of the objectdetection.c file.
• Then there also is the issue of shipping the results via UART etc.

I assume this approach can work, but it requires touching multiple files deep inside the DPC/DPU framework. Therefore, is there a recommended, less‑invasive way to add such functionality—perhaps via a standalone module invoked from dss_main.c or a higher‑level callback—so that I don’t have to modify the core DPU so heavily?

Best 

Mark