Frequency Response Analyzer with Bode Plots

Post discussions on applications you are writing
Post Reply
hexamer
Advanced User
Advanced User
Posts: 5
Joined: Tue Aug 12, 2014 10:09 pm

Re: Frequency Response Analyzer with Bode Plots

Post by hexamer »

Gary,

Here is a link to a new version that I hope will fix the error code 269 you experienced:

https://bitbucket.org/hexamer/fra4picos ... 0.5.2b.msi

Thanks,

Aaron.

garya
Newbie
Posts: 0
Joined: Mon Nov 16, 2015 10:02 pm

Re: Frequency Response Analyzer with Bode Plots

Post by garya »

Hi Aaron,
you are right that my 'scope has a 20MHz band limiter tick-box

It also has low pass filtering settable to a particular frequency if that helps in the scheme of things.

'tis I who thanks you - a handy looking little tool you're working on!

garya
Newbie
Posts: 0
Joined: Mon Nov 16, 2015 10:02 pm

Re: Frequency Response Analyzer with Bode Plots

Post by garya »

Yes, that fixes the problem :) It runs and gets a plot.
I just have to get a sensible one.

hexamer
Advanced User
Advanced User
Posts: 5
Joined: Tue Aug 12, 2014 10:09 pm

Re: Frequency Response Analyzer with Bode Plots

Post by hexamer »

garya wrote:Yes, that fixes the problem :) It runs and gets a plot.
I just have to get a sensible one.
Hey, that's good news! If you are not able to get plots that look sensible based on the circuit you're measuring, there are a couple of ways to debug:

1. First is the log created in the lower left section of the main window. It can tell us about the auto-ranging status and selected output and sampling frequencies, which can give a clue as to what kinds of problems were experienced.
2. There is a diagnostic mode we can turn on which will spit out files with time domain plots of all the waveforms captured.

Obviously one of the easiest circuits to measure for testing purposes is an RC filter. You could measure a resistor divider, but the default plot will look noisy because the gain and phase are so constant - the default plot zooms in on the data and so even small variations will look noisy. But that can be addressed by setting the plot axis ranges: just single click on the plot and you'll get a plot settings dialog.

garya
Newbie
Posts: 0
Joined: Mon Nov 16, 2015 10:02 pm

Re: Frequency Response Analyzer with Bode Plots

Post by garya »

Yes, that's good with RC
Only niggle is 20000000 Hz faults, can get around 18999999

Fatal error: Failed to start channel data capture: 14

but not with all 9s. And at those high values, 50 samples starts to fault at end with
too long to download data - or some such fault.
18R and 10nF
18R and 10nF

hexamer
Advanced User
Advanced User
Posts: 5
Joined: Tue Aug 12, 2014 10:09 pm

Re: Frequency Response Analyzer with Bode Plots

Post by hexamer »

Clipboard01.jpg
Gary,

I'm glad you tested at the limits to expose these issues. I have a strong suspicion that the code 14 failure has to do with this statement in the PS6000 datasheets: "*To achieve the best sampling rate across two channels, choose one channel from A or B, and one from C or D". I noticed this while researching the earlier issues you found, then logged it in the issue tracker, but didn't explore where it might become an issue. I can see now that this would be an issue above 19,531,250 Hz. If you were to try channels A and C the issue might go away. In the mean-time I'll think of some way to encode this in the app.

On the timeout issue, I'm not really sure. I applied a fix in v0.5b for a similar issue affecting low frequencies on other scopes. Maybe I broke something else. 50 samples seems strange, so i'm also wondering if it's a side effect of the issue above. I'll explore further.

Thanks,

Aaron.
-->
garya wrote:Yes, that's good with RC
Only niggle is 20000000 Hz faults, can get around 18999999

Fatal error: Failed to start channel data capture: 14

but not with all 9s. And at those high values, 50 samples starts to fault at end with
too long to download data - or some such fault.
Clipboard01.jpg
Gary,

I'm glad you tested at the limits to expose these issues. I have a strong suspicion that the code 14 failure has to do with this statement in the PS6000 datasheets: "*To achieve the best sampling rate across two channels, choose one channel from A or B, and one from C or D". I noticed this while researching the earlier issues you found, then logged it in the issue tracker, but didn't explore where it might become an issue. I can see now that this would be an issue above 19,531,250 Hz. If you were to try channels A and C the issue might go away. In the mean-time I'll think of some way to encode this in the app.

On the timeout issue, I'm not really sure. I applied a fix in v0.5b for a similar issue affecting low frequencies on other scopes. Maybe I broke something else. 50 samples seems strange, so i'm also wondering if it's a side effect of the issue above. I'll explore further.

Thanks,

Aaron.