This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR1843BOOST: ADCBUFCFG: IQ swap selection

Part Number: AWR1843BOOST
Other Parts Discussed in Thread: AWR1843, AWR1642, MMWAVE-SDK, AWR1443

Hello, 

I'm going through the "mmwave_sdk_03_01_00_02" for AWR1843 and observed that the ADC buffer configuration, "MmwDemo_ADCBufCfg::iqSwapSel", is configured with 1 from mmWave visualizer.

But for AWR1642, this value is 0. The same has been noticed in the "mmwave_sdk_user_guide.pdf" in the docs folder.

Why is this change suggested? Is it because of hardware accelerator?

What is the format supported by hardware accelerator?

Is it possible to change the I/Q format for hardware accelerator?

Thanks,

Chidvilas

  • Hi Chidvilas,
    Can you confirm if visualizer is sending CLI command having 'adcbufCfg:SampleSwap' set to 1?
    As SDK supports only value '0' for this parameter.

    Regards,
    Jitendra
  • Hi Jitendra,

    PFA the screenshot of pdf and the config file generated with the mmwave visualizer.

    Thanks,

    Chidvilas

    % ***************************************************************
    % Created for SDK ver:03.01
    % Created using Visualizer ver:3.1.0.1
    % Frequency:77
    % Platform:xWR18xx
    % Scene Classifier:best_range_res
    % Azimuth Resolution(deg):15
    % Range Resolution(m):0.044
    % Maximum unambiguous Range(m):9.02
    % Maximum Radial Velocity(m/s):1
    % Radial velocity resolution(m/s):0.13
    % Frame Duration(msec):100
    % Range Detection Threshold (dB):15
    % Doppler Detection Threshold (dB):15
    % Range Peak Grouping:enabled
    % Doppler Peak Grouping:enabled
    % Static clutter removal:disabled
    % Angle of Arrival FoV: Full FoV
    % Range FoV: Full FoV
    % Doppler FoV: Full FoV
    % ***************************************************************
    sensorStop
    flushCfg
    dfeDataOutputMode 1
    channelCfg 15 5 0
    adcCfg 2 1
    adcbufCfg -1 0 1 1 1
    profileCfg 0 77 429 7 57.14 0 0 70 1 256 5209 0 0 30
    chirpCfg 0 0 0 0 0 0 0 1
    chirpCfg 1 1 0 0 0 0 0 4
    frameCfg 0 1 16 0 100 1 0
    lowPower 0 0
    guiMonitor -1 1 1 0 0 0 1
    cfarCfg -1 0 0 8 4 4 0 1280 1
    cfarCfg -1 1 0 4 2 3 1 1280 1
    multiObjBeamForming -1 1 0.5
    clutterRemoval -1 0
    calibDcRangeSig -1 0 -5 8 256
    compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
    measureRangeBiasAndRxChanPhase 0 1.5 0.2
    aoaFovCfg -1 -90 90 -90 90
    cfarFovCfg -1 0 0 8.92
    cfarFovCfg -1 1 -1 1.00
    sensorStart

  • Hi,

    BTW my target device is AWR1843, I'm trying to port code from AWR1642 to AWR1843.

    Can you please provide an update?

    Thanks,

    Chidvilas

  • Hello Chidvilas,

    The OOB demo in MMWAVE-SDK for the AWR1843 illustrates the use of both the DSP and the HWA in the demo.
    For the ease of implementation only the swapsel:1 is supported.


    BR,
    Raghu
  • Hello Raghu,

    Thanks for info.

    In HWA params configurations, only the macro "HWA_SAMPLES_FORMAT_COMPLEX" is seen, this only configures whether the sample is real or complex.

    But is it possible to configure HWA to configure for i/q swap?
    What is the format supported by HWA?

    Thanks,
    Chidvilas
  • Can you provide any update on this?

    Thanks,

    Chidvilas

  • Hi

    The input to the HWA is I/Q. This is dedcribed in the Input Formatter section in UG

    Thank you

    Cesar

  • > BTW my target device is AWR1843, I'm trying to port code from AWR1642 to AWR1843.

    Porting from AWR1642 to AWR1843 can be a rather complex task, since the internal data formats are different. Most importantly, the radar cube for AWR1642 is what SDK 3.x calls DPIF Format 1, but most of the HWA examples/demos use the original AWR1443 code, which is DPIF Format 2. This impacts everything. If you are using SDK 3.x DPUs and can select DPIF Format 1 it will help. If this is not possible, it will be easier to start with SDK 3.x code, and pull in the pieces of the AWR1642 demo that you need, making doubly sure that your inputs/outputs are in a compatible format.

    -dave