Frequency Response Analyzer with Bode Plots

[emjey]

Hello All,

Based on a need I had for a good Frequency Response Analysis tool for PicoScope, I started to develop one. Initially it was just for my PS5444A, but I decided to go ahead and make it general purpose since I had seen several posts on here asking for this. Unfortunately I don't have any other scopes to do any testing on, so I'd really love some help. I'd consider it in "beta" status for now, but I've tested it with my scope on Windows XP (SP3), Vista, and 7. Right now it's only got built in support for the PS2000A, PS4000, and PS5000A families, but adding more scopes is pretty trivial.

If anyone is interested, I'm hosting it here: https://bitbucket.org/hexamer/fra4picoscope/wiki/Home

Binaries are available if you're not into building the code yourself.

Hope it's useful!

Aaron.

Hi Aaron,

I am planning to buy PicoScope for FRA purposes. Can you tell which model does the FRA software is most reliable to? Roughly a little less than $1000 would do. I'll be using it for power converter stability measurement.

Likewise, do I need sort of isolation transformer?

Regards,
MJ

[hexamer]

Hi Aaron,

I would like to help you get this running on the 4262 in any way I can. Should I try to install the test build you linked to in the original 4262 post or can you point me to the newer non-released version that can record the call issue?

Thank you for continuing to work on this,

Mike

Mike,

Below is a link to a version that has API call tracing. To turn it on, choose Tools -> Settings, then press the "Log Verbosity" button. Minimally check the "PicoScope API calls" checkbox, but it won't hurt to have others checked too.

https://drive.google.com/open?id=1vB8hm ... lJQtELwcKh

Thanks,

Aaron.

[Miq]

Hi Aaron,

Here's what the log shows:
ps4000SetChannel( 16384, 0, 1, 0, 6 );
ps4000SetBwFilter( 16384, 0, 1 );
ps4000SetChannel( 16384, 1, 1, 0, 0 );
ps4000SetBwFilter( 16384, 1, 1 );
ps4000GetTimebase( 16384, 3, 0, 0, 1, 034CF6DC, 0 );
ps4000PingUnit( 16384 );
Status: Starting frequency step 1 (1.000 Hz)
Status: Starting frequency step 1, range try 1
Status: Setting signal generator frequency to 1.000 Hz
ps4000SetSigGenBuiltIn( 16384, 0, 1000000, 0, 1.00002, 1.00002, 1, 1, 0, 0, 0, 0, 0, 0, 0 );
Status: Setting input channel range to ± 1 V
ps4000SetChannel( 16384, 0, 1, 0, 6 );
ps4000SetBwFilter( 16384, 0, 1 );
Status: Setting output channel range to ± 10 mV
ps4000SetChannel( 16384, 1, 1, 0, 0 );
ps4000SetBwFilter( 16384, 1, 1 );
ps4000SetTriggerChannelConditions( 16384, 0, 0 );
ps4000SetTriggerChannelProperties( 16384, 0, 0, 0, 0 );
ps4000RunBlock( 16384, 0, 1025, 156246, 1, 015EE1B4, 0, 00B6F0E0, 015EE3D8 );
Status: Capturing 1025 samples (16 cycles) at 64 Hz takes 16.0 sec.
BlockReady( 16384, 0, 015EE3D8 )
Status: Transferring and processing 1025 samples
ps4000SetDataBuffers( 16384, 0, 034CF0C4, 034CF0C0, 1 );
ps4000SetDataBuffers( 16384, 1, 034CF0BC, 034CF0B8, 1 );
ps4000GetValues( 16384, 0, 034CF0AC, 1025, 1, 0, 034CF0B4 );

Let me know if you need any more logs.

Miq

[hexamer]

Thank you, Miq. That is all that I need. It confirms my suspicion on what's happening. However, I'm going to need assistance from the Pico support staff to determine why it hangs there. On a related note, on the latest version of other drivers (e.g. PS2000A), instead of hanging it returns an error in that same spot. And it didn't do that before, so something was changed to break it.

What the code is trying to do is use buffer aggregation to quickly get the min and max values in the buffer without transferring the whole buffer (it uses this to make auto-ranging decisions). The trick is to aggregate the entire buffer down to 1 sample. It seems like lately that's been a problem with some drivers.

[Miq]

Hi Aaron,

Glad I could provide some info. Please let me know if you are able to get the help you need from Pico and have another trial version for me to load. I look forward to getting this working for the 4262. This model, aimed at LF analog/audio, is begging for this kind of tool.

Thanks again for not getting discouraged supporting this ever changing platform.

Miq

[_Wim_]

Thanks again for not getting discouraged supporting this ever changing platform.

