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.

IWR6843AOP: Importing CCS Out Box Demo project spec of IWR6843ISK and recompiling it for AOP antenna pattern

Part Number: IWR6843AOP
Other Parts Discussed in Thread: IWR6843ISK

Pedrhom Nafisi wrote:

>>So you can indeed flash ISK's binary to AOP, and then change the antenna pattern on the ISK's config file to be what AOP's is and then run it, however this will more likely than not perform poorly. This is due to the FFTs >>being done differently between AOP and ISK to optimize for FOV. You are welcome to try it, but I would also take a note of performance differences between the intended AOP binary and the ISK running on AOP one.

If the binaries for DSS & MSS are recompiled in the imported IWR6843ISK CCS project with --define=AOP switch instead of --define=ISK switch will the FFTs be done correctly for the AOP antenna pattern?

  • Hello,

    The changes needed in 6843ISK's Out of Box demo that I am referencing to would not be changed with a definition change in the projectspec. This change might adjust some target configuration and labeling, but Radar performance will stay the same with that specific change. My best advice is to try 6843ISK's out of box demo on the AOP with the proper configuration file changes to adjust antenna differences, get an idea of the performance via point cloud and other parameters you care about, and then do it again with the proper out of box demo made for AOP that only uses the MSS. If the performance change is little or you are still okay with the performance, then it is fine to use the ISK one for your project.

  • Hi Pedrhom,

    Thanks for your reply.

    1. >>My best advice is to try 6843ISK's out of box demo on the AOP with the proper configuration file changes to adjust antenna differences,
      1. 3D people counting demo has specific configuration commands (antGeometry0 & antGeometry1) to adjust for the antenna differences, but on 6843ISK's out of box demo which Configuration Command to be adjusted for the antenna difference to match that of AOP?
      2. Can you guide me or suggest modifications or changes to any of the project files of 6834ISK's out of box demo to optimise the FFTs for AOP antenna pattern?
    2. If I import the 3D people counting demo from projectspec and remove the tracker layer and utilise only the point cloud data and use the specific configuration commands (antGeometry0 & antGeometry1)  will the FFTs be done correctly for the AOP antenna pattern?
  • Hello,

    The tracker is completely independent and built on top of the main detection layer. You are free to remove or ignore it with no impact on the detection layer. The FFTs will be done properly as the People Tracking for AOP was made compatible/optimally with that device and antenna pattern. Within the 3D People Tracking folder, within the Radar Toolbox, in the TI Resource Explorer is a PDF on tuning the detection layer and the way it is done. I recommend you look at that document and use People Counting binary/project for the best point cloud performance on AOP

    Best Regards,

    Pedrhom 

  • Hi Pedrhom,

    I have tried the 3D people counting demo by removing the tracker layer. Capon 2D algorithm's processing time is quite intense, where as my application requires faster frame rates in the order of 40 to 50Hz. 

    I have tried 6843ISK just with the definition change in projectspec with ISk -> AOP. Although it performs quite well with TDM MIMO profile, but as you mentioned it gets the angles wrong with BPM MIMO profile. 6843ISK OOB is quite responsive to suit my frame rate requirements.

    Could you please guide me to the correct files in the 6843ISK project to correct the antenna configuration for AOP to get the correct FFT computation in the DSP? (Sorry that I have misinterpreted with the profile configuration file in my last reply 1.a & 1.b)

  • Hello Vithy,

    It will not be easy, but Objectdetection.c is going to be your biggest focus. If you import both 6843ISK and 6843AOP out of box demos, you will see that this is the key file that is being done on the DSP (DSS) for ISK while on AOP it is being done in MSS. I would start by comparing these two versions of objectdetection and work your way through.

    Best Regards,

    Pedrhom

  • Hi Pedrhom,

    Thanks for your guidance.

    I analysed both 'Objectdetection.c' files and identified that the antenna geometry definition being passed through the preStartConfig -> staticCfg and has made the appropriate changes by adding DPC_ObjDetDSP_GetAntGeometryDef function to the dss 'Objectdetection.c'.

    I have also had to pass the antenna geometry definition to the preStartCommonCfg.antDef in 'mss_main.c'.

    bpmCfg appears to be getting the angle correctly now. I have to do bit more testing with fine tuning the profile / chirp configuration.

    Please let me know whether I am on the right track or doing something completely wrong to what you have expected. 

  • Hello Vithy,

    You are definitely on the right track and are doing what I suggested. As we do not have an OOB for AOP that uses the DSS, I cannot say for certain about every change needed, but it will be encompassed mostly in objectdetection.c.

    Best Regards,

    Pedrhom

  • Hi Pedrhom,

    'out_of_box_6843_aop.projectspec' from radar_toolbox / industrial_toolbox specifies the switch USE_2D_AOA_DPU and hence the 'mmwdemo_rfparser.c' sets the number of azimuth & elevation antennas to 0.

    However 'out_of_box_6443.projectspec' which also uses the hardware accelerator only doesn't specify the switch USE_2D_AOA_DPU, but uses the same 'mmwdemo_rfparser.c' and sets the the number of azimuth & elevation antennas.

    Is it because there is no correct definition for the azimuth & elevation antenna masks for AOP under the section 'RF Parser platform dependent params' in the commonly used 'mmwdemo_rfparser.c' file?

    As the 6443 project uses the hardware accelerator only, if correct definitions for the azimuth & elevation antenna masks are made for AOP in the 'mmwdemo_rfparser.c' file then the switch USE_2D_AOA_DPU can be removed and there shouldn't be any hardware limitations for the 6843_aop project.

    Is this correct? Could you please confirm this as you have the OOB for AOP out_of_box_6843_aop.projectspec?

  • Hello Vithy,

    That sounds correct, but if you run into any issues or errors that you do not understand or feel stuck on, I will dig deeper.

    Best Regards,

    Pedrhom

  • Hi Pedrhom,

    Thanks, I have also identified that the aoa2dproc library (libaoa2dproc_hwa_xwr68xx.aer4f) has to be removed and aoaproc library (libaoaproc_hwa_xwr68xx.aer4f) has to be added.

    I will try and let you know. If I succeed in this then I don't have to pay much attention to the DSP (DSS) of ISK with uncertainty as I will be able to test the bpmCfg with HWA - my preferred choice for reduced latency. 

  • Hi Pedrhom,

    As you have expected, removal of the switch USE_2D_AOA_DPU worked fine with the change of 'aoa2dproc' library to 'aoaproc' library and I was getting expected point cloud data with some offset due to lack of bias compensation.

    When I analysed the differences in between aoaproc_hwa library and  aoaproc_dsp library, it became clear to me that the HWA based AOA DPU does not support BPM configuration and I will have to use the DSP (DSS) of ISK for bpmCfg with DSP.

    As I have had two comparable OOB projects with correct antenna configuration for 6843AOP with proper utilisation of azimuth and elevation antennae, I compared the point cloud data from both projects with the same setup and was able to get identical results in TDM MIMO configuration.

    When I compared the point cloud data from DSP (DSS) based project for TDM MIMO and BPM MIMO configuration I get the bias offset reduced by 40%.

    (See below the point cloud data for the object placed at 0.385)

    HWA Only
    x = -0.040 y = 0.439 z = 0.000 r = 0.441


    DSP Based
    TDM MIMO
    x = -0.040 y = 0.439 z = 0.000 r = 0.441
    BPM MIMO
    x = -0.021 y = 0.352 z = 0.000 r = 0.353

    I believe the 6843AOP antenna pattern changes have taken effect correctly and the reduction of offset bias with BMP is to be expected with improved SNR.

    What is your opinion?

  • Hi Pedrhom,

    I have done further tests and convinced that the the 6843AOP antenna pattern changes have taken effect, however I would very much appreciate your very valuable feedback, so that I can move further on with my development confidently.

    I have had an inconsistency in the profile file I copied from the SDK for the BPM configuration that used the 'compRangeBiasAndRxChanPhase' sequence for ISK antenna pattern. When I corrected it I have been getting consistent results for TDM/BPM configuration with identical setup and profile configuration.

    Pre-built binary 'out_of_box_6843_aop'.bin from radar_toolbox_1_00_00_26
    x = 0.064 y = 0.417 z = 0.026 r = 0.422

    out_of_box_6843_aop.projectspec - with switch USE_2D_AOA_DPU (a0a2dproc HWA library)
    x = 0.076 y = 0.415 z = 0.025 r = 0.422

    out_of_box_6843_aop.projectspec - without switch USE_2D_AOA_DPU (a0aproc HWA library) 
    x = -0.025 y = 0.421 z = 0.000 r = 0.422  [ z coordinate changes correctly to 0 with antDef changes taking effect]

    out_of_box_6843_isk_mss(dss).projectspec - with TDM MIMO (a0aprocdsp library) 
    x = -0.038 y = 0.420 z = 0.000 r = 0.422

    out_of_box_6843_isk_mss(dss).projectspec - with BPM MIMO (a0aprocdsp library) 
    x = -0.038 y = 0.420 z = 0.000 r = 0.422

    All project specs were imported with SDK 3.6.0.0 LTS

    Here are the summary of changes I have done. (may be useful for someone else with the same intentions)

    Imported project specs 'out_of_box_6843_aop.projectspec' and 'out_of_box_6843_isk_mss.projectspec' from radar_toolbox_1_00_00_26

    • AOP antenna changes on respective 'mmwdemo_rfparser.c' files of projects (6843_aop and 6843_isk_mss):

    // AOP Antenna Mask
    #ifdef SUBSYS_MSS
    MmwDemo_RFParserHwAttr MmwDemo_RFParserHwCfg =
    {
    SOC_ADCBUF_SIZE,
    0x1,
    0x6
    };
    #endif

    #ifdef SUBSYS_DSS
    MmwDemo_RFParserHwAttr MmwDemo_RFParserHwCfg =
    {
    SOC_ADCBUF_SIZE,
    0x1,
    0x6
    };

    • 'objectdetection.c' file changes on 6843_isk DSS project:

    Copy function 'DPC_ObjDet_GetAntGeometryDef' from 6843_aop project to 6843_isk project.

    Modify 'DPC_ObjDetDSP_AoAconfig' function with additional input parameter as a pointer to antDef (ANTDEF_AntGeometry  *antDef)

    Call function DPC_ObjDetDSP_GetAntGeometryDef(staticCfg, antDef) within the 'DPC_ObjDetDSP_AoAconfig' function on line 1594.

    Modify function call to 'DPC_ObjDetDSP_AoAconfig' to pass in antDef pointer '&commonCfg->antDef' within 'DPC_ObjDetDSP_preStartConfig'  function at line 1993.

    • To use the 6843_aop project without the switch USE_2D_AOA_DPU (i.e. 3D)

    Delink aoa2dproc hwa library (libaoa2dproc_hwa_xwr68xx.aer4f) and link aoaproc hwa library (libaoaproc_hwa_xwr68xx.aer4f).

  • Hello,

    Elaborate a little for me. The x,y,z, and r values you are giving me is of a single point? You are using out of box demo so you have cartesian coords and do not have spherical tracker/target coordinates. When you have an object you will have points sporadically populate the respective area, and it is not like it is just one point for one object right? So points slightly off from each other still are representing the same object, such as the delta I'm seeing with x = -0.025 in AOP and x = -0.038 in ISK. The other cases where the x values were farther apart aka in the positive domain, yes something was wrong there.

    If your points with AOP (out_of_box_6843_aop.projectspec without switch USE_2D_AOA_DPU (a0aproc HWA library) ) is closely matching the location when using an ISK (out_of_box_6843_isk_mss(dss).projectspec - with TDM MIMO (a0aprocdsp library) ), you should go forward with full confidence you are getting valid coordinates. You can always go back and sanity check yourself with an ISK later since it seems you have access to one. This is again territory we have not explored here at TI with making 6843AOP OOB use both MSS and DSS, but I can assure you from a results perspective that it will not be mere coincidence if all your AOP points align with ISK's, as object processing calculations that differ would cause the points to be VERY wrong/different. Especially with the differing antenna pattern between AOP and ISK

    Best Regards,

    Pedrhom Nafisi

  • Hi Pedrhom,

    Thanks for your reply.

    I have restricted the field of view with +/- 60 degrees and range to 0.75 in the CFAR configuration such that I get always get a single point in close range as per my application requirement. 

    I hope TI would pay attention and make a proper 6843AOP OOB project spec with 6843AOP antenna pattern at least in the future rather than leaving the 6843AOP with borrowed project specs from other devices.

    Thanks for your help in this matter.