clf

Thanks @JColvin. Can those additional copies be installed on other computers? The wording of Section 5 of the EULA is a bit confusing to me. Chris

1) How frequently should an Analog Discovery 2 be recalibrated? 2) Can devices be sent to Digilent for recalibration, or can Digilent recommend a calibration lab? Thanks in advance! Chris

The EULA presented during installation of the WaveForms software indicates that only one copy of WaveForms is permitted to be installed per hardware product. How can additional WaveForms licenses be obtained? Thanks in advance! Chris

Bought an additional AD2. USB cable fit perfectly, could definitely feel it snap into place.

Hello @attila, Could you kindly cite a source for your above statement "BNC is 'by definition' single ended", please? I offer the Tektronix THS720 oscilloscope [1, page "1-2"] as a particular counterexample, and the Tektronix Application Note "Fundamentals of Floating Measurements and Isolated Input Oscilloscopes Application Note" [2] as a general counterexample. From my perspective, it's much more desirable to have a versatile instrument that maintains its differential channels all the way through: you can easily reconfigure them to have a common ground by tying their "-" inputs together; taking channels with a common ground and making them differential is a much uglier problem, as highlighted by the other posters in this thread. Dug into this topic when a Hackaday article [3] elicited a discussion in its comments of oscilloscope channels with common grounds vs. oscilloscope channels with isolated grounds. Thanks in advance, Chris [1] https://www.tek.com/oscilloscope/ths710-manual/ths710-ths720-user-manual [2] http://in.tek.com/dl/3AW_19134_2_MR_Letter.pdf [3] https://hackaday.com/2017/10/18/testing-brushless-motors-with-a-scope-or-a-meter/

@peter64, please: 1) post a photo of your entire setup that clearly shows all connections 2) post a photo of the switch settings on your uCurrent Gold 3) indicate the range of resistances your sensor is expected to produce - Chris

When is Digilent planning to release Analog Discovery and Digital Discovery variants with USB 3.x support? I'd love to see higher streaming rates in these devices. Thanks in advance, Chris

As a general rule of thumb, you can resolve the errors by resolving the associated problems. For a more descriptive answer, please post a more descriptive question. Chris

Thanks @attila. I was looking at a time scale that was off by orders of magnitude. I hadn't realized the frequency parameter had different meanings for "funcCustom" (frequency = repeat rate of waveform) versus "funcPlay" (frequency = sample rate). This fact is mentioned, though, in the the SDK Reference Manual's entry for FDwfAnalogOutNodeFrequencyInfo(). For anybody curious, I've attached Waveforms 2015 oscilloscope screenshots of the AWG "funcCustom" and "funcPlay" renderings for the same sample vector. Screenshot "awg_custom_[...]" was produced using the "analogout_custom" C sample program mentioned earlier, and shows the entire waveform repeating at frequency=10kHz. Screenshot "awg_play_[...]" was produced by a slightly modified version of the "analogout_custom" program, where "funcCustom" was replaced with "funcPlay", and shows the samples being output at frequency=10kHz. Chris

Hello All, I'm playing around with the "analogout_custom" C sample program that comes with the Waveforms SDK (/usr/share/digilent/waveforms/samples/c/analogout_custom.cpp). I've made some observations that don't align with my expectations. I'm hoping one (or more) of you could kindly offer some insight on what is happening. I'm running libdwf.so.3.4.7 on an Ubuntu 16.04 x86-64 machine. I have an Analog Discovery 1 and an Analog Discovery 2 wired such that ad1.aout1 --> ad2.ain1+ ad1.gnd --> ad2.ain1- I'm playing the waveform out through the Analog Discovery 1 and the "analogout_custom" program. I'm capturing the resulting waveform through the Analog Discovery 2 and the Waveforms 2015 oscilloscope. I've attached my Waveforms 2015 oscilloscope configuration file. I've also attached a screenshot of the Waveforms 2015 oscilloscope showing the results of two runs of "analogout_custom". Channel 1 (yellow) displays the waveform produced by my most recent run of "analogout_custom". Reference 1 (gray) displays a waveform that was captured on Channel 1 during a prior invocation of "analogout_custom" and saved off as a reference waveform. Expectations: 1) A waveform consisting of 4096 samples played at 10 kHz should have a duration of ~0.5 seconds. 2) The waveform should play once, given the default of AnalogOutRepeat = 1. 3) The waveform should begin playing at the first sample, which always has the same value. 4) The generated waveform should be consistent for all invocations of "analogout_custom". Unexpected observations: 1) The waveform has a duration of ~1.8 seconds, as highlighted by the cursors' delta X in the oscilloscope screenshot. 2) The waveform plays more than once, as indicated by the multiple peaks on the yellow waveform in the oscilloscope screenshot. 3) The waveform does not begin playing at the first sample, as indicated by the different values at x=0 for the yellow and gray waveforms. 4) The played waveform is not consistent between invocations, as indicated by the yellow and gray waveforms not aligning. Here's the "analogout_custom.cpp" source code for your convenience: #include "sample.h" int main(int carg, char **szarg){ HDWF hdwf; double rgdSamples[4096]; char szError[512] = {0}; // generate custom samples normalized to +-1 for(int i = 0; i < 4096; i++) rgdSamples = 2.0*i/4095-1; printf("Open automatically the first available device\n"); if(!FDwfDeviceOpen(-1, &hdwf)) { FDwfGetLastErrorMsg(szError); printf("Device open failed\n\t%s", szError); return 0; } printf("Generating custom waveform for 5 seconds..."); // enable first channel FDwfAnalogOutNodeEnableSet(hdwf, 0, AnalogOutNodeCarrier, true); // set custom function FDwfAnalogOutNodeFunctionSet(hdwf, 0, AnalogOutNodeCarrier, funcCustom); // set custom waveform samples // normalized to ±1 values FDwfAnalogOutNodeDataSet(hdwf, 0, AnalogOutNodeCarrier, rgdSamples, 4096); // 10kHz waveform frequency FDwfAnalogOutNodeFrequencySet(hdwf, 0, AnalogOutNodeCarrier, 10000.0); // 2V amplitude, 4V pk2pk, for sample value -1 will output -2V, for 1 +2V FDwfAnalogOutNodeAmplitudeSet(hdwf, 0, AnalogOutNodeCarrier, 2); // by default the offset is 0V // start signal generation FDwfAnalogOutConfigure(hdwf, 0, true); // it will run until stopped or device closed Wait(5); printf("done\n"); // on close device is stopped and configuration lost FDwfDeviceCloseAll(); } Thanks in advance! Chris (This is a repost. Original post somehow ended up in Home > Digilent Technical Forums > Scopes & Instruments > WaveForms Live and OpenScope feedback.) analogout_custom.dwf3scope

