Frequency Response Analyzer with Bode Plots

[hochfrequenz]

Hi there,
would like to install the FRA Bode-plot- program. The instructions in the wiki are out of date. Can someone explain what I have to do. I'm really overwhelmed. I have attached a screenshot of the download page.

WIN 10 64bit, Picoscope 2205A

Marco Schramm

[ts8051]

Hello, I downloaded your application for pico 3000 oscilloscope fra4picoscope and it is working properly in my MAC under VMware. Please let me know if there is a possibility to compile it for use in MAC OS. I live in Athens, Greece

[hexamer]

Hello,

many thanks for that usefull tool, is that possible to change X axis to linear view? I intend to measure the frequency response of a IF filter, please see the attached file here:
https://www.picotech.com/support/topic40059.html?&p=143399#p143399

Best Regards

If you strictly wanted to plot in linear view, you could export the data and re-plot it. But I assume you probably actually want to have the frequency samples in linear mode too. Unfortunately the application isn't currently designed for that use case, but I do have plans to do that some day.

[hexamer]

Hi there,
would like to install the FRA Bode-plot- program. The instructions in the wiki are out of date. Can someone explain what I have to do. I'm really overwhelmed. I have attached a screenshot of the download page.

WIN 10 64bit, Picoscope 2205A

Marco Schramm

Hi Marco,

First, you should download and install the latest version of the 32 bit Pico SDK: https://www.picotech.com/download/software/sr/PicoSDK_32_10.6.13.97.exe

Then you should be able to download and install the latest version of the FRA app from the downloads page. Here's a direct link: https://bitbucket.org/hexamer/fra4picoscope/downloads/FRA4PicoScope%200.6.2b.msi

Let me know if you run into issues.

Thanks,

Aaron.

[hexamer]

Hello, I downloaded your application for pico 3000 oscilloscope fra4picoscope and it is working properly in my MAC under VMware. Please let me know if there is a possibility to compile it for use in MAC OS. I live in Athens, Greece

The UI portions of the FRA application are very Win32 API specific. Even the "backend" software is probably not perfectly portable. So, to make it portable and compile it all for MAC would be a really big undertaking.

I'm glad to hear you can run it in a VM. I've had pretty good success with that approach too as it's the only realistic way I can still test for Windows XP compatibility.

[berprang]

Thank you for the very nice software. I was able to use the software without any problem.

I have a request if it is possible. I works in the area where i need to measure the harmonics of signal. Could you put some options in the DFT process, whether to pick the signal with the same frequency of the internal function generator or the multiple number of the frequency (harmonics).
Thank you

[hexamer]

Thank you for the very nice software. I was able to use the software without any problem.

I have a request if it is possible. I works in the area where i need to measure the harmonics of signal. Could you put some options in the DFT process, whether to pick the signal with the same frequency of the internal function generator or the multiple number of the frequency (harmonics).
Thank you

Thank you for the kind feedback. I am curious about your use case. Can you elaborate on where such an analysis is useful? Also, are you interested in just specific harmonics or the combination of all higher order harmonics?

Depending on which harmonics you are interested in, you may be use the low noise oversampling setting to get what you want. E.g. by setting the oversampling value to 2 (exactly at Nyquist), the DFT would pick up all the higher order odd harmonics.

[hexamer]

External Signal Generator Part 1:

Since it's a top request, and I recently developed a need myself, I started work on a feature to use an external signal generator. A first version of that work is nearly ready.

When I first considered doing this, I felt that it needed to be done in a way that would not be intrusive to the typical user who would most likely only use the PicoScope's built in function generator. To do this, I made a plugin design, where a separate DLL provides the functions to interface with the signal generator.

One thing stopping me before was that I didn't have a signal generator. I found pretty quickly that the frequency range I needed would be pretty pricey. So I built my own based on a Linduino and the Mini-Kits EME165-R2. So, for now the only plugin I've developed is for this homebrewed signal generator.

Obviously this feature is only as useful as there is support for various signal generators. And I've tried to make the plugin interface as general/broad as I can imagine, but without building more plugins I don't know for sure it will handle a wide variety of instruments.

[hexamer]

External Signal Generator Part 2:

I did some initial investigation into what would be required to support the Siglent SDG2000X series and it quickly made me appreciate how much more simple the PicoScope SDK is . I don't necessarily want to deal with NI VISA. I started to look into USBTMC and while it seems lighter weight, it would still require significant work/research. And a likely bigger problem is that I don't have ready access to a Siglent device to test.

So, that said, I'd like to see if anyone else is motivated to help out. Even if you don't have time or skills to create a new plugin, perhaps you could offer experience, suggestions, or a review of the plugin interface.

Depending on interest I'd probably start a new thread.

[_Wim_]

So, that said, I'd like to see if anyone else is motivated to help out. Even if you don't have time or skills to create a new plugin, perhaps you could offer experience, suggestions, or a review of the plugin interface.

Depending on interest I'd probably start a new thread.

