6402D persistence mode issue

mchouinard · Post by **mchouinard** » Fri Sep 25, 2015 2:54 pm

Hi Sir, I am having an issue with the persistence viewing mode on my PicoScope 6402D.

Equipment PicoScope 6402D Serial CP472/012
USB Version 3.0
Calibration date : 10 Décember 2014
Hardware revision 11
Driver version 1.4.4.45
Firmware revision 1.0.2.0/1.1.37.0

I conducted a series of tests using a PicoScope software 6.10.18.1052 Window 7 64 bits ultimate edition and Linux Mint 7 PicoScope software 6.11.6.33 and a Rigol signal generator DG1022U applying a 1 MHZ signal, 1 Vpp, modulation AM 100% @ 1 Khz + using the external trigger output to the AuxIO of the PicoScope 6402D.

The results are surprising and unusable on my PicoCope 6402D, I have repeated these tests under the same lab setup using the older PicoScope 5204, 5203 and got very good results.

I have also noted that my 6402D is slow update in persistence mode and I tested all other persistence mode didn't work properly either. At this time I wander if there is a issue with my new 6402D PicoScope? or is there a software issue?

I have 16 snapshots but I could not upload them because of web service limitation.

I took several snapshots to show my findings. I thank you for your support.

Regard Michel from Canada

Post by **alan** » Sat Sep 26, 2015 2:58 pm

Hi,

I think some of the issue is the timebase you are using 200uS/div x 10 divisions is 2 milliseconds across the screen.

If you have 2 milliseconds per screen then (by the laws of physics) you can not have more than 500 updates per second. Try changing to say 1us/div or faster and the number of waveforms per second should speed up.

mchouinard · Post by **mchouinard** » Sun Sep 27, 2015 3:16 pm

Hi Sir, I am having an issue with the persistence viewing mode on my PicoScope 6402D.

Equipment
PicoScope 6402D Serial CP472/012
USB Version 3.0
Calibration date : 10 Décember 2014
Hardware revision 11
Driver version 1.4.4.45
Firmware revision 1.0.2.0/1.1.37.0

PicoScope 5204 Serial YJL38/25
USB Version 2.0
Calibration date : 12 août 2009
Hardware revision 1
Driver version 1.5.5.15
Firmware revision n/a

Signal Generator Rigol signal generator DG1022U

Agilent 10073C 10:1 probe with BNC adaptor (2)

Software
PicoScope software 6.10.18.1052 Window 7 64 bits ultimate edition

Lab test setup

Output from the Rigol signal generator DG1022U CH 1 --> 1 MHZ signal, 1 Vpp, modulation AM 100% @ 1 Khz to channel to channel A of PicoScope of 6402D and channel A of Picoscope 5204.

Output trigger from the DG1022U SyncOut to --> AuxIO of the PicoScope 6402D and the EXT Picoscope 5204.

Under simultaneous test condition the Picoscope 5204 much more responsive than the 6402D. The 6402D appear much slower waiting for data update. I have captured the display and found the capture rate on the 5204 to be over 210 while the 6402D was only 12.

I have previously tried the Linux, Windows PicoSoftware + the Beta version on different computer, USB 2 + 3, without any improvement.

I wander why my PicoScope 6402D is having a much slower Capture rate than the much older 5204 under exact test condition? I am having a firmware, software or hardware issue with my PicoScope 6402D?
I have included a snapshot.

Thank you for your help

Michel from Canada

Post by **Gerry** » Mon Sep 28, 2015 3:41 pm

Hi Michel,

The mechanism used on the PicoScope 5000 series for external triggering differs subtly from the mechanism used on the PicoScope 6000C/D series. Replicating the signals that you used in your tests, the 6403D has a lower trigger limit below which the triggers reduce or stop. For the units we have in our department the lower limit for reliable triggering is in the region of 6mV for an input signal (1MHz sinewave, modulated 100% with 1Hz sinewave) of 200mV p-p, while there is no lower limit for the 5204 down to zero volts.
So, in order to guarantee triggering in persistance mode for your PicoScope 6402D, we would recommend that you increase the trigger level to maintain reliable triggering comparative to what you have been used to seeing in your PicoScope 5204. Alternatively you could send the sync into channel B and trigger off of that to lose the level restriction.

