• Content Count

  • Joined

  • Last visited

About Engineer

  • Rank

Recent Profile Visitors

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

  1. Hi @AlexanderGDean, We have similar issues in our lab. The best solutions I have been able to come up with are to: 1) Use very high quality USB cables with integrated chokes (Tripp Lite USB 2.0 Hi-Speed A/B Cable with Ferrite Chokes (M/M) 3-ft. (U023-003)) 2) Build a custom enclosure for the entire AnalogDiscovery - PC system. We have an embedded PC and the AnalogDiscovery inside a custom enclosure. I recommend protocase ( We use 50 ohm thru-panel BNC connectors which are grounded to the enclosure to make connections to our input sources. Even in this configuration we have to ensure that there is a very low impedance between each side of the enclosure and ground (1-2 ohms). This isn't a perfect solution, but it is a dramatic improvement over the plastic enclosure for the AnalogDiscovery. As a side note: be careful if you have any sensitive equipment attached to the AnalogOut channels. Disconnecting the USB cable and/or resetting the USB connection in software can cause those channels to go high for ~10ms. Please update us if you find any new solutions that improve this issue.
  2. Thanks Attila, That seems to work. What is the default idle state? Is there a reason why the analog out does not idle at 0V by default?
  3. Hi Tetus, I have a similar issue with this 'pop' damaging external circuitry. One solution is to use an opamp or buffer with a positive enable pin in between the AnalogDiscovery and your other components. You can then use the digital IO on the AnalogDiscovery to enable the opamp after this 'pop' has occurred. You can also disable the opamp before turning off the analog channels. However, this same pop occurs when the USB cable is disconnected from the AnalogDiscovery, so you will have to ensure that this cannot happen.
  4. Hi, I am having a trigger issue with the AnalogDiscovery (1 and 2) running DWF version 3.3.7. I set the analog in trigger threshold to a double value between 0.1 and 5.0 V [self.dwf.FDwfAnalogInTriggerLevelSet(self.AD1, self.input_trigger_voltage)] then I set the analog in trigger length to 1 microsecond [ self.dwf.FDwfAnalogInTriggerLengthSet(self.AD1, c_double(0.000001)) ] and configure the device. Then when I run diagnostics to check these values the analog discover returns a trigger length and a trigger voltage of 0.000001. Is there a reason why ...TriggerLengthSet is affecting the trigger voltage? ::configuration of AnalogIn:: #set up acquisition self.dwf.FDwfAnalogInFrequencySet(self.AD1, c_double(self.frequency)) self.dwf.FDwfAnalogInBufferSizeSet(self.AD1, c_int(self.bufferSize)) #enable both channels self.dwf.FDwfAnalogInChannelEnableSet(self.AD1, c_int(0), c_bool(True)) self.dwf.FDwfAnalogInChannelEnableSet(self.AD1, c_int(1), c_bool(True)) #set input range on both channels self.dwf.FDwfAnalogInChannelRangeSet(self.AD1, c_int(0), self.input_range) self.dwf.FDwfAnalogInChannelRangeSet(self.AD1, c_int(1), self.input_range) #self.dwf.FDwfAnalogInChannelRangeSet(self.AD1, self.input_channel, self.input_range) #set up the acquisition mode self.dwf.FDwfAnalogInAcquisitionModeSet(self.AD1, acqmodeSingle) #single buffer acquisition #set up trigger self.dwf.FDwfAnalogInTriggerSourceSet(self.AD1, trigsrcDetectorAnalogIn) #one of the analog channels self.dwf.FDwfAnalogInTriggerChannelSet(self.AD1, self.trigger_channel) #set the trigger channel self.dwf.FDwfAnalogInTriggerAutoTimeoutSet(self.AD1, c_double(0)) #disable auto trigger self.dwf.FDwfAnalogInTriggerTypeSet(self.AD1, trigtypeEdge) #set the trigger method to edge detect self.dwf.FDwfAnalogInTriggerConditionSet(self.AD1, trigcondRisingPositive) #set condition to rising edge self.dwf.FDwfAnalogInTriggerFilterSet(self.AD1, filterDecimate) #look for trigger on each ADC conversion self.dwf.FDwfAnalogInTriggerLengthConditionSet(self.AD1, triglenLess) self.dwf.FDwfAnalogInTriggerLengthSet(self.AD1, c_double(0.000001)) #for some reason this is changing the trigger level self.dwf.FDwfAnalogInTriggerLevelSet(self.AD1, self.input_trigger_voltage) ::Analog in Diagnostics:: dwTriggerLevel = c_double() self.dwf.FDwfAnalogInTriggerLevelGet(self.AD1, byref(dwTriggerLevel)) print("The trigger is set at " + str(dwTriggerLength.value) + "[V]") dwTriggerLength = c_double() self.dwf.FDwfAnalogInTriggerLengthGet(self.AD1, byref(dwTriggerLength)) print("The analog trigger length is: " + str(dwTriggerLength.value))
  5. Hi Attila, How can we expect the system to behave if it is configured with both: FDwfAnalogInConfigure(hwdf, c_bool(True), c_bool(True)) FDwfAnalogInTriggerAutoTimeoutSet(hdwf, 0) This seems to be contradictory by enabling the auto-trigger in the ...Configure command, then disabling the auto-trigger in the ...TimeoutSet command. Thanks!
  6. Hi ADal, Thanks for replying. Unfortunately I am not quite sure what you mean. I am essentially trying to implement the 'burst' feature found on most arbitrary function generators. For example, I want to emit two cycles of a sine wave and then have the analog output return to 0Vdc for one second then repeat. The code above works perfectly with DWF 2.7.5. However when DWF 3.3.7 is installed the analog out returns to ~5Vdc rather than 0V after the waveform is emitted. If the frequency of the the waveforms is high (e.g. 1MHz) then I cannot reliably programatically turn off the AWG fast enough because Windows is not a real time operating system and coded sleep functions are not accurate below 10-20 ms. It appears that for some reason the implementation of FDwfAnalogOut* was changed in 3.37 so that the default 'Ready' state sets the analog voltage to some value other than 0.0V, which is completely illogical.
  7. I am working on a custom python package for the analog discovery (1 and 2). When I run the software on a computer with DWF version 2.7.5 and an original Analog Discovery it runs without issue. However, when I run this on a different computer with DWF version 3.0+ and either Analog Discovery (1 or 2), the analog output stays high after a waveform has been run. The code is written to repeatedly output a specific waveform (sample) a number of times (numCycles) then return to zero output. Has something specifically changed in the DWF file which would result in this behavior? Below is a code snippet: #enable analog output self.dwf.FDwfAnalogOutEnableSet(self.AD1, channel, c_bool(True)) #set function to Arbitrary self.dwf.FDwfAnalogOutFunctionSet(self.AD1, channel, funcPlay) #define output function self.dwf.FDwfAnalogOutDataSet(self.AD1, channel, sample, c_int(len(sample))) #define output frequency (Each data point represents 1 us, so f=1e6) self.dwf.FDwfAnalogOutFrequencySet(self.AD1, channel, c_double(frequency)) #set amplitude to 5V peak self.dwf.FDwfAnalogOutAmplitudeSet(self.AD1, channel, c_double(5)) #tell system how long each cycle is self.dwf.FDwfAnalogOutRunSet(self.AD1, channel, c_double(runTime)) #tell the system how many cycles to send self.dwf.FDwfAnalogOutRepeatSet(self.AD1, channel, c_int(numCycles)) self.dwf.FDwfAnalogOutRepeatTriggerSet(self.AD1, channel, c_int(1)) #tell the AD to output data self.dwf.FDwfAnalogOutConfigure(self.AD1, channel, c_bool(True))