Does oversampling work on 220X scopes with 64 bit Linux?

Sonander · Post by **Sonander** » Mon Jan 05, 2009 10:23 pm

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

Code: Select all

	oversample = 1;

to

Code: Select all

	oversample = 4;

Then enable channel 1, 100mv scale, select timebase 10 and kit B for an immediate block it locks up.

If anyone has got oversampling to work on Linux, specially 64 bit Linux I would be very interested to hear how it was done.

Robin · Post by **Robin** » Tue Jan 06, 2009 2:03 pm

Hi Sonander

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.

Thanks for bringing this to our attention.

Robin

Robin · Post by **Robin** » Thu Jan 08, 2009 11:29 am

Here is the fixed Windows driver. The Linux driver should follow next week.

Robin

Robin · Post by **Robin** » Mon Jan 12, 2009 3:03 pm

Here are 32-bit and 64-bit Linux drivers for the 2000 and 3000 series scopes.

Robin

Sonander · Post by **Sonander** » Tue Jan 13, 2009 8:50 pm

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.

Sonander · Post by **Sonander** » Wed Jan 14, 2009 9:04 pm

Hi Robyn,

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.

Robin · Post by **Robin** » Thu Jan 15, 2009 2:01 pm

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?

Robin

Sonander · Post by **Sonander** » Thu Jan 15, 2009 2:55 pm

Sorry, what I forgot to mention I was using a times 10 probe to connect channel a to the signal generator output. So the scope sees 0.1V p-p square.

The high sampling rate means you normally see a constant voltage, a tiny part of the top or bottom of the square wave.

Robin · Post by **Robin** » Thu Jan 15, 2009 3:17 pm

Even with a 100 mV p-p input, on a +/- 50 mV range I would expect to see values close to 32767 or -32767.

Sonander · Post by **Sonander** » Thu Jan 15, 2009 3:43 pm

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.

Robin · Post by **Robin** » Wed Jan 28, 2009 9:36 am

Hi

I haven't forgotten about this post. It looks like there could be a bug in the driver oversampling and we are investigating.

Robin

Robin · Post by **Robin** » Mon Feb 02, 2009 1:04 pm

Here are updated drivers that have oversampling correctly implemented.

Sonander · Post by **Sonander** » Fri Feb 20, 2009 9:03 pm

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.

Sonander · Post by **Sonander** » Wed Mar 11, 2009 8:32 pm

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.

Robin · Post by **Robin** » Thu Mar 12, 2009 4:10 pm

Hi

Sorry, I missed this post. (If you have a query specifically for Pico, it's best to email directly, support@picotech.com)

How many samples are you trying to collect? If it is 1024, then you cannot have an oversample value of 16.

The maximum number of samples (for a 2205) is (2^14 - 128) / (oversample * no. of channels).

ps2000_get_timebase will return the max samples for a given time base and over sample value.

Hope this helps

Robin