• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 1712 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AWR1642: Is it possible to trigger frames externally

Lifeng Liu
Intellectual 330 points
Part Number: AWR1642
Other Parts Discussed in Thread: IWR1642, IWR1642BOOST, AWR1243

HI,

    I have a question, currently,  the radar frames are triggered by the internal radar control logic. Is it possible to trigger frames form an external source through a GPIO?

Many thanks.

  • 0
    TI__Guru*** 148954 points
    Please see HWTRIGGER in the AWR1xxx Radar Interface Control Document

    This document is included in the dfp release.

    www.ti.com/.../MMWAVE-DFP

    Thank you
    cesar
  • 0 in reply to Cesar
    TI__Expert 7215 points
    Hi Jerry,

    Please look at rlSetFrameConfig API in mmWaveLink and update below configuration.

    rlFrameCfg_t.triggerSelect = 0x0002 /* HWTRIGGER */

    Once you configure and trigger frame using rlSensorStart, Device will wait for pulse on SYNC_IN pin (P4). You can generate this pulse externally and connect to the pin mentioned.

    Please note that periodicy of these pulse should match rlFrameCfg_t.framePeriodicity. If pulse is generated earlier than the periodicity, pulse would get ignored and FMCW transmission would not happen.

    Regards,
    Kaushal
  • 0 in reply to Kaushal Kukkar
    Prodigy 160 points

    There appears to be as if conflicting information in regards the proper settings of 

    SW specified frame periodicity  frameCfg 0 1 128 1 50 2 0   (5th parameter "50") verus

    the HW pulse peridocity (SYN_IN input).

    In this thread (AWR1642) "periodicy of these pulse should match rlFrameCfg_t.framePeriodicity." (which I interpret as them required to be *equal*) while

    the next statement suggests "If pulse is generated earlier than the periodicity, pulse would get ingnored" (which I interpret framePeriodicity needs to be *less than* SYNC_IN periodicity)

    ¨'which contradict each other, in strict sense. Practically, 'equal' is impossible in asunchronous clocking systems..

    Elsewhere, the thread  https://e2e.ti.com/support/sensor/mmwave_sensors/f/1023/p/639919/2360401#2360401

    sugests "SYNC_IN needs to happen for every frame and at the same period as frame periodicity." (i.e.required to be *equal*, again!) while in the next sentence

    "..trigger this pulse ... less than frame active duration" (in which I intepret 'active duration' i.e. SW framePeriodicity must be *longer* than SYNC_IN periodicity).

    All these are mutually contradictory, assuming the functionalities are the same  in AWR1642 versus IWR1642 (whi I believe is the case).

    Anyways, none of these altenatives (*equal* *longer* *shorter* appears working, at first try.

    Could you clarify if SYNC_IN is functional, at all. If yes, which are the proper settings in AWR1642, IWR1642 (-BOOST, I deem).

  • 0 in reply to user5235784
    Intellectual 330 points
    According to my experiment, the pulse period can be longer or equal to the specified number but can not be shorter.
  • 0 in reply to Lifeng Liu
    Prodigy 160 points
    Confirmed on IWR1642BOOST.
    Works ok on external trigger pulse 3.3V 8ms in length ino J6 Pin 9.
    Elsewhere there was a query on the pulse shape on SYNC_OUT (J6 pin 18):
    no sync-related signal observed.
  • 0 in reply to user5235784
    TI__Expert 7215 points
    Hi,

    If I understand correctly, You don't seem to see SYNC_OUT signal from device?

    Can you confirm if you configure device as Master in rlSetChannelConfig API?
    rlChanCfg_t.cascading = 0x0001; /* MULTICHIP_MASTER */

    Regards,
    Kaushal
  • 0 in reply to Kaushal Kukkar
    Prodigy 160 points

    My device is AWR1642.

    SDK doxygen tells

    "cascading.... This is applicable only in AWR1243."

    Indeed, mmw application does not accept a CLI setting "channelCfg 15 3 1" which would likely imply your query "rlChanCfg_t.cascading = 0x0001; "

    Are these SW constraints outdate i.e. could AWR1642 be cascaded, in fact?

    This is not a critical issue, for time being. I am able to sync AWR1642 by using an external pulse generator.

  • 0 in reply to user5235784
    TI__Guru*** 148954 points
    Hi.

    AWR1642 should not to be cascaded.

    Closing this thread.

    If there are new questions, please start a new thread

    thank you
    Cesar