Products > Test Equipment

Siglent SDS2000 new V2 Firmware

<< < (31/56) > >>

Performa01:
MSO – Digital Channels

This is a short review of the digital channels that make for the SDS2000 MSO functionality, and there are two bugs right from the start:

1.   After enabling ‘Digital’, all digital channels appear at the same vertical screen position (as already shown in an earlier post). Only pushing the ‘Position’ knob in the vertical section where also the ‘Digital’ button sits, automatically aligns them in a way we’d expect it to be right from the beginning.

2.   The ‘Variable’ control in the vertical section where also the ‘Digital’ button sits can be used to select a specific digital channel, which is then highlighted in red. Turning this control should select the digital channels in a consistent order 0~7, but by en-/disabling individual channels in the soft menu we easily get into a state where channel selection has discontinuities or even goes all over the place, which is rather confusing.

The bugs mentioned above are still relatively easy to handle, so we can continue the test with some real signal.

It should be noted that with digital channel enabled, memory is generally restricted to 14Mpts maximum for both analogue and digital, except for 1ms/div timebase with only one analogue channel per group enabled, where we can get a combination 28Mpts for analogue and 7Mpts for digital. Maximum sample rate for digital channels is generally limited to 500MSa/s.

The signal is a 7 bit counter changing state every 200ns and stopping for about 1µs at every 19th edge, thus creating some interesting stream of bursts.
On top of that, the MSB (D7) is fed with an asynchronous pulse <10ns wide at a repetition rate of slightly more than 1µs.

The basic settings for my tests are maximum memory, peak detect acquisition, x interpolation, vector display.

Analogue channel 4 is hooked up to the LSB of the basic counter in parallel with the digital channel D0, in order to see the time skew between analogue and digital channels – but we have to expect some inaccuracies here due to the different signal path through the analogue probe and the additional capacitive load.

Trigger is set to the falling edge of the analogue signal on Ch. 4.

Digital bus decoding has been set to display all 8 bits at once, which should give some interesting pattern, when the short, asynchronous pulse on D7 appears at random positions.

A detailed view of the signals can be seen in the following screenshot (Digital_Signals_200ns)



As can be seen, everything looks fine so far. Digital channels appear blue when low or falling edge and green when high or rising edge, which I think is a great idea. The digital channel currently selected by the ‘Variable’ control next to the ‘digital’ button is displayed in red and I haven’t found a way to disable that, but then again it’s also nice to have one particular channel stick out.

The bus decoding on the bottom of the screen shows the correct results and at this timebase setting, space is way too narrow to display any values when the short pulses occur, as has been expected.

I should also mention that despite the bus decoding, screen update is as quick as it can get and measured waveform update rate is about 2500/s in this scenario.


The next screenshot shows a detailed view of the trigger point at a timebase setting of 5ns/div (Digital_Signals_5ns_Probe_D0)



As can be seen, there is a delay of precisely 6ns from digital channel D0 to analogue channel 4, so the digital channels have less trigger delay. But when talking about delay times of a few nanoseconds, it’s quite obvious that the digital and analogue probes cannot be exactly the same and I will repeat this test with a direct coaxial connection to the analogue channel in a subsequent post.

We also see a slight uncertainity at capturing the digital channels, as the transition of D3 occurs 2ns later compared to D0 and D1. Interestingly, we still get a valid bus decoding (0C) for that misaligned portion of the signal at the bottom of the screen.

In general, we cannot expect a timing accuracy of better than +/- 2ns at a digital sample rate of 500MSa/s.


Now let’s have a look at a huge amount of data. At a timebase of 2ms/div, digital and analogue channels both run at 500MSa/s with 14Mpts of memory and the picture we get is a little boring (Digital_Signals_2ms)




If we zoom in 1000x by lowering the timebase to 2µs/div (in stope mode), we get a good overview of what’s actually going on here (Digital_Signals_2ms_2us)




Bug: The bus decoding at the bottom of the screen is a fair bit misaligned though. The displayed values should be aligned with the gaps in the D0 burst signal, but the first one (7d) is already about 1µs late, and it gets progressively worse and ends up with a lag of some 3µs for the last value (49).


If we zoom in even further, 10000x at a timebase of 200ns/div, bus decoding gets well aligned again (Digital_Signals_2ms_200ns)




With a zoom factor of 200000 at 10ns/div, we find a serious mismatch between analogue and digital channels (Digital_Signals_2ms_10ns_Probe_D0)



Now D0 is about 44ns late with regard to Ch. 4, which doesn’t appear too bad at first, considering the huge zoom factor, but then again I still wouldn’t expect more than 10ns, as we saw a skew of 6ns earlier, where Ch. 4 was sampled at 2GSa/s and it now is at 500MSa/s, which might introduce another 2ns of uncertainty. Even more surprising, the skew has changed sign, i.e. the digital channels now lag the analogue one.


Finally let’s have a look at Zoom mode (Digital_Signals_2ms_Zoom_200ns_D40us)



