Frequency Response Analyzer with Bode Plots

[_Wim_]

Thanks for uploading the file here also. For me, the file limit was/is limited to 256K?! Could this be related to the number of post? Just tried again to upload a dummy file of 5mB, could not attach it..

[_Wim_]

Full source code is available at:
https://github.com/WimHuyghe/FRA-Impedance-Viewer

[hexamer]

Full source code is available at:
https://github.com/WimHuyghe/FRA-Impedance-Viewer

Very nice work, Wim! I'll have to try this our soon.

BTW, this is one of the kinds of application I had in mind when I made the API version of FRA4PicoScope. Had you considered integrating it that way? Should be pretty easy with C#.

[_Wim_]

Hi Hexamer,

Thanks for your comments. I was not aware an API version of your app was available. I will definitely look into that. I briefly first considered changing your app, but as I am not a C++ guy, and also not familiar with the PLPlot lib, that seemed a bit too much work. Wrapping a dll and using it in C# however should be fairly straight forward.

[_Wim_]

Hi Hexamer,

I have a basic version working with your API (I can perform the measurement from my app), but I am strugling with the GetMessageLog() function. Depending on timing when I call the GetMessageLog(), I get one of the following reactions:
- message is returned correctly
- message contains random characters
- API crashes with no clear exeption.
all with the same code.

Currently I am invoking your API function as follows:

[DllImport("FRA4PicoScope.dll", CharSet = CharSet.Unicode, CallingConvention = CallingConvention.StdCall)]
public static extern string GetMessageLog();

I also tried returning an IntPtr instead of a string, and using the function below to convert it to a managed string:

private string GetStringFromPtr (IntPtr pptr)
{
IntPtr ptr = Marshal.ReadIntPtr(pptr);
return Marshal.PtrToStringUni(ptr);
}

I also tried adding [return: MarshalAs(UnmanagedType.LPWStr)] to the DLLImport. So far nothing works reliable.

Any tips?

[_Wim_]

Attached a version with a basic user interface to control the picoscope directly. As posted above, reading the status log does not work yet, but is default disabled in the app. Source code is on Github

[kaimex]

Hi,
I am using a PicoScope 2204A with FRA4PicoScope V. 0.6.2b.RC4, assuming that it is the newest version.
In recent weeks I have used this for impedance measurement on capacitors and inductances in the range 1 Hz to 100 kHz. The setup is apparently the same as the one posted by _Wim_ on Feb 10, 2019, but I only saw this about half an hour ago.
In the course of these measurements I noticed, that there are reproducable irregularities in the impedance versus frequency plots, especially pronounced in the real part of the impedance or e.g. in the dissipation factor (tan(delta)). These irregularities come from errors in the phase measurement of FRA4PicoScope, which vary with frequency. I have provided illustrations of this effect in the form of plots. The postprocessing is presently done with a MatLab-Script but could likewise be done with Octave (requiring possibly minor changes in the graphics).
In the beginning I used FRA4PicoScope with the default settings. Later I found that the phase ripple can be reduced by setting the "Extra settling time" parameter to 25 , in some case also to values as high as 50, 100, 200. Experimenting with the "Minimum cycles parameter" brought further improvement by increasing from the default 16 to 28 or 30. From 32 on the program complains that this is not compatible with a start frequency of 10 Hz. I have not found documentation about these parameters, so this was the result of experimentation.
Sometimes these settings lead to smooth result curves, at other "times" the plots still show bumps that cannot be explained by the DUT-properties. So my impression is, that there is some potential of improvement in the implemented phase calculation method.
The attached example has been produced with a 1 kOhm resistor between inputs A & B, the AWG connected to A and the DUT was a 10 uF capacitor from B to ground. I used 200 Steps/decade for this demonsration ( otherwise only 20 steps/decade).
Regards Kai

[_Wim_]

Hi Hexamer,

I solved the problem of returning the message log. I declared the P/Invoke to return and InPtr, and converted this InPtr using Marshal.PtrToStringUni(ptr) directly instead of calling Marshal.ReadIntPtr(pptr) first as I found in interop examples. Now it works perfectly, and I learned a bit more about using interop

[_Wim_]

Updated version with the fixed message log.

[hexamer]

Hi Hexamer,

I solved the problem of returning the message log. I declared the P/Invoke to return and InPtr, and converted this InPtr using Marshal.PtrToStringUni(ptr) directly instead of calling Marshal.ReadIntPtr(pptr) first as I found in interop examples. Now it works perfectly, and I learned a bit more about using interop

Very happy you figured this out. I was going to have to dig very deep into the memory banks to help out. It's been a long while since I've P/Invoked a DLL from C#

[hexamer]

Kai,

Your results are a bit perplexing. I would like to see if I can reproduce them. Your description should help. Here is what I can tell you for now:

A primary reason for the extra settling time is that the Picoscope's AWG transition has discontinuities which can affect measurement. I'd be curious to see if taking it to an extreme would eliminate the issue here.

The number of cycles collected affects how many scope samples are collected. It's the number of whole stimulus cycles to collect. Total samples are this times samples per cycle. More samples will lead to more processing gain which can be important in noisy environments (simple impedance measurements of passive components are not generally noisy).

The phase measurement is done with a DFT, and though it is using a more efficient version (Goertzel), it should be mathematically equivalent. It is using double precision arithmetic, and in your use case (low DFT sample count) should not be suffering any numerical accuracy issues. But as a DFT it would have all the associated limitations like spectral leakage. But since the application maintains an integer stimulus cycle count for sampling and noise is presumed low, I doubt this is the issue here.

