Thank You for test.
The results a similar to mine. So, it seems to be scope intrinsic jitter. May be it’s the noise on power lines in scope. May be jitter of FPGA/CPLD/PLD (which is)…
Can You repeat the test with higher sensitivity, with overdriving of vertical scale? This can increase signal-to-noise relation at trigger comparator inside the scope and jitter can decrease. If so, it’s definitely intrinsic noise…
It seems that overdriving of vertical scale doesn’t change the amount of the jitter.
It seems that the trigger jitter is no the cause.
I noted a strange thing: Changing the delay time in steps of 100us the jitter amount and direction changes.
Below there are results with 50100us and 50000us delay.
The operation of the FPGA is very straightforward:
When the normal triggering occurs the further triggering is disabled and a counter of 100MHz starts to count down starting from the delay value.
When complete, the oscilloscope data is read to the PC.
We must remember that even this “large” jitter is only 0.0013% (13ppm).
[quote=“VEL255”]It seems that overdriving of vertical scale doesn’t change the amount of the jitter.
It seems that the trigger jitter is no the cause.[/quote]
Agree.
[quote]I noted a strange thing: Changing the delay time in steps of 100us the jitter amount and direction changes.
Below there are results with 50100us and 50000us delay.
The operation of the FPGA is very straightforward:
When the normal triggering occurs the further triggering is disabled and a counter of 100MHz starts to count down starting from the delay value.
When complete, the oscilloscope data is read to the PC.[/quote]
Jitter seems to be code-depended. Even if the counter is jitter-fee, there may be code-depended delays between end of counting and first sample recording. May be it’s ADC starting time jitter or something similar?
Yes. It’s quite good. The declared time tolerance for PCSU1000 is 100ppm if I’m not mistaken.
But if it possible, why didn’t check wither jitter can be significantly decreased. The Delta time tolerance may be an orders better than the absolute time tolerance. If the system have no stricture imperfections, the jitter will be only noise-related (voltage or phase) but not code-related, I suppose…
I’ll try to find the time values with minimal jitter amplitude if I find the time…
[quote]The declared time tolerance for PCSU1000 is 100ppm if I’m not mistaken.[/quote]You are right, it is 100ppm.
[quote]But if it possible, why didn’t check wither jitter can be significantly decreased. [/quote]Yes, this will be done.
May be this helps. Below the [TAB] separated table:
bit Delay, us Jitter, us Comment
0 0 0,02 No delay, no difference activated/deactivated
1 0,01 0,02 Delay -0,02us (wrong)
2 0,02 0,02 Delay -0,01us (wrong)
3 0,04 0,05 Delay 0,03us,3 bands: two thin and one thik
4 0,08 0,09 Delay 0,05us, 6 bands: one thik, five thin
5 0,16 0,17 Delay 0,13us, 8 bands: 5 thin, one thik, 2 thin
6 0,32 0,32 Delay 0,29us, 9 bands: 4 thin, 1 thik, 2 thin, 2 thin
7 0,64 0,65 Delay 0,62us, 12 bands, one thik.
8 1,28 1,25 Delay 1,25u
9 2,56 2,57 Hard to determine delay, several maximums
10 5,12 5,12 Jitter is absent at T/D>5us. At T/D=5us appears abruptly and stays the same at T/D<=5us
11 10,24 10,28 Jitter is absent at T/D>5us. At T/D=5us appears abruptly and stays the same at T/D<=5us
12 20,48 29,5 Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
13 40,96 40,9 Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
14 81,92 N/A Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
15 163,84 0,1 6 bands: one thik, five thin, as for 0,08us but slightly blurred
16 327,68 N/A Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
17 655,36 N/A Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
18 1310,72 N/A Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
19 2621,44 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
20 5242,88 0,03 With many errors at T/D<=5us.
21 10485,76 N/A Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
22 20971,52 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
23 41943,04 0,17 As 0,16us but blurred
24 83886,08 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
25 167772,16 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
26 335544,32 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
27 671088,64 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
28 1342177,28 N/A Jitter is terrible at T/D<=5us and less than 0,4us at T/D=10us.
29 2684354,56 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
30 5368709,12 N/A Jitter is terrible at T/D<=5us and less than 0,6us at T/D=10us.
31 10737418,24 0,66 OK
Mention must be note, that this measurements are performed on my particular setup, with first version of “Horizontal delay”.
Thank you for doing these tests.
This (strange) jitter problem will be fixed next week a.s.a.p.
Now the jitter is removed.
Here is the link to download the updated PcLab2000SE v.4.04: box.net/shared/rq33xp67hc
Here is example screenshot with the following settings:
Horizontal delay = 50000us
Signal source: Function generator PCGU1000
Frequency: 1kHz
Jitter peak-to-peak: 0.05us/50ms = 1ppm
Here the signal source is crystal oscillator + divider.
Jitter: 0.03us/50ms = 0.6ppm
The problem was solved by modifying the FPGA code.
The delay counter result check is now isolated from the other counters (holdoff and delay-by-event counters) by putting it to own process.
Anyhow it was very strange why the jitter was very bad on all “1-bit” values e.g. 128, 256… 4096, 8192 etc.
BTW: Now also the “Save/Recall last settings” bug is fixed: The trigger delay settings and values are saved and restored.
Thank You for quick and quality software modification!
I’m glad to communicate such responsive and qualifyed support.