Regards,

Gerry

mchouinard · Post by **mchouinard** » Tue Oct 06, 2015 6:00 pm

Hi Gerry,

I have repeated the test and I can assure you that test condition were absolutely similar for the 6402D and the 5204 Picoscope which are sitting side by side. I have also used use the channel B to display trigger level to assure you that we are on same page.

As I indicated earlier the trigger is from a Rigol signal generator and the output sync is level is TTL. Somehow under the same test condition the 6402D is getting very slow update response as shown on the picture, the capture rate is only 8 while the capture rate on 5204 unit is above 200! and I got similar test result on the 5203 unit.

Unfortunately I don't have a second 6204D to compare these results, this unit is less than year old (2014) I wonder if there is a hardware or software issue. I have also checked the production date, the date on the 5204 is (2009) and 5203 is (2007). I cannot understand that these much older units should refresh and perform that much faster than the Pico6402D other than something being wrong with the my 6402D unit.

Thank you for your help.

Michel from Canada

Post by **Martyn** » Tue Oct 06, 2015 7:40 pm

You have a trigger level set at -1.984mv can you try changing this to say 100mv and repeat the test.

mchouinard · Post by **mchouinard** » Thu Oct 08, 2015 2:47 pm

Hi Gerry,

I have repeated the test with a trigger level set at 100 mv and the capture rate jump to 150 (MUCH IMPROVED). I repeated the test at lower trigger level setting and I got similar results down to 8 mv. I continue testing and at trigger level below 8 mv I get a ghost effect and other artifacts and capture rate is reduced and at trigger level below 800 uv capture rate is around 8.

I tested again with my Picoscope 5304 and it is getting a much faster capture rate (up to 240) and less artifacts under same test condition!

I also noticed an intermittent issue when first start my 6204D that requires restarting software to clear issue as per blue trace in picture. It would be very nice to be able to send more than 1 files attachment.

Thank you for your support

Michel from Canada

Post by **Martyn** » Tue Oct 13, 2015 1:48 pm

You should be able to add more than 1 attachment, just repeat the add file process.

In the picture is the square wave on CH B the same as the signal you are triggering on the AUX Channel ?

mchouinard · Post by **mchouinard** » Tue Oct 13, 2015 9:19 pm

Hi Martyn,

Yes it is.

>Thank you for your support.

Michel from >Canada

Post by **Martyn** » Wed Oct 14, 2015 6:34 am

I would definitely be setting the trigger level at a point halfway between the high and low values of the square wave, not at a level close to the low level. Noise in the signal and hysteresis in the trigger circuit could easily result in kissed events, and therefore a slower update rate.

The capture update rate can be affected by many things :-

Are you using the USB3 cable with the 6402D, and into a USB3 port on your PC ?

Have you tried using the same USB2 cable and PC port when comparing the units ?

mchouinard · Post by **mchouinard** » Tue Oct 20, 2015 4:01 pm

Hi Martyn,

Are you using the USB3 cable with the 6402D, and into a USB3 port on your PC ?

Re: Yes

Have you tried using the same USB2 cable and PC port when comparing the units ?

Re: I have ran tests using USB2, USB3.0, USB3.1 my finding are as follow;

-There is a substantial performance hit using USB2.

- There are no performance hit using USB3.0 or USB3.1.

- The 6402D USB3.0 / 3.1 driver doesn't register with the Windows Performance Monitor counter.

- Using the USB3 allows to lower the trigger level to 30 mV while maintaining a capture rate of
170. Reducing the trigger level below 10 mV reduce the capture rate to less than 10.

It appear there is a unexpected direct relationship between capture rate and trigger level and USB transfer performance. All other parameters (CPU, Memories, I/O) is within normal expected values.

I have included a comparison picture for your info.

I hope this is helpful.

Thank you
Michel a Canadian user

Test & Measurement Forum

6402D persistence mode issue

6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue

Re: 6402D persistence mode issue