• State TI Thinks Resolved
  • Locked Locked
  • Replies 23 replies
  • Answers 3 answers
  • Subscribers 32 subscribers
  • Views 1853 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.

AWR1642: profile/chirp config when LVDS outputs CP_ADC_CQ

Chris Meng
Mastermind 37666 points
Part Number: AWR1642
Other Parts Discussed in Thread: MMWAVE-STUDIO, DCA1000EVM

Hi,

My customer uses LVDS output radar raw data to do signal analysis on PC. But they found with the same profile/chirp config, when LVDS outputs CP_ADC_CQ, the angel estimation got by PC is not good as the one got with only ADC output on LVDS case. When LVDS outputs CP_ADC_CQ, customer can detect moving object with the RAW data, but the angel estimation has shift which is not expected. 

Do you have any idea on this issue? Do we need more spare time after ADC sample to ramp end time with CP/CQ data output enabled on LVDS? If yes, how much need to add?

Any comment is appreciated!

  • 0
    TI__Guru 69960 points
    Is there any specific reason they are enabling CP/CQ data?
    What is the Silicon and SDK version? Are they seeing same behaviour with mmw demo+LVDS streaming?

    Regards,
    Jitendra
  • 0
    TI__Genius 15005 points
    Hi Chris,

    Could you please provide us with a chirp configuration that shows this behavior?

    Also, could you let us know if you are able to replicate this on a TI EVM?

    Best Regards,
    Anand
  • 0 in reply to Jitendra Gupta
    TI__Mastermind 37666 points

    Jitendra Gupta said:
    Is there any specific reason they are enabling CP/CQ data?

    Customer wants to check the CQ2 value to see if data is saturated or not.

    Jitendra Gupta said:
    What is the Silicon and SDK version?

    ES2.0 and SDK 2.1.

  • 0 in reply to Chris Meng
    TI__Expert 3980 points

    The mmWave SDK 2.1 release note has the following statement:

    "For xWR16xx, CQ cannot be streamed out reliably when datapath processing is also enabled. The data corruption for CQ data
    over LVDS lanes is seen more pronounced when multiple chirps/chirp event is enabled."

    Not sure if your symptom/condition matches the statement? This bug is still there.

  • 0 in reply to Chris Meng
    TI__Guru 69960 points
    Hello Chris,
    With SDK currently it has limitation to configure ADC+CQ over LVDS.
    But with mmWave Studio it should be fine, can you ask your customer to try this option AWR1642+mmWave-Studio+DCA1000.


    Regards,
    Jitendra
  • 0 in reply to Jitendra Gupta
    TI__Mastermind 37666 points

    Jitendra,

    I am trying to test the ADC data +CQ with AWR1642 EVM+DCA1000EVM+mmWave Studio. But with below DataConfig setting in mmWave studio, the result of post process is not correct. Would you pls kindly advise what I missed?

    Below comparison tests have same config, except the Packet 0 setting in Data Path configuration. Left side is configured as ADC_ONLY and right is as above (CP_ADC_CQ).

  • 0 in reply to Chris Meng
    TI__Genius 15005 points

    Hi Chris,

    You will also need to enable the appropriate monitors (RX Saturation Detector Mon Config and RX Signal and Image Mon Config groups) in the Analog RX Mon Tab in mmWave Studio.

    The tab you show is only for the data path - if the corresponding monitors are not enabled, the returned data will be incorrect.

    Best Regards,

    Anand

  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points
    Anand,

    I tried to enable above monitor config you mentioned after framecfg set. Then I did capture and post processing. But the result is still not correct (similar as I shared before). Would you pls kindly help again?
  • 0 in reply to Chris Meng
    TI__Genius 15005 points
    Hi Chris,

    Could you please provide the full sequence of steps you have followed? Or alternatively, share the log from mmWave Studio.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points

    Anand,

    Pls find the mmWave studio log attached. Pls kindly help to check what I missed. Thanks.

    Fullscreen cq_enable_log.txt Download 
    [16:09:19]  ***Script completed successfully.***
