• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 46 subscribers
  • Views 321 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.

ADS5400evm +TSW1200EVM external triggering

Nancy Saldanha
Prodigy 40 points
Other Parts Discussed in Thread: ADS5400EVM

Hi Richard,

Thanks for the Matlab code and the quick response.  I have another question about the ADS5400evm+TSW1200EVM setup.  I am using the ADC in a wireless transceiver prototype and need to externally trigger the synchronous capture of data.  I will be generating the trigger in an FPGA, that will also be controlling the tx/rx switches in the transceiver.  Is there a  way to connect the external trigger for sampling/capture of data on these boards.  The way I understand it the GUI for the TSW1200EVM allows for triggered capture of data through software, but is there a way to do this using a trigger signal from external hardware?  Is there a limit on how often it can be triggered, i.e. what is the minimum latency between consecutive triggers?

Thanks,

Nancy

  • 0
    TI__Mastermind 29220 points

    Hi,

    The firmware in the TSW1200 does have a mode for external triggering of the capture.  The way this normally works (if using the normal Labview-based GUI) is that the user still presses the capture button and the GUI sets up the FPGA for a capture as before.  But this time the FPGA is 'armed' for a capture instead of just proceeding with the capture.  The FPGA is looking for a rising edge on a certain input pin (wired to pushbutton SW4 on the TSW1200 board) and when it sees the rising edge on this input then the capture begins.   If the FPGA does not see the rising edge within abotu 15 seconds then the Labview-based GUI is programmed to time out.

    The Matlab code could be modified to use this function of the FPGA firmware.  Currently the last register that the GUI (or Matlab code) writes to is to write a value 0000 0011 to register address 2 of the FPGA.  The '1' in the least significant bit is the bit that starts the capture.  The bit next to that simply goes to light the USB LED D3 on the TSW1200 and is not necessary.   But if we want to 'arm' the FPGA for capture, then we write 0011 0000 to that register instead.  The FPGA firmware is programmed to always look for a rising edge on the tringger (SW4) input and when that happens then it will shift the contents of register 2 right by four positions.  If the register 2 has been 'armed' for a capture with 0011 0000 in it, then the trigger causes it to become 0000 0011 and the capture begins. 

    Each externally triggerd capture must see the software arm the capture with a register write first.  We do not have a way to simply force a capture without software intervention.  After the capture, the FPGA firmware begins to stream the captured data out through a serial port and the software must be expecting to get the data, so ultimately it is the software that initiates the whole process by either starting a capture or arming for a capture through a write to register 2.  The Matlab code could be modified as you see fit to change the time out interval, or to loop for repeated captures, or whatever you wish to do within the framework set up by the FPGA firmware.

    There is no minimum cycle time for repeated captures, other than it takes about a second (more for larger captures such as 65536 samples) to unload the caprtured data up the USB cable and to process and update the display.  If you wish to store the captured data in a file for later, then the next capture could begin right after the FPGA has finished streaming the last byte of data up the USB cable.

    Regards,

    Richard P.

  • 0 in reply to Richard Prentice
    Prodigy 40 points

    Hi Richard,

    Thank you for the very informative email.  I think this functionality should work for me.  I have a couple more questions though.  Here is a brief explanation of what I am trying to do.  I need to capture the analog transmitted signal for post-processing later against rec'd data.  Let's say the transmitted pulse is about 1 microsecond long and then the system would switch to receive mode and listen for 5 microseconds and the rec'd signal needs to be captured by ADC and saved in a file for post processing.  The sampling rate will be the maximum 1Gsps. 

    I probably can do the tx and rx data capture in one trigger cycle.  Ideally I would have liked to be able to transmit and receive data several times per second, but it sounds like the USB data upload will be the bottleneck.  The FIFO registers on the capture card can hold a maximum of 64k samples, is this correct?  Say each cycle only requires 8192 samples, would it be possible to make the external trigger repeatable and allow multiple capture cycles to fill up on board memory and then have one long data transfer? Can the capture card be armed for new capture and receive more data as old data is being emptied? Are there any other ADC/ capture card options that would have been a better choice?

    On a separate note, I purchased the CECE62002EVM to clock the ADS5400EVM and I now realize that for a 1GHz clock it only outputs a differential LVPECL clock and ADS5400EVM accepts a single ended input.  Would it be best to transform the CECE62002EVM output to a single-ended clock externally?

    My experience in the area is limited and I'm trying to get a good understanding of the ADC limitations.  Thanks a lot for the technical feedback, it has been quite helpful.

    Nancy