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.

MMWCAS-RF-EVM: one of the four AWR2243 chips is not synchronized with the other chips

Part Number: MMWCAS-RF-EVM
Other Parts Discussed in Thread: MMWCAS-DSP-EVM,

We purchased the MMWCAS-RF-EVM board and MMWCAS-DSP-EVM boards in November 2020, and they have been working fine. In January of 2021 we purchased a 2nd set of boards. Unfortunately, the RF board is not working correctly. One of the 4 radar chips is not synchronized with the other 3. I have attached a Powerpoint file showing images from the 16 Rx channels for one Tx for a data collection. We know this has a problem because we can run the same data collection with the first set of boards and all Rx channels are in sync. We have tested the first RF board with the second DSP board and it works correctly, so we know the problem is with the RF board. This is not a calibration issue because the basic Rx raw data is bad. Is there a fix for this, or do we need a new board?Rx plots for defective board.pptx

  • Hi,

    Please give us a few days to check if this is a known issue

    thank you
    Cesar

  • Hello Chris,

    Have you tried capturing data from a test source? If yes, do you see the same behavior?

    If not, can you simply try running Cascade_Configuration_TestSource.lua script present at the following location and let us know your observations after data capture: C:\ti\mmwave_studio_03_00_00_14\mmWaveStudio\Scripts\Cascade 

    Regards,

    Ishita

  • Hi Cesar,

    I tried the script you suggested (Cascade_Configuration_TestSource.lua) and everything works correctly. I assume this is just a test of the DSP board?

    Also, we purchased a 3rd MMWCAS-RF-EVM board and it does not exhibit this problem. The 3rd board works as well as the 1st board. What we did notice is that the average signal strength recorded by the receivers on the 2nd RF board is ~15% of the signal strength measured with either the 1st or 3rd RF boards. These boards were all tested using the same acquisition scripts, and using the same physical test setup. Something appears to be very wrong with this 2nd board of ours.

    Regards,

    Chris

  • Hello Chris, 

    Yes, you are right. The test source capture was a test for the capture card.

    Chris Sexton said:
    hat we did notice is that the average signal strength recorded by the receivers on the 2nd RF board is ~15% of the signal strength measured with either the 1st or 3rd RF boards.

    Thankyou for your observations. Let me reach out to the cascade team internally for some insights on this. I will get back you before the end of this week. 

    Hoping this would not hinder your development activities. 

    Regards,

    Ishita

  • Hello Chris,

    I have couple of questions here, and we would need some additional information to debug this further.

    When you say the average signal strength recorded by the receivers on the 2nd RF board is less than the other two boards, how have you measured this? Is it for all the 16 receivers or just the 4 bad receivers?

    Can you send us the individual FFT plots for all the 16 receivers in case of a good and a bad device? Also, what is the configuration you're using for this experiment? Is it from one of our lua scripts or something of your own? It would be good if you could send that as well.

    Regards,

    Ishita

  • Hi Ishita,

    I acquired data with the two RF-DSP combination boards side-by-side to get you a fair comparison. RF1 is a good board, RF2 is the suspected bad board. I have attached a Powerpoint with the FFT plots that you requested. What you can see from the data is that the recorded signal for RF2 is about 12dB lower than the signal for RF1 for all Tx and all Rx. You can also see that the four Rx on chip4 of the bad board show that it is not working correctly.

    The lower power is not our main problem. It is the fact that the receivers for the bad chip are not properly synchronized with the other three chips.

    I have also attached the configuration and capture scripts that I used. These are just copies of the cascade scripts that were supplied with MMWAVE Studio, with some slight modifications. If there is some setting that isn't being set correctly that may be causing the problem please let me know.

    Regards,

    Chris

    Cascade.zip0412.TI_data_RF1_RF2.pptx

  • Hello Chris,

    Thanks a lot for the effort in getting all the required information. I will go through the plots and configurations you've attached and get back to you before the end of this week with my comments.

    Regards,

    Ishita

  • Hello Chris,

    Extremely sorry for the delay.

    I agree, it seems to be some data capture issue from the 4th device of the bad board. This can't be configuration issue since the same config is working well for you on the other good boards. I'm not sure on how we can move further on this. 

    In case you want a replacement, you will need to go through the required process outlined on the TI page if you purchased the board directly from TI store. 

    https://www.ti.com/support-quality/additional-information/customer-returns.html

    Regards,

    Ishita