• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 47 subscribers
  • Views 1409 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.

TSW14J56EVM: Is there any way to skip plotting graphs in HSDC Pro GUI?

Huioon Kim
Intellectual 395 points

Part Number: TSW14J56EVM
Other Parts Discussed in Thread: ADC34J45EVM, ADC34J45

Hello,

I'm trying to collect data continuously using ADC34J45EVM and TSW14J56EVM. I also use the HSDC Pro GUI automation DLL to program it. The problem is that, I guess the data collecting speed is slow because the GUI plots time domain and FFT data. If I collect samples more than 10,000,000 (10M), it takes about 4 second to be done. I measured time programmatically, anyway (from Pass_Capture_Event (TimeoutInMs) to HSDC_Ready (TimeoutInMs)).

So, I guess I can reduce the time if I can skip plotting graphs, I read the user guide of HSDC Pro GUI and manual of the automation DLL, but I couldn't find the way.

Or, my guess is wrong? If so, is there any way to make it faster?

Sorry for my poop English. :)

  • 0
    TI__Intellectual 2750 points

    Huioon,

    Your English is fine.  We do not expect the graph-plot to be limiting your capture. 

    But, we do not expect a 4sec retrigger time. 

    Can you give more details on your setup?

    What INI file are you using to initialize?

    What is the setup of the ADC34J45 EVM ?

    Regards,

    Brian

  • 0 in reply to Brian Kincaid
    TI__Intellectual 2750 points
    Also, are you saving the capture data to file as part of your capture loop (inline process?)
  • 0 in reply to Brian Kincaid
    Intellectual 395 points
    OMG! I just found I made a big typo in the last line of my post! Alright, now I can't avoid to admit my English is not "that" bad. :D

    Back to the question, my program is based on the C example of the automation DLL, whose file name is "HSDCPro Automation DLL ADC Example.cpp" which is located in "C:\Program Files (x86)\Texas Instruments\High Speed Data Converter Pro\HSDCPro Automation DLL\Manual and Examples\Automation DLL C Example\ADC"

    In the example, all trigger options are OFF (set to "0") and so are they in my program. I don't know about the INI file, but I set the ADC by loading a configuration file, "ADC3xJxx_160MSPS_Operation_LMK_Setting.cfg," in the ADC3000 GUI, which comes with the ADC3xxxx GUI installer. I set up the boards as described in the ADC3xxx, ADC3xJxx EVM User’s Guide ("slau579c.pdf").

    File saving is not performed in the loop, I just measured time by putting the timer before calling "Pass_Capture_Event (TimeoutInMs)" and after calling "HSDC_Ready (TimeoutInMs)" functions. It seems that the "HSDC_Ready ()" waits for the GUI to finish plotting and FFT, which slows down the speed, or if capturing and plotting/FFTing are performed simultaneously, is it the maximum speed already?

    By the boards' spec, I think it should be much more faster. Am I wrong?

    Ah, I forgot to thank you for your reply, Brian. :)

    Huioon
  • 0 in reply to Huioon Kim
    TI__Intellectual 2750 points

    Huioon,

    I have set up a board, and I confirm it takes approximately 4 sec to complete a 10M sample capture.

    I am going to check into the software buffering cycle and get back to you.  It does not look to me like the calculation or visual update is gating the capture turnaround.  I think there is some buffering that is holding it back.

    I'll see what we can do to help, but HSDC Pro software is designed for cycle analysis and does not really have any optimization for retrigger time.

    Regards,

    Brian

  • 0 in reply to Brian Kincaid
    TI__Intellectual 2750 points
    Huioon,
    I have identified the bottle-neck in the software. For non-trivial captures the software is buffering the capture memory DDR transfer to PC hard-drive in a blocking operation. This creates a transfer throttle depending on your hard-drive transfer speed. I am working on some ideas for workaround or new feature for customers that have enough PC memory to buffer instead of disk. This will take some work on so I cannot promise any timeline at this time.

    Regards,
    Brian
  • 0 in reply to Brian Kincaid
    Intellectual 395 points
    Brian,

    Thank you for your answer. Now I know what's going on. Anyway, there's nothing I can do, and I'm going to accept the speed for now. I also understand the boards are for evaluation and may not be a good choice for some use cases.

    Thank you anyway, I'm going to find a workaround to reduce total amount of time to take for the whole process including signal processing. Actually, saving and loading a file to get raw data is also a bottle-neck for my program, so I'm considering if I need to modify the FPGA firmware. The problem is I'm a layperson of the FPGA. :)

    Regards,
    Huioon
  • 0 in reply to Huioon Kim
    TI__Intellectual 2750 points
    Huioon,
    I have determined that the bottle-neck is not with the FPGA firmware, but it is the way the USB3.0 driver is running in our middle-ware. I am working on a fix, but it will take some time. I hope to get a new release in the next couple of months.
    Regards,
    Brian