PCGU1000 Analysis

Thank you for this update! The international support seems to work fine.
Also the possibility to use labels is good.

I have not yet tested all the features - have to continue tomorrow…

Now the FGU.EXE and the DLL are updated. You may download from: vel255.diinoweb.com/files/FGULink_update_4.zip

One function added “LogSweep”. Here is the declaration:

Private Declare Sub LogSweep Lib "FGULink.dll " (ByVal log As Boolean)

And here examples:

[code]Private Sub Sweep_Click()
LogSweep (True)
SetSweep 100, 20000, 5, 1.5, 5, 1
End Sub

Private Sub Command4_Click()
LogSweep (False)
SetSweep 1000, 20000, 5, 1.5, 10, 2
End Sub[/code]

About the source: It seems that this file is missing from the package:
Module=IDBAS_CommonDialog; C:\Program Files\Sniper Performance\ScreenScrape\EditDFProj\IDBAS_CommonDialog.BAS

[quote=“VEL255”]Thank you for this update! The international support seems to work fine.
Also the possibility to use labels is good.

I have not yet tested all the features - have to continue tomorrow…

Now the FGU.EXE and the DLL are updated. You may download from: vel255.diinoweb.com/files/FGULink_update_4.zip

One function added “LogSweep”. Here is the declaration:

Private Declare Sub LogSweep Lib "FGULink.dll " (ByVal log As Boolean)

And here examples:

[code]Private Sub Sweep_Click()
LogSweep (True)
SetSweep 100, 20000, 5, 1.5, 5, 1
End Sub

Private Sub Command4_Click()
LogSweep (False)
SetSweep 1000, 20000, 5, 1.5, 10, 2
End Sub[/code]

About the source: It seems that this file is missing from the package:
Module=IDBAS_CommonDialog; C:\Program Files\Sniper Performance\ScreenScrape\EditDFProj\IDBAS_CommonDialog.BAS[/quote]

This has been corrected–that’s what happens when you “reuse” code…

The logarithmic sweep is a great addition!!!

-cliff-

BTW: Re: International support, this is the first time I have done that–thank you for the challenge!!!

I added support for the logarithmic sweep, cleaned up a few remaining bugs, and have improved startup stability a bit.

The source code and executable can be downloaded here:

http://www.paladinmicro.com/documents/PCGU1000CtlSource.zip

A Windows installation package for the application can be found here:

http://www.paladinmicro.com/documents/PCGU1000Install.exe

Thank you very much for this software. It is very good tool for me to test the behavior of the FGULINK.DLL.
I have now tested your software for a while and everything works fine!

Thank you also for releasing the source code!

Thank you for your willingness to test same, one concern I have is that I’ve had to insert a number of calls to my WaitAWhile(ms) routine to let things settle in between the switching of modes within the application. These have been based upon trial and error mostly, any feedback you could provide based upon your more imtimate knowledge of FGULink.dll and FGU.exe would be greatly appreciated.

In this last version I have taken care to preserve the state of Timer1 upon entry to any routine calling an FGULink.dll routine, and reinstate same at the routine’s exit. This seems to have improved stability quite a bit, since this change I have not mucked about with the various delays, that’s my next path toward optimisation…

I have validated that the PCGU1000 can accept 7 significant digit values for frequency assignment and have modified my application accordingly, while doing this I also added fine tuning multipliers for frequency and amplitude.
The application now looks like this:

The current fine tuning multipliers are displayed in the caption of the Current Settings frame.

Double-clicking on the Current Settings frame loads the revised options dialog.

One other addition, “hovering” the mouse over the output voltage “pk-pk” and “RMS” labels will display the true RMS output for the standard waveforms (sine, square, and triabgle), including DC offset. If a library waveform is being generated the “pk-pk” and “RMS” labels will appear in maroon and the tool-tip message will be “Pk-Pk and RMS are waveform dependent” as a bit of a warning.

These are nice new features! - I’ll test soon.
BTW: Indeed, the generator itself accepts many decimals but the DLL can’t transfer more than three decimals to the generator.

As these test results show, even the fourth decimal has effect to the output voltage amplitude:
Entered _ Measured
RMS _____ RMS
1.9999 __ 1.99757
1.9998 __ 1.99750
1.9997 __ 1.99744
1.9996 __ 1.99735
1.9995 __ 1.99720
1.9994 __ 1.99710

Sorry - at the moment only three decimals are transferred via the DLL…
This will be changed soon in the next release of the DLL.

