AWR2944PEVM: Custom UDP Payload Formatting, Host-Side API Compatibility, GPIO_28 Sync-In & DCA1000 Role

Part Number: AWR2944PEVM
Other Parts Discussed in Thread: AWR2944P, AWR2243BOOST, AWR2243

Tool/software:

Hey,

Using mmWave SDK on the AWR2944P DSP, we first run FFT, CFAR and angle-estimation on the DSP itself. How can we then define a custom UDP payload format over Ethernet so that the Jetson receives exactly our processed data? For example, I need to package each detected target’s [range, Doppler, angle] triplet (12 bytes) plus a user-defined 4 byte timestamp, instead of the default point-cloud TLV. What API calls or cfg files control that?

Does the AWR2944P use the same host-side mmWave Link (TLV-based) API as the AWR2243BOOST? Are there any changes in function names, parameters, or supported TLV types that I should be aware of when moving my Jetson code from the 2243 to the 2944?

On the AWR2944P EVM, we couldn’t find a dedicated SYNC-IN pin. GPIO_28 is tied to the on-board button (SW1). Can we remove SW1 and wire an external trigger cable into GPIO_28 for multi-chip synchronization? We currently drive a 3.3 V pulse from a Jetson into the AWR2243BOOST successfully and need the same setup on the AWR2944P.

Does the programming we do on the AWR2944P EVM survive powercycling? so we dont need to load a .cfg each time we restart the board.

The final question is just a observation i noticed in the AWR2944Ps user guide, I saw in a picture that the AWR2944P had a DCA1000 connected, does this serve any purpose? Since the AWR2944P EVM has it's own ethernet port and can send the UDP packets to a external processor by itself.

//Emil

  • Hi Emil,

    How can we then define a custom UDP payload format over Ethernet so that the Jetson receives exactly our processed data? For example, I need to package each detected target’s [range, Doppler, angle] triplet (12 bytes) plus a user-defined 4 byte timestamp, instead of the default point-cloud TLV. What API calls or cfg files control that?

    AWR2x44P SDK demo supports transmitting point cloud over ethernet using TCP protocol and LwIP stack. There is no readily available solution to transmit the point cloud using UDP. You can refer to scatter gather example - C:\ti\mmwave_mcuplus_sdk_04_07_01_03\mcu_plus_sdk_awr2x44p_10_01_00_04\examples\networking\enet_tx_scatter_gather and modify it based on your usecase.

    Does the AWR2944P use the same host-side mmWave Link (TLV-based) API as the AWR2243BOOST? Are there any changes in function names, parameters, or supported TLV types that I should be aware of when moving my Jetson code from the 2243 to the 2944?

    Firstly, mmwavelink runs on MSS or DSS of AWR2x44P. You have a separate DFP for AWR2x44P/AWR294x. Since AWR2243 is a front end only device, a host processor is needed to configure the device. For AWR2x44P, you can configure the Radar front-end from MSS or DSS using mmwavelink APIs. 

    On the AWR2944P EVM, we couldn’t find a dedicated SYNC-IN pin. GPIO_28 is tied to the on-board button (SW1). Can we remove SW1 and wire an external trigger cable into GPIO_28 for multi-chip synchronization? We currently drive a 3.3 V pulse from a Jetson into the AWR2243BOOST successfully and need the same setup on the AWR2944P.

    May I know what kind of synchronization are you looking for? Since AWR2243 has a cascading capability, there is a dedicated SYNC_IN pin.

    Does the programming we do on the AWR2944P EVM survive powercycling? so we dont need to load a .cfg each time we restart the board.

    Data won't be retained once you power cycle. You can bypass the CLI so that you don't need to load the configuration everytime over UART. 

    Follow the steps given below to bypass the CLI -

    • Navigate to C:\ti\mmwave_mcuplus_sdk_<ver>\mmwave_mcuplus_sdk_<ver>\ti\utils\cli\src\cli.c
    • Uncomment CLI_BYPASS macro
    • Rebuild cli library
    • And rebuild the demo application

    You can update the configuration in cli.c file based on your requirement.

    The final question is just a observation i noticed in the AWR2944Ps user guide, I saw in a picture that the AWR2944P had a DCA1000 connected, does this serve any purpose? Since the AWR2944P EVM has it's own ethernet port and can send the UDP packets to a external processor by itself.

    DCA1000 is used to capture data transmitter over LVDS lanes. You cannot perform real-time processing using the data captured by DCA1000. 

    Regards,

    Samhitha

  • Hey Samhitha,

    May I know what kind of synchronization are you looking for? Since AWR2243 has a cascading capability, there is a dedicated SYNC_IN pin.

    We need hardware frame-start trigger synchronization, so we can start multiple AWR2944Ps at the same time with a digital pulse.

  • Hi Emil,

    Below is a screenshot from AWR2944P/AWR2E44P/AWR2944-ECO/AWR2E44-ECO/AWR2944LC/AWR2E44LC Single-Chip 76 to 81GHz FMCW Automotive Radar Sensor datasheet (Rev. A) regarding SYNC_IN pin -

    When you configure the frames, you can use Hardware SYNC_IN based triggering.

    You can check section Sub block 0x0102 – AWR_FRAME_CONF_SET_SB of "C:\ti\mmwave_mcuplus_sdk_04_07_01_03\mmwave_dfp_02_04_18_00\docs\mmWave-Radar-Interface-Control.pdf".

    Regards,

    Samhitha