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.

MCU-PLUS-SDK-AM273X: Cascade waveform configuration idletime cannot be configured arbitrarily (only with very small values)

Part Number: MCU-PLUS-SDK-AM273X

Hello,

Debugging background: The cascading data acquisition demo comes from SDK4412 in DDM mode, and the data volume should not change due to the increase in the number of transmitting antennas. A self-made cascading board is designed according to the official website schematic diagram.
We encountered an issue with the waveform configuration when debugging the data acquisition program,
When both of our radar antennas are transmitting (6 rounds), the pulse interval time can only be set to a very short time, which is basically 8us or less,
For example, 3us, but we would like to freely configure this time, such as 65us and other times, as follows. However, in this case, we do not have any data sent from LVDS.
This issue also exists when debugging the cascaded software package applied for. When the waveform configuration idleTime is relatively large, it will quickly hang up after the radar is started.
A single radar has 3 transmitters, while the other does not transmit, allowing for a large idle time and data acquisition.
May I ask, what is the possible reason for this question? Is there a similar issue with the official cascading board data collection debugging? Have you ever tried a higher value for idle time?
Static gap Mmwave_ PopulateDefaultProfileCfg (rlProfileCfg_t * ptrProfileCfg)
{
/*Initialize configuration file configuration:*/
Memset ((void *) ptrProfileCfg, 0, sizeof (rlProfileCfg_t));
/*Fill in * default * configuration file configuration:*/
PtrProfileCfg ->profileId=0;
PtrProfileCfg ->startFreqConst=START_ FREQ_ VAL// 80G
PtrProfileCfg ->idleTimeConst=65 * 1000/10;
PtrProfileCfg ->adcStartTimeConst=5 * 1000/10;
PtrProfileCfg ->rampEndTime=60 * 1000/10;
PtrProfileCfg ->txOutPowerBackoffCode=0;
PtrProfileCfg ->txPhaseShift=0;
PtrProfileCfg ->freqSlopeConst=FREQ_ SLOPE_ VAL// 2Mhz/us
PtrProfileCfg ->txStartTime=1 * 1000/10;
PtrProfileCfg ->numAdcSamples=256;
PtrProfileCfg ->digOutSampleRate=20000;
PtrProfileCfg ->hpfCornerFreq1=0;
PtrProfileCfg ->hpfCornerFreq2=0;
PtrProfileCfg ->rxGain=52;
}

Regards,

Gary

  • Hi Gary,

    • What is the frame periodicity in your capture when having a 65 us interchirp delay?
    • The cascade test application does not imply DDM with perchirp phase shift. Can you let me know if you have added something?
    • Personally, I have not used a delay of 65us on the 2-chip board that is available but I can't think of any reason why it won't work (at first glance). Can you confirm if all the mmwavelink APIs were configured properly without returning any errors?
    • When you say there is no data sent from the LVDS, can you at least confirm if the chirp interrupt or CSI callback is hit on the device when debugging?
    • Are you seeing any issue with the default capture application when running it on your device? Is idle time the only change required to get to your observed failure?

    Regards,

    Kaushik

  • Hello,

    rlRfPhaseShiftCfg_t phaseShifChirpCfgDev1[NUM_OF_PHASE_SHIFT_CHIRPS] =
    {
    {
    .chirpStartIdx = 0,
    .chirpEndIdx = 0,
    .tx0PhaseShift = 0,
    .tx1PhaseShift = (56 << 2),
    .tx2PhaseShift = (48 << 2),
    .reserved = 0
    }
    };

    rlRfPhaseShiftCfg_t phaseShifChirpCfgDev2[NUM_OF_PHASE_SHIFT_CHIRPS] =
    {
    {
    .chirpStartIdx = 0,
    .chirpEndIdx = 0,
    .tx0PhaseShift = (40 << 2),
    .tx1PhaseShift = (32 << 2),
    .tx2PhaseShift = (24 << 2),
    .reserved = 0
    }
    };

    This is the phase shift configuration parameter

    Regards,

    Gary

  • Hi Gary,

    Can you please confirm if the issue comes up only with this change or happens in the default test as well?

    Also, kindly provide more details based on the questions asked in the previous reply for me to understand the issue better :)

    Regards,

    Kaushik

  • Hello,

    yes, because the default test idletime=7us, and we need a larger idle time, this problem of no data output will occur when only modifying the idle time based on the default test.

    The debugging situation is as I described earlier. When we follow the lvdsdemo provided by the sdk, we only modify the idletime to a value exceeding 8us. When both AWR2243s send 3 times, there is no data output, CSI EOL no longer calls back, and chirpcount No more increases.

    I hope you can actually test it to see if this problem also exists, and look forward to your reply.

    Regards,

    Gary

  • Hi Gary,

    Thank you for your feedback. I will try to reproduce the reported problem, investigate the same and get back to you in some time.

    Regards,

    Kaushik

  • Hello,

    Any progress?

    Regards,

    Gary

  • Hi Gary,

    Please give me time till Friday to comment on this.

    Regards,

    Kaushik

  • Hello,

    OK,Thanks

    Regards,

    Gary