While it certainly works for the signal traces, it does not for the digital bus decoding, which shows just nonsense. Bug alert!


Conclusion

Digital channels are basically working just fine, apart from the two bugs regarding initial channel position and slightly random channel selection mentioned at the start of this review.

Digital bus decoding is fine in many regards, especially its response to narrow pulses, but still has some alignment issues as shown in this review. A big issue is the zoom mode, where it’s just displaying nonsense.

The correlation between digital and analogue seems fine too, except when zooming into a long waveform, where the error can get surprisingly high at up to 50ns (from +6 to -44ns).

Performa01:
MSO – Digital Channels Pattern Trigger

Now that we’ve seen digital channels basically working, we would like to know if we can trigger on a digital word by means of the pattern trigger. In particular, I wanted to know if the trigger reliably captures narrow pulses on the digital channels.

The setup is pretty much the same as in my previous post, but as triggering on narrow pulses is a major topic here, we want to examine these pulses a little closer and also repeat the channel skew test without the analogue probe.

I’ve now connected Ch. 4 to the pulse generator directly via a coaxial cable and activated the 50 ohms termination on the scope input. I’ve used a BNC T-adapter at the generator output to tap off another signal for the logic probe and fed it there over a coaxial cable of equal length. Of course this arrangement introduces a considerable mismatch and we will see a 2nd (reflected) pulse about 10ns after the initial one, which is double the time the pulse travels through 1 metre of coaxial cable with a velocity factor of about 0.66 (1m forward, then 1m return) and is because the end of the cable connected to the digital probe isn’t properly terminated. This reflected pulse is about 30% the amplitude of the initial one, so the return loss is still high enough to make reasonable measurements.

First we look at the pulse delay from digital to analogue (Digital_Trigger_Delay)



As can be seen, the analogue channel is still late, but it’s only by 1~4 nanoseconds, which is within the range of expectations for a 500MSa/s LA and a casual setup like this. In particular, it should be way accurate enough for practical tasks, where we have to correlate analogue with digital signals.

This picture also shows the pulse width to be slightly under 4ns at the threshold level of 2.5V that I’ve set for the digital channels as well as for the analogue trigger.


Now for the actual triggering. The pattern trigger setup includes analogue and digital channels at the same time, which is exactly what we want. For this test, I leave the analogue channels alone and just use the simplest possible digital trigger word for a start (Digital_Trigger_Setup)



The trigger condition is very nicely displayed on the right info bar with don’t cares for all channels except D7, which is set to high.

It can be seen that the trigger shows some unexpected 20ns lag, but other than that it works reliably.

Now let’s try a full qualified trigger word HHHHHHLL and see what we get (Digital_Trigger_11111100_50ns)



Well, the result is similar to before, but now the trigger only fires when D0 and D1 are low and all others, including D7, which is connected to the narrow pulse, are high. The 20ns lag is still there.


Now let’s try that with a huge amount of data again at 2ms/div (Digital_Trigger_11111100_2ms)




As there is nothing much to see, we immediately zoom into the waveform 2000 times by lowering the timebase to 1µs/div (Digital_Trigger_11111100_2ms_1us)



At this timebase setting, triggering appears to be a bit early, but still accurate enough. The bus decoding only works occasionally and appears a bit misaligned, just as we’ve seen it before.


If we zoom in even further at 200ns/div, we can see the trigger is indeed almost 30ns early for a change. So there generally seems to be a uncertainty of that magnitude, which I don’t have an explanation for. At least the trigger condition is met correctly (Digital_Trigger_11111100_2ms_200ns)




Conclusion

Triggering on the digital channels works almost as expected, but I cannot think of any real reason why there has to be that rather high uncertainty of at least +/- 30ns, that I’ve observed in the test.

Mark_O:

--- Quote from: Performa01 on January 04, 2016, 02:09:43 pm ---MSO – Digital Channels

This is a short review of the digital channels that make for the SDS2000 MSO functionality...
--- End quote ---

Nicely done coverage of the MSO section.


--- Quote ---As can be seen, there is a delay of precisely 6ns from digital channel D0 to analogue channel 4, so the digital channels have less trigger delay. But when talking about delay times of a few nanoseconds, it’s quite obvious that the digital and analogue probes cannot be exactly the same and I will repeat this test with a direct coaxial connection to the analogue channel in a subsequent post.
--- End quote ---

One thing that may help there is if the analog channel menu has a Deskew Setting on Page 2 (as the 1000X does).  That could be used to bring the analog and digital channels back into alignment (at least initially).  Though it would do nothing to rectify the 50 ns shift in that relationship which you observed later.

One thing to keep in mind is that as clean and well-defined as the digital traces look, they are still based on a user-set threshold-level.  And that threshold is adjustable.  While your digital generator is "fast enough" in the context it's being used, your scope traces indicated an ~18ns fall-time (and presumably similar rise-times).  That throws a fair amount of uncertainty into the process, which significantly exceeds the 2ns you (correctly) attributed to sampling resolution.

