• Content Count

  • Joined

  • Last visited

About StuE

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @attila as you suggested I used the python example. For some reason it wasn't working; wouldn't stream off the buffer. Something I did randomly made it work but I'm not entirely sure what I did (although since it's working it doesn't really matter) One thing, though. Looking at the waveform of the data stream running at 100kHz or 200kHz, I can see that there ARE some missed samples. I think I can work around these, but it's worth noting. I did wonder whether I could split my signal across the two AnalogIn channels and pull data down at different times to characterise how much is dropped but haven't tried it yet. Thanks for the advice re doubling the buffer size, that's the first thing I'm going tomorrow while my laser warms up. Thanks for your advice.
  2. @attila thanks, I actually found it after digging around for a while. Sorry to have asked a question without looking into things myself first.
  3. @attila Can I ask the reason FDwfDeviceConfigopen doesn't support AnalogIn/Out?
  4. Hi @attila, thanks for the suggestion to base my code off of the python examples, it's helped a fair bit but I just need to clarify something: Taking "" as a basis, it's pretty clear what the program is doing, but I'm not sure how the data retrieval from the buffer to the computer memory works in relation to this line: """ dwf.FDwfAnalogInStatusData(hdwf, c_int(0), byref(rgdSamples, sizeof(c_double)*cSamples), cAvailable) # get channel 1 data "" Say this gets called partway through the collection process, when ~2000 (eg cSamples = 2000) out of 20000 samples have been taken. Does this function pull those 2000 out of the buffer into memory and then clear the buffer? Alternatively, if that's not the case, when the buffer is filled, what happens? I'm just trying to work out where/when I need to move data around to prevent the buffer filling up, and I'm not sure what's happening. I'm tempted to move to scanShift mode, but record appears to be a better option for my application
  5. I've had the same issue in Labview, it appears that when the buffer gets filled it waits ~0.5 seconds before it's ready to refill the buffer. I was told by @attila to base my code off of the python samples and that's helped but I'm still having issues. If you plot the timestamp that you're adding to each measurement, between each 8192 samples do you see a jump in which no data has been taken? i think you need to do the same as I'm trying to do, and pull data down from the buffer while continuing to record data. I suspect that between each iteration of your while loop you've actually got a fairly large chunk of down time. Let me know if you solved this issue, I'd love to see your solution
  6. @xc6lx45Thanks for taking an interest; part of the reason we chose the AD2 was the 14bit (rather than 12bit) ADC. I have not FPGA experience; I shoot lasers. If I can get this working it's better because when I eventually move labs whoever takes over has a better chance of picking up where I left off. Having said that, if you've got a suggestion I'm willing to try it.
  7. @attila ok, I don't really know Python and was hoping to avoid that but looks like I'll need to learn. Thanks for the advice.
  8. Hi @JColvin thanks for replying. Essentially I just want to record the signal from the photodiode using the AD2 for several seconds at a high rate, so all I need is to use it like an ADC. Right now I'm accomplishing this via the oscilloscope functionality, but if there's an easier way I'd love to hear it. I did find those functions in the SDK and am trying to implement them in labview (around a million other things, unfortunately), but I assume I'll be limited to 2x8192 = 16384 samples. Ideally, I'd like to write to the buffer in a circular fashion, or even write into ram/solid state drive rather than the AD2 buffer. I'm not sure if that's feasible considering it runs via USB2, but it isn't much information. Any suggestions would be greatly appreciated; I find it frustrating that the buffer is the only thing limiting me, other than the the AD2 is great!
  9. Hi @attila thanks for the fast response. As long as I keep below the limit of the buffer it's fine, the issue is that I would like to monitor my laser in real-time, continuously, for the entire data acquisition. If I have to limit my data collection to avoid filling the buffer it'll slow my experiment down. I'm taking ~5000-1000 spectra from a fast sCMOS camera, triggered from an optical chopper, and I want to reference the laser intensity prior to my sample using this, but it needs to be able to resolve every shot of my laser running at rep rates up to 10.416kHz, outputting sub-30fs pulses. The intrinsic integration of the (relatively) slower response of the photodiode means I don't need to run at 1000MS/s, but I will need to run in the ~100-500kHz range, I suspect. 100kS/s gives me ~81ms to collect data, while each spectra takes ~163us to collect. The buffer only allows me to collect ~500 samples before needing to stop measuring, which is more than an order of magnitude less than I'd ideally collect for a decent SNR. My questions, then: 1) Is there any way to write to ram or directly to a (fast solid state) drive to circumvent this limitation? 2) In waveforms I can change the configuration to allow my buffer to take 16384 samples; can I do that in labview? That get me almost enough samples to work with post-collection averaging. It seems like not being able to continuously pull data off the device somehow really limits it. Any help you can provide would be great, this is a great device, but right now it looks like it's not going to do what I bought it for.
  10. @Bianca, from what I've seen on my AD2, there's a ~0.5s gap between groups of samples when the buffer is filled before the next set of samples collected at 100MS/s (or whatever sampling rate used). This is using Labview, so it's entirely possible that I've screwed up, and if so I'd love to know! Max F-Z asked for the maximum continuous acquisition sampling rate on the AD2, but I'd suggest that continuous means completely uninterrupted data collection. Is this possible (ie circular writing to the buffer, for example), or is it that continuous sampling is only available until the buffer is full? Even on Waveforms it looks like the gap between filled buffers is present. Cheers Stu
  11. I'm trying to use the high sampling rate of the AD2 to monitor my probe beam in a transient absorption experiment controlled in Labview. I need to run at probably between 100kHz-10MHz, depending on the response of the PD itself and how well it samples the laser, and I need to capture every pulse (the laser rep rate is between 125kHz down to 1kHz, pulses are sub 100fs visible, but the photodiode's response is slower since I'm running it in photovoltaic mode unbiased, which reduces the sampling requirement on the SD2). Ideally, I'd like to be able to collect data for an arbitrary amount of time. In reality, this means a few seconds to collect up to 10000 spectra on my spectrometer, and the accompaning data from the photodiode via the AD2. However, running the AD2 at 100kHz in a simple labview vi that just initialises the AD2 and reads the output of the analog channel I'm using, I can see via the waveform timestamp that every time the buffer fills up there's a ~570ms space before the next readout (eg timestamp of the 8001st datapoint from the 8000th datapoint, for a buffer of 8000 samples). This will screwup my data correction something fierce. I'm currently using a while loop and shift register to extract the data just to see what it's giving me for now (see attached screengrab). Is there a better way that I can readout the photodiode signal so that I'm just constantly pulling data off of the buffer, or create a circular buffer or something? I've checked the digilent examples (this code is a simplification of one) but can't see anything that helps me. Any recommendations for functions that will allow me to maximise the memory allocated for the buffers would be great, too. Cheers!
  12. I had this same issue with XP and 64-bit Labview 2017. I have waveforms installed and the installed both the waveforms and AD2 packages via the package manager. Weirdly, if I try to run anything from AD2 it doesn't work, but if I just open a vi from waveforms and THEN open an AD2 vi, it works fine. I'm concerned if I write a vi using AD2 packages it will randomly throw errors because of this behaviour. Has anyone else seen this? It didn't happen with 32-bit Labview 2017, so I assume it's related to the 32-bit vs 64-bit issue Kamran is seeing. Kamran, can you try to see if you get this too, please?