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: IRW6843 single shot mode for the radars for device synchronization

Part Number: IWR6843AOP

Hi, 

Our system requires synchronization between multiple radars and a master device. We are currently interested in implementing a single-shot mechanism, i.e., when the radar receives a command from the master, it will perform a scan, and then return the result to the master. How do we implement this feature using the mmWave library? We have tried the MMWave_stop () and MMWave_start (&startCfg) APIs, and they take way too much time and thus are feasible. 

Alternatively, is there any other mechanism we can do to synchronize multiple radars with a master device? The radars are using one single communication line, so they will need to be synced to avoid conflicts. 


Many thanks,

Po-Chih Chen



  • Hi,

    Thank you for your patience over the holiday. We will be able to give a response on Tuesday when work resumes. Thank you!

    Best,

    Nate

  • Hi Po-Chih Chen,

    Is it possible to share a bit more information about your application? You mention MMWave_stop and MMWave_start  APIs take too much time. What latency is acceptable for your application?

    Alternatively, is there any other mechanism we can do to synchronize multiple radars with a master device?

    Another possibility would be to try to use the hardware trigger mode in which the radar can be configured to begin chirping upon detecting the rising edge of a pulse on the SYNC_IN pin. However, I would warn you that this feature is not directly supported by the SDK, we do not have any examples which show this and there has been very little to no testing done from our side. There are several E2E posts which discuss this topic that may help you out if you wish to try to use this. I have linked some below.

    Best Regards,

    Josh

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1029352/iwr6843aop-how-can-multiple-iwr6843aop-radar-sensors-be-used-at-the-same-time-to-record-data-with-time-synchronization

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1130150/iwr6843aopevm-daisy-chaining-multiple-radars-through-sync_in-sync_out 

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1182017/iwr6843-synchronization-between-multiple-radar-board 

  • Hi Josh, thank you for your reply!

    We would like to attach multiple (4 to be specific) radars around our system for a larger field of view. We are using IWR6843AOP on customized PCB boards, and the four sensors will be connected to our system using one shared RS485 channel, meaning they need to avoid the timing of data transfer to avoid conflicts. This can also avoid the interference of the chirping, so we think it is ideal. 

    I think the hardware trigger mode can be really helpful, we will investigate it. Just wondering if this can be achieved using a software approach. For example, can we trigger the chirping using the firmware? By doing so we can trigger the chirping when the device receives a command.

    Thanks a lot!

    Best wishes,
    Po-Chih Chen

  • Hi Po-Chih Chen, 

    No problem! I'm looking into if there is another software based approach for this which is faster than MMWave_start() / MMWave_stop(). Please allow me an additional day to investigate this and get back to you with a response. 

    Best Regards,

    Josh

  • Hi Josh,

    I wonder if it is possible to use the GPIO of the 6843 itself (either on MSSro DSS) to trigger the SYNC_IN? If this is possible, then by controlling the GPIO we can achieve a software triggering. (of course, we will have to customize the PCB board)

    Another issue is that although there are many people discussing the Hardware-triggering mode, I found that the user's guide for the mmwaveSDK (3.6.0 LTS) says that only software triggering mode is supported (p. 24 in frameCfg): 




    Before we move forward, I would like to check if this is just a mistake in the SDK user's guide or if the IWR6843AOP doesn't actually support this feature.

    Thanks in advance.
    Po-Chih Chen

  • Hi Po-Chih Chen, 

    Using the GPIO for this should be possible but I don't believe that is something that we have tested. With the AOP EVM + MMWAVEICBOOST the SYNC_IN pin should be accessible via the headers on the ICBOOST.  

     

    I would like to check if this is just a mistake in the SDK user's guide

    I'm inquiring internally about the purpose for the note in the user's guide. You can expect an answer tomorrow. 

    Best Regards,

    Josh

  • Hi Josh,

    I have tried to use ICBOOST to test out this function. Here's the setup:

    1. Move the 0 ohm from R346 to R348 position to allow access to the SYNC_IN pin
    2. Change the frameCfg to "frameCfg 0 2 32 1 100 2 0" (1 for one frame and 2 for the hardware trigger) 
    3. I trigger the SYNC_IN pin using a GPIO

    However, the sensor doesn't function at all. Are there any requirements for the trigger pulse? I would like to know where can I find some more details about the hardware trigger because there it's not mentioned in the SDK User's Guide.


    Best Regards,
    Po-Chih Chen






  • Hi, 

    Please refer to the Interface Control Document. Table 5.26 and the notes below the table provide some timing information.

    Best Regards,

    Josh

  • Hi Po-Chih,

    I wanted to give you an update since I got a response about the note in the SDK on software trigger being the only supported option. This note was included because the HW trigger mode was not tested within the context of the SDK. A use case such as this was not considered, typically the HW trigger is more suited in the cascade configuration which is connected in the daisy chain mode and secondary devices are triggered via the Sync_In pulse of the primary device and so on.. 

    If you have no further questions I will close this thread. Please do not hesitate to create another post if additional questions come up. 

    Regards,

    Josh