LabVIEW sub VIs for TSW1200 with ADS5486EVM

Hi,

The TUSB3410 device on the TSW1200 does handle the communication between the TSW1200 hardware and the TSW1200 User Interface software that runs on a PC.  Specifically, the TUSB3410 is a USB to UART device and so it communicates with the PC as a USB port and it communicates to the FPGA on the TSW1200 hardware over a simple 2-wire UART.

The User Interface that runs on the PC is not distributed with the source code (that is, the sub-vis behind the front panel of the GUI.)  The control of the TSW1200 hardware is not documented in such a way that we would expect a customer to write code to talk to the TSW1200.  The TSW1200 has a small register space where the software can set bits to set up the hardware for the next capture.  There are so many different ADC data formats supported, including different timing numbers from different ADCs, that the control of the register space is complicated.  Some of the registers control the FPGA functions that are very tightly tied in with the use of the Xilinx logic cells that you would also have to know how the TSW1200 FPGA firmware was coded in order to know how to set the register bits.

We also supply a kernal of Matlab code to control the TSW1200, and that Matlab code should also have been on the CD that came with the TSW1200.  The Matlab code was meant for users who want to cature the sample buffer and then write their own analysis routines.  The Matlab code would have the register writes needed for a specific device such as the ADS5485 already coded so that you would not have to know how to program the TSW1200 - that part has been done already.  But then you would be able to write further code to initiate data captures and to process the results however you wish.

Would the Matlab code for the TSW1200 and ADS5485 be useful for what you wish to do?

Regards,

Richard P.

Dear Richard,

Thank you for your reply.

I do understand the policy.

If I don't need to develop my own program, it would save my time as well.

My application is pretty simple. I just need to capture my time domain signal, triggered by an external pulse, and pass the data to the host PC for data processing.

Since I just submitted a requisition form, I do not have the CD yet. So I have no idea of the Matlab code.

What controls or functions are available in the Matlab code?

I appreciate your prompt reply.

Sincerely,

Chang

Hi,

The Matlab code has little more than what is needed to capture a buffer of data from the ADS5485 EVM.  The code prompts the user for sample rate, input frequency, number of samples to capture (either 4k, 8k, 16k, 32k, or 64k samples) and then captures the sample data.  Then it calls an FFT routine to plot an FFT power spectrum.  This is meant to be just the minimal amount of code needed to get the data captured into a Matlab variable so that the user can then process the data however they wish.

The User's Guide for the TSW1200 can be found at http://focus.ti.com/lit/ug/slau212a/slau212a.pdf which will describe much of the features of the hardware and of the User Interface.  (But not the Matlab code.)  One feature that the current TSW1200 supports but is not in the User Guide is the external trigger feature.  Using the User Interface that comes with the TSW1200, there is the option (a checkbox on the front panel of the User Interface) to enable External Triggering.  When enabled, the 'Capture' button on the User Interface instead 'arms' the hardware to do a data capture, but the data capture doesn't begin until a trigger event is seen at the hardware.  There is a pushbutton switch on the TSW1200 called SW4 that when pressed creates a low-to-high trigger event to begin the capture.  If there is an external trigger pulse that is to trigger capture with a low-to-high transition, then this signal can be wired in to the hardware in place of switch SW4.  This sounds like it would be a useful feature to you in this application.  (The Matlab code does not yet support the external trigger option, but it would be easy to modify to make it do so.)

The TSW1200 User Interface also has the option to save the captured data to a file name as a csv (comma separated value) file, which could then be read and processed by a spreadsheet or other software written to process the sample data.  This also may be of interest in this application.

Regards,

Richard P.

Dear  Richard,

I appreciate your kind reply.

It sounds like LabVIEW interface is all I need.

Is it possible for you to provide the LabVIEW application VI with control inputs and data output, instead of making it exe file?

And I don't need to see the inside of the LabVIEW.

If it has control input and data output, I can easily use that LabVIEW VI in my application. I'm pretty sure that this would be very useful for others as well.

What is the delay from the hardware trigger and actual data capture?

Thank you very much,

Chang

Hi,