I've posted a makefile for building the sample programs at: https://github.com/cfeyer/cfeyer-makefile-dwf-c-samples-project/ Chris

I've created a project on github at https://github.com/cfeyer/gr-dwf-analog-discovery-2-community-project Chris

Looks like I've been writing "GNU Radio" wrong (it's not "GnuRadio"). Also, here's their code style guide: https://wiki.gnuradio.org/index.php/Coding_guide_impl

@fusionimage, From Gqrx's design documentation at [1]: Gqrx is heavily based on GNU Radio using both DSP blocks as well as its famous runtime engine. [...] At lowest level we have various DSP and I/O blocks. These can be blocks from GNU Radio, gr-osmosdr or even implemented in gqrx. You've mentioned GnuRadio and Gqrx by name as desired applications. It's looking like we can satisfy these use cases by implementing a plain ol' GnuRadio module for the AD2. Chris [1] http://gqrx.dk/doc/gqrx-design#more-136

@D@n, you were correct when you previously stated that we'll need a "sync" block. Both source and sink blocks are implemented in code by inheriting from the "gr::sync_block" class. From [1]: "Sources and sinks are derived from gr::sync_block." Building on my previous post, we'll want to start by implementing: an "Analog Discovery 2 Analog Source" class that inherits from GnuRadio's gr::sync_block class, configures its gr::sync_block with an I/O signature of one 16-bit integer output, and sources its stream from one of the AD2's analog input channels an "Analog Discovery 2 Analog Output" class that inherits from GnuRadio's gr::sync_block class, configures its gr::sync_block with an I/O signature of one 16-bit integer input, and sinks its stream into one of the AD2's analog output channels @fusionimage, I looked at the project wiki for "gr-osmosdr" at [2]. It states it is "primarily being developed for the OsmoSDR hardware", but supports some other devices as well. From this, I have the impression that those other devices are supported in gr-osmosdr as a result of scope creep rather than of design or necessity. I'm thinking the AD2 support should be implemented as its own module. Can you explain the specific features that you were seeking to gain by integrating with gr-osmosdr? What software beyond GnuRadio are you seeking compatibility with? In case anybody is curious why I specified 16-bit integer interfaces for the source and sink, take a look at GnuRadio's data types in [3]. ADC outputs and DAC inputs are discretely valued and of fixed finite precision by virtue of being digital; they map naturally to integers, which are also discretely valued and of fixed finite precision. I specified 16 bits because that's the smallest / least expensive integer precision supported by GnuRadio that can preserve the precision of the AD2's 14-bit ADC and 14-bit DAC. I did not specify a complex integer type because we will only be able to interface real-valued sequences with a given AD2 channel. I did not specify a float type because they are more expensive than integers and, in this situation, don't provide any additional value over integers. Chris [1] https://wiki.gnuradio.org/index.php/OutOfTreeModules#Sources_and_sinks [2] https://osmocom.org/projects/sdr/wiki/GrOsmoSDR [3] https://wiki.gnuradio.org/index.php/Guided_Tutorial_GRC#2.2.5._Examining_the_Output