In addition to that, the digital channels will have a certain amount of hysteresis built-in (if they're any good), which will contribute to the uncertainty.  On a rising-edge the digital state will be delayed, as will the state-transition on a falling edge.  They generally balance out fairly well (assuming similar rise & fall rates), so the pulse-width itself isn't impacted too badly, but the pulse position will definitely be affected.

NB:  But just by adjusting your digital threshold level, you should be able to watch the skew between the A and D channels shift.

Performa01:
Trigger puzzle

In preparation of another test I stumbled across some funny phenomenon with the trigger system.

Have a look at the screenshot (Trigger_Puzzle_10ns)



Yeah, nothing special – just a pair of narrow pulses spaced some 10ns apart – and the SDS2000 shows a rock stable triggering here, no worries whatsoever. I use rising edge trigger without any specialities and the trigger level is somewhere near half the signal amplitude, but that doesn’t matter anyway. The curious thing is that the scope reliably triggers on the 2nd pulse, whereas I’d have thought there should be a bigger chance to trigger on the first one.

Why is it so?

Just out of curiosity I adjusted the pulse spacing and at 24ns I finally got this (Trigger_Puzzle_24ns)



Now we got like a 50% chance to trigger on the first pulse. Still not quite what I’d expected, yet a fair bit closer. And in this case, no amount of trigger holdoff would change the picture either, which is also rather surprising.

Pulse and Interval triggers didn’t work either.

With the minimum holdoff time of 100ns, I had to increase the pulse spacing to 30ns, in order to get a stable triggering again (Trigger_Puzzle_30ns_H100ns)



Without holdoff, the occasional triggering on the 2nd pulse can still be seen as a faint image (Trigger_Puzzle_30ns_HC)




So I’ve finally found a case, where the scope proved unable to trigger on a signal.

To sum it up:
With a pulse spacing > 30ns we can get stable triggering by means of the trigger holdoff.
With a pulse spacing 19 ~ 29ns we can’t get a stable triggering.
With a pulse spacing < 19ns we get stable triggering on the 2nd pulse unexpectedly.

Granted, that’s no big deal, it is just the very special case of a pair of narrow pulses that have a spacing in the range of 20.to 30ns (triggering on the 2nd pulse for a spacing below 20ns is certainly acceptable).

Performa01:

--- Quote from: Mark_O on January 04, 2016, 06:53:18 pm ---One thing that may help there is if the analog channel menu has a Deskew Setting on Page 2 (as the 1000X does).  That could be used to bring the analog and digital channels back into alignment (at least initially).  Though it would do nothing to rectify the 50 ns shift in that relationship which you observed later.

--- End quote ---

I’ve already demonstrated the deskew option to work fine in one of my earlier posts in this thread, and yes, I’ve actually tried it in this situation as well – and it worked a treat.
I still didn’t mention it in my review, as I thought it was ridiculous to try to compensate for a few nanoseconds, when we already have a sampling uncertainty of 2ns for digital and at least 500ps for analogue.



--- Quote ---One thing to keep in mind is that as clean and well-defined as the digital traces look, they are still based on a user-set threshold-level.  And that threshold is adjustable.  While your digital generator is "fast enough" in the context it's being used, your scope traces indicated an ~18ns fall-time (and presumably similar rise-times).  That throws a fair amount of uncertainty into the process, which significantly exceeds the 2ns you (correctly) attributed to sampling resolution.

--- End quote ---

Look closer. The automatic measurement of the fall time is not valid in the screenshot you’re regarding to, as it takes some 10ns for the last 20% of signal amplitude to actually reach the ground level. Actually, it takes less than 5ns to approach the 2.38V trigger level. In later screenshots you can see even the automatic measurements indicating rise and fall times between 8 and 10ns.



--- Quote ---In addition to that, the digital channels will have a certain amount of hysteresis built-in (if they're any good), which will contribute to the uncertainty.  On a rising-edge the digital state will be delayed, as will the state-transition on a falling edge.  They generally balance out fairly well (assuming similar rise & fall rates), so the pulse-width itself isn't impacted too badly, but the pulse position will definitely be affected.

--- End quote ---

That's certainly true and also the reason why I didn't look further into it when I observed a channel skew of just about 2ns in my digital trigger test. By this result I was convinced that initial matching between channels on the time axis is not an issue ;)



--- Quote ---NB:  But just by adjusting your digital threshold level, you should be able to watch the skew between the A and D channels shift.

--- End quote ---

That’s the reason why I explicitly set the digital trigger level to 2.5V and yes, I failed to make the analogue trigger level exactly the same for the first test, but 2.36V should still be close enough, especially considering that the analogue and digital triggers would most likely be very different in their nature.
We know that the analogue trigger is digital, based on the sampled data. This cannot be the case for the digital channels, as there is just one bit per channel, so it has to be analogue…

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod