Picoscope Triggering

Having problems ? let us know the details here
Post Reply
gerardtouma
User
User
Posts: 4
Joined: Sun Dec 02, 2018 1:32 am

Picoscope Triggering

Post by gerardtouma » Sun Dec 02, 2018 1:39 am

Hi,

I have a picoscope 6000 series. I am running the simple experiment of applying a 5 cycle sine wave to one of the picoscope channels, and triggering the picoscope from the trigger_out port of the function generator. The repetition rate of the burst is 10 us, the sine is at 120 MHz, has 20 mVpp amplitude, and 0 DC offset. I am using the Matlab piscoscope libraries to run the experiment.

Problem: every ~3 milliseconds, I see that there is a 'single' sample shift in the acquired signals. This is problematic for me as I need all the acquired signals (over a period of ~2 seconds) to be all the same phase. I checked with a lab oscilloscope that I have, and the trigger-signal delay seems the same and I do not have this problem on the oscilloscope.

Can you please help with this? It is urgent.

Thanks.

Hitesh
PICO STAFF
PICO STAFF
Posts: 2855
Joined: Tue May 31, 2011 3:43 pm
Location: St. Neots, Cambridgeshire

Re: Picoscope Triggering

Post by Hitesh » Mon Dec 03, 2018 2:48 pm

Hi gerardtouma,

Would it be possible to post your code here or send it support@picotech.com so we can investigate further please?

Do you see the same effect with the PicoScope 6 software at all?

What is the source of the 120 MHz sine wave?

Which version of the PicoSDK and MATLAB are you using?

Regards,
Hitesh

Software Dev. Engineer

gerardtouma
User
User
Posts: 4
Joined: Sun Dec 02, 2018 1:32 am

Re: Picoscope Triggering

Post by gerardtouma » Mon Dec 03, 2018 9:53 pm

Hi Hitesh,

I will send the code to the email you included.
The source of the 120 MHz source is a function generator: Agilent Technologies 81150A.
The version of the picoSDK is: 1.2.20 (from pico tech_ps6000_generic.mdd file, summary section).
Matlab version I am using: R2017b.

Best,
Gerard

gerardtouma
User
User
Posts: 4
Joined: Sun Dec 02, 2018 1:32 am

Re: Picoscope Triggering

Post by gerardtouma » Tue Dec 04, 2018 11:29 pm

Hi Hitesh,

An update on the experiments:
- When I synchronize the reference clocks of picoscope and my function generator, this solves this issue. However, by doing this I am losing an analog channel because the reference clock is connected to AUX, and the trigger needs to be connected to one of the 4 channels A-D. However, this will not work for my application, as I need the data for 4 channels. Any recommendations?
- When I visualize the trigger on channel A, it seems that the 'relative' delay between the trigger and the sine RF signal from the generator is correct, but the 'moment' when picoscope triggers (starts collecting samples) is not correct. Any advice on that? Is it possible to access the data from channel AUX?

I would be great if you can let me know soon as I am under a tight time constraint.
Thanks!

Gerry
PICO STAFF
PICO STAFF
Posts: 403
Joined: Mon Aug 11, 2014 11:14 am

Re: Picoscope Triggering

Post by Gerry » Fri Dec 07, 2018 4:53 pm

Hi gerardtouma,

Going back to your first post, if you have a PicoScope 6000, and a separate Agilent Signal Generator which you are setting to repeatedly send a signal at a multiple of the sample rate of the PicoScope 6000 you will always get spurious phase delays between an actual sample point and the expected sample point. This will happen because the clocks will never be exactly synchronized for the duration of a capture. When they are not synchronized, the relationship between the trigger point and the start of a waveform will vary statistically. For any oscilloscope, depending upon a number of factors, including; the actual versus interpreted signal levels at the time a trigger fires, the aperture delay, the method of sample and hold used by the ADC, etc, the distance between 2 samples that should be a small fraction of a sample period could be converted to something approaching a whole sample period, for a small 'statistical' sample of the entire data population making up a data acquisition capture. What this means, from a practical point of view, is that a very small percentage of samples can be hugely out-of-position.

Clearly, when you synchronize the sample clock to the Sig Gen clock, this problem goes away because, the samples will now be occurring at or near the same position every cycle, so there will be no statistical variance for a few out-of-position samples, as described previously.

You say that synchronizing through the additional input won't work, because you need to use a channel for triggering and you need 4 channels for your data. Well, this is the only way to use a 6000 series PicoScope, whether synchronized or not, for accurately triggered captures. If you were thinking of using the additional input as an Aux Trigger input instead of as a Reference clock input, then you need to be aware that the trigger accuracy for that input is +/- 1 sample interval, so you wouldn't be getting rid of the 'Single sample shift' that you mentioned in your first post by using this input for triggering. And you don't have to necessarily lose an input channel because you are using one for triggering. What you can do is use the 4 data input channels for your data, and trigger off of an event on one of the signals being captured as data, so that you're using a channel for both triggering and data.

Regarding your last statement (in particular when you say "the 'moment' when PicoScope triggers (starts collecting samples) is not correct"), The trigger fires according to a mechanism unrelated to the sample clock, so the first sample is highly unlikely to occur exactly when the trigger does.
In PicoScope 6 the software does something called 'Trigger Time Offset' adjustment, where all of the samples are moved backwards or forwards in time so that, for the 2 samples above and below the trigger, the interpolated waveform passes through the trigger diamond. You can perform a similar function in the SDK by adding or subtracting the ps6000GetTriggerTimeOffset(), (or sample interval - ps6000GetTriggerTimeOffset(), if you want keep the adjustment to within half a sample interval) to the occurrences of your data points. That way the reconstructed waveform in Matlab should pass through the trigger point, even if the sample points don't line up to it.

Regards,

Gerry
Gerry
Technical Specialist

gerardtouma
User
User
Posts: 4
Joined: Sun Dec 02, 2018 1:32 am

Re: Picoscope Triggering

Post by gerardtouma » Mon Dec 10, 2018 9:52 am

Gerry,

Thanks for the detailed and clear response. It all makes sense now.
The experiments I have been doing support what you said, and now I am working on running the SDK function to compensate for the trigger offset. I am running through few issues calling the function, but that should be resolved (I am in touch with Neil over email). If I face more issues, I will also post it here, as I think this should solve the issue I am facing.
For your reference, I am attaching the trigger offset (in time) for a continuous number of samples without compensating for the trigger offset. Note how the offset/drift bounces between [0-Ts] (I am using Ts = 0.8 ns, i.e. fs = 1.25 GS/s). I am hoping that the SDK function should solve this issue.


Thanks.
Attachments
Pasted Graphic.png

Post Reply