[16:11:39]  [RadarAPI]: Opening Gpio Control Port()
[16:11:39]  [RadarAPI]: Status: Passed
[16:11:39]  [RadarAPI]: Opening Board Control Port()
[16:11:39]  [RadarAPI]: Status: Passed
[16:11:40]  [RadarAPI]: ar1.FullReset()
[16:11:40]  [RadarAPI]: Status: Passed
[16:11:41]  [RadarAPI]: Closing Board Control Port()
[16:11:41]  [RadarAPI]: Status: Passed
[16:11:41]  [RadarAPI]: Closing Gpio Control Port()
[16:11:41]  [RadarAPI]: Status: Passed
[16:11:41]  [RadarAPI]: ar1.SOPControl(2)
[16:11:41]  [RadarAPI]: Status: Passed
[16:11:42]  [RadarAPI]: ar1.Connect(77,115200,1000)
[16:11:43]  [RadarAPI]: ar1.Calling_IsConnected()
[16:11:44]  [RadarAPI]: ar1.SelectChipVersion("AR1642")
[16:11:44]  [RadarAPI]: Status: Passed
[16:11:44]  [RadarAPI]: RS232 is not connected ..!!!!
[16:11:44]  [RadarAPI]: ar1.frequencyBandSelection("77G")
[16:11:44]  [RadarAPI]: ar1.SelectChipVersion("XWR1642")
[16:11:44]  [RadarAPI]: Status: Passed
[16:11:44]  Device Status : XWR1642/ASIL-B/SOP:2/ES:2
[16:11:45]  [RadarAPI]: ar1.SelectChipVersion("AR1642")
[16:11:45]  [RadarAPI]: Status: Passed
[16:11:45]  [RadarAPI]: ar1.SelectChipVersion("XWR1642")
[16:11:45]  [RadarAPI]: Status: Passed
[16:11:45]  Device Status : XWR1642/ASIL-B/SOP:2/ES:2
[16:11:45]  [RadarAPI]: ar1.SaveSettings('C:\Users\AppData\Roaming\RSTD\ar1gui.ini')
[16:11:47]  [RadarAPI]: ar1.DownloadBSSFw("C:\\ti\\mmwave_studio_02_00_00_02\\rf_eval_firmware\\radarss\\xwr16xx_radarss.bin")
[16:11:47]  [RadarAPI]: Downloading BSS Patch RPRC Binary..
[16:11:54]  [RadarAPI]: ar1.GetBSSFwVersion()
[16:11:54]  [RadarAPI]: BSSFwVersion:(02.00.00.01 (05/10/17))
[16:11:55]  [RadarAPI]: ar1.DownloadMSSFw("C:\\ti\\mmwave_studio_02_00_00_02\\rf_eval_firmware\\masterss\\xwr16xx_masterss.bin")
[16:11:55]  [RadarAPI]: ar1.GetBSSPatchFwVersion()
[16:11:55]  [RadarAPI]: BSSPatchFwVersion:(01.02.00.03 (24/10/18))
[16:11:56]  [RadarAPI]: Downloading MSS RPRC Binary..
[16:12:08]  [RadarAPI]: ar1.PowerOn(0, 1000, 0, 0)
[16:12:08]  [RadarAPI]: Status: Passed
[16:12:08]  MSS power up done async event received!
[16:12:09]  [RadarAPI]: ar1.RfEnable()
[16:12:09]  [RadarAPI]: Status: Passed
[16:12:09]  BSS power up done async event received!
[16:12:10]  [RadarAPI]: ar1.GetBSSFwVersion()
[16:12:10]  [RadarAPI]: BSSFwVersion:(02.00.00.01 (05/10/17))
[16:12:11]  [RadarAPI]: ar1.GetBSSPatchFwVersion()
[16:12:11]  [RadarAPI]: BSSPatchFwVersion:(01.02.00.03 (24/10/18))
[16:12:16]  [RadarAPI]: ar1.ChanNAdcConfig(1, 1, 0, 1, 1, 1, 1, 2, 1, 0)
[16:12:16]  [RadarAPI]: Status: Passed
[16:12:17]  [RadarAPI]: ar1.LPModConfig(0, 0)
[16:12:17]  [RadarAPI]: Status: Failed, Error Type: REGULAR ADC MODE NOT SUPPORTED IN 5 MHz PART VARIANT DEVICE
[16:12:18]  [RadarAPI]: ar1.RfInit()
[16:12:18]  RF Init async event received!
[16:12:18]  [RadarAPI]: Status: Passed
[16:12:18]  [RadarAPI]: Time stamp, Temperture: 8780,39; APLL Status, Update: 1, 0; SynthVCO1 Status, Update: 1, 1; SynthVCO2 Status, Update: 1, 1; LODist Status, Update: 1, 1; RxADCDC Status, Update: 1, 1; HPFcutoff Status, Update: 1, 1; LPFcutoff Status, Update: 1, 1; PeakDetector Status, Update: 1, 1; TxPower Status, Update: 1, 1; RxGain Status, Update: 1, 1; TxPhase Status, Update: 0, 0; RxIQMM Status, Update: 1, 1; 
[16:12:23]  [RadarAPI]: ar1.DataPathConfig(513, 1216644150, 0)
[16:12:23]  [RadarAPI]: Status: Passed
[16:12:23]  [RadarAPI]: ar1.LvdsClkConfig(1, 1)
[16:12:24]  [RadarAPI]: Status: Passed
[16:12:24]  [RadarAPI]: ar1.LVDSLaneConfig(0, 1, 1, 0, 0, 1, 0, 0)
[16:12:24]  [RadarAPI]: Status: Passed
[16:12:37]  [RadarAPI]: ar1.ProfileConfig(0, 77, 4, 6, 40, 0, 0, 0, 0, 0, 0, 25.009, 0, 128, 6000, 0, 0, 30)
[16:12:37]  [RadarAPI]: Status: Passed
[16:12:38]  [RadarAPI]: ar1.ChirpConfig(0, 1, 0, 0, 0, 0, 0, 1, 0, 0)
[16:12:38]  [RadarAPI]: Status: Passed
[16:12:38]  Test Source Already Disabled...!!!
[16:12:38]  [RadarAPI]: Status: Passed
[16:12:38]  [RadarAPI]: ar1.FrameConfig(0, 0, 20, 128, 40, 0, 1)
[16:12:38]  [RadarAPI]: Status: Passed
[16:12:43]  [RadarAPI]: ar1.SetRfRxIfSatMonConfig(0, 1, 0, 0, 0.8, 63, 0, 0, 0, 0, 0, 0)
[16:12:43]  [RadarAPI]: Status: Passed
[16:12:43]  [RadarAPI]: ar1.SetRfRxSigImgMonConfig(0, 8, 63)
[16:12:43]  [RadarAPI]: Status: Passed
[16:12:48]  [RadarAPI]: ar1.SetRfRxIfSatMonConfig(0, 3, 0, 0, 0.8, 63, 0, 0, 0, 0, 0, 0)
[16:12:48]  [RadarAPI]: Status: Passed
[16:12:55]  [RadarAPI]: ar1.SelectCaptureDevice("DCA1000")
[16:12:55]  [RadarAPI]: passed
[16:12:56]  [RadarAPI]: StatusDCCard Event Registered
[16:12:56]  [RadarAPI]: Status: Passed
[16:12:56]  [RadarAPI]: ar1.CaptureCardConfig_EthInit("192.168.33.30", "192.168.33.180", "12:34:56:78:90:12", 4096, 4098)
[16:12:56]  [RadarAPI]: SYSTEM_CONNECT_CMD_CODE Async event recieved(9)
[16:12:56]  [RadarAPI]: ConnectRFDCCard Status: Passed
[16:12:56]  [RadarAPI]: ReadRFDCCarFpgaVersion Status: Passed
[16:12:56]  [RadarAPI]: READ_FPGA_VERSION_CMD_CODE event recieved(14)
[16:12:56]  [RadarAPI]: ar1.CaptureCardConfig_Mode(1, 2, 1, 2, 3, 30)
[16:12:56]  [RadarAPI]: Status: Passed
[16:12:56]  [RadarAPI]: CONFIG_FPGA_GEN_CMD_CODE Async event recieved(3)
[16:12:56]  [RadarAPI]: ar1.CaptureCardConfig_PacketDelay(25)
[16:12:56]  [RadarAPI]: Status: Passed
[16:12:56]  [RadarAPI]: CONFIG_PACKET_DATA_CMD_CODE Async event recieved(11)
[16:12:59]  [RadarAPI]: ar1.CaptureCardConfig_StartRecord("C:\\ti\\mmwave_studio_02_00_00_02\\mmWaveStudio\\PostProc\\adc_data.bin", 1)
[16:12:59]  [RadarAPI]: Status: Passed
[16:12:59]  [RadarAPI]: RECORD_START_CMD_CODE Async event recieved(5)
[16:13:07]  [RadarAPI]: ar1.StartFrame()
[16:13:07]  [RadarAPI]: Status: Passed
[16:13:07]  Frame start async event received!
[16:13:08]  Frame End async event received!
[16:13:08]  [RadarAPI]: Frame Ended
[16:13:10]  [RadarAPI]: STS_RECORD_COMPLETED Async event recieved(8)
[16:13:10]  [RadarAPI]: ar1.CaptureCardConfig_StopRecord()
[16:13:10]  [RadarAPI]: Status: Passed
[16:13:10]  [RadarAPI]: RECORD_STOP_CMD_CODE Async event recieved(6)
[16:13:13]  [RadarAPI]: Packet Reorder Utility Started...please wait...
[16:13:13]  [RadarAPI]: ar1.PacketReorderZeroFill("C:\\ti\\mmwave_studio_02_00_00_02\\mmWaveStudio\\PostProc\\adc_data_Raw_0.bin", "C:\\ti\\mmwave_studio_02_00_00_02\\mmWaveStudio\\PostProc\\adc_data.bin", "C:\\ti\\mmwave_studio_02_00_00_02\\mmWaveStudio\\PostProc\\pktlogfile.txt")
[16:13:18]  [RadarAPI]: Packet Reorder Utility process completed!
[16:13:33]  Reordering required : NO
[16:13:33]  Packet loss : NO
[16:13:33]  Number of packets received : 4811
[16:13:33]  Number of zero filled packets : 0
[16:13:33]  Number of zero filled bytes : 0
[16:13:33]  [RadarAPI]: ar1.StartMatlabPostProc("C:\\ti\\mmwave_studio_02_00_00_02\\mmWaveStudio\\PostProc\\adc_data.bin")

  • 0 in reply to Chris Meng
    TI__Genius 15005 points
    Hi Chris,

    This seems to be a known issue in this version of mmWave Stdio.

    I am checking if there is a fix.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points
    Anand,

    Thanks for your update.

    My customer tried to disable the DSP process when streaming the ADC+CQ data on LVDS, but the angel estimation with the ADC data got from LVDS is still not correct. The 1D/2D FFT result seems ok. So we need to check it if EVM+ mmWave studio has this problem or not.
  • 0 in reply to Chris Meng
    TI__Genius 15005 points
    Hi Chris,

    The known issue I mentioned appears to be a post-processing issue with the tool in mmWave Studio - the raw ADC data should still be okay.

    Is it possible for you to recreate this issue and upload the raw data files for the two cases here? We can check it offline and get back to you.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points

    Anand,

    Would you pls kindly help to compare attached two outputs on angle estimation?

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/adc_5F00_data.7z

  • 0 in reply to Chris Meng
    TI__Genius 15005 points
    Hi Chris,

    Can you confirm that you did not run the post proc on these files?

    Thanks in advance,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points
    Anand,

    No, I didn't. You can check the log.
  • 0 in reply to Chris Meng
    TI__Genius 15005 points
    Hi Chris,

    We are looking into this and will get back to you later today.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Genius 15005 points
    Hi Chris,

    We looked at the cq_enable_log.txt file and it appears that you are running with Regular ADC mode with CQ Enabled vs Low Power ADC Mode with CQ Disabled - can you double check this setting? (See line 91 of cq_enable_log.txt file).

    If possible, can you replicate the issue again with and without CQ in your own environment with the same settings?

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points
    Anand,

    If you checked the latest log adc+cq_log.txt in adc_data.7z which I uploaded, you will find that I already corrected the ADC mode setting and there is no error in the log. Pls use the raw data in adc_data.7z.
  • 0 in reply to Chris Meng
    TI__Genius 15005 points

    Hi Chris,

    I checked the data now. This is due to an issue in the post-processing DLL released with mmWave Studio 2.0.0.2. It will be fixed in the next release.

    If you want to check this yourself, you can use the DLL included in the attachment. Please copy it to the following location:

    C:\ti\mmwave_studio_02_00_00_02\mmWaveStudio\Clients\AR1xController

    Best Regards,

    Anand

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/CPCQ_5F00_Fix_5F00_MatlabPostProc.7z

  • 0 in reply to Anand Gadiyar
    TI__Genius 15005 points
    Hi Chris,

    Can you confirm that this issue is resolved with the updated DLL?

    Thanks,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Mastermind 37666 points

    Anand,

    Thanks. The patch solves the mmWave studio issue with CQ data.

    I tried and can't reproduce customer's issue. I have asked customer to try to see if the issue can be reproduced with fixed corner reflector at their own board/own capture card.

  • 0 in reply to Chris Meng
    TI__Genius 15005 points
    Hi Chris,

    Thanks for confirming. I will close this thread, but please raise another one if the customer replicates the issue again.

    The DLL fix will be included in the next release of mmWave Studio.

    Best Regards,
    Anand