Noticing there was no Linux front for the Picoscopes I decided to write one. I currently have waveforms being acquired, being plotted I can control the timebase, input gain and the signal generator. Thats all provided oversampling is off.
As soon as I turn oversampling on, the scope refuses to select a timebase or acquire data.
The example file PS2000con.c exhibits the problem too, if I enable oversampling by changing line 400 from
This appears to be due to a driver bug. The Windows driver has been fixed and we are now looking at the Linux driver. I will post updated versions of both once complete.
I confirm that enabling oversampling no longer locks up the scope, thanks for turning that around so quickly.
The resulting data is not what I was expecting however. Increasing the oversampling parameter reduces the effective length of the stores, but the quantisation noise seems unaffected. I was expecting the difference between quantisation levels to be reduced.
I attached two screen shots of my GUI to show this, one without oversampling and one with a 16x oversample. In both the quantization levels look the same.
Its quite likely its my error this time, but it would be great if someone at Picotech taking a quick look and check that more fine grain data is returned if the calls are made correctly. I would imagine the example application should be sufficient to verify this.
Perhaps you can do this test for me, it should only take you a few minutes. I tried it and it locked up, but if you can make it sample the results will be interesting.
Compile the PS2000con.c on 64 bit Linux
gcc -lps2000 PS2000con.c -oPS2000con
Then run it as follows
./PS2000con
Set 50mV input range
v
2
99
Use ADC counts
a
Set up the signal generator, 1khz square
g
1000
1
Sample period 320 ps
i
5
Take some samples
b
For example I get
-209
-512
-209
-512
-512
-512
-512
-512
-209
-209
The minimum difference between different readings is 303 counts
I try again and get
b
1304
1002
1002
1304
1002
1304
1304
1002
1304
1304
This time minimum difference is 302 counts
Now we repeat this with oversampling enabled. So edit line 400 of PS2000con.c to read
oversample = 16;
Then recompile and rerun
gcc -lps2000 PS2000con.c -oPS2000con
./S2000con
Then rerun PS2000con and repeat the above sequence. This time on pressing b we expect a smaller minimum difference. When I tried it just now it locked up. If you get that, then it needs fixing. If you get samples, and the minimum difference is similar to before, that needs fixing. If you get samples, and the minimum difference is more like 19 (by my estimation), then its working for you.
If you get a chance to try it, I would be very interested to hear what happens.
In this scenario, the signal generator outputs a 1 V p-p square wave and the input range is +/- 50 mV, so I would expect to read 32767 or -32767. Am I missing something?
That's a fair point, and hopefully its just the probe wasn't making contact.
However this doesn't explain the lockup or the large jumps in ADC values with oversampling enabled that I saw on a separate occasion.
All the test needs though is a DC voltage that's in range. I would like to see some evidence that at least it works for you on 64 bit Linux. If you could post your ADC numbers with and without 16x oversampling it would be appreciated.
I just got a driver update email, so revisited this problem.
I downloaded both the latest published driver and the one mentioned above, and notice they are the same. So here is what happens for me after I deleted all the old drivers from /usr/local/lib64/libps* and /usr/local/include/libps* and installed the new libps2000-2.0.7.7-1.x86_64 files
Compiled the demo with
gcc -lps2000 PS2000con.c -oPS2000con
Ran with
./PS2000con
Configured for 50mv, 160ps timebase, show ADC counts with this input
v
2
99
i
4
a
Now we try an acquisition after grounding the scope channel A input by clipping the ground of the oscilloscope to its own measuring tip.
b
Collect block immediate...
Press a key to start
timebase: 4 oversample:1
First 10 readings
Value
time unit: 2
(ps)
94
397
94
397
397
397
397
94
94
397
OK, now we enable oversample by changing line 400 of PS2000con.c to be
oversample = 16;
Recompiled with
gcc -lps2000 PS2000con.c -oPS2000con
Reran with ./PS2000con
Ran the above config again, and this time the collect block operation locked up.
So has anyone tried this driver on 64 bit Linux? If they could repeat the above and post the results I would really appreciate that.
Is it too much to expect that someone at Picotech try this simple test and post the result?
This issue has been around since January. I notice its been viewed 879 times, so to carry on ignoring it cannot be good for the image of Picotech.