BTW: The offset is quantized to 256 levels - so there are no more than two decimals needed.

Nice! There seems to be added a true RMS value display and possibility to enter the voltage as true RMS too. This is very useful feature.

  • I immediately used it to check my (newly purchased) multimeter’s RMS accuracy with different waveforms.

The possibility to enter fine tuning multipliers is nice feature too to “calibrate” the generator.
Maybe the defult setting should be 1.00000 and 1.000

There seems to be a minor “international” problem in this kind of “comma separator county” - doesn’t accept my figures entered…

It seems that the “Library” button is missing from this version…

[quote=“VEL255”]Nice! There seems to be added a true RMS value display and possibility to enter the voltage as true RMS too. This is very useful feature.

  • I immediately used it to check my (newly purchased) multimeter’s RMS accuracy with different waveforms.

The possibility to enter fine tuning multipliers is nice feature too to “calibrate” the generator.
Maybe the defult setting should be 1.00000 and 1.000

There seems to be a minor “international” problem in this kind of “comma separator county” - doesn’t accept my figures entered…

It seems that the “Library” button is missing from this version…[/quote]

I have corrected the entry and display ussues with the fine tuning parameters–being a newcomer to creating “international” applications there has been a bit of a learning curve here. It turns out that the VB6 Format() function does not recognise the regional setings and insist’s that the format string parameter use periods. I am using that function to display the values in the LostFocus event and in the Current Settings frame title. The values do default to 1.00 however the Format() function was really messing them up.

I apologise for forgetting to mention that in order to reclaim some space I changed the Load Library function from a command button to right-clicking on the libary filename. Right-click on the name and the open dialog will pop-up.

You will also note that when running a library function the “pk-pk” and RMS labels will change colour (to maroon). Hovering over those will display the tool-tip “Pk-Pk and RMS are waveform dependent”. Since the libraries do contain the actual point-by-point defintion of the waveform it should be possible to use that information and the amplitude and offset values to calculate the true RMS of a library waveform–if I get ambitious maybe I’ll work on that.

A clarification: The RMS entry is made in “centered around 0.0V” values, I.e. the entered value does not provide for the effect of DC offset on the true RMS value. As the parameter sent to FGULink.dll is the peak-peak value any value entered into the RMS settings is simply corrected to the peak-peak value for the selected waveform (sine, square, and triangle) and that is used to control the generator. The “true RMS” value displayed a tool-tip when hovering on the labels is calculated usng both the peak-peak and offset settings as shown below

 true RMS = (((pk-pk * kRMS)^2) + (Voffset^2))^0.5 

Where kRMS is a constant related to the waveform (0.35355 for sine, 0.5 for square, and 0.28867 for triangle waves), this is the square root of the sum of the squares of the waveform RMS and the DC offset.

Rather than add more screenshots to this thread I have edited the message above to shown the latest revisions to the forms.

I also reverted to the 4 significant digit displays for the voltages. The 4th digit may not do anything but IMHO it looks nicer.

An added option is the ability to hide the FGU.exe application–though I sort of prefer to see it as a validation that things are working as intended.

Regarding the frequency resolution and accuracy, I continue to be very impresed with this instrument. I got together with the local shop I spoke of on Monday and we once again calibrated my HP 5316A counter to his rubidium standard. I have a custom oven heated (using a PTC thermistor) 10 MHz timebase in 5316A that is very stable once up to temperature.

Using the 1.000015 calibration setting shown in the modified message above, I programmed the PCGU1000 to output a 1.000015 kHz sinewave, here is a link to a .avi video of the readout on my HP 5316A counter.

You cannot beat that, I watched it for over 30 minutes and it was nearly rock stable at 1.0000150 kHz with and occasional blip to 1.0000151.

Here’s a table showing the results (also to 8 significant digits) of setting the PCGU1000 frequency to 7 significant digits, from 1000.001 to 1000.005 Hz, and the HP counter’s readouts at 8 digits.

These are the real numbers, with no manipulation of any sort–very impressive for a $200 instrument!

Thank you for this detailed description and the impressive test results!

The library functions open OK by right click!

About the amplitude display for the library wave: Indeed it is good to indicate that they are wave form dependent. The Vpp display for library waveforms of the original Velleman PCGU1000 is “theoretical”. It is OK if the whole range (-1.0 to +1.0 or 0x00 to 0xFF) is fully utilized in the waveform data file.
I noted that your software displays the RMS value for the library waveforms too. The value seems to be calculated based on the last standard waveform used…

