SDS1104X-E waveform alignment problem - Page 1
Forum section: electronics / testgear

author: nez
author_rank: Regular Contributor
timestamp: January 30, 2021, 07:12:03 am
content: This is a follow-up to some posts I initially made in the general SDS1104X-E and SDS1204X-E thread where I was describing problems with phase, amplitude, and Deskew threshold values, the last of which is here:https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3241020/#msg3241020After setting the issue aside and forgetting to look at it again (oops), I finally gave it some more thought and realized to look at the individual samples in Dots mode to better understand what's happening.(I'm leaving out the amplitude issue here, however.)----------------Problem:I am seeing incorrect alignments of waveforms between channels depending on which ones are enabled with my SDS1104X-E scope (unlocked). The issue affects the display of the waveforms and sample dots, auto-measurements, and Deskew window thresholdsI made a quick video to show the rough idea of the behavior. In it I'm basically starting the signals and showing the alignments, and using Stop mode to show the sample Dot positions. (Sorry if the dots are a bit dim and hard to see in Stop mode).The AWG CH 2 phase is adjusted -9 degrees to make sure it matches CH 1 on the scope when using CH 1+2 with two different cables (both 50ohm terminated).The video shows:1. At start, CH 1+2 only with signals has expected output, sample Dots are aligned.2. At 0:20, a few cycles showing different CH 3 (no signal) Dot alignments not matching CH 1+2 (with signals) Dots, each 'cycle' is me disabling/re-enabling CH 2.3. At 0:46, swapping the signal cable from CH 2 to CH 3 very clearly shows the waveform is now incorrectly displayed, even though it should be exactly the same as CH 1.4. At 0:55 on, more cycles of disabling/re-enabling CH 2 while CH 1+3 have the signal inputs, showing the misalignment amount varies each time.https://youtu.be/FBkE_Yl4OYY(Edit: added the video as embedded)I wonder if the signals are being recorded properly, but are stored or read using a wrongly calculated/shifted timestamp mapping.(Disclaimer - I know very little about oscilloscope architecture)Separate from the offset problem itself, CH 3's samples sometimes seem to be 180 degrees (plus the incorrect offset) from the CH 1 samples, and sometimes 0 degrees (plus incorrect offset). This also varies as I disable/re-enable CH 2. I don't know the nature of why the samples are sometimes staggered 180 degrees like that and sometimes not.Any ideas why that happens? If I remember correctly from past trials, this also affects the Deskew window thresholds in addition to the offset error.An additional observation: When CH 2 is disabled (meaning only CH 1+3 enabled with signals), I also see a small offset between sample times between channels, even though the waveforms seem to be drawn properly in Run mode. I wonder if this means there is a small amount of 'proper' compensation for when sample times are out of sync a little bit to still get the waveform to display correctly in this case. This is shown at about the 1:00 mark in the video. But, even in this case there can still be a slight variation/error (compare 1:00 mark to the 1:04 mark after a cycle of enabling CH 2). When the enabled channels are only on the same ADC (like CH 1+2), the samples are exactly aligned, as seen at the start of the video.When disabling/enabling CH 2 while CH 1 and 3 are also enabled, there is a period of time in which the UI lags/stalls and the waveforms rearrange and flicker (displayed several times after about 1:03 mark), so I imagine there is a lot of computational work being done in this scenario. Seems like there is something flakey in whatever algorithm is being used to ensure proper alignment data samples across channels. (Or, perhaps system interrupts are messing up its timing during this calculation lag?)Isn't this something that can be fixed in firmware? Even if it takes a bit of extra time on top of the current channel enable/disable lag to fix it, that's better than having a varying error.I think it would be very frustrating to deal with this when trying to do real timing comparisons/troubleshooting of high-speed and overlapping signal edges, even more so as you increase to 200MHz.Is this an issue that's better to forward directly to Siglent?

author: tautech
author_rank: Super Contributor
timestamp: January 30, 2021, 07:23:41 pm
content: Some questionsSelf Cal, when was it last run ?Did you Default the DSO to clear any previous settings ?Could there be a timing error between the channels of the AWG ?Did you run the AWG Default to clear and previous settings ?Did you Phase lock the 2 channels ?

author: nez
author_rank: Regular Contributor
timestamp: January 30, 2021, 09:58:53 pm
content: Quote from: tautech on January 30, 2021, 07:23:41 pmThanks for the reply tautech.I did a self-cal around an hour before I made the video (done after warm-up).I hadn't reset the scope using Default, but I did just now and the results are the same.There is a small timing difference between the two channels on the AWG, this is why I tuned CH 2 output by -9 degrees @100MHz to get them synced.If I output only from CH 1 with a T-adapter using the same cables + terminators, the phase is virtually identical to each other without any adjustments on the scope (CH 1+2), meaning the cables are very closely matched. Naturally, the amplitude is different due to two 50 ohm terminators being used off the same output.The AWG was cleared by Default before setting up the signals (just 100MHz, 1Vpp, -9 degrees phase adjustment on CH 2).Using AWG channel coupling with a phase deviation of -9 degrees @ 100Mhz produces the same matched alignment as the original test using scope input CH 1+2.

author: nctnico
author_rank: Super Contributor
timestamp: January 30, 2021, 11:31:41 pm
content: Looks like a bug in the scope to me. The waveform generator isn't touched (at least I didn't see that happen in de video) so that can be ruled out. What does happen is that the samplerate of the oscilloscope changes when a (not 'the') 3rd channel is enabled / disabled so likely something goes wrong in the firmware due to that mode change.