• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 342 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.

IWR1843BOOST: Unable to perform synchronization between two IWR1843's with DCA1000EVM

Bishakh Ghosh
Prodigy 100 points
Part Number: IWR1843BOOST
Other Parts Discussed in Thread: DCA1000EVM, , IWR1843

Tool/software:

I am trying to achieve synchronization between two IWR1843BOOST radars and collect raw data from one of them using the DCA1000EVM. I want to use one radar as a TX and another radar as an RX and collect data from the RX radar. To do this, I have modified and used the hw_sync_quad_sensor.launch file from the mmwave_ti_ros package on a Jetson Nano. The synchronization is working fine with the two radars without any DCA. I am following this article: https://software-dl.ti.com/jacinto7/esd/robotics-sdk/08_06_00/docs/source/docs/multi_sensor_time_synchronization.html. Additionally, I am using the DCA1000EVM CLI to collect data from the DCA while the radar is flashed with the Out-of-Box demo. My setup is shown below.

However, when I connect and power on the DCA, the synchronization signal on SYNC_IN (sent from Pin 33 on the Jetson Nano) gets corrupted, as shown in the figure below. I discovered that SYNC_IN is also connected to Pin 16 on the 60-pin HD connector, which is connected to DMM_MUX_CTL on the DCA side. Jetson and DCA are trying to drive the SYNC_IN pin, which corrupts the signal. Attached is a photo showing the corrupted signal on the oscilloscope, which would otherwise be a normal PWM signal.

According to my understanding, the DMM interface is used for the playback functionality and has no role in LVDS data streaming from the ADC, which is the target application. I want to understand why DMM_MUX_CTL is still driven even when the DCA works in the LVDS streaming mode. I looked around the documentation but could not find any way to disable it.

I discovered that Pin 16 is connected to the SYNC_IN pin using the R62 resistor.

A reply on this forum post suggests removing the R62 resistor. However, we lack the expertise for SMD desoldering, especially for such small packages. I looked at the DCA1000EVM schematic and found that DMM_MUX_CTL is connected to IO14 on the FPGA (see image below). I believe that the pin is being driven somewhere in the HDL codes. If we could disable that, the issue would be solved. However, I cannot find the HDL codes for the DCA FPGA anywhere online. 

Finally, I have these questions: 

1) Is it possible to disable the DMM interface, especially the DMM_MUX_CTL pin, using some command / uploading some configuration? 

2) Can we access the FPGA HDL codes so I can manually disable the IO14 pin? 

3) Is there any other way to sync the two radars while collecting DCA data simultaneously? Something that preferably does not involve the SYNC_IN pin? 

4) Is there any other way of collecting raw data from the IWR1843 without using the DCA? I know about the TSW1400 board + mmWave DEVPACK, but I think they are obsolete and have the DMM interface.

  • 0
    TI__Expert 4600 points

    Bishakh, 

    Thanks for your detailed set-up and questions. Before getting to the outlined question, I think it is important to look at a more fundamental mistake that is happening here. 

    You will not be able to use one radar as a TX only and the other as an RX. This is becuase the APLLs and Synths betweent he two devices (and in this case EVMs) will not be phase locked together. Additionally, the potential for 1ms variation could mean that your chirps are offset from one another significantly. The end result is that sometimes you may not get any data at all, and other times you will get very poor quality data. The system will fluctuate between those two states. 

    What is it you are trying to accheive by using one EVM/device as TX only and the other as RX only? This wouldn't change the resolution of the system. Is the point that you don't have the TX and RX antennas nearby? Are you attempting more of a bistatic MIMO radar? 

    Next, let me briefly answer your questions here:

    1. No that isn't possible to my knowlege.

    2. No, the FPGA HDL code is closed and not availible for modification

    3. If the goal is to have them both act as intended (each performing TX-RX), you could use the SW sync functionality that is discussed in the link you provided. 

    4. It is possible that you might be able to pull data over SPI, however the throughput would have limitations compared to what is feasable with the DCA1000. 

    Hope this helps! 

    Blake

  • 0 in reply to Blake Kisshauer
    Prodigy 100 points

    Hi Blake! Thanks for pointing that out. I understand that the radars will not be phase-locked. However, I understood by reading this article that SW synchronization has a 1ms delay, whereas HW synchronization should ideally trigger the frames simultaneously. Am I mistaken here?

    I am trying to research if I can use the backlobe of the patch antennas on the IWR BOOST boards to receive any radiation. For this, I need to direct radiation toward the back of the receiving radar. To do this, I plan to use another IWR1843BOOST in Tx-only mode. The setup will be similar to a bistatic radar setup, except that one radar will be facing away from the other.

    I understand that the FPGA HDL code is closed. Would it be possible to modify the code at your end to disable IO14 and send over the .bit file? That would be a huge help!

    Unfortunately, I cannot use the SW sync since the 1 ms delay would be unacceptable for my application.

    Thank you for suggesting the SPI idea. I do not need a high FPS, so throughput should not be an issue. I am not sure how to use the SPI to collect data. Is there any documentation for that? Would be grateful if you could provide something.

    Edit:

    I found the links below, but none show how to do this with an IWR1843. My understanding is that data can only be pulled from SPI out-of-box with the L series of devices. Am I correct? Can it be done with the IWR1843? If yes, what changes do I need to make?

    https://dev.ti.com/tirex/explore/node?node=A__ADY01vykb-1yBikfkjWXnQ__radar_toolbox__1AslXXD__LATEST

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1254691/iwr1843-only-use-mss-to-get-adc-raw-data

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1383225/iwrl6432boost-iwrl6432boost-adc-data-acquisition-procedure-via-spi

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1384436/iwrl1432-raw-adc-streaming-with-spi

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1388606/iwrl6432aop-adc-streaming-via-spi-with-6432aop

  • 0 in reply to Bishakh Ghosh
    TI__Expert 4600 points

    Bishakh, 

    There can still be a time delay between the two devices in triggering due to non-idealities in wiring and silicon performance. Additionally since the radars are not phase locked it is possible that there could be slight differences in frequency output between the two devices that render the experiment uselss. Since this method of synchronizing the EVMs falls outside of the intended use, I'm unable to support it. 

    Also, it's worth mentioning that the large ground planes and signal planes in the EVM under the antennas may significantly reduce backlobe. If you really want to measure back lobe, I'd suggest placing a reflector and seeing if you can detect it in the ADC captures. 

    I'm not able to change or issue a new FPGA HDL. 

    I'll ask a collegue to comment on ADC-over-SPI. 

    Thanks,

    Blake

  • 0 in reply to Blake Kisshauer
    TI__Expert 4600 points

    Bishakh, 

    I've spoken with some software collegues and they have told me that it is possible to perform ADC-over-SPI however we don't have example code on how to execute it. 

    I hope this helps! 

    Blake