• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 48 subscribers
  • Views 1525 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Need to capture every 333us with HSDC and not overwrite data

Darren Midkiff56
Prodigy 225 points

Part Number: TSW14J56EVM

We are using a the ADC12j4000 & TSW14j56 for prototyping a synthetic aperture radar.  This requires that we capture discrete 5us samples every 333us. Right now, we are successfully using HSDC for individual, externally triggered captures. The issue is that HSDC automatically overwrites data each time it is triggered. Can HSDC be configured to save raw capture data elsewhere every time that it captures so that we can continuously run the system without losing our data to overwrites?

  • 0
    TI__Guru* 91947 points

    Darren,

    We are looking into this and someone will get back to you back soon.

    Regards,

    Jim

  • 0 in reply to jim s
    TI__Mastermind 43930 points

    Hi Darren

    The High Speed Data Converter Pro capture firmware in the TSW14J56EVM is not capable of storing multiple triggered capture records in sequence. It is only intended to store one single record into memory for subsequent download to the PC for processing and analysis. You would need to modify the existing firmware to add the ability to perform multiple triggered captures adding up to the total specified record size and then readout of the larger composite record.

    The ADC12J4000EVM can also be used with a few different Xilinx development platforms. (VC707, ZC706, KCU105). You would still need to modify the existing firmware as discussed above. 

    The third option would be to locate a third party digitizer platform based on the ADC12J4000 that can be customized as needed.

    Best regards,

    Jim B

  • 0 in reply to Jim Brinkhurst1
    Prodigy 225 points
    Jim,

    Thanks for the reply. I understand that the capture board will not keep multiple records in sequence and that to do so would require custom firmware; however, that isn't what I'm aiming for at this point. One capture at a time is fine for me so long as I can save all of the captures on the PC without overwriting them and the trigger can happen at a frequency of 3KHz. There is enough time between captures to transfer all of the data to the PC via USB 3.0, but this doesn't account for the time HSDC spends processing the data. What I really want is to simply save the raw data from each capture to the PC without any processing and then repeat with the next capture indefinitely. Is this possible? I have been looking into the HSDC libraries for MATLAB, but so far there seems to be no way to bypass the data processing in order to offload the data quickly.
  • 0 in reply to Darren Midkiff56
    TI__Mastermind 43930 points
    Hi Darren
    I've contacted a colleague who is more knowledgeable regarding HSDC Pro capture/storage capabilities. He may be able to provide more information tomorrow.
    Best regards,
    Jim B
  • 0 in reply to Darren Midkiff56
    TI__Intellectual 2750 points
    Hi Darren,
    What is the sample size per channel that you are saving?

    To store the consecutive samples I think you are going the right direction with MATLAB / C / LabVIEW automation features.

    We have been working on some speed updates for HSDC Pro, and I think you will see some benefit of it when we release later this year. Even with these updates though I do not think you will be able to realize a 333usec retrigger rate. With that fast of a retrigger rate you are likely going to have to do some work on the FPGA firmware to queue multiple samples and move data to the PC in multi-sample packets. We do not have this type of structure in our FPGA firmware. Our state machine will not allow retrigger until the data has been completely offloaded, and this process takes >1msec from PC request to transfer completion even for small sample size (due to PC request being software timed operation).

    Regards,
    Brian
  • 0 in reply to Brian2001
    Prodigy 225 points

    Brian,

    Thanks for the help. We are capturing for 5us at 1.6Gsps. Right now we are in bypass mode, so that is 1.6Gsps*12bits*5us = 96Kb. I was thinking that if USB3.0 allowed us to transfer at 300MBps = 2.4Gbps, the transfer could take as little as 40us. I see that the software timing would bottleneck that plan, though.

    I was hoping to avoid custom firmware for a couple of reasons. First, continuous capture would make for a better radar system. Second, I only have access to Quartus Prime 17.1, and the firmware provided by TI was developed on Quartus 14, so modifying it will first require significant work in reconciling IP updates that will put me a bit out of my depth.

    I'm going to leave this open until I get another reply in case you have any other ideas/advice. It sounds like my only option to go with the firmware change, though.

    p.s. which version of the firmware is provided on TI's tsw14j56 page? There is only one project, but HSDC has many firmware versions available.

  • 0 in reply to Brian2001
    Prodigy 225 points
    Brian,

    Related question. It may warrant its own thread, but I'm going to reply here since you are an HSDC person and already on this thread. Currently, when we capture a chirp with HSDC, the data begins somewhere between 800 and 1000 samples. The precise start sample varies between these values. This is obviously problematic for radar. The trigger for capture and transmit are the same signal, so there should be no timing variation there. Do you know if this is a problem that could be related to HSDC?
  • 0 in reply to Darren Midkiff56
    TI__Intellectual 2750 points
    Hello Darren,
    I also have some issue opening firmware projects in Quartus 17. I would need to take some time to understand the errors and see what is going on with the IP, but I was able to open other projects in Quartus 14 without any error.

    I will have to look at the firmware, but I am fairly sure it is a JESD (BRAM not DDR) implementation that can be configured for different JESD modes.

    We do have a "Rapid Capture" utility written in C that has been published on E2E. It is a little dated at this point but you can have a look at it and see if it is helpful for you. We are in the process of making some major changes down to the DLL level right now so we will be updating HSDC Pro and the examples in the next couple of months.

    Regards,
    Brian
  • 0 in reply to Darren Midkiff56
    TI__Intellectual 2750 points
    Darren,
    For your chirp capture setup can you give me more information on the board setup? How are you triggering transmit and capture at the same time (I am sorry if this is obvious, please explain)

    Regards,
    Brian
  • 0 in reply to Brian2001
    Prodigy 225 points

    The output enable for our Analog Devices DDS is tied to the same microcontroller output as the trigger on the tsw14j56. The confusing part is that the latency is variable.

  • 0 in reply to Darren Midkiff56
    TI__Mastermind 43930 points

    Hi Darren

    I believe the trigger in to the TSW14J56EVM will get re-synchonized to the LMFC timing boundary in the FPGA (aligned to SYSREF coming from the ADC EVM).

    If your chirp and trigger generation is not synchronized to SYSREF this will cause the variable delay you are seeing.

    Best regards,

    Jim B

  • 0 in reply to Jim Brinkhurst1
    Prodigy 225 points
    The chirp generation is clocked from a PLL that uses the ADC SYSREF as its reference. Is there more that needs to be done to ensure synchronization?
  • 0 in reply to Darren Midkiff56
    TI__Intellectual 2750 points
    Darren,
    Were you able to synchronize the chirp and trigger to ADC SYSREF ? Did this tighten the trigger delay ?
    Regards,
    Brian
  • 0 in reply to Brian2001
    TI__Mastermind 43930 points
    Hi Darren
    To get consistent timing of the captured chirp waveform with respect to the beginning of data capture the beginning of the chirp would need to begin with fixed timing relationship to the SYSREF rising edge.
    If you are going that and still having variations in timing of the captured chirp please let us know.
    Best regards,
    Jim B