PicoScope 7 Software
Available on Windows, Mac and Linux
Gap in data during "long" acquisition
Gap in data during "long" acquisition
I'm using a PicoScope 5444D to capture as much data as possible at 41.667 MHz without segmentation or using the streaming API. It turns out that I can capture 100 Ms with a single trigger, so about 2.5 s worth of data. I'm capturing 11 digital signals and one computed signal. (It is a 16.1 MHz clock signal and a 10 bit A/D converter, so the sample rate is enough to capture what the A/D converter sends to an FGPA.)
I've then exported the data as csv and wrote a small script to convert the data to a more compact form. When analyzing the data I discovered that some samples are missing, and that the missing samples have a repeating pattern: every 1024x1024-epsilon samples (epsilon is between 1 and 20) samples, there is a gap of a few samples, and the timebase column does not reflect this. If I insert a few dummy values every 1 Mi samples the glitch is mostly covered up. The time column increments by 1/41.667M s per line in the csv file, however, so it is impossible to exactly correct for the missing samples.
Is this a known limitation, and if so, any good workarounds? I'm using PicoScope 6 on Linux in case it matters. The periodicity of the missing samples smells like it is a firmware problem rather than a problem with the pc software.
I've then exported the data as csv and wrote a small script to convert the data to a more compact form. When analyzing the data I discovered that some samples are missing, and that the missing samples have a repeating pattern: every 1024x1024-epsilon samples (epsilon is between 1 and 20) samples, there is a gap of a few samples, and the timebase column does not reflect this. If I insert a few dummy values every 1 Mi samples the glitch is mostly covered up. The time column increments by 1/41.667M s per line in the csv file, however, so it is impossible to exactly correct for the missing samples.
Is this a known limitation, and if so, any good workarounds? I'm using PicoScope 6 on Linux in case it matters. The periodicity of the missing samples smells like it is a firmware problem rather than a problem with the pc software.
Re: Gap in data during "long" acquisition
can you try this in picoscope software and post a .psdata file ?
What programming language are you using for the SDK.
Benno
What programming language are you using for the SDK.
Benno
Re: Gap in data during "long" acquisition
I did use the PicoScope software, but didn't save the psdata file (only csv since that is what I can easily write tools to parse). So no API at all. I'll try to set up a new experiment within a day or two and post the result. Hopefully the effect can be observed with smaller captures than 100 Ms.
Staffan
Staffan
Re: Gap in data during "long" acquisition
First let me say I remembered incorrectly: I double checked and I have Picoscope 7.0.94-1r10729. It is also incorrect that the timebase column doesn't reflect the missing data: it was a mistake in my parser that didn't see the time jump since it was smaller than a (too large) tolerance value. But samples are definitely missing.
I tested now, and it seems the problem disappears if I remove the computed column, which, btw, has some NaN entries next to the missing rows. I can reproduce the problem with the following settings:
41.67 MS/s
5 ms/div
Samples 2.08 MS
Inputs enabled: D0-D10,D15
Computed signal: LowPass(D0+2*D1+4*D2+8*D3+16*D4+32*D5+64*D6+128*D7+256*D8+512*D9,9999999)
D0-D10 were not even connected during the test, but D15 was connected to a signal generator outputting a square wave at 5 MHz. (So I could see the missing samples due to an "odd" cycle in the waveform.) Of course now that I know the time column also has a jump that wouldn't really be needed. The psdata file is attached.
Zooming in on the waveform in the picoscope software everything actually looks good, so it does seem it is the export to csv function that does something strange. I'm not 100% sure, however, since I'm very unused to the PicoScope software and might have zoomed incorrectly. The exported csv file is available here: http://madeye.org/~staffanu/20220420-0005.csv (I didn't even try to attach it due to its size.) The easiest way to spot the problem might be to search for NaN in the file. After the first line with a NaN value, there is a gap in time to the next line. This is line 1048575, so notice it is almost 2^20.
Staffan
I tested now, and it seems the problem disappears if I remove the computed column, which, btw, has some NaN entries next to the missing rows. I can reproduce the problem with the following settings:
41.67 MS/s
5 ms/div
Samples 2.08 MS
Inputs enabled: D0-D10,D15
Computed signal: LowPass(D0+2*D1+4*D2+8*D3+16*D4+32*D5+64*D6+128*D7+256*D8+512*D9,9999999)
D0-D10 were not even connected during the test, but D15 was connected to a signal generator outputting a square wave at 5 MHz. (So I could see the missing samples due to an "odd" cycle in the waveform.) Of course now that I know the time column also has a jump that wouldn't really be needed. The psdata file is attached.
Zooming in on the waveform in the picoscope software everything actually looks good, so it does seem it is the export to csv function that does something strange. I'm not 100% sure, however, since I'm very unused to the PicoScope software and might have zoomed incorrectly. The exported csv file is available here: http://madeye.org/~staffanu/20220420-0005.csv (I didn't even try to attach it due to its size.) The easiest way to spot the problem might be to search for NaN in the file. After the first line with a NaN value, there is a gap in time to the next line. This is line 1048575, so notice it is almost 2^20.
Staffan
- Attachments
-
- 20220420-0006.psdata
- (68.22 KiB) Downloaded 188 times
Re: Gap in data during "long" acquisition
the .psdata file looks empty and is seqence 0005 and the CSV is 0006
The CSV file has 1 NaN in the middle it looks like it is missing 5 samples.
Looks like some calculation is going wrong in the LowPass math calculation.
can you try in picoscope 6 ?
Benno
The CSV file has 1 NaN in the middle it looks like it is missing 5 samples.
Looks like some calculation is going wrong in the LowPass math calculation.
can you try in picoscope 6 ?
Benno
Re: Gap in data during "long" acquisition
I tried to download the .psdata file to my computer at work and it seemed to contain everything. It is small but I assume it is compressed and that the information content is very small since the only input was a regular clock signal. The .psdata file is also available at http://madeye.org/~staffanu/20220420-0006.psdata
The sequence number looks wrong but this is just the default file name given by picoscope when I first saved as csv, and then as psdata -- it seems it increments the number by one for each save.
Unfortunately I gave up after trying to install picoscope 6. I uninstalled everything picoscope 7 and have the repository
deb https://labs.picotech.com/debian/ picoscope main
in my sources. Trying to install gives me this error:
I also cannot find Picoscope 6 for mac on the download page -- otherwise I could have tried that.
The sequence number looks wrong but this is just the default file name given by picoscope when I first saved as csv, and then as psdata -- it seems it increments the number by one for each save.
Unfortunately I gave up after trying to install picoscope 6. I uninstalled everything picoscope 7 and have the repository
deb https://labs.picotech.com/debian/ picoscope main
in my sources. Trying to install gives me this error:
Code: Select all
$ sudo apt-get install picoscope=6.14.61-4r6219
The following packages have unmet dependencies:
picoscope : Depends: libpicoipp (= 1.3.0-4r130) but 1.4.0-4r133 is to be installed
Depends: libps2000 (= 3.0.82-3r3072) but 3.0.86-3r3127 is to be installed
Depends: libps2000a (= 2.1.82-5r3072) but 2.1.86-5r3127 is to be installed
...Re: Gap in data during "long" acquisition
Yes tried it in PS7 but dit not get the ADC result got the digital signals.
It seems like there is a bug in the CSV export the NAN is at exactly row 1048575 that is in hex 0xFFFFF so they probably have a buffer of 0x100000 rows and somehow the last row gets a NAN.
b.t.w. on windows the filter output is not visible and also not in the CSV output if you generate it again.
Benno
It seems like there is a bug in the CSV export the NAN is at exactly row 1048575 that is in hex 0xFFFFF so they probably have a buffer of 0x100000 rows and somehow the last row gets a NAN.
b.t.w. on windows the filter output is not visible and also not in the CSV output if you generate it again.
Benno