P. Fiery

  • Content Count

  • Joined

  • Last visited

About P. Fiery

  • Rank

Recent Profile Visitors

270 profile views
  1. Pajda, I implemented isolation a few months ago and have had instant and durable operation at the highest speed the AD2 is capable of by using this device: https://hifimediy.com/product/hifime-high-speed-usb-isolator/ I haven't stressed it by using it to measure across any particularly challenging reference frame differences like a circuit referenced to a high voltage or for example the high side AC line, but it does work reliably and at high speed, (not just full speed) and does provide the ground noise isolation I need in my work. I have no connection to this company other than having bought one if these devices.
  2. The AD2 specs and overall circuit performance is excellent. A mathematically perfect 14 bit A/D would have exactly identical bit steps and a flat noise floor. Delta sigma converters do have effectively identical bit steps, but currently they top out at about 10 MSPS. The AD9648 appears to be a clever "successively approximating flash converter" running at 100 MSPS. It specs no missing codes, which implies it is monotonic but like all such converters, the actual size of each LSB step is not guaranteed to be the same. This means for example that a given LSB can represent a change of say 100 uV with the next step making up the difference with a 540 uV change, etc. The average step size can thus be 320 uV, (as I recall), but the individual steps can be uneven. The particular spectral signature this creates in the noise floor for a given input signal likely varies device to device, all within the spec though. There may be other factors at work too due to undisclosed details of the device, but looking at the AD9648 data sheet spectral examples with this in mind helps them make sense to me. All of this is way down below FS, and is really excellent. It is useful to at least have some approximate insight into why things look the way they do. Similar real-world considerations probably apply to the DAC in the AWG.
  3. Attila, yes I see what you mean. The piecewise corner artifacts of an AWG, (or any other DAC for that matter), generate harmonics that are somewhat similar as a spectrum signature as a Fourier glitch produces, and of greater amplitude it seems. I didn't think about the source of the sine wave when I gave my advice. (Which, Kkubik, is not wrong advice, but in this case it's not the main cause of what you see in the spectrum.) For audio work, it's hard to beat this ancient circuit realized with an excellent opamp: (From Analog Devices LT1037 overview) This probably won't have any high harmonics to speak of; the 0.0025% should consist mainly of low-order harmonics due to the time constant of the lamp resistance. However as the AD2 has a 14 bit digitizer, the quantization noise floor limits the measurable THD floor and will create similar harmonic artifacts. This resolution can be further improved with other signal processing techniques applied both before and after the FFT.
  4. I can offer one possible reason for what you are seeing: The test signal is one cycle of a 1 KHz sine wave. For the spectrum analyser to "see" this as presented on the scope display, the entire waveform must fit exactly within the data record input to the spectrum analyser. However, the spectrum analyser record length, (number of samples), is probably of a length that does not contain only the entire waveform and no part of the wave before or after. This means that the actual waveform you are doing an FFT upon is a whole sine wave + some segment of either the next or the preceding sine wave or both. This may be the "Fourier glitch" you are seeing the results of within the blue circle. The same glitch happens with any non-integer number of cycles within the FFT data set. The available windowing functions can help with this, but or course each different window has a different set of trade-offs.
  5. This latest beta, (and the previous), have been very good. I have no complaints, and no "must have" additional requests. The ability to control the FFT window instance is welcome, thank you.. There is still a bug though that manifests on my Windows 7 desktop system: When exiting the waveform application in any of the usual ways of closing an app, the script window closes right away. The plot child windows of the script don't close properly, nor does the main Waveforms window. This happens whether I choose to save the project on exit or not. The windows hang, the cursor hourglasses, and the usual microsoft error window allows me to close the app. There seem to be no negative side effects to this. One thing I've noticed is that some variables declared without var in root scope will retain their values from run to run. I now realize this is probably because they are not just global but bound to the parent window of script. Specifically: load the waveforms app write and run this code: testvar = 10; edit the code to this: print(testvar); // testvar = 10; run this revised code. The output is "10". Adding "use strict" to the file ahead of this doesn't flag this as an error. Should "use strict" work as in the JS standard? On further experimentation I now realize that all variables and constants declared at rood scope retain their values from run to run. That is, you can run once, and then print any of these variables in the code before they are declared and the output will be the values they held at the end of the previous run of the script. After reading up on the inner details of variable scope in javascript, I've placed all my code into functions. (All my functions were written as 'pure' so this wasn't too difficult.) There are a very few variables and several constants still declared with var and const at root scope and therefore properly global. However, these do persist from one run to the next. The plotn.Yn.data arrays persist too, and these may be very large in my script application. Is this behavior as intended? Could it be the reason for the crash on exit bug I'm experiencing?
  6. In analyzing the signal pictured below, I want to ignore the first few cycles and focus on the remaining cycles. I'm using the AD2 scope and Waveforms with the scope input set to 500mV/div where the effective resolution is still on the high setting. The signal amplitude is adjusted externally to fit the cycles of interest within +/- 2.5 volts to get the full benefit of 14 bit resolution, but this means the initial cycles are clipped and distorted by the AD2 input circuit and the extremes of the A/D range. It seems the inputs are well behaved with very fast recovery, and in reading the manual it seems there is no danger in damaging the AD2 inputs possible. (The overdrive is 3 volts at most, and the average time spent in overdrive during repetitive bursts is less than 5% of the test time.) My question: Could clipping the first few cycles subtly compromise the A/D accuracy of immediately subsequent conversions of the signal within the A/D range? It doesn't seem like it does. (Using 100 MHz sample rate, and each burst event is < 150 us. )
  7. I think you'll find the AD2 manual answers your questions very thoroughly. Scroll down into the details of the scope input gain staging, etc. https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/reference-manual?s[]=schematic&s[]=analog&s[]=discovery&s[]=2
  8. Attila, this seems fine so far and thank you for this great work. The "all files" button in the search bar executes a "replace all" across all open script files. I discovered this when I had the letter "i" as the Find argument and nothing as the Replace argument. Clicking 'All Files' deleted all instances of the letter "i" in both my script files. Logical, but yikes. Perhaps both "Replace All" and "All Files" should include a "Confirm?" interaction? Nothing seems to be broken in this latest rev. I'll be using this every day for the next while. Thanks again!
  9. Attila, thanks again, this is just great. I'm sure everyone using script will welcome these features. I've used most of these new features for a few hours now. Within the Waveforms app itself everything seems to be fine, but saving and exiting exhibit the following misbehavior: The waveforms app crashes during exiting. I didn't check closely enough to see if it saves the project before crashing. The previous "save project" and "save .js" functionality works correctly. However, the new "save all" item does the following: It asks for a folder, and writes to this folder my two script tabs out under the names I'm using. No problem. However, the next time I do this, the result is shown below. "Functions" and "Main" are meant to be pairs within one code version so of course the copy suffix should match. Upon the third use of "save all", nothing at all seems to happen on disk. In the "bug or feature?" department, pasting text into the new Find: <text> search feature immediately causes the first instance of the text to be selected and highlights all other instances in the script tab window that has focus. Note that this first search occurs consequent to the paste, not due to clicking "Next". (Not really a problem, perhaps it's the more efficient behavior. ) Switching to the other tab again automatically selects the first and highlights the remaining instances of <text> found there. If user searches for something else in the 2nd tab window, this different text is found as expected. However, upon returning to the first tab the original <text> is still highlighted. This may be good and useful behavior. Initiating another search clears the highlight. Finally, the "All Files" toolbar item is part of the search suite, but it seems to do nothing at all, not even in the context I detailed just above. CTRL+F invokes "find" - great! And upon CTRL+F any text in one's copy buffer is pasted into Find and instantly found. Perfect! I discovered child windows in the script editor can be surfaced or hidden with a right-click in the upper menu area. Plot1 was there, unchecked so that's all good. Clearing the output window - ah, relief, thank you! With these features, I found working on a complex script to be fast and efficient. Oh: FYI. I'm running Windows 7 still. It's fully updated, but it's not Windows 10. I will be making this project portable soon on a Win 10 laptop. (I dread having to move my desktop to Win 10. I have so much software on this machine and it all works perfectly. Some is older XP engineering software that is second-nature to me now. Alas.)
  10. Attila, thank you, this works. And thanks for pointing out the script hints in the status bar; all this time and I didn't notice them. Two additional things would make this coding environment sufficiently "complete" IMO: Within the script editor, please give us a hot key to sequence between different script tabs. CTRL+TAB would be consistent across the app. OR: If possible, provide separate simultaneous instances of the script editor so one can view and edit all script files at once. Of course, a search and replace would be great to have. It's the one editor function I truly miss. I cut, paste to notepad, and do search and replace there as a workaround. Helpful things: A way to clear the output window, other than quitting and restarting. If user accidentally closes a plot window, say PLOT1, it seems there is no way to bring back PLOT1. You have to instantiate a new plot, which will be automatically PLOT2, and manually set the axis as they were, and manually change any references from PLOT1 to PLOT2. The "safest" practice is to save everything: the individual scripts as .js, the script project, the scope project, waveform project, etc. This way, if user closes some child windows and saves the whole waveforms project that way, everything can be reassembled. Backups are good practice but one can still lose one's current post-backup work with a couple of thoughtless clicks perhaps to make screen space for multitasking. I'm saving individual things now manually whenever I've edited something. A "SAVE ALL" command would be great. Even without any of this, Waveforms + AD2 has about doubled my productivity as a consultant. And I have only begun to leverage it. So: Thank you for this great product! Two heads are useful:
  11. Attila you may already be aware of all the following, but in the hope of being helpful I offer a bug report on this beta release: The overall waveforms project file fails to store the window position of the script. Not sure this is so if the script is docked, but definitely when it is not docked. Minor issue. If the user has renamed script File 1 and File 2, the overall waveforms project file fails to store these new names. In general, the file save command within the script window functions like a file export. It seems that once the script is saved this way, no further reference is made by Waveforms to this saved .js file. Consistent with #3, in the scenario where user has file 1 and file 2 and associated tabs, and user has checked the 'include' box for file 2 in the file 1 tab, removing file 2 maintains it's functionality in the script. The file tabs disappear though. Modifying file 2.js externally with another editor has no effect, so there must be a local copy in memory. Worse, if waveforms is now closed and reopened, the 'include' functionality is gone, along with file 2. (Though if the user saved it, it is on drive. ) And by the way, if one has un-docked the script and closes the script window before saving the overall waveform project, the entire script is gone. Gone irretrievably it seems, unless of course one has an earlier backup, or one has saved the script project separately from the waveforms project, or one has, (now with this new beta), saved the individual script file. This is the case in the last official non-beta release and it still is. My overview is this is on the way to what I'd like, (using an external editor running simultaneously with waveforms.exe, with the "main" program in the native waveforms script window and the functions in the separate concurrent editor application), but it's not there yet. In general, unless one is careful and knows there are pitfalls, it would be quite easy to lose one's code entirely, or lose the portion of it in "file 2", or think the file on disk was actually in use within waveforms, etc. I almost did so a few weeks ago, but fortunately I'd just made a backup so I lost only a few comments I'd added.
  12. Thank you Attila, this will probably be an effective work around. I very much appreciate your support here. Coming to javascript from C, I have gleaned a great deal from the answers you have given to others' questions. The AD2 is really a fine and powerful tool and the scripting makes it open-ended and even more useful. I have an expensive Tektronix scope on my bench but the only reason to ever turn it on is if I need 1G sampling. An "AD3" could obviate it entirely. The AD2 with scripting is probably saving me about 6 months of time relative to how I was going to handle my current work before I tried scripting the AD2. But my script is getting quite long... Question: Is it possible to use some form of syntax such as src="filename.js"? I would be great to be able to keep a short "main" program within the editor integrated with AD2 script, and have all the functions in an external script. Having these two files side by side would be much more efficient than jumping around within one long script file, and it would be nice to work mostly in a full-featured JS editor.
  13. From within a script, how do I perform the equivalent of checking the View-FFT item to display and activate the FFT? I want to turn on the FFT, perform an acquisition, access the FFT mag and freq array data, and then turn off the FFT for subsequent acquisitions. The reason for turning it off after the first acquisition is that I'm doing a large series of sequential acquisitions and keeping the FFT function active takes an extra few milliseconds per acquisition, which adds up and slows down my application appreciably. I've used the completion feature, which looks very helpful, except consider: Scope1.FFT.Window.setChecked(true); This looks like it should do the trick, but it does nothing. Neither does the false argument, or 1 or 0. And there are many other plausible but unsatisfying things to try via the code completion feature. As a more general question then, how does one go from what one wants to do to finding the syntax to do it? Is there somewhere where all these possible statements are listed? Alternately, is there a way to dump all of the settings that configure what you see on the screen, then make the FFT graph visible, then dump all the settings again and look for what has changed to discover how to do such things in script?
  14. Thank you, this is clarifying regarding jitter. The glitch: [ Some time later... Yes, I see that setting "idle output" to "offset" repairs the behavior I've reported here. However, I'll leave this comment here with your permission as it may help someone just discovering the inner workings of the AD2, as I am. One really does need to know these non-obvious things to make proper use of the Wavegen module. ] I am using the Analog Discovery 2. The glitch seems due to the offset value not being maintained across the entire loop of the waveform buffer. You will not see this problem with any waveform that starts at zero but it shows up when you introduce an offset. In my example, the output should be -1v with a +1v pulse, but at t = 0 the output returns to 0 volts for what looks like one sample interval. Is it possible that a loop in Wavegen code responsible for adding the offset to the output is running from 1 to 4096 and excluding zero? Also, note that the drawn Wavegen signal spends the 5us delay at zero volts, differing from the actual signal produced. All in all, it seems there is something to reconcile here. [I still think the behavior here is counter-intuitive.]
  15. Hello, There is a pulse width jitter caused by some kind of aliasing between various unsynchronized events. My screen capture grabs only one frame of video, but you can see it in the red persistence trace, and I can see it on my Tek scope. I discovered this while running one of the script examples, and then confirmed that it exists in all the pulse modes of the Wavegen except as follows: It is here with these "simple" settings: It is here with these "basic" settings: For my buffer setting and 1% at 5KHz the pulse width here varies from 1.870 us to 1.98 us. It should be 2 us of course. The actual frequency is similarly unstable by a few Hz around 5KHz. Synchronization with a "Run" argument of 200 us or less cures the problem. It appears that when this is =< the set period, it dominates as the period of the waveform. : Placing Wavegen into "autosynchronized" mode does the same thing, but enforces a 200 us "run" argument: As expected, the "run" argument automatically takes on the period of the set frequency. However, note that at 2KHz a glitch appears in the pulse. (It is real): None of these setting produces a waveform that matches the settings exactly. The glitch is particularly troubling. Am I doing something wrong here? - Paul Vo