Alanf

I mean adding a math channel in Waveforms app. yes I can do this in a custom app.

OK so I have connected it to real signal and found it works way better than I expected. I originally calculated the 20Mhz sample rate based on the specs of the source signal max slew rate but it turns out the actual slew rate is no where near that figure and the Discovery 2 capturing at 1.6Mhz gives an excellent result (10ms of capture). At 800khz is also very good. I was wrong with the 14bit, its actually 12bit. Do you know much about the math functions? Can I use math to show the delta change between samples on a channel?

Thanks @reddish I think you are right in saying that the Digilent devices are not well suited. I though that the specs on the pro say 1Ms (my assumption was 1million samples buffer) but you are saying its only 65k buffer which as you say is not enough either. I do have a low-end oscilloscope but its resolution of data is (can I say crap) not as good as the Discovery Pro 2. The resolution I need is 14bits over -10v to +10v. I was also thinking that the analogue waveforms I am trying capture are frame based (repeat every 20ms) so in theory if the waveform is static (in alot of test cases it is) then I could capture the data in slices (capture one buffer at a time) using offset from trigger point and add them together. Not ideal but in theory might work. Anyway thanks for your help with this. Alan

Thanks Sidney, That makes more sense now and answers the questions to the timing. I need to capture about 20ms of analog data from two channels at 20MHz min and trigger from an external source or one of the channels so looks like the Discovery 2 can’t do that with its buffer size. Looks like the Pro has a much larger buffer so will probably work better. Alan

Hi, I have a Discovery 2 and have trialled the Waveforms application on Windows and it is very nice however I need to be able to get data out of it at 20MHz. The most that Waveforms can do is able 3-4MHz. I have created a standalone program based of the example analogin_acquisition.cpp using the SDK and found that the FDwfAnalogInStatusData16 call takes less than about 200us to read and in most cases much faster. The buffer is 8192 in size so should take 409us to capture at 20MHz so in theory we should be able to capture data at 20Mhz easily. A single acquisition works nicely. My issue however is that if you use the ScanScreen mode then to use the FDwfAnalogInStatusIndexWrite to get the location of the buffer pointer (I assume this is the pointer where the Discovery 2 is up to) then you have to first call FDwfAnalogInStatus. A call to FDwfAnalogInStatus followed by FDwfAnalogInStatusIndexWrite takes about 2.3ms. Any thoughts? Why is a read of data much faster than a call to get the status? I have used the internal Windows QueryPerformanceCounter to measure 409us frames and read the data in and it seems to work fine at full speed (at least for 20ms). Assumption that the Windows performance counter is reasonably accurate. Still yet to validate the captured data as this is on my desk - not in the lab. Update: OK the data is not valid. it looks like it copies the same data over and over. So it looks like using ScanScreen mode, you still have to use FDwfAnalogInStatus to update the buffer.