In order to verify I can am to use the AWG in my program, I used AWG drawer in PicoScope 6 to draw a one cycle square of 1024 samples. It starts high at 1 and goes to -1 halfway through the cycle.
Since the 5244B requires the signal to be from -32768 and +32767, I wrote this function to do this as seen below. I should note that I am doing this in C++ through the Qt framework.
void Acquisition5000::setSignalGenerator(double ddsFrequency)
{
PICO_STATUS status;
short *arbitraryWaveform = NULL;
long waveformSize = (long)waveformvector.size(); //max of 49152
unsigned long pkpk = 4000000;
long offset = 0;
arbitraryWaveform = convertWaveFormToSamples(waveformvector);
unsigned long deltaPhase = calculateDeltaFromFrequency(ddsFrequency,waveformSize);
status = ps5000aSetSigGenArbitrary( unitOpened_m.handle,
0, // offset voltage
pkpk, // PkToPk in microvolts. Max = 4V +2v to -2V
deltaPhase, // start delta
deltaPhase, // stop delta
0,
0,
arbitraryWaveform,
waveformSize,
(PS5000A_SWEEP_TYPE)0,
(PS5000A_EXTRA_OPERATIONS)0,
PS5000A_SINGLE,
0,
0,
(PS5000A_SIGGEN_TRIG_TYPE) 0,
(PS5000A_SIGGEN_TRIG_SOURCE) 0,
0);
systemArmed = true;
}
The result I get is just noise on the output of the signal generator, and sometimes not even that. I can't see anything that I am doing that would cause this to happen. Any ideas?
What is the value of deltaPhase once you have calculated it? Have you checked the values in the waveform array at the point of calling the function.
In the latest release of the SDK (10.5.2.1), the ps5000aApi.h header file contains the following function which can be used to calculate the phase value from the frequency:
I didn't use that function because the version of the SDK I had, downloaded in early January, listed the function in the header file but did not seem to have it in the dll. I will download the latest SDK and try it out this morning.
As far as the AWG goes, I will make the necessary corrections and see what happens.
So using the lib included in the new SDK build caused more problems than fixed.
I am now getting:
"acquisition5000.obj error: LNK2019: unresolved external symbol __imp__ps5000aGetTimebase2@24 referenced in function "private: void __thiscall Acquisition5000::blockDataHandler(char *,long)" (?blockDataHandler@Acquisition5000@@AAEXPADJ@Z)"
and still the original reason why I didn't using the included frequency to phase function
"acquisition5000.obj error: LNK2019: unresolved external symbol __imp__ps5000aSigGenFrequencyToPhase@24 referenced in function "public: void __thiscall Acquisition5000::setSignalGenerator(double)" (?setSignalGenerator@Acquisition5000@@QAEXN@Z)"
In other words those two functions are not part of this current builds .lib file.
You sent me and updated lib file to my email which fixed the issues listed in the previous topic. However I hadn't tried ps5000aSigGenFrequencyToPhase at that point. If I use the lib file you sent me then I can use ps5000aGetTimebase2 but not ps5000aSigGenFrequencyToPhase. So it looks like in this latest build lib did not get updated once again. In fact, the build dates are the same as the SDK I downloaded early Janurary:
ps5000aApi - Created: Thursday, September 11, 2014, 1:31:30 PM
ps5000a.dll - Created: Thursday, December 11, 2014, 4:32:04 PM
ps5000a.lib - Created: Tuesday, February 12, 2013, 9:52:18 AM
I don't know what was updated in the latest SDK build but it was not these.
Thanks, Hitesh, I just received the email and will try these out momentarily. Currently playing around with reading in the csv file. I checked the contents of the array I was passing, and things were not quite right.
I responded in the email, but I will do it here also in case anyone else runs into the same issues.
Upon using the new dll and lib you sent to my email, I received this email upon compiling:
*** A stack buffer overrun occurred in C:\Users\Jason\Documents\Development\Qt\build-CrackDetection-Desktop_Qt_5_4_0_MSVC2013_32bit-Debug\debug\CrackDetection.exe:
This is usually the result of a memory copy to a local buffer or structure where the size is not properly calculated/checked.
If this bug ends up in the shipping product, it could be a severe security hole.
The stack trace should show the guilty function (the function directly above __report_gsfailure).
*** enter .exr 774BA9A8 for the exception record
*** then kb to get the faulting stack
I have not had this problem with any other versions of the dll or lib.
In other news, using the old files I have the information you requested.
Using my function to calculate deltaPhase based on the equations in the original post, I get a value of 4294963874 when the input frequency is
unsigned long pkpk = 4000000;
and the waveform length is
long waveformSize = (long)waveformvector.size(); or in my case for this waveform 1024.
I was able to get the function to work by creating a signal that had the max number of samples. I am going to investigate further into varying sample sizes to see how it changes.
Using my function to calculate deltaPhase based on the equations in the original post, I get a value of 4294963874 when the input frequency is
unsigned long pkpk = 4000000;
The value 4294963874 is close to 2^32 which doesn't seem right. What is the frequency that you are looking to output as the peak to peak voltage was given above?
So I set up several debug statements to watch variables as I need them. Turns out I had awgBufferSize in my UNIT struct defined as a short instead of an unsigned short so using PS5X44A_MAX_SIG_GEN_BUFFER_SIZE caused the variable to turn negative because it is larger than 32767. I found an example on the forums of opening and closing the PicoScope 5000 series using C++ somewhere on the forums that I based the beginning of my project on that defined the awgBufferSize like this instead of an unsigned variable. I've verified my output and all is well now that I have adjusted the variable type.
Thanks for the help! I am sure I will be posting about other questions in the near future as I start working on data collection.