Search the Community

Showing results for tags 'acquisition'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • New Users Introduction
    • Announcements
  • Digilent Technical Forums
    • FPGA
    • Digilent Microcontroller Boards
    • Non-Digilent Microcontrollers
    • Add-on Boards
    • Scopes & Instruments
    • LabVIEW
    • FRC
    • Other
  • General Discussion
    • Project Vault
    • Learn
    • Suggestions & Feedback
    • Buy, Sell, Trade
    • Sales Questions
    • Off Topic
    • Educators
    • Technical Based Off-Topic Discussions

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 3 results

  1. Hi, and thanks for the support so far. After a lot of experimenting and reading the help, I'd like to understand the "envelope" of possible triggered, repeated, logged acquisitions, which can run unattended for days or weeks. We need to leave a system in an inaccessible location and log at least 4 analog channels with at least 100 KHz sample rate, for a time of at least 100 usec after the trigger occurs for each triggered event. We believe these events have a time frame of 5 or so 60 Hz cycles, so that's 85 msec post-trigger and we'd like a cycle or two (16 or 32 msec) of pre-trigger. These events are rare and not on a predictable timetable. So we are rather searching for a needle in a haystack and we hope to find evidence it exists. Here I am talking about Scope function (Logger's sample rate of 100 msec is too slow for this case) and there are still many details I don't claim to understand. But since I need to make a report of what is possible with AD2, here goes. Record mode can capture much longer numbers of samples Device manager determines what is possible (e.g. Patterns) but some things seem ignored (e.g. Scope samples) Sample rate, number of samples, and pre-trigger samples are set with the "Config" button with the green diode-like symbol. This is intuitive with a % of total acquisition setting for trigger location. Zooming and scrolling in the display window does not change what you set with the Config button so subsequent captures use the same config. Actual sample rate and length is limited by USB connection speed to the host PC. On a 1.7 GHz dual core Linux with 16 GB RAM and SSD, it seems to be limited to 200 KHz sample rate. At 100 KHz we can capture up to 10 M samples, for a 100 second acquisition Acquisition in "record" mode can only be started with a button click and cannot be triggered by normal scope triggers even though those settings are still present on the GUI. Pressing Record is the only way to start capture and that immediately captures one acquisition. It can't wait for trigger conditions to be met. An acquisition can be saved using the logging settings if set for "each triggered acquisition", even though it really wasn't 'triggered'. Also "each acquisition" works. In record mode, if Device Manager is set to allow it, Patterns can work to use Scope Detector to make an external trigger output on a DIO pin, and this will trigger on the stated conditions but only *after* the Scope Record button is clicked. And I also have to remember to separately click the Pattern Run button or its output won't generate This can only record a single event and you have to click on the Scope Record button to start the acquisition. So Record mode won't work for us. In "repeated" mode, the scope will use the trigger settings Device Manager determines how many samples can be captured: 8K or 16K are the highest options of the 6 available and those seem to be the only ones possible. so it can wait until trigger conditions occur, then capture each time the trigger conditions are met. Sample length is a max of 16384 samples Settings - Options can make one of the trigger pins "Scope" which generates a single rising edge trigger per acquisition, to trigger other AD2s or other logging devices Sample rate and pre-trigger are confusing in repeated mode. It appears they can be set in the Time dialogs, also number of samples, pre-trigger (the "position" setting), but this interacts with the scope display screen: zooming and panning changes your intended settings. There seems to be no way to lock them like on a traditional desktop DSO. It's nothing like Config in Record mode. The display has 10 divisions so if I want to trigger at 2 divisions I'm better off to drag the white triangle on the top of the scope display to 2 divisions from the left. In repeated mode, Trigger takes place at time 0 and pretrigger time is negative. So for 16K samples at 100 KHz, that is about 16 msec/div. Trigger two divisions from left makes the leftmost time -32 msec and Time "Position" 48 msec, which doesn't make any sense to me. Time Base is 16 msec/div as expected. Don't dare zoom in the scope display or the time settings will also change, changing the next triggered acquisition! If you do this by accident its a tedious, multi-click process to get back to the settings you intended. At 100 KHz 16384 samples is 168 msec, long enough for us, we hope. At 8K samples we'd have to drop to 50 KHz samples Clicking Run button means scope will wait for trigger satisfied, then log both channels to PC memory, auto-incrementing the file name File name can include day hour min sec which is handy. Be careful entering this information or Waveforms will crash. I'll post a bug elsewhere. Full timestamp and setting values are included in the .csv log file You specify how many acquisitions to save, at which point logging halts. 1,000,000 is the largest number I could set. Saving workspace sometimes causes a ghost progress window which can be cleared with another save. So Repeated mode will work for us, with the limits of 16K @ 100 KHz samples Each 2-channel 16K log file is about 984 KBytes. As each 16K sample file is a bit under 1 MByte, you get 1000 log files per GB. Summary: For unattended, auto trigger and acquisition of multiple events, and logging to a computer file, "repeated" mode is the only option. We can log two analog channels per AD2, plus digital inputs if we wish. External trigger output: one rising edge per triggered acquisition. Trigger goes low at end of acquisition. Trigger other AD2s or external equipment. Samples per acquisition are 16K or 8K Logging can occur up to the maximum value you set (up to 1 M acquisitions), or the PC runs out of disk space, at about 1 MByte per 16K acquisition.
  2. Because the ScanScreen and ShiftScreen acquisition modes ignore triggers, how do I know precisely when they start the first acquisition? Is it possible to start the analog and digital scan-acquisitions simultaneously to ensure that both data streams are reading/displaying with a common time axis? Or do I misunderstand how these types of acquisition work? My previous approach was to generate a slow pulse and use the rising edge as a trigger to simultaneously start single acquisitions on both analog and digital scopes, then plot and repeat on the next pulse. But this is tedious, I can't get it to play nice with threading, and it means I only get snapshots of my data instead of seeing the whole stream. Thoughts?
  3. I am sending synchronized, phase-shifted pulses with the AWG on both AnalogOut channels on the Discovery2, using a custom application I'm writing in python. I am feeding the AnalogOut directly back to the AnalogIn with no additional hardware involved. I am trying to read the two AWG signals using the AnalogIn channels, but I can't get Channel 2 to report the signal. Instead, both signals are adding together and displaying as coming from channel 1, with the expected channel 2 signal showing up as negative voltages on channel 1. How do I separate the two signals? This is the chunk of code I am using to record samples and plot (mostly copied from the provided code samples): #configure analog in self.dwf.FDwfAnalogInFrequencySet(hdwf, c_double(int(hzSys.value/(100*self.xRate)))) self.dwf.FDwfAnalogInBufferSizeSet(hdwf, c_int(4000)) self.dwf.FDwfAnalogInChannelEnableSet(hdwf, c_int(0), c_bool(True)) self.dwf.FDwfAnalogInChannelRangeSet(hdwf, c_int(0), c_double(5)) self.dwf.FDwfAnalogInChannelEnableSet(hdwf, c_int(1), c_bool(True)) self.dwf.FDwfAnalogInChannelRangeSet(hdwf, c_int(1), c_double(5)) #begin acquisition self.dwf.FDwfAnalogInConfigure(hdwf, c_int(1), c_int(1)) #collect data sts = c_int() while True: self.dwf.FDwfAnalogInStatus(hdwf, c_int(1), byref(sts)) if sts.value == DwfStateDone.value : break time.sleep(0.1) #read data rg1 = (c_double*1000)() #rg = pointer to allocated buffer to copy the acquisition data rg2 = (c_double*1000)() #rg = pointer to allocated buffer to copy the acquisition data self.dwf.FDwfAnalogInStatusData(hdwf, c_int(0), rg1, len(rg1)) # get channel 1 data self.dwf.FDwfAnalogInStatusData(hdwf, c_int(1), rg2, len(rg2)) # get channel 2 data #set up plot self.canvasX.figure.clear() plt1 = self.canvasX.figure.add_subplot(211) plt2 = self.canvasX.figure.add_subplot(212) #plot data rgpy1=[0.0]*len(rg1) rgpy2=[0.0]*len(rg2) for i in range(0,len(rgpy1)): rgpy1=rg1 rgpy2=rg2 plt1.plot(rgpy1, 'b') plt2.plot(rgpy2, 'r') self.canvasX.draw()