Frequency Response Analyzer with Bode Plots

[hexamer]

Hello Kai,

I will probably keep editing this post to answer some of your earlier questions, but I'll start with the most important information first. Thanks for your patience with this.

You are correct, unfortunately 0.7.0b has a very similar bug that was fixed in this commit on 12/13/20: https://bitbucket.org/hexamer/fra4picos ... mpl.cppF68

Both of these issues are fixed in release version 0.7.3b, which ideally we can get working for you.

I will guess the reason you're having trouble with 0.7.3b is because of the issue described here and fixed in this commit (not yet in a released binary): https://bitbucket.org/hexamer/fra4picos ... fff5a65d70 With that fix, you don't have to install any more than just the necessary parts of the SDK to support your scope. I hope to release this version soon.

In the meanwhile, to work around this, you can either (a) install some later/latest version of PicoScope App (which I understand may be a problem for you) or (b) install all of the components in the SDK (even for scopes you don't own). If this is not the problem, then I'll try to help further debug what you're experiencing. In any case, I promise you the scope and FRA app can get down to 0.1 Hz.

For what it's worth, the full 10.7.21.211 SDK is ~73MB and much of that is in libs for scopes besides your PS2204A. Once I release a version with 8afff5a, by my estimate, you should be able to cut that down considerably (probably < 10 MB). In the meantime, I've also logged a new enhancement/bug for the issues with the installer (can't install to alternate locations and incorrectly reporting version 0.6.0.0)

=== First Update ===

Here's how the FRA app depends on DLLs.

First some background: The PicoScope app uses the "same" DLLs as are distributed by the SDK. In fact, when the FRA app was first released, there was no separately distributed SDK. If you go to the PicoScope installation folder, you'll see those DLLs (e.g. ps2000.dll). While these DLLs have the same API between the SDK versions and the PicoScope distributed versions, I don't know much about how their versions are related or configurations are controlled.

Since the DLLs can exist in multiple places, all where the they can be automatically located, the FRA app can get them from either place. And with no special controls, the location chosen can be unpredictable.

A long time ago, I decided that the FRA app would be released and tested against the SDK, not the PicoScope App. However I also didn't necessarily want to prohibit use without an installed SDK (though you'll see on the Wiki that I warn that path is not tested).

To do that in a reliable fashion, I had to implement a system that (1) prefers to get the DLLs from the SDK directory when it's installed (2) checks for minimum compatible versions. (3) warns if these preferences are not satisfied.

Unfortunately that system had a bug where it would crash if no version of the DLL (for all scope DLLs) exist on the machine.

Thanks,

Aaron.

[kaimex]

Hello Aaron,
thank you for the detailed explanation.
I have not yet read every word, but tried to grasp the main "scene".
1. So I understand, version 0.7.0b was not yet ok with respect to lowest possible frequency.
2. Version 0.7.3b crashed at every attempt to start. In any instance, however, I had a version of PicoScope6 installed. So there was a place below C:\Programs(x86)\Pico Technology\PicoScope6\ where the DLLs could be found.
So, missing DLLs can't be the reason for the crashes, right ?
3. PicoScope6 for Windows support does not react to my post about the failure of r6_14_54 to find the 2204A in a Windows 7 environment.
That's why I returned to version r6_13_17
4. Does your FRA4... version 0.7.3b require the PicoSDK_32_10.6.13.97 (~75 MB) or the present PicoSDK_32_10.7.21.227 (~115 MB) ?
Presently I have the ...97 installed (expanded to ~164 MB !). This was not yet the case when I tried the 0.7.3b version. Should I test, whether it still crashes with this SDK present ?
Regards Kai

[hexamer]

So, missing DLLs can't be the reason for the crashes, right ?

I agree. That does seem to be a contradiction to my theory.

3. PicoScope6 for Windows support does not react to my post about the failure of r6_14_54 to find the 2204A in a Windows 7 environment.

That is odd. I can tell you that 6.14.54 does work for PS2204A on my Windows 10 machine. I still have a Windows 7 laptop, where I could try that out to see if I can replicate it too.

4. Does your FRA4... version 0.7.3b require the PicoSDK_32_10.6.13.97 (~75 MB) or the present PicoSDK_32_10.7.21.227 (~115 MB) ?
Presently I have the ...97 installed (expanded to ~164 MB !). This was not yet the case when I tried the 0.7.3b version. Should I test, whether it still crashes with this SDK present ?

The release notes for 0.7.3b say that the correct SDK is 10.7.20.192, but if you can't find that one later ones will probably work fine. Let me know what you see and we can go from there.

[kaimex]

Hello Aaron,
I have looked for the 10.7.20.192 version of the SDK and found that its only insignificantly smaller (111.7 MB) than the current version ...21.227 (112.5 MB filesize shown under Linux).
Then I tested this:
De-installed FRA4...0.7.0b
installed FRA4...0.7.3b
Started FRA4... with PicoSDK_32_10.6.13.97 present -> Appcrash in Kernel... with exception c06d007e
De-installed SDK
Installed PicoSDK_32_10.7.21.227, Control panel shows size as 251 MB
Started FRA4... , proceeds and reports Status: 2204A S/N: GP812/652 successfully initialized.
Attached my little test setup with the 1000 µF capacitor again
Have set Start Freq to 0.1 Hz, Stop Freq to 3000 Hz, changed stimulus to 4 Vpp, Coupling to DC
Have not changed the default settings
Clicked Go, and it actually starts with step 1 (0.101 Hz)
... and takes a long time to move ahead,
and obviously different from previous version plots data already when they become available.
Now the first run has become ready.
Looks mostly ok, only the attenuation beyond 1 kHz i.e. below -70 dB shows more irregularity than one would like to see. May be that for such reasons I had increased "Minimum cycles captured" from 16 to 28 many months ago (but not yet after this new installation).
This is a nice success (apart from possibly 240 MB wasted storage space for the SDK ).
Do you think that further improvement is possible ?
At least it leads to the new question, whether it could be possible to make "Minimum cycles captured" dependent on the frequency, or, in other words, limit the time spent for that such that e.g. for 0.1 Hz it does not do more than 4 cycles. This would speed up the measurement for the "first" steps considerably.
(Almost) Final test: does PicoScope6_r6_13_17 still work ? -> Yes, passed...
Final test: does the minimum Start Freq still depend on "Minimum cycles captured" ?
Have changed it from 16 to 28 -> Go: again starts with 0.101 Hz -> does not depend on it

Thank you Aaron
Kai

[hexamer]

Hello Kai,
I’m so happy that you got it working. Many of these troubles should be remedied in future releases. Thank you again for your patience. Here are some explanations for your other observations:

... and takes a long time to move ahead

At 0.1 Hz, 16 cycles will take about 160 seconds to capture the data. If you want to see a status that communicates that to you, turn on “Sample Processing Diagnostics”

Looks mostly ok, only the attenuation beyond 1 kHz i.e. below -70 dB shows more irregularity than one would like to see. May be that for such reasons I had increased "Minimum cycles captured" from 16 to 28 many months ago (but not yet after this new installation).

The main reason for this is that this use case begins to stretch the dynamic range of the scope. I don’t know what you have the stimulus amplitude set to, but if it were for example 2 Vpp (the default), a 70 dB attenuation will put you at 0.632 mVpp. With 8-bit sampling for a 100 mV range (+/- 50 mV), that’s only 1.62 ADC counts peak to peak. And that’s not even considering the ENOB due to noise. So, there are a couple things you can do to combat this:

1. Increase the stimulus Vpp – you could even use an amplifier to add gain to the AWG if your circuit can tolerate it
2. What you already pointed out - Increase samples to increase the DFT “Processing gain”. When you increase the cycles from 16 to 28, that’s what happens. When I tried this earlier, I found that you can get to 31 cycles before the minimum frequency becomes > 0.1 Hz

At least it leads to the new question, whether it could be possible to make "Minimum cycles captured" dependent on the frequency, or, in other words, limit the time spent for that such that e.g. for 0.1 Hz it does not do more than 4 cycles. This would speed up the measurement for the "first" steps considerably.

If you want a fixed smaller capture duration, you should use Noise Reject mode. It will keep bandwidth (which is the exact inverse of capture/record length) fixed. To take your example above: 4 cycles at 0.1 Hz = 40 seconds, so set bandwidth to 1/40 = 0.025 Hz. To stay within the memory of the scope, you’ll also want to set the timebase to 21 (47.7 Hz). Just to be safe, set the minimum cycles captured to 4. The limitation here is that you’ll want to stay below the Nyquist frequency of 23.8 Hz for the stimulus.

Final test: does the minimum Start Freq still depend on "Minimum cycles captured" ?
Have changed it from 16 to 28 -> Go: again starts with 0.101 Hz -> does not depend on it

As you can tell from the discussion above, minimum start frequency does still depend on minimum cycles captured. You don’t see the effects in your example because you’re still above the minimum start frequency. For 16 cycles it’s 0.0536562 Hz and for 28 cycles, it’s 0.0897074 Hz.

Thanks,

Aaron.

[kaimex]

Hello Aaron,

thank for the explanations and hints.
I have made two further test measurements,
1. one with my previous settings, i.e. "low noise mode", "Minimum cycles captured": 28, and default values.
Stimulus 4Vpp, sweep from 0.1 to 3000 Hz. This took 34 minutes, spending most of the time for 0.1 to 1 Hz, speeding up considerably for the rest, presumable spending ~1/f for each f.
2. "noise reject mode" with the parameters you proposed. In contrast to my expectation, this was not faster. It took 36:50 min. It proceeded faster than measurement (1) for the frequencies below 1 Hz, but took much more time for each measurement above (presumably) 1Hz.
The result looks similar to the first only up to ~600 Hz, apart from higher errors at 50 Hz, 100Hz (150?), i.e. multiples of the mains frequency. Above 600 Hz the results are too wrong to be useful.
So, with this parameter set, measurement 2 provides no advantage, its result is actually worse.

I was thinking, whether it could possibly suffice to put all ps2000a*.lib & ps2000a*.dll from C:\Programs(x86)\Pico Technology\SDK\lib into the C:\Programs(x86)\FRA$PicoScope\Lib to get your program working without the SDK.
Would it also require the ps2000a*.h files ?

I was also curious how much storage space the SDK occupies there: the Windows file manager reports 71.3 MB --- while the Control Panel reports 251 MB. I wonder where the other 251-71 MB reside ?

Another strange oddity: the Windows Control Panel -> Programs & Functions reports for every version of FRA4PicoScope that I installed after the first one (0.6.2bRC4) the version 0.6.0.0 .

Regards Kai

[kaimex]

Hello Aaron,

my impression is that FRA4PicoScope applies "Minimum cycles captured" already while Auto-ranging to find the most appropriate sensitivity for input and output. This takes a long time for frequencies <1Hz.
Is my impression correct ?
If yes, my feature request for your next version would be to reduce the number of cycles during auto-ranging to the absolute minimum required and to apply "Minimum cycles..." only for the actual measurement.
Do you apply a window ? Could auto-ranging be done without a window ?
Am I correct, that at these low frequencies the noise bandwidth of the measurement can be inherently much smaller than for a measurement e.g. at 1 kHz ? -> such that less cycles can suffice ?

Regards Kai

[setti]

I'd like to use the FRA tool with my picoscope 3204B which has a function generator of 600ohms in internal output impedance. The BNC cable type I possess has 50ohms impedance, so is there any problem with the impedance match? If yes how can I workaround it?

[hexamer]

Hello Kai,

Sorry for the delay. Hopefully the following responses to the last couple posts are helpful:

2. "noise reject mode" with the parameters you proposed. In contrast to my expectation, this was not faster. It took 36:50 min. It proceeded faster than measurement (1) for the frequencies below 1 Hz, but took much more time for each measurement above (presumably) 1Hz.

Sorry if it seems I sent you on a wild goose chase here. Now that I’m more aware you’re interested in overall speed, we can discuss tradeoffs. Here are the basics:

1. The bandwidth of the DFT is always the exact inverse of the capture time. E.g. if you capture for 10 seconds, you’ll get a bandwidth of 0.1 Hz
2. So, assuming a fixed/limited scope memory, slower sample rates will result in narrower bandwidth (normally good), but the tradeoff is that you will get frequency foldback (aliasing) for frequencies above fs/2. With lower fs/2 that's more noise that can be "aliased in"
3. Conversely sampling faster can avoid “aliasing-in” higher frequency noise, but will require more memory to store the samples for a given bandwidth (capture time)
4. The PS2204A has a relatively small buffer (3968) samples per channel

All that said … Since you’re measuring a standalone passive circuit, I'll assume you’re not primarily dealing with a noisy background, but rather, a pretty significant attenuation (70dB) causing a very small output signal, which leads to quantization noise. I think if you want a cleaner signal with the PS2204A while also decreasing the analysis time, your best bet is to widen the bandwidth and increase the voltage (consider building an amplifier). Widening bandwidth can be done in either low noise or noise reject mode. In low noise mode it’s pretty straightforward to set the min cycles to 1. Of course, be aware that some capacitors have voltage dependent capacitance. So, your results may not match the way the capacitor will behave in the real circuit.

The result looks similar to the first only up to ~600 Hz, apart from higher errors at 50 Hz, 100Hz (150?), i.e. multiples of the mains frequency. Above 600 Hz the results are too wrong to be useful.
So, with this parameter set, measurement 2 provides no advantage, its result is actually worse.

The main issue here is that the sampling rate required to achieve narrow bandwidth with the scope’s limited memory also limits the upper stimulus frequency. As I noted above: “The limitation here is that you’ll want to stay below the Nyquist frequency of 23.8 Hz for the stimulus.”

I was thinking, whether it could possibly suffice to put all ps2000a*.lib & ps2000a*.dll from C:\Programs(x86)\Pico Technology\SDK\lib into the C:\Programs(x86)\FRA$PicoScope\Lib to get your program working without the SDK.
Would it also require the ps2000a*.h files ?

Unfortunately that won’t work until the next release of the application. It’s because the code still must see all the DLLs (*.lib and *.h don’t matter)

I was also curious how much storage space the SDK occupies there: the Windows file manager reports 71.3 MB --- while the Control Panel reports 251 MB. I wonder where the other 251-71 MB reside ?

I was wondering the same . It could just be a bug in Windows or the deployment package. You could try looking at free disk space both before and after installation see.

Another strange oddity: the Windows Control Panel -> Programs & Functions reports for every version of FRA4PicoScope that I installed after the first one (0.6.2bRC4) the version 0.6.0.0 .

As noted above, I filed an issue against this and have since found the root cause. It’s pretty straightforward, so it should be fixed in next release.

my impression is that FRA4PicoScope applies "Minimum cycles captured" already while Auto-ranging to find the most appropriate sensitivity for input and output. This takes a long time for frequencies <1Hz.
Is my impression correct ?

That's correct.

If yes, my feature request for your next version would be to reduce the number of cycles during auto-ranging to the absolute minimum required and to apply "Minimum cycles..." only for the actual measurement.

That seems like a good idea. To be honest, the main reason auto-ranging is so slow is that it’s not very sophisticated (e.g. only steps one range at a time). I have an issue logged to improve it. While I’m doing that I can explore your idea to cut stimulus cycles to 1 during auto-ranging.

Do you apply a window ? Could auto-ranging be done without a window ?

Applying a window isn't so critical in the FRA App because the Goertzel algorithm allows me to capture a whole number of stimulus cycles. The same doesn't apply to random noise, but this can often be combated with processing gain by increasing samples.

Am I correct, that at these low frequencies the noise bandwidth of the measurement can be inherently much smaller than for a measurement e.g. at 1 kHz ? -> such that less cycles can suffice ?

If I understand you correctly, you are correct. As described above, you can get away with slower sampling here which (assuming a fixed memory size) narrows the bandwidth.

Thanks,

Aaron.

[hexamer]

I'd like to use the FRA tool with my picoscope 3204B which has a function generator of 600ohms in internal output impedance. The BNC cable type I possess has 50ohms impedance, so is there any problem with the impedance match? If yes how can I workaround it?

Hello,

Given the fact that the signal is limited to 1MHz, I tend to doubt you'll have any issues. I have a different PicoScope, also with 600 ohm output AWG, and I always use standard 50 ohm RG-58 cable and have never noticed a problem. Of course the real answer can depend on the circuit you're measuring. If that circuit is very low impedance at higher frequencies, it could load down the AWG. The best way to tell here is to use the PicoScope application and see what the signals look like in real-time while connected to your circuit. The FRA application will experience the same thing.

Thanks,

Aaron.

[kaimex]

Thank you Aaron for the detailed answer.
I am looking forward to your next version of FRA4PicoScope :

@setti:
The possible problem depends on the length of cables that you are going to use and the kind of termination at the other end.
E.g. RG58 coax cable is specified with 105 pF/m. If you attach 2.5 m to the AWG without any termination this results in a -3 dB frequency of 1 MHz. When you are using FRA... in the usual (B)/(A) or (A)/(B) mode with the denominator channel attached to the AWG, only the SNR will be a little bit degraded at 1 MHz. When you are using PicoScope6 for absolute measurements, you will have -3 dB error. The output signal will only be independent of frequency if you feed the cable with 50 Ohms from a buffer and when the cable it terminated with 50 Ohms.
Regards Kai

[MAX66]

Hello Aaron,

I have a oscilloscope AKIP 4111 which has the same hardware as the Picoscope 5203, but differs in firmware, as it was produced for sale in Russia.
Could you add this oscilloscope model to the list of models supported by the FRA4PicoScope?
I am saving money for Omicron Bode 100. But if AKIP 4111 works with this wonderful program, I think many people in Russia will be very grateful to you!
Thanks in advance,

With Regards,
Armen Mkrtchyan

[MAX66]

Hello Aaron,
Here is a list of correspondence of AKIP models to Pikoscope models.
AKIP I Pico I Bandwidth I Ch. N I Res. I
AKIP-4106 I PicoScope 2104 I 10 MHz I 1 I 8 Bit I
AKIP-4106/1 I PicoScope 2105 I 25 MHz I 1 I 8 Bit I
AKIP-4107 I PicoScope 2203 I 5 MHz I 2 I 8Bit I
AKIP-4107/1 I PicoScope 2204 I 10 MHz I 2 I 8Bit I
AKIP-4107/2 I PicoScope 2205 I 25 MHz I 2 I 8 Bit I
AKIP-4108 I PicoScope 3204 I 50 MHz I 2 I 8 Bit I
AKIP-4108/1 I PicoScope 3205 I 100 MHz I 2 I 8 Bit I
AKIP-4108/2 I PicoScope 3206 I 200 MHz I 2 I 8 Bit I
AKIP-4109 I PicoScope 3224 I 10MHz I 2 I 12 Bit I
AKIP-4109/1 I PicoScope 3424 I 10 MHz I 4 I 12 Bit I
AKIP-4109/2 I PicoScope 3425 I 5 MHz Diff. in I 4 I 12 Bit I
AKIP-4110 I PicoScope 4224 I 20 MHz I 2 I 12 Bit I
AKIP-4110/1 I PicoScope 4424 I 20 MHz I 4 I 12 Bit I
AKIP-4111 I PicoScope 5203 I 250 MHz I 2 I 8 Bit I
AKIP-4111/1 I PicoScope 5204 I 250 MHz I 2 I 8 Bit I
AKIP-4112 I PicoScope 9201 I 12 GHz I 2 I 12 Bit I
AKIP-4112/1 I PicoScope 9211 I 12 GHz I 2 I 16 Bit I
AKIP-4114 I PicoScope 6402 I 350 MHz I 4 I 8 Bit I
АКИП-4114/1 I PicoScope 6403 I 350 MHz I 4 I 8 Bit I

Is it possible to add support for all of them?

With Respect,
Armen

[Martyn]

For information those are all legacy models, that haven't been manufactured for a number of years. Some do not have signal generators, others only have a very simple generator, and two are sampling scopes.

[MAX66]

Hello Martyn!

I agree with you, these are outdated models, but they are all still perfectly supported in the PicoScope software. If we look at my AKIP 4111, we can see, that it's hardware it is much more powerful than the 2204A so vigorously discussed here.

Regards,
Armen