The Programmer's Guide should be correct. Line 1166 appears to be incorrect, as the arbitrary waveform buffer size for the PicoScope 6403D is 64 kilosamples.
Please scale your values in the range -32768 and 32767 and verify the output. I suggest a simple ramp signal to test with (you can export the csv file from the Arbitrary Waveform Generator in PicoScope 6 and then scale it in something like MS Excel).
I suggest saving the text file from the above using the ANSI standard.
I am really at a loss as to which version of the PS6403. Looking back, it seems that I have a PS6403B because I am able to achieve up to 500,00,000 samples with the Picoscope 6 software by setting:
divs = 20ms/div
and 2GS for the samples
This gives me a sampling interval of 400ps (I am assuming it uses ETS ???)
but claims to measure 500,000,000 samples.
the getInfo function only returns 6403, which probably means 6403B.
Anyway, I experimented with supplying different types of waveforms. It seems that the Picoscope only uses the lower 12 bits as I explained before.
pkToPk = int(4E6)
offset = 0
0x0000 gives min dac = -2V
while 0x0FFF gives max dac +2V
Once again, can you double check if this is consistent with your LabView code for the PicoScope6 Software?
Can't check any code at the moment as I don't have access to a scope, but I am guessing that there is an issue with parameter types and signing. From memory the values given for the buffer values were correct last time I used them.
For information it's not Ets, the scope can run at 5GS/s or 200ps depending on enabled channels. As you have USB2 and AWG you will have a B model, Picoscope6 Help->About will confirm this for you.
I've attached my sample code as well as plots showing the difference between the two methods of scaling.
Plot
In the code I attached, I generate ramp from -2V to 2V measure it for a period 5 times its period.
No trigger is set therefore it takes a bit of time before the picoscope forces a trigger. This gives some time for the picoscope to settle before measuring the waveform (I've observed some strange behaviour with the AWG moments after boot up).
The plots indeed suggest that there is a either a typo in the programming guide, or a bug in the driver.
Thank you for helping me through this. If it is indeed a bug, I hope it will get fixed in future releases.
I have just tested and the waveform buffer values need to be between 0 and 4095, which correspond with the 12bit DAC accuracy, above this and the values are truncated giving strange waveforms.
With a Peak to Peak of 4000000uV, the waveform buffer value 0 gives -2V, and the value 4095 gives +2V.
Our console application states this in the AWG section so I will get the programmers guide updated.