Old analogue scopes beat new digital scopes, for bit-bashed digital outputs

[tggzzz]

That statement should provoke the immune response

The standard statement seen all too often on this forum is that an entry-level Rigol scope is better than an old analogue scope. But is that really true for a common basic use-case: a beginner looking at bit-bashed outputs from a microprocessor?

Test setup:

• a low-end DevKit for a modern microprocessor[1], cost £12 from Digikey or Farnell
• a 1.5GHz Z0 probe connected across one processor I/O pin; that is sufficiently good that it won't affect the measurements
• bit-bashed single bit output in software
• Rigol DS1052E: borrowed, cost £275
• Tektronix 2465 scope: cost £84 and working, but I prophylactically replaced the mains X and Y filter capacitors
  

The first point to note is that the 80:20 transition times of the output is 1ns (90:10 is 1.8ns). Using the BW=0.35/tr rule-of-thumb, that implies a 350MHz scope is required to measure the risetime. Hence a 50MHz scope is completely inadequate when checking signal integrity of a modern microprocessor's outputs. There is absolutely no doubt about that, and no surprises either.

But if you (falsely) regard that as “esoteric”, what about bit-bashed outputs using only the hardware inside the processor? It will be seen that low-end digitising scopes can be inadequate and/or misleading compared with cheaper old analogue scopes.

Before replying, please note my repeated statements elsewhere in the forum: choose the right tool for the job. Occasionally a digitising scope is necessary, occasionally an old analogue scope is necessary, frequently either are sufficient.

And yes, I do know the reasons for the displays shown, and (where possible) which sequence of 5 buttons to press to get the expected traces. But would a beginner know? If not, what would their reaction be?

[1] for the curious, that low end XMOS microprocessor and DevKit can drive at least 4 I/O ports as shown in the tests, with guaranteed timings down to 4ns resolution, while simultaneously communicating with a host PC over a USB link. Not bad, and IMNSHO makes Arduino-class machines look anaemic.

[tggzzz]

In this test the program sits in a tight loop outputting a constant pattern (0x005555ff) using an I/O port's SERDES output running as fast as possible.

While the old Tek 2465 displays a sensible waveform, the new Rigol is clearly struggling; it looks like the logic signals are invalid.

I'm not going to explain the details of the code, other than to note that the "outPort <:0x005555ff" outputs the pattern after any previous output has completed. FFI see the introduction to xC .

Code: [Select]

clock clk0 = XS1_CLKBLK_2;
buffered out port:32 outPort = XS1_PORT_1C;
void processes() {
    configure_clock_rate(clk0, 250, 1);
    configure_out_port(outPort, clk0, 1);
    start_clock(clk0);
    while (1) {
        outPort <:0x005555ff;
    }
}

[tggzzz]

This is a simple 10kHz waveform output.

The old analogue scope display is clear and simple - and correct.

But the (single shot) digitising scope display is woefully incorrect. When not in single shot mode, the trace twinkles like a demented Christmas decoration!

(EDIT added for clarification. That is a very common waveform in hard realtime systems, when you are blipping a bit to see how fast/slow a loop is occurring, or  the latency between two events, typically a stimulus and a response)

Code: [Select]

clock clk0 = XS1_CLKBLK_2;
out port outPort = XS1_PORT_1C;
void processes() {
    timer tmr;
    uint32_t t;
    configure_clock_rate(clk0, 250, 1);
    configure_out_port(outPort, clk0, 1);
    start_clock(clk0);
    while (1) {
        outPort <: 1;
        outPort <: 1;
        outPort <: 1;
        outPort <: 1;
        outPort <: 0;
        tmr :> t;
        t = t + 10000; // 10ns clock cycles
        select {
            case tmr when timerafter(t) :> void:
                    // wait for precisely 10000 clock cycles
                    break;
        }
    }
}


[P90]

coming soon to a theater near you...

[ataradov]

So if all you do is observe repeating signals, then sure go ans stare at your analogue scope. How about outputting incrementing counter in one of the digits and meaningfully observing that? We are talking about digital signals after all.

Also, does your Rigol has 20 MHz BW limit enabled by any chance?

[tggzzz]

So if all you do is observe repeating signals, then sure go ans stare at your analogue scope. How about outputting incrementing counter in one of the digits and meaningfully observing that? We are talking about digital signals after all.

Traditionally, and especially for PRBS sequences, that is done with an eye diagram, for both analogue and high-end digitising scopes. Eye diagrams with low-end digitising scopes can, depending on the digitising scope, be another source of bafflement. I may get around to showing an example of that (in an Agilent scope) scope next week. I might even throw together a PRBS sequence tomorrow, if Real Life doesn't intervene.

