External Trigger capture for TSW1200

Hi,

The TSW1200 does have an external trigger function.  This has been added for the current revision of the FPGA firmware and the current revision of the User Interface, and the User Guide has not caught up with this revision yet to document it.

On the User Interface, you may see a checkbox labeled External Trigger right next to the capture button.  How this is used is as follows:

1) check the external trigger checkbox

2) press the capture button

3) assert a rising edge on the external trigger signal on the TSW1200 circuit board, which is also connected to pushbutton SW4.  (you can test the external trigger function by doing steps 1 and 2 and then pressing SW4.  If this functionality is found to be what you want, then the actual trigger signal could be wired in to that signal on the board)

Normally when the capture button is pressed on the GUI, there is a value 00000011 written to a register in the FPGA and this starts the capture.  The '1' in the lsb position is what starts the capture FIFOs filling up, and when the FIFO fills to the requested depth then the FIFO is emptied out through the USB up to the PC.  When the last byte of captured data leaves the FIFO, the register self clears back to all zero.

The second bit in the register next to the lsb is wired out straight to the USB LED.  So while the FIFO is filling up an while it is being emptied the USB LED is lit.  Then when the register is cleared, the LED goes off.

In current FPGA firmware, we have added code that upon a rising edge on the signal wired to the pushbutton SW4 we take the contents of that same capture register and do a right-shift by four bit positions.  That is all that SW4 does.   And now when the External Trigger checkbox is checked, when the Capture button is pressed we do *not* write 00000011 to the capture register, we write 00110000 to that register.    This has the effect that when the external trigger capture is initiated, nothing happens initially.  But then when SW4 is pressed, the 00110000 is shifted down and becomes 00000011 and the capture begins.

So now if the external trigger checkbox is checked, then pressing the Capture button *arms* the hardware for capture and the rising edge of the trigger signal makes the capture happen.  If the rising edge is not seen for about 15 seconds, then the User Interface times out.  if there is a trigger signal and the hardware is not armed, then nothing happens because 00000000 shifted down four positions is still 00000000.  So the trigger signal can be a repetitive signal and the only rising edge used is the one that follows the pressing of the capture button.

Would this functionality do what you are looking for?

Regards,

Richard P.

Morning,

First off I want to express my pleaser at using this forum. I have never had a customer support experience like this and I have to say it is fantastic. Please pass along my praise for whoever is setting this up. I can't believe I can so quickly get ahold of an engineer who knows what is going on. Thanks again for your support.

What I want to do is pixel noise analyis from a IR camera we are developing for a customer. They have a good and low noise spec and to measure it I needed a good 16bit ADC with at least 15MHz of sample speed. I found one and this board and figured I could get things to work. Espeically ifI had acess to the verilog source code and could make little modes if not purfectly suited to me.  

From your discription I understand that the FIFO is either only filling up or only beign readout, is this correct? Does continous captuer capability not work when using a external trigger? I might be able to use this in the short run if I can set things up to trigger to captuer 64KS after a tirgger signal from the camera.  Can I get  the board to reset for another capturer in say 20ms? I need to reset and be ready again for the next trigger without missing frames. This will allow me to do FFTs in MATLAB on a segment of the pixels in the image (maybe even row noise measurements).

My original plan was to set up a read enable input.  Since I don't know the upload effecency of the TWS1200 USB to be used as a data loger my first instinct was to limit the data flowing into the FIFO.  so if I added a read enable input signal and the data from the ADC was only writen top the FIFO when it was high I could set things up so I get up to 64K pixel sampels saved which is good for a FFT.

Hi,

Thanks, i am glad i could help. 

Yes, the capture memory of the TSW1200 is made to only fill up to the requested depth and then empty out.  That is all it does. The filling of the memory takes an amount of time that can easily be calculated as the number of samples requested times the sample period.   Unloading the memory also takes a known amount of time which is the amount of bits to be moved times the baud rate set for the UART out of the FPGA (plus the start/stop bit overhead).  The continuous capture option on the User Interface front panel should maybe be called 'repeated capture' because that is what it does.  Once a capture is finished *and* processed on the PC, then a new capture is initiated automatically if the continuous capture checkbox is checked.  There is a drop-down menu item to change the repetitiion rate for the continuous capture to some number of seconds, such as every second or every 5 seconds, or whatever. 

You cannot make the repetition rate for the continuous capture be too fast.  For a 16K sample capture, it takes nearly a second to capture, upload and process.  A good chunk of that is wait statements in the processing software to make sure that things process correctly and smoothly.  For 64K sample captures, the complete time is several seconds.  This could become even longer if the UART baud rate is changed from the default 460600baud down to half or a quarter of that.  There is an option for 931200baud out of the FPGA but that is not reliable.

Continuous capture has not been tested in conjunction with external trigger, but i think if used together it should work if the trigger were a very frequent repetitive trigger, so that after the capture is initiated then the trigger will let the capture begin without much delay and the repetition rate of the continuous capture wasn't violated.

We cannot begin to approach repetition rates in the 20ms range.    We also don't have a mechanism to fill some memory and suspend filling and then resume filling, like we might have been able to do if we had a gating signal.  The card was just made for capture, dump, and post-process, and the complete cycle time of that process was not intended to approach real-time.

For captures that need more depth of memory or something other than what the FPGA can do, there is the option to use a logic analyzer to catch the sample data.  That is what the eight banks of header posts are there for around the edge of the capture card.  The sample data can stream through the FPGA real time to the header posts, continuously, and then you can captrue data from the posts.  We do that with a logic analyzer when we need something large, like a million samples.  In fact, the original porpose for the hardware was to enable this function and the capture memory function came later.   Now this feature is used so infrequently that by default the header posts are off.  Pushbutton SW5 enables the output drivers for the header posts, but only for the channel selected by the GUI, so as to keep down unnecessary switching at other times. With a scope or logic analyzer you can see the sample clock  and data on one of the headers if you press SW5 and have the GUI set up the FPGA for a particular device and channel.

Regards,

Richard P.

Richard,

Well that was a diffrent answer then what I was hoping for but the header thing might give me an out as I have an Intronics Logic analyser and can set it up to gate when it captures data. I could also maybe whip something up with a Opal Kelly/CameraLink board to act as a digial camera output. I was worried that might be the case. Can I get the verilog source code/ISE project folder to maybe tinker with the FIFO and headers? I hate to lok through it but I really did like your Matlab interface and woudl prefer not to build up another board interface and use the additional USB resources of the host computer.

sdowney@bfe.com

Regards,

Stephen