I have some experience in controlling instruments via GPIB/VISA, and also have a Rigol DG1062Z (60Mhz). No Siglent however, but would guess that once we have a plugin that uses GPIB/VISA communication, extending it to other generators would be quite straightforward.
No promises however on time schedule, and as with my previous endeavour of the LCR meter, it could come to a halt also due to other priorities.
Programming would be done in C# and Visual Studio.

[hexamer]

I have some experience in controlling instruments via GPIB/VISA, and also have a Rigol DG1062Z (60Mhz). No Siglent however, but would guess that once we have a plugin that uses GPIB/VISA communication, extending it to other generators would be quite straightforward.
No promises however on time schedule, and as with my previous endeavour of the LCR meter, it could come to a halt also due to other priorities.
Programming would be done in C# and Visual Studio.

Thanks, Wim, I definitely understand getting other priorities!

Your mention of C# made me realize one thing I should mention. The external signal generator plugin interface is designed as a pure virtual C++ class. I did this to implement a factory pattern like the way I handle scopes. While I'd guess this doesn't completely prohibit other languages, I'm sure it probably makes it tougher.

Since my EME165-R2's Arduino code uses CmdMessenger and there is a PC-side C# library, my initial efforts at a plugin were calling C# from C++ using UnmanagedExports Nuget package. But that was before I made the C++ class interface and then decided that interfacing to CmdMessenger was simple enough with just straight C++.

Also, there's a Python library for USBTMC, so I might look into making a Python based DLL for the Siglent devices. This could turn out to be some interesting learnings in cross language integration!

[_Wim_]

It is indeed always a challenge working cross languages, but typically all has been done before and google always has an answer...

Does your virtual interface already run in another thread to avoid that the application freezes while connection with the signal generator is made and also when sending commands back and forward? Or should the interace-dll make a separate thread for instrument communication?

I think as a first try it would be good to write a dll that just answers the requests from your application and writes these request to a log file, without actual communication to a signal generator. When this works ok, we know the interface in robust, and I can start communication to the signal generator.

Is your interface definition already available to have I look at?

[hexamer]

It is indeed always a challenge working cross languages, but typically all has been done before and google always has an answer...

Does your virtual interface already run in another thread to avoid that the application freezes while connection with the signal generator is made and also when sending commands back and forward? Or should the interace-dll make a separate thread for instrument communication?

I think as a first try it would be good to write a dll that just answers the requests from your application and writes these request to a log file, without actual communication to a signal generator. When this works ok, we know the interface in robust, and I can start communication to the signal generator.

Is your interface definition already available to have I look at?

Here is the interface file: ExtSigGen.h

The application does use a separate thread from the UI for carrying out the FRA activities, and another thread with timeout is used for the data collection. But there is no separate thread and timeout for signal generator calls. So, the application is relying on the plugin to not hang. In the plugin I made there are communication timeouts.

The plugin header I linked above has shows the methods which I think are are intuitively named, but the methods are documented in the plugin project which is here EME165-R2 Plugin

Finally, here is an initial release candidate for the app with external signal generator capability: FRA4PicoScope_0.7.0b_RC1.msi

Since there are new settings, it will delete your old settings. After you install, you should check in help->about that it says 0.7.0b RC1. To install a plugin, just place the new DLL in the same directory as FRA4PicoScope.exe

Let me know if something doesn't make sense.

[sbabic44]

Hello!
I have 3046D MSO and 4262 and Rigol DG1062Z and Siglent 6052X.
I do know C++ and C# but my programmer-fu is very weak(not really actively programming in many years) , but would be willing to test and maybe fix minor things..
If I may make a suggestion: SCPI is just string exchange protocol, and it is the same over serial, USB, and Ethernet.
I think, maybe direct telnet to instruments and just exchange strings. Nothing to enumerate or anything, Just IP, port and SCPI strings set for different instruments.
Best regards, and again, thanks Hexamer for all the effort!

[hexamer]

Hello!
I have 3046D MSO and 4262 and Rigol DG1062Z and Siglent 6052X.
I do know C++ and C# but my programmer-fu is very weak(not really actively programming in many years) , but would be willing to test and maybe fix minor things..
If I may make a suggestion: SCPI is just string exchange protocol, and it is the same over serial, USB, and Ethernet.
I think, maybe direct telnet to instruments and just exchange strings. Nothing to enumerate or anything, Just IP, port and SCPI strings set for different instruments.
Best regards, and again, thanks Hexamer for all the effort!

Very good point about SCPI. I see lots of examples that boil down to that. As of now I'm still learning the alphabet soup of standardized instrument programming!

Your comment about enumeration makes me realize there is something I should explain. While the plugin interface shows enumeration and instrument ID capabilities, they are optional. In the example plugin project, they are not supported.

Another related topic is the Initialization function and the string parameters it can be passed. In the example plugin project, I use it as sort of an id/address in leiu of enumeration: it's just the COM port id for the Arduino in my signal generator.