Totally agree! This tool was one of the main reasons I choose the Pico 5000 in the first place. I hope the team at Pico appreciates how much additional value this piece of software brings.

[Martyn]

We will be looking into this issue on Monday.

[Miq]

Thanks Martyn!

Miq

[hexamer]

Hi Aaron,

I am planning to buy PicoScope for FRA purposes. Can you tell which model does the FRA software is most reliable to? Roughly a little less than $1000 would do. I'll be using it for power converter stability measurement.

Likewise, do I need sort of isolation transformer?

Regards,
MJ

Hello MJ,

Thank you for your interest in FRA4PicoScope!

Technically the most reliable would be any of the models I own and can therefore test I have a PS5444A, PS2408B, and PS2204A. But many other models are known to work.

The parameters most important for power supply stability measurements would be:

1) Sensitivity (think ENOB at lowest range)
2) Memory buffer depth

For this, the 5000A or 5000D (currently being sold) series would be best. Since bandwidth is usually not as important for power supply stability measurements, there are some lower bandwidth 5000D models that are pretty close to your price target. Unfortunately the FRA app is not yet updated to use these newer 5000D scopes. However it should be soon.

You may still get reasonable results from models with lower sensitivity and large buffer depth, but I am not aware of any experiments that demonstrate this.

For an excellent tutorial on using FRA4PicoScope to conduct power supply stability measurements, including info on isolation transformers, check out this video from Roland van Roy: https://www.youtube.com/watch?v=wKs8VyERZXU

Thanks,

Aaron.

[tristanc]

Hi Aaron,

Can I check the behaviour I'm seeing is as expected. Basically, is autoranging meant to occur during the frequency sweep?

What's happening is:

- I'm taking frequency / phase measurements of an audio amplifier I have built
- the 'fringe' frequencies (<100Hz & >80kHz, e.g.) give low output compared to 1kHz
- autoranging of the output occurs for the 1st step (10Hz)
- this is fine for the next couple of steps until the output response increases to 'normal'
- then the autoranging doesn't seem to kick-in to give a sensible reading - the plot just plateaus...

I've attached a couple of example images and the entire image set as a zip.

I experimented changing the output starting parameters from input stimulus to +/-10V etc, but no joy other than altering the 1st autorange process.

Thanks for your help!

Tristan

[hexamer]

Hi Aaron,

Can I check the behaviour I'm seeing is as expected. Basically, is autoranging meant to occur during the frequency sweep?

Hi Tristan,

Thank you for your interest in the FRA app.

Yes, it is normal for autoranging to occur throughout the frequency sweep. It is trying to find the ranges that maximize the signal.

Are you getting Bode results that don't make sense? If so, you can always check against manual measurements using the PicoScope app.

One thing I noticed in your time domain plots is that the input signal seems to be getting loaded down. What is the filter's expected impedance vs the PicoScope's output impedance?

Thanks,

Aaron.

[tristanc]

Are you getting Bode results that don't make sense? If so, you can always check against manual measurements using the PicoScope app.

I thought I'd created a brilliantly performing single ended valve hifi amp!
Using the picoscope or old-school sig-gen + DSO I get a gain of around 20db at 1kHz - around what I'd expect. The FRA peaks at ~14dB or so and is completely flat. Not what I expect to see!

One thing I noticed in your time domain plots is that the input signal seems to be getting loaded down. What is the filter's expected impedance vs the PicoScope's output impedance?

Ah yes, that's strange. I had set the parameters in the GUI to be 10x for the probes. Perhaps that isn't being picked up by the code? I tried this with both the GUI and the excel macro. But would that impact on the autoranging not happening on the output signal?

The input Z is 1 Meg, so shouldn't be a problem of loading?

Thanks for your help,

Tristan

[hexamer]

I had set the parameters in the GUI to be 10x for the probes. Perhaps that isn't being picked up by the code? I tried this with both the GUI and the excel macro. But would that impact on the autoranging not happening on the output signal?

Ahh, I should have looked more closely at the value. I see that it is about 1/20th the stimulus. The other 2x is the difference between P2P and Amplitude. So I guess the time domain plots need to be fixed to account for probe attenuation. Thank you for pointing that out.

That bug should not impact auto-ranging.

[Hitesh]

Hi Miq and Aaron,

I have been able to reproduce the issue from this post and have reported it to the Development Team.

Aaron, I have contacted you about this via a support ticket.

Regards,

[hexamer]

Based on a workaround proposed by Hitesh in the support ticket, I've made a test version which I hope someone can test on a PS4262:

https://bitbucket.org/hexamer/fra4picos ... 20Test.msi