About the fine tuning: I can now enter the numbers and everything seems to be OK, but the entered values have no effect. Next time I open the fine tune window there are the default values back.

This software is very good tool to control the operation of the PCGU1000. - I hope many Velleman Projects Service Forum visitors find it too…

This is also very good tutorial on how to use the FGULINK.DLL in Visual Basic.

Perhaps I should dim the RMS value when a library wave is being used? The pk-pk voltage setting does affect the library waveforms to the extent that 1 (or 0x00) and -1 (0xFF) represent the potential upper and lower voltage peaks (1/2 of the p-p setting), so that should stay.

I will see if I can reproduce the fine tuning problems and get back to you–I have several PCs and I have set on to the French (Belgium) region for testing.

-cliff-

Fixed it…

I am saving the floating point values for the frequencies, amplitude/offset, and fine tuning values to the registry as REG_SZ values (null terminated strings).

When saved in this manner they are stored using the regional decimal separator I had to apply the same “normalisation” routine to these values as is used for the configuration files. This routines converts string representations to normalised values for the region by first replacing “.” or “,” with a “|”, and then by replacing the vertical bar with the proper decimal separator for the loaded regional settings. In this manner they be be stored in either format, and subsequently read and used by the application regardless of regional settings.

I also added that the RMS value display and the command button for setting RMS are disabled in library mode.

The source and installtion files have been updated…

-cliff-

I tested your latest software release and everything seems to work perfect!
It was good idea to dim the RMS display and disable the RMS button in library mode.

Test will be continued…

Thank you!

I have found a couple of awkward things I wish to correct, and am also working on a routine to calculate the pk-pk and RMS of library waveforms. I have this working with the basic -1.0 to 1.0 files and it seems quite accurate as compared to the Wavejet’s RMS measurments (within +/- 2% or better).

The waveform points in the file are loaded to an array, and then the pk-pk and RMS are dynamically calculated based upon the generator amplitude and offset voltages. I need to make the import routine aware and capable of processing the waveform repetion and distribution directives–not a big deal but I do need to sleep sometimes (a curse of our species)…

Hi All!

Then

“Decimals”? Please elaborate, since some users would like to make the most of the PCGU1000 internal resolution for the frequency command.

Very low cost DDS devices e.g. AD9832 have 2^32 steps/range, we could expect the same from such a wonderful instrument :wink:

Alain

In the PCGU1000 there are 2^44 steps in the range of 25MHz.

Hi,

Wow :astonished: So it is possible to send the dll a frequency with 1.4 µHz step definition and effectively get the corresponding frequency (taken apart the master-clock precision/stability)?

Indeed, but this resolution is accessible only by entering the frequency value to the user interface of the generator software - either in sweep mode or in normal mode.

Via the DLL the entered value is limited to three decimals.
For example you can enter values like these:
0.011 (i.e. 11 mHz)
0.012 (i.e. 12 mHz)

1000.001 (i.e. 1.00001 kHz)
1000.002 (i.e. 1.00002 kHz)

1000000.001 (i.e. 1.00000001 MHz)
1000000.002 (i.e. 1.00000002 MHz)
etc…

[quote=“VEL255”]Indeed, but this resolution is accessible only by entering the frequency value to the user interface of the generator software - either in sweep mode or in normal mode.

Via the DLL the entered value is limited to three decimals.
For example you can enter values like these:
0.011 (i.e. 11 mHz)
0.012 (i.e. 12 mHz)

1000.001 (i.e. 1.00001 kHz)
1000.002 (i.e. 1.00002 kHz)

1000000.001 (i.e. 1.00000001 MHz)
1000000.002 (i.e. 1.00000002 MHz)
etc…[/quote]

I believe the 1kHz and 1MHz expansions are incorrect. If the resolution of the passed frequency value is always 3 decimal places, and as the value is passed as an unscaled real value, then the decimal part of any passed value will represent mHz, it has too.

Therefore:

1000.001 = 1.000001 kHz (not 1.00001 kHz)
1000.002 = 1.000002 kHz (not 1.00002 kHz)

and,

1000000.001 = 1.000000001 MHz (not 1.00000001 MHz)
1000000.002 = 1.000000002 MHz (not 1.00000002 MHz)

-cliff-

You are absolutely right. - Thanks for the correction!
For some reason I missed one ‘0’ from the kHz and MHz values in parentheses…