Edit: thinking about it a bit further ... I suppose the AWG discontinuities could be a noise source that shows up as a spectral leakage. That could be helped by both eliminating the noise (increasing settling time) or increasing processing gain (increases cycles and cycles/sample). The scalloping in your data seems to support that idea.

Thanks,

Aaron.

[_Wim_]

Hi,
I am using a PicoScope 2204A with FRA4PicoScope V. 0.6.2b.RC4, assuming that it is the newest version.
In recent weeks I have used this for impedance measurement on capacitors and inductances in the range 1 Hz to 100 kHz. The setup is apparently the same as the one posted by _Wim_ on Feb 10, 2019, but I only saw this about half an hour ago.
In the course of these measurements I noticed, that there are reproducable irregularities in the impedance versus frequency plots, especially pronounced in the real part of the impedance or e.g. in the dissipation factor (tan(delta)). These irregularities come from errors in the phase measurement of FRA4PicoScope, which vary with frequency. I have provided illustrations of this effect in the form of plots. The postprocessing is presently done with a MatLab-Script but could likewise be done with Octave (requiring possibly minor changes in the graphics).
In the beginning I used FRA4PicoScope with the default settings. Later I found that the phase ripple can be reduced by setting the "Extra settling time" parameter to 25 , in some case also to values as high as 50, 100, 200. Experimenting with the "Minimum cycles parameter" brought further improvement by increasing from the default 16 to 28 or 30. From 32 on the program complains that this is not compatible with a start frequency of 10 Hz. I have not found documentation about these parameters, so this was the result of experimentation.
Sometimes these settings lead to smooth result curves, at other "times" the plots still show bumps that cannot be explained by the DUT-properties. So my impression is, that there is some potential of improvement in the implemented phase calculation method.
The attached example has been produced with a 1 kOhm resistor between inputs A & B, the AWG connected to A and the DUT was a 10 uF capacitor from B to ground. I used 200 Steps/decade for this demonsration ( otherwise only 20 steps/decade).
Regards Kai

Hi Kai,

I am probably misunderstanding, but ss the Z the impendance of the DUT only in your plot? Because normally for a 10µF capacitor this should be around 1600 for 10Hz, and around 8 ohm at 2kHz.

Attached it the impendanc plot I get running the same test. No matter how much I zoom in, I do not see any ripples.

[_Wim_]

New version:

Bugfix:
- was not possible any longer to open multiple FRA4Pico plots (was always opening new plot).

Other changes:
- cursor info always same nr of lines (so chart does not move when right mouse button is used)
- pompt on exit when unsaved files are present

[kaimex]

Hi Aaron and Wim,
thank You for responding to my message.
Wim: the left end of my plot starts at 40 Hz, so 10 µF -> ~ -j400 Ohms and I guess I was not mistaken. when I tried to remember the nominal capacitance value of the test candidate.
Normally I make more broadband plots from e.g. 10 Hz to 20 kHz with only 20 steps/decade. Then the plots look more irregular and you don't realize the periodicity of the underlying phase error.
This plot was done with the default settings (no extra settling time; minimum cycles captured = 16). I also made plots with extra settling time set to 25ms, 30ms, 40ms, 50ms, which showed much less but apparently not yet random ripple. 50ms seemed to have more ripple than 25ms. Later I noticed/explored that increasing the minimum cycles number led to further improvement of the smoothness of the traces. In my opinion (without fully understanding, what the software does in detail) it should however be possible to reduce the systematic phase errors by a better calculation method without using the settling time and minimum cycles parameters. The FFT phase result is always depending on how much signal cycles fit into the time intervall. The phase error is zero, when an integer number fits exactly in. It is totally predictable, when non-integer numbers of cycles are in the intervall. But you can put this in different terms: it is possible to calculate phase exactly by using the proper mathematics (and not just the FFT result).
One method might be to fit a sine/cosine to the sample-vector with least squares methods, if no direct or easily invertible analytical solution can be found. It should be possible to improve the phase calculation to a level, that the residual errors look like random or quantization noise.
Regards Kai

[hexamer]

The FFT phase result is always depending on how much signal cycles fit into the time intervall. The phase error is zero, when an integer number fits exactly in. It is totally predictable, when non-integer numbers of cycles are in the intervall. But you can put this in different terms: it is possible to calculate phase exactly by using the proper mathematics (and not just the FFT result).

A primary reason I chose the generalized Goertel is that it does not have to deal with this limitation of the FFT. It can always fit exactly an integer number of stimulus cycles into the sample window.

I was able to reproduce your results and I am pretty sure this is due to the AWG discontinuities, whose effects can be minimized by increasing the settling time. I took it to a more extreme settling time and I can pretty much eliminate the effect.

1) Here is a bode plot on a PS2204A with 1k resistor and 10 uF cap showing the phase ripple at 200 steps per decade:

2) Here is a time domain plot showing what the AWG discontinuities are doing. Notice the slow decaying signal and resulting lack of spectral purity in the lower plot:

3) Here is the same bode plot, this time with 1000 ms settling time:

In theory we could significantly suppress this by increasing processing gain, but since the sample buffer of the 2204A is 8k, there is only so far we can go. My suspicion on why Wim was unable to reproduce these results is that maybe he was using different sampling settings or his scope has less discontinuities in the AWG?

What I can't totally explain is why the phase gets a periodic ripple. Maybe it has something to do with the size of the jumps the DDS is taking on a log step?