Beyond that, if you know you are observing valid digital signals, then it is usually more appropriate to examine them with digital instruments such as a logic analyser or printf statements.

Please look at the paragraph in the first post starting "Before replying".

Also, does your Rigol has 20 MHz BW limit enabled by any chance?

No.

[xrunner]

The standard statement seen all too often on this forum is that an entry-level Rigol scope is better than an old analogue scope. But is that really true for a common basic use-case: a beginner looking at bit-bashed outputs from a microprocessor?

...

Indeed, the statement we've all read around here "an entry-level Rigol scope is better than an old analogue scope" is too simplistic, as you've very clearly demonstrated. The hobby is clearly too varied and complex for people to utter such a statement. But that being said, I doubt many new young hobbyists would go for the old analog scope even if you tried to convince them with your data, as the bling of colors, screen shots, USB ports, and LCD displays would be too attractive. But there's always hope a few would listen. 

[ataradov]

Traditionally

Traditionally it is done that way because of crappy outdated equipment. With modern equipment you can capture a lot of real-time data, and do all sorts of analysis on it.

But yeah, I'm not going to waste much more of my time on this.

[tggzzz]

Traditionally

Traditionally it is done that way because of crappy outdated equipment. With modern equipment you can capture a lot of real-time data, and do all sorts of analysis on it.

But yeah, I'm not going to waste much more of my time on this.

Don't ignore the cost implications of your statement. For the past 40 years the rule of thumb has been that the scope you want and can reasonably expect to have costs about a year's salary.

[ataradov]

Don't ignore the cost implications of your statement. For the past 40 years the rule of thumb has been that the scope you want and can reasonably expect to have costs about a year's salary.

When debugging digital signals, I can reasonably live with bandwidth limitations. In general, just get the best scope you can, and factor its limitations into observed results.

I routinely use advanced triggering modes, not available on analogue scopes. I have no doubts that there are techniques to works around that as well, but I'd rather use equipment that directly lets me do what I want to do.

[KE5FX]

Low-grade DSO with (deliberately) incorrect operating procedure beaten by older high-performance analog model that is somewhat harder to misconfigure.     Ric Romero has film at 11!

[tautech]

Blah, blah, blah.   

Any muggins that can read can see the limitations of their scope AND the specified transition times of devices there are trying to measure.
Bashing blindly into measurements without these simple facts being observed and how they might confuse the user is demonstrated nearly everyday on this forum.

Old news...........over and out.

[snoopy]

In this test the program sits in a tight loop outputting a constant pattern (0x005555ff) using an I/O port's SERDES output running as fast as possible.

While the old Tek 2465 displays a sensible waveform, the new Rigol is clearly struggling; it looks like the logic signals are invalid.

I'm not going to explain the details of the code, other than to note that the "outPort <:0x005555ff" outputs the pattern after any previous output has completed. FFI see the introduction to xC .

Code: [Select]

clock clk0 = XS1_CLKBLK_2;
buffered out port:32 outPort = XS1_PORT_1C;
void processes() {
    configure_clock_rate(clk0, 250, 1);
    configure_out_port(outPort, clk0, 1);
    start_clock(clk0);
    while (1) {
        outPort <:0x005555ff;
    }
}

Why is the Rigol scope stopped when the Analog scope can't be stopped ? Try running the Rigol scope with repetitive triggering.

Also this Rigol scope is fairly old with shallow record depth and no Peak detect. Try a later scope such as the 1054Z etc.

You should compare apples with apples !! Also for digital signals you should preferably use linear interpolation rather than sinX/X interpolation.

[nidlaX]

Also, who the fuck pays 275 pounds for a 1052E?? 

[P90]

Also, who the fuck pays 275 pounds for a 1052E?? 

obviously someone in the UK...

LOL

[3db]

@tggzzz
I loved your description   " the trace twinkles like a demented Christmas decoration!"   

3DB 

[mtdoc]

Let's see how many "immune responses" are triggered and replies made without reading the qualifications stated in the OP. 

[Electro Detective]

Megahertz considerations aside for a nanosecond,

can the audio frequency community be guaranteed accurate, precise, audiophool transparency(?) with cheap DSOs from 6hz up to 30khz?  (100khz would be nicer, lol)

Or must they still rely on analogue scopes to check/view their hi-fi, recording gear and synthesizer performance etc