We do not at this time have the hooks in the Labview GUI for programmatic control of the front panel, and the whole hierarchy of the .vi files is not something that we can provide either.  I have opened an inquiry within our support staff as to what i could do for the next revision of the TSW1200 GUI to be able to support making the GUI such that it can be controlled by a higher level of code.  I am told that there may be third party software that can emulate a person operating a GUI for things like mouse clicks to push buttons, so that may be an option for the current revision of the Labview GUI.  And i am checking to see if there is any other options for the current revision of code for controlling the front panel of the GUI.

The only delay in the hardware trigger to the start of a data capture is for the FPGA firmware to latch the input trigger signal to synchronize the asynchronous external signal to the internal clock domain of the capture memory, so there may be a couple of clock cycles of delay.  (and by clock cycles, i refer to an internal 250MHz clock within the FPGA.)

Regards,

Richard P.

Hey Richard,

we face the exact same problem. We need external triggering for capturing. When you say: "a checkbox on the front panel of the User Interface", do you mean the "continous capture" checkbox? This is the only checkbox I could find in the User Interface. 

Regards

Felix W.

Hi,

No, enabling continuous capture will simply put the User Interface in a loop of capturing repeatedly at a set time interval.  The time interval is by default every 1 second, but may be changed with one of the menu options.

For newer versions of the User Interface we added another checkbox below the continuous capture checkbox, labeled External Trigger.  You may be using an older version of the TSW1200 software and firmware that did not yet have the external trigger option.

The latest TSW1200 User Interface software is available for download on the web, at http://focus.ti.com/docs/toolsw/folders/print/tsw1200gui-sw.html under the DOWNLOAD button.  I think this will be version 2.5 at the present time.  But the external trigger option will not be availble unless you *also* have the latest firmware in the TSW1200 eeprom for the FPGA.  The current version for the firmware is 1.6 for the parallel LVDS DDR data formats and 1.5 for the 1-wire and 2-wire serial data formats.  if you have an older version of the software, you may also have an older version of the firmware.

You can easily see what verison of software and firmware you have by connecting the TSW1200 to your PC, opening the User Interface, and then look in the lower left status pane after the User Interface initializes.  If you have a device selection that is for a parallel LVDS DDR format while the hardware is jumpered for serial, then you will see instead a warning message in the status pane.  Remedy that situation if necessary by choosing a device type that matches the format the hardware is jumpered for (such as select ADS5483 if jumper J11 is set HI, or select ADS6445 if jumper J11 is set LO) and then reinitialize the User Interface.  (Control-Shift-I is a short cut to reinitialize the software.)  Then you would be able to see what revision software and firmware you have.

Again, you would need to see firmware revision 1.5 or higher in order to have external triggering be available.  If not, then your local sales office should be able to assist with how to upgrade the FPGA firmware in the eeprom, and it would be easy if a Xilinx programming pod is available for use.

Regards,

Richard P.

Any update on putting hooks in the Labview code so you can control it in your own panel? This would be very useful for us as well. Also, is there a trigger out from this board? This would be more useful for us then the trigger input.

Thanks,
Tim

Hi,

No, there is no update on whether it may be possible to let a higher level piece of Labview control this GUI. 

But for trigger output, there is one possible development.  We are testing out a new feature where we do supply a trigger output.  But this feature is tightly tied to a feature on a new EVM.

Under what conditions would you wish the EVM to source such a trigger?  If the trigger is to be related to the Capture button, we do output a signal from the FPGA when the capture begins and that would be the LED D3 labeled USB.  When the User Interface tells the FPGA to begin a capture, we bring that signal active.  Using this signal for an additional purpose would require soldering onto the Capture Card.  We do not have any other general purpose connections for such a signal except the header posts for output sample data.  The output trigger in development now is a signal through the Samtec connector to the EVM itself, pin 111 of that connector, but that feature will require new FPGA firmware, new User Interface software, and is still tightly tied to the use of the Capture button.

Regards,

Richard P.

What would the jitter on this trigger output be? Is it always aligned to the same clock cycle as the ADC capture begins, or is this trigger signal still asynchronous, so there would still be a clock or two of resynchronizing?

Hi,

any trigger that we generate from the FPGA by way of the User Interface initiating it would be asynchronous to the data converter clocking, as the FPGA runs off an internal 250MHz clock derived from its own crystal oscillator.

Regards,

Richard P.