Hello!
Preamble: OS Microsoft Windows Vista 32b, driver v2.04.16, oscilloscope software (PCLAB2000SE) v4.03.
I’ve find out, that “delay” function for trigger doesn’t operate at all.
The Holdoff function doesn’t operate when I typed the value and have set “Holdoff” check-box. I should obligatory press the Enter key while the text cursor is in “Holdoff us” box. After Enter key pressing, Holdoff function works as indeed. I suppose it’s a bug. The function should work right after checking the box, without any keyboard pressing.
Nor pressing Enter, nor other manipulations with trigger delay value and check-box have an effect. The delay will not apply.
I’ve checked EXT, CH1, CH2 synchronization. There is no trigger delay, even if it’s selected and entered.
For example:
[ul][li]I’ve connected EXT terminal to 1kHz square wave generator.[/li]
[li]Then I selected EXT trigger from positive transition.[/li]
[li]While seeing the same wave through the CH1 in RUN mode, I’m entering delay value 250 and checking the box “Delay”.[/li]
[li]Nothing is happen. The wave phase on screen remains the same - without 250us shift.[/li][/ul]
P.S. Delay and Holdoff values are not saved when “Save/Recall Last settings” in “Options” is selected and program is restarted usual way. Possibly it’s another bug.
[quote]• While seeing the same wave through the CH1 in RUN mode, I’m entering delay value 250 and checking the box “Delay”.
• Nothing is happen. The wave phase on screen remains the same - without 250us shift.[/quote]Please see in the oscilloscope Help/Contents the section “Trigger Holdoff and Delay” -> “Delay by Time”.
There you’ll find the description how the delayed triggering works.
It doesn’t delay the trace compared to the triggering point but delays the triggering compared to the first triggering event.
[quote]Delay and Holdoff values are not saved when “Save/Recall Last settings” in “Options” is selected and program is restarted usual way. Possibly it’s another bug. [/quote]This feature will be considered for future releases.
[quote]After Enter key pressing, Holdoff function works as indeed. I suppose it’s a bug.[/quote]This is not a bug. In the help file is written: “Press Enter key when the data is entered into the edit box.”
Thank You for quick and qualified support (judging on whole DSO tread)!
[quote=“VEL255”][quote]• While seeing the same wave through the CH1 in RUN mode, I’m entering delay value 250 and checking the box “Delay”.
• Nothing is happen. The wave phase on screen remains the same - without 250us shift.[/quote]Please see in the oscilloscope Help/Contents the section “Trigger Holdoff and Delay” → “Delay by Time”.
There you’ll find the description how the delayed triggering works.
It doesn’t delay the trace compared to the triggering point but delays the triggering compared to the first triggering event.[/quote]
Unfortunately, the English isn’t my native language. I’ve read help/contents in this section carefully, and my understanding this feature is that the delay function is delaying the trigger event inside of DSO relatively to real trigger signal edge.
Another thing - there is nothing about delay and holdoff in EN user manual (PDF).
Can You give some more info and samples for trigger delay? May be user manual should be updated?
It’s clear. Thank You. I’ll be glad to discover this feature in newer software versions.
It’s some kine of inconvenience. Why the number typing and checking the box is insufficiently? Why Enter is necessary, if the check-box is there?
[quote]Can You give some more info and samples for trigger delay? May be user manual should be updated?[/quote]In the software v4.03 download package there is a PDF file “Release Notes”. There in the chapter “New features: Trigger Holdoff and Delay” is description of the trigger holdoff, delay by time and delay by events with example screenshots.
The same data is found also in the help file of the PCSU1000.
At the moment these are the only documents concerning the trigger delay options.
[quote]It’s some kine of inconvenience. Why the number typing and checking the box is insufficiently? Why Enter is necessary, if the check-box is there?[/quote]The problem is that the oscilloscope control software must know when the entered value is complete. You can confirm this by either pressing the Enter button or using the mouse to check the check box. If the check box is already checked, you have to uncheck and check it.
VEL255, thank You for answer and patience.
Well, I think I correctly understood the delay feature. I confirm: the delay feature didn’t work.
Please, repeat an experiment:
[ol][li]Take 1kHz square wave generator;[/li]
[li]Connect EXT terminal of PCSU1000 to generator output and click “RUN”;[/li]
[li]Select EXT trigger, positive edge and set the trigger level to obtain stable triggering at middle of usable triggering level range;[/li]
[li]Connect CH1 terminal to the same generator output as the EXT connected;[/li]
[li]Adjust V/div and T/div to clearly view 2 periods of square wave;[/li]
[li]Click “>|<” button in trigger menu to normalize triggering point position;[/li]
[li]In holdoff and delay section, type delay value 250us. Press Enter;[/li]
[li]Check the box “delay”.[/li][/ol]
After completion of point 6, You should seen the positive edge of pulse right at the trigger position mark at the time axis. The positive pulse lasts from trigger mark 500us. Another 500us lasts the negative pulse. OK. The instrument works as it should.
After completion of point 8, acquired waveform record should be shifted at 1/4 of period in right direction respectively waveform graph. It didn’t in my case. The graph stays absolutely the same. There is no time shift distinguishable on the graph when 250us shift should be at 1/4 of period - highly noticeable.
Where I’m not right?
The description of the delayed triggering is quite draft in the documents. I try to clarify it here with some examples.
Here is the description how the delayed triggering works:
Delay by time triggering is a trigger mode in which the trigger circuitry arms on an edge of the selected channel, waits for a period of time, then triggers on an edge of the selected channel. Basically, the trigger criterion is two edge triggers separated by at least the selected period of time.
You can use the Delay by Time triggering mode when you want to acquire a waveform record that is separated from the trigger event by a significant interval of time. The delay function can be used mainly in Single mode.
The first trigger arms the instrument.
The acquisition starts on the first edge after the trigger delay time.
In your example the triggering is delayed by 250us from the first triggering event.
The final triggering and the waveform acquisition starts on the next rising edge found after the 250us time is elapsed.
The triggering occurs on the next rising edge.
In a continuous wave there is no difference seen on the screen.
Below there are images showing how the delay can be seen on the screen.
The example waveform is a 1kHz sine burst.
In the first image there is no triggering delay and the triggering occurs on the first rising edge.
In the second image there is triggering delay set to any value from 1us to 999us.
The triggering occurs on the second rising edge.
In the third image there is triggering delay set to any value from 1010us to 1999us.
The triggering occurs on the third rising edge.
[quote]May be there is problem after PCLAB software upgrade, from v4.00 to v4.03? I’ve found interesting post at this forum.[/quote]The link in the post is updated to the latest software.
The Vista / Windows 7 problem is fixed in the latest version 4.03.
VEL255, thank You again.
I’ve realized that the “delay” feature of PCSU1000 isn’t what I want. And isn’t what I understood firstly. Please, excuse Me for my obstinacy.
There is difference between holdoff and delay as I understood:
Each holdoff cycle consist of one triggering. Each delay cycle consist of two triggerings. The recording is performed only at second triggering in delay cycle.
“Delay” feature is not what I need.
Can You change the name of present delay feature from “Delay” to “Delayed triggering” or “Pause” and implement new, true delay (in My opinion) feature as described below:
Each “Delay” cycle consist of one triggering and one recording. After trigger event, the delay period is started. The triggering during the rest of delay cycle, until the recording completed, must be suppressed. The recording should start right after the delay period, without need of second trigger event.
In that way the record period is directly bounded to single, first trigger event via delay time.
The requested feature is needed to examine the weak, short or unknown signals of any form which are delayed from certain “clock” pulse for certain time. Such signals may be not suitable to stable triggering with current “Delay” feature.
An example of application field for requested “delay” feature - the reflectograms. Any region of reflectogram may be examined more precisely in time domain even there is no suitable signal to triggering at selected time.
The current delay feature prevents to determine exact time of the event in relation to first triggering. The requested - allows.
I hope it is possible.
[quote]The recording should start right after the delay period, without need of second trigger event.[/quote]This is good idea. I think it is possible to add this kind of second delay function to the PCSU1000 oscilloscope.
I’ll inform here in this forum when the first release of the modified software is available for download.
Horizontal Delay
Use horizontal delay to acquire waveform detail in a region that is separated from the trigger location by a significant interval of time. The horizontal delay function is not usable in 1GS/s mode.
The first trigger arms the instrument.
Waveform acquisition starts after the delay time.
You may toggle the horizontal delay on and off to quickly compare signal details at two different areas of interest, one near the trigger location and the other centered at the delay time.
The horizontal delay function can be used together with the Holdoff trigger option.
The “Save/Recall Last settings” bug is not yet fixed. – Will be fixed in the “official” v4.04 release.
I’ve checked “Horizontal delay”. It works as it necessary for me.
Less than 24 hours from request to realization! Thank You with all my heart!
Velleman oscilloscope support is the best I’ve ever contacted! I’ve shocked in the best sense of this word!
There is few companies in the world where the users have a direct contact with qualified engineers.
I had to recommend Velleman products to my friends and colleagues.
By the way: why Velleman called new delay “Horizontal delay”. May the “Vertical delay” exist?
I’ve got first results:
I’ve measured an Audio DAC analog output signal jitter. The DAC was playing a 10kHz sine wave.
When I’ve activated the “Horizontal delay” of 10000000us (10 seconds), the phase of signal on the screen was changed greatly because of scope and DAC clock frequencies mismatch, but the wave image stays stable.
The jitter of crossing “0” by “eye diagram” is 1.8us peak-to-peak after 10s delay. It’s 0.18ppm drift between DAC and scope clock generators averaged during 10s. Quite good, I suppose.
One reason to the new name “Horizontal Delay” was that the “Delay by Time” was already used for different type of delay. The new name is descriptive to indicate that the trace is delayed (shifted) horizontally on the screen…
Indeed, what might be the “Vertical Delay” ?
Thank you for doing the test with long delay.
The delay stability seems to be good!
Also the time accuracy seems to be good:
I made a test with the function generator PCGU1000.
With a 10 seconds delay the error was only 60us (6ppm).
I’ve tested 20s delay. It works. I was able to catch a signal pattern at 20s from clock pulse. The difference on certain signal (synthesized pattern which was played through an audio DAC) was 1.68ms, ~84ppm.
Is the delay limit 21s?
As I tested, the Holdoff and the Horizontal delay can be used together. I was able to stay synchronized with S/PDIF interface signal at 44100Hz pattern rate (usable holdoff was 22.59-22.66us) and use horizontal delay for 1-5 seconds simultaneously. While enabling horizontal delay, the S/PDIF pattern becomes shifted but stays synchronized. When I disabling the holdoff while delay activated, the pattern runs. So holdoff works with delay together.
May I mistaken?
Thanks again for doing the tests.
The holdoff and delay seems to work together as expected.
[quote]Is the delay limit 21s?[/quote]Yes, at the moment it is 21s. There is a 32 bit delay counter in the hardware. The delay clock is 100MHz - delay resolution 10ns.
Now in the software there is used 32 bit integer. This limits the max value to 2.1 billion x 10ns = 21s.
By using an unsigned 32 bit integer, the delay can be expanded to 42 seconds. This will be done in the next release.
Also one bug found: The delay is effective also it the trigger is off. - Will be fixed too.
Please, take a look at images below. I’ve trying to compare DAC’s jitter of different DACs and in different modes.
I’ve generated the test signal (spectrum on graph below). Judging by spectrum, there is no jitter in discrete representation of the test “pattern” (WAV-file).
Then I’ve played this signal through 2 different audio DACs. I’ve tested 2 different software interface (ASIO and WASAPI) and 2 different physical interfaces in combinations for first DAC and 2 software interfaces for second DAC (it was Realtek HD Audio Codec of laptop).
I suppose there is jitter in oscilloscope himself, because the jitter appearance on the graphs for different DACs and different physical interfaces is similar. The DAC in first case have intrinsic hardware ASRC). The second DAC - standard audio codec for PC. First DAC gives absolutely identical “jitter bars” on graph in any software mode, at any interfaces and even with software upsampling to 192kHz fs. Very stable. The second DAC - generic PC soun out. Its “jitter bars” are wider, but the same by placing and distance between. I think that the DACs should show different jitter walue (bars wide), but bars count is the delay jitter.
I haven’t check carefully different delays yet.
Have You a low jitter generator to check jitter on screen for horizontal delay of 50ms?
[size=150]The spectrum of digital test sine signal 13333.33Hz (1000s lenight, 24bit, 44100Hz fs):[/size]
[size=150]Analog signal on screen, 1 case:[/size]
[size=150]Scope settings, 1 case:[/size]
[size=150]“Mafnifyed” positive slope of sine, 1 case:[/size]
[size=150]Analog signal on screen, 2 case:[/size]
[size=150]Scope settings, 2 case:[/size]
[size=150]“Mafnifyed” positive slope of sine, 2 case:[/size]
I should add that I saw during the measuring case 2, the trace lines was spreaded by time the same way as in case 1, just more chaotically (the second DAC have definitely lager jitter).
I made a test using a microcontroller to generate a crystal based 10kHz signal.
Indeed, there seems to be some strange jitter if the horizontal delay time is increased.
Below there are results at 5000us and 50000us delay.
The jitter seems to be quite random.
At the moment I don’t know why there is the jitter and why it is so random.
The analysis have to be continued…
