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.

IWR6843ISK: Radar Firmware

Part Number: IWR6843ISK

Hi Team,

Is there any way to stop the radar module, without issuing a "sensorStop" radar command from the host machine?

Thanks,

Balaji S

  • Hi Balaji,

    The rlSensorStop API, part of the mmwavelink library, can be used to stop the radar. Documentation for this API can be found at: <SDK_INSTALL>/packages/ti/control/mmwavelink/docs/doxygen/html/index.html. 

    Best Regards,

    Josh

  • Hi Josh,

    Thank you for your response.

    But, isn't this rlSensorStop API need to be called from the host machine?

    Instead of issuing "sensorStop" command or calling the rlSensorStop API from the host, The radar firmware should stop the radar module after streaming the number of frames configured in "frameCfg" command.

    Is it possible to stop the radar module from the firmware after streaming the number of frames?

  • Hi Balaji,

    Is it possible to stop the radar module from the firmware after streaming the number of frames?

    Yes, this is possible. As you have mentioned, the number of frames is configurable in the frameCfg command. Please see the mmWave SDK User Guide for more information.

    Best Regards,

    Josh

  • Hi Josh,

    Thanks for the suggestion.

    We tried the same, But while issuing the next "sensorStart" radar command. we got the ACK "Ignored: Sensor is already started" from the radar.

    The radar firmware is expecting a "sensorStop" command, before issuing the next "sensorStart".

    Could you help us in stopping the radar module from the firmware after streaming the configured number of frames?

    When triggering (sensorStart) the radar it should stream the data and stop(sensorStop) from the firmware.

    So, in the next trigger, we don't need to give "sensorStop" command, Will directly give "sensorStart 0" command.

  • Hi,

    I apologize for the delayed response. I wanted to let you know that I am investigating this and will respond here with an update by tomorrow at the latest.

    Best Regards,

    Josh

  • Hello,

    I'd like to once again offer my apologies for the delayed response. Once the number of frames specified in frameCfg is reached then the device stops chirping and subsequently the data path is stopped as well; however, the sensor state is not updated as is the case when issuing the "sensorStop". This is the reason that you are unable to do sensorStart without first doing sensorStop even though the sensor is already "stopped". 

    Typically, the number of frames parameter in frameCfg is used for testing/debugging purposes and so this use case was likely not envisioned. You can look into adding code to update the sensor state (similar to how its done when the sensorStop command is issued) once the event message is received which says the BSS is stopped (RL_RF_AE_FRAME_END_SB). 

    Regards,

    Josh

  • Hi Josh,

    Thank you very much for your suggestion, it was really helpful in debugging the issue.

    We tried it by changing the state inside the async call-back function.

    However, when the next start command "sensor start 0" is issued, it fails on the MwDemo_dataPathStart function(Invoked from MwDemo_startSensor Function).

    Code Change: State Changes from sensor start to sensor stop inside the MmwDemo_eventCallbackFxn in main.c

    Command and ACK from radar in the logic analyzer for the second radar trigger ("sensorStart 0")

    Exception Throws:

    Could you please assist us in debugging and resolving this issue?

  • Hi Josh,

    We tried to debug further by printing the error number in DPM_Start  and attached the image for reference.

    The error code received from the radar is -4201 and its corresponding error message is "MMWAVE_ERRNO_DPM_BASE - DPM_EINVAL(Invalid Argument)"

    Whether the invalid argument pointing to the DPM handle or anything else?

    Could you assist us in debugging this issue?

    Thanks,

    Balaji 

  • Hi Balaji,

    I believe there are a couple checks that can throw that error. Are you able to use breakpoints to determine exactly which check is failing?

    Regards,

    Josh

  • Hi Josh,

    We tested further.

    It is failing inside the DPM_start, thus there are two possibilities for failure.

        1. Handle issue (NULL)

        2.  Profile is an invalid state (ptrDPM->procChainStatus & DPM_PROC_CHAIN_STATUS_STARTED)

    We tested by checking the handle whether NULL or not, inside the MwDemo_dataPathStart function.

    However, the handle is not NULL. Then the issue is due to the second scenario.

    Could you please help us in debugging and resolve the issue?

  • Hi Balaji, 

    Are you still facing this issue? I suspect that when the configured number of frames is reached then DPM_stop() is not called like it is when sending sensorStop. This means that the value for ptrDPM->procChainStatus is never updated and thus DPM_start() fails.

    Regards,

    Josh

  • Hi Josh,

    Yes, we are still trying to figure out and resolve the issue.

    Is there any other way to use the sensorStop API to stop the radar module from the firmware?

  • Hi Balaji,

    It is a holiday in the US until January 3rd. Expect delayed responses until then. Thank you.

    Best,

    Nate

  • Hi Josh,

    Any suggestion from your end for this requirement?

  • Hi,

    Are you using the DPM_stop() API when the number of frames is reached? I believe this function updates the value for ptrDPM->procChainStatus which might resolve your issue with DPM_start() failing.

    Best Regards,

    Josh

  • Hi Josh,

    I'm hoping, it will be taken care of by the MmwDemo eventCallbackFxn.

    Because we have one registered event function to mmwave which is invoked when we received an event((RL_RF_AE_FRAME_END_SB) from the BSS.

    It handles the DPM stop functionality.

    Warm Regards,

    Balaji Sridhar

  • Hi Balaji, 

    Does this achieve the functionality that you are looking for or are you still running into issues?

    Best Regards,

    Josh

  • Hi Josh,

    I'm still dealing with the same issue.

    Error: DPM errorCode -4201 


    Warm Regards,

    Balaji Sridhar

  • Hi Balaji,

    That error likely means that ptrDPM->procChainStatus is still not being updated. Can you place breakpoints in DPM_stop() to debug and check if/why this is the case?

    I believe there is another, albeit somewhat lazy, way for you to achieve the functionality that you are looking for. Instead of modifying the frame end handler, you could simply add a call to MmwDemo_CLISensorStop() at the beginning of MmwDemo_CLISensorStart() located in mmw_cli.c. You already determined that if you send sensorStop before sensorStart 0 then the device starts, this would achieve the same without the need to send sensorStop over UART.

    Best Regards,

    Josh