i.e. can they TRUST that the DSO is truly WYSIWYG from 6hz up to 30khz (this includes pulse, square, triangle, weird, not just simple sine waves) without resorting to buying (or keeping) an old school CRO to get the job done PROPERLY?

[ataradov]

Audiophools don't need any measurements, they can hear stuff. Because when you measure, you get objective numbers, and that just kills the buzz from paying $1000 for a power cable

[Electro Detective]

Audiophools don't need any measurements, they can hear stuff. Because when you measure, you get objective numbers, and that just kills the buzz from paying $1000 for a power cable

Good point, my comment above should have included DSO performance powered WITH $1000 IEC power cable 

Solid gold RCA to BNC adapters freshly dipped in DEOXIT,

and let's not forget the oxygen free audio cables in vacuum tight blister packaging, for one shot use only,
otherwise the calibrated performance will degrade with time,
due to the aged audio electron cadavers blocking the narrow frequency response time domain sonic corridor.

Did I miss anything?   

[rstofer]

Comparing a 50 MHz Rigol against a 300 MHz Tektronix doesn't prove a lot.  Of course the Tek has more bandwidth.

I didn't toss my 350 MHz Tek 485 just because I bought the 100 MHz Rigol DS1054X.  Different tools for different jobs.

I see no point in comparing the scopes.  And, yes, I can get a 350 MHz 485 for a couple of hundred dollars.  But it still won't decode SPI or provide measurements or do single shot or FFT or any of the other things a modern DSO can do.  It does have the bandwidth advantage.

Pretty meaningless comparison...

[Paul Moir]

I disagree completely, and I'll give you an example of why.  Just a few days ago, I was unexpectedly debugging a 16 bit, bit banged SPI transfer.  Since my DSO is in the mail (or possibly hasn't been manufactured yet) I had to use my analog CRO, with the intensity set way up, the lights turned out and a bunch of shots with my cell phone camera hoping for a lucky strike. 
If you look at the trace, you'll see the upper is the SCLK and the bottom is the data.  Due to the bit banging, it hangs a bit between bytes.  However the data is completely wrong:  the first few bits should be 0.
After too much time I found the problem.  My 3 almost 4 year old nephew had previously pressed practically every button on the 'scope.  While I had reset most, I neglected the 2nd channel invert button.  Therefore any DSO is superior to an old analog CRO because the invert channel 2 button doesn't exist.

[ataradov]

with the intensity set way up, the lights turned out and a bunch of shots with my cell phone camera hoping for a lucky strike. 

That's how shamans traditionally did it

[Fungus]

Let's see if I've got this straight:

We're looking at a 150MHz signal on a 50MHz DSO and a 300MHz Analog 'scope and concluding that Analog 'scopes are "better"?

 

This is a simple 10kHz waveform output.

No it isn't. It's a program that generates 10,000 very narrow pulses per second.

Code: [Select]

        outPort <: 1;
        outPort <: 1;
        outPort <: 1;
        outPort <: 1;
        outPort <: 0;
Is there a reason for having 4 ones and 99996 zeros?

(I mean apart from when you manually tuned the program to look bad on the 50MHz DSO?)

[tggzzz]

In this test the program sits in a tight loop outputting a constant pattern (0x005555ff) using an I/O port's SERDES output running as fast as possible.

While the old Tek 2465 displays a sensible waveform, the new Rigol is clearly struggling; it looks like the logic signals are invalid.

I'm not going to explain the details of the code, other than to note that the "outPort <:0x005555ff" outputs the pattern after any previous output has completed. FFI see the introduction to xC .

Code: [Select]

clock clk0 = XS1_CLKBLK_2;
buffered out port:32 outPort = XS1_PORT_1C;
void processes() {
    configure_clock_rate(clk0, 250, 1);
    configure_out_port(outPort, clk0, 1);
    start_clock(clk0);
    while (1) {
        outPort <:0x005555ff;
    }
}

Why is the Rigol scope stopped when the Analog scope can't be stopped ? Try running the Rigol scope with repetitive triggering.

If you think about it, that makes no difference.

Also this Rigol scope is fairly old with shallow record depth and no Peak detect. Try a later scope such as the 1054Z etc.

As I said, I know how to get the expected trace: change from "normal" to "peak detect"; IMNSHO peak detect should be the normal setting!

You should compare apples with apples !! Also for digital signals you should preferably use linear interpolation rather than sinX/X interpolation.

If you read the first post, you will see I am doing exactly what many posts on this forum recommend. That is the point.

BTW, sin/x was off - and is irrelevant anyway.