Hackable oscilloscope with 4 channels and >100Mhz bandwidth?

[Gandalf_Sr]

I've tried to used $10,000, 1GHz scopes for decoding, they suck at it - it's like trying to look at the Great Barrier Reef through the botom of a jam jar - far better to be able to a) check that the signals look like you expect them to with the scope and b) move to the logic analyzer.

If you're a masochist, then I suppose the scope might do the job.

[nctnico]

I've tried to used $10,000, 1GHz scopes for decoding, they suck at it - it's like trying to look at the Great Barrier Reef through the botom of a jam jar - far better to be able to a) check that the signals look like you expect them to with the scope and b) move to the logic analyzer.

The trick is to save the data as CSV and analyse it on a PC. When the 'bad' message is found then go back to the scope and look at the signal. Sometimes a problem only occurs once per hour or more. Deep memory is very useful for these kind of cases.

[SWR]

• Analyze EMI suppression in power supply and amplifier circuits, mostly LF-UHF related projects.

IMHO none of the 8 bit scopes are gonna cut it on the low signal levels for EMC pre compliance testing.
You really need a high dynamic range SA like the SSA3021 or similar with a real tracking generator. Build a LISN for the conducted measurements (there's a nice wide band SMD design here on the forum) and a wide band common-mode clamp with a ferrite torroid for radiated measurements. You can also buy a low cost near-field probe set from Deepace to locate radiation sources on the PCB. All of this will be hidden by the noise-floor of the scope, unless you've got a really serious compliance issue.

• Analyze RF components: filter response, attenuation, etc.

If you have the patience all the scopes mentioned here can be used for this (depending on the frequency range). The andvantage of the Instek I mentioned above is that it has the SA input controls that are easy to work with. Another feature is a Bode plot app (FRA) I didn't mention above. Using the built in tracking AWG it will sweep a circuit and give you the Amplitude & Phase plots on screen.

If you're above 200MHz you're out of luck and need a proper SA. I do some work on LoRa (170M, 433M & 868M), GPS and WiFi (2,4G) that none of these lower end scopes will handle. I did need to modify my SA a bit to cover the WiFi range, but that's fairly easy to do if you're ok with that sort of thing.

• Troubleshoot radio equipment: figure out if oscillators are working OK, debug receiver stages, etc.

All the scopes mentioned here can do this, especially if you don't mind fiddeling with the FFT mode.
Having an AWG with AM, FM, FSK and sweep modulation is useful for this as well, but can be bought separately.

• Reverse engineering: I2C/SPI/UART and other buses, memory dumping, rewriting, glitches/side channel attacks.

For this type of work it's a big advantage with deep memory and memory decoding. Screen based decoding becomes frustrating really quickly. A flexible content based trigger and search function with wild cards is also a really nice feature. Scrolling through a 10M sample buffer is paralyzing.

• Debugging small circuits with the usual run of the mill PIC/AVR/MCU: arduino, STM32.
• Assorted experiments, like firmware stuff for hard drives, computer equipment, FPGAs
• Video signals: sync clocks, conversion....

All the scopes mentioned here should be able to do this, but again - it depends on the type of HDD and FPGA signals you need to measure.

[daybyter]

https://hackaday.io/project/4327-stretching-the-limits-of-a-rigol-ds-1102e-scope

I guess the 1054z should show the same performance?

[rsjsouza]

I really appreciate your responses, it's always great to see someone putting in some effort and time. I will just list a few of the case scenarios I will likely be involved with, in my lab:

• Analyze EMI suppression in power supply and amplifier circuits, mostly LF-UHF related projects.
• Analyze RF components: filter response, attenuation, etc.
• Troubleshoot radio equipment: figure out if oscillators are working OK, debug receiver stages, etc.
• Reverse engineering: I2C/SPI/UART and other buses, memory dumping, rewriting, glitches/side channel attacks.
• Debugging small circuits with the usual run of the mill PIC/AVR/MCU: arduino, STM32.
• Assorted experiments, like firmware stuff for hard drives, computer equipment, FPGAs
• Video signals: sync clocks, conversion....

I was initially looking for spending up to 1k EUR, since I have put quite some money into things recently... Considering this, what do you honestly think would suit me best? Siglent or splurge a little and pick the Tektronix? Any decent EU seller that offers discounts? (I'm between jobs now)

Apart from the higher frequency required by the radio equipment, both a Rigol DS1054Z or the Siglent SDS1204 seem enough. If you max your budget the GW Instek GDS2204E starts to become interesting. Another alternative is the Rigol EU clearance bin, which has a DS4014E for €1.2k but probably is net price with no freight. If you go that route, be sure to figure out warranty and accessories.

A Tek MDO3014 would put you well into €2.5k...

[tggzzz]

I've tried to used $10,000, 1GHz scopes for decoding, they suck at it - it's like trying to look at the Great Barrier Reef through the botom of a jam jar - far better to be able to a) check that the signals look like you expect them to with the scope and b) move to the logic analyzer.

If you're a masochist, then I suppose the scope might do the job.

So very very true. Use analogue tools for the analogue domain and digital tools for the digital domain.

Thoughtful use of sprintf() is a very useful tool as well!

[tggzzz]

I've tried to used $10,000, 1GHz scopes for decoding, they suck at it - it's like trying to look at the Great Barrier Reef through the botom of a jam jar - far better to be able to a) check that the signals look like you expect them to with the scope and b) move to the logic analyzer.

The trick is to save the data as CSV and analyse it on a PC. When the 'bad' message is found then go back to the scope and look at the signal. Sometimes a problem only occurs once per hour or more. Deep memory is very useful for these kind of cases.

The better technique is to use the right tool for the job in the first place: a logic analyser or sprintf(). Both of those are very good at selecting only the interesting information, and discarding the rest.

[tggzzz]

I really appreciate your responses, it's always great to see someone putting in some effort and time. I will just list a few of the case scenarios I will likely be involved with, in my lab:

• Analyze EMI suppression in power supply and amplifier circuits, mostly LF-UHF related projects.
• Analyze RF components: filter response, attenuation, etc.
• Troubleshoot radio equipment: figure out if oscillators are working OK, debug receiver stages, etc.
• Reverse engineering: I2C/SPI/UART and other buses, memory dumping, rewriting, glitches/side channel attacks.
• Debugging small circuits with the usual run of the mill PIC/AVR/MCU: arduino, STM32.
• Assorted experiments, like firmware stuff for hard drives, computer equipment, FPGAs
• Video signals: sync clocks, conversion....

EMI: unlikely a scope is much use.
RF components: scope not much good if you are characterising the stopband
Radio equipment: scope not much good for oscillator harmonics, spurs, and phase noise, nor if looking for "rf level" signals (consider 5mVpp/50ohm is -36dBm)
Reverse engineering: logic analyser has width and depth that a scope doesn't, plus decent triggering/filtering
Debugging: analogue tools for analogue problems, digital tools for digital problems
Assorted experiments: assorted tools.
Video: analogue or digital?

[nctnico]

I've tried to used $10,000, 1GHz scopes for decoding, they suck at it - it's like trying to look at the Great Barrier Reef through the botom of a jam jar - far better to be able to a) check that the signals look like you expect them to with the scope and b) move to the logic analyzer.

The trick is to save the data as CSV and analyse it on a PC. When the 'bad' message is found then go back to the scope and look at the signal. Sometimes a problem only occurs once per hour or more. Deep memory is very useful for these kind of cases.

The better technique is to use the right tool for the job in the first place: a logic analyser or sprintf(). Both of those are very good at selecting only the interesting information, and discarding the rest.

As I wrote before: that way you know something is wrong but not exactly what is wrong. IOW: you learn nothing new! A lot of communication related problems are rooted in the analog domain and a problem may not repeat itself often. An oscilloscope with deep memory and good decoding tools really is very useful because it offers an all in one solution.

A couple of years ago I was involved in a project where someone had to interface with a circuit my customer provided. This was a half duplex UART over RS485 interface. After 3 weeks (or so) the engineer at the third party still was unable to get it to work. He followed your advice: look at the signals in the digital domain only. That way he was completely oblivious to the fact he got the RS485 rx/tx switching timing all wrong. I had to come over and connect his scope and on that the problem was immediately visible.

[tggzzz]

I've tried to used $10,000, 1GHz scopes for decoding, they suck at it - it's like trying to look at the Great Barrier Reef through the botom of a jam jar - far better to be able to a) check that the signals look like you expect them to with the scope and b) move to the logic analyzer.

The trick is to save the data as CSV and analyse it on a PC. When the 'bad' message is found then go back to the scope and look at the signal. Sometimes a problem only occurs once per hour or more. Deep memory is very useful for these kind of cases.

The better technique is to use the right tool for the job in the first place: a logic analyser or sprintf(). Both of those are very good at selecting only the interesting information, and discarding the rest.

As I wrote before: that way you know something is wrong but not exactly what is wrong. IOW: you learn nothing new! A lot of communication related problems are in the analog domain and a problem may not repeat itself often.

I'm not entirely sure what use-cases you mean, but it sounds like an infinite-persistence eye diagram is appropriate.

[nctnico]

Any eye diagram won't work well for SPI, I2C, UART, etc. And then you still don't know when & what happened in relation with other signals.

[tggzzz]

Any eye diagram won't work well for SPI, I2C, UART, etc. And then you still don't know when & what happened in relation with other signals.

I'm still not sure of what use-cases you have in mind.

I've used eye diagrams with UARTs perfectly successfully w.r.t. signal integrity - once that is assured, flip to the digital domain.

The analogue/digital cross-correlation can be important, hence mixed signal oscilloscopes - but low-end DSOs aren't MSOs. Personally my generic strategy is to:

• use scope to assure signal integrity
• use LA/sprintf() to discard "noise" and decode messages
• use LA to trigger scope, or vice versa

[Gandalf_Sr]

As I wrote before: that way you know something is wrong but not exactly what is wrong. IOW: you learn nothing new! A lot of communication related problems are rooted in the analog domain and a problem may not repeat itself often. An oscilloscope with deep memory and good decoding tools really is very useful because it offers an all in one solution.

A couple of years ago I was involved in a project where someone had to interface with a circuit my customer provided. This was a half duplex UART over RS485 interface. After 3 weeks (or so) the engineer at the third party still was unable to get it to work. He followed your advice: look at the signals in the digital domain only. That way he was completely oblivious to the fact he got the RS485 rx/tx switching timing all wrong. I had to come over and connect his scope and on that the problem was immediately visible.

I think we may be in violent agreement.  I'm an embedded designer - usually my I2C / SPI doesn't work first time, so I look at it with analogue scope, often with decoding too.  Then I see that the voltage levels are wrong, or that my code is failing to send a restart - I fix this and data is now flowing as expected.  I then switch to the LA to capture the actual data exchange.

[SWR]

I'm not entirely sure what use-cases you mean, but it sounds like an infinite-persistence eye diagram is appropriate.

It can work well if you have stable timing, but if your protocol have random delays between bytes or messages it's not really working well with the eye diagram or mask function.

You get deep memory and good search functions with the low cost digital bus decoders, but like nctnico points out you won't get the full analog picture of what's going on at the physical protocol layer. I just wanted to point out that not all scopes suck totally at serial decoding. If you've got a deep segmented memory with memory based decoding and flexible content based trigger and search functions, it sucks less than screen based decoding without search functions. There are degrees of totality.

[Fungus]

You get deep memory and good search functions with the low cost digital bus decoders, but like nctnico points out you won't get the full analog picture of what's going on at the physical protocol layer.

The logic analyzers cost $6 so there's no reason not to get both. Combine the two.

[tggzzz]

As I wrote before: that way you know something is wrong but not exactly what is wrong. IOW: you learn nothing new! A lot of communication related problems are rooted in the analog domain and a problem may not repeat itself often. An oscilloscope with deep memory and good decoding tools really is very useful because it offers an all in one solution.

A couple of years ago I was involved in a project where someone had to interface with a circuit my customer provided. This was a half duplex UART over RS485 interface. After 3 weeks (or so) the engineer at the third party still was unable to get it to work. He followed your advice: look at the signals in the digital domain only. That way he was completely oblivious to the fact he got the RS485 rx/tx switching timing all wrong. I had to come over and connect his scope and on that the problem was immediately visible.

I think we may be in violent agreement.  I'm an embedded designer - usually my I2C / SPI doesn't work first time, so I look at it with analogue scope, often with decoding too.  Then I see that the voltage levels are wrong, or that my code is failing to send a restart - I fix this and data is now flowing as expected.  I then switch to the LA to capture the actual data exchange.

Yup. Standard operating practice for the past 30 years.

individual technologies change rapidly, but fundamental strategies change very slowly.

[tggzzz]

I'm not entirely sure what use-cases you mean, but it sounds like an infinite-persistence eye diagram is appropriate.

It can work well if you have stable timing, but if your protocol have random delays between bytes or messages it's not really working well with the eye diagram or mask function.

You get deep memory and good search functions with the low cost digital bus decoders, but like nctnico points out you won't get the full analog picture of what's going on at the physical protocol layer. I just wanted to point out that not all scopes suck totally at serial decoding. If you've got a deep segmented memory with memory based decoding and flexible content based trigger and search functions, it sucks less than screen based decoding without search functions. There are degrees of totality.

The "full analog picture of what's going on at the physical protocol layer" is signal integrity. No doubt you have noticed that I have explicitly stated (reply #36) that my first step is to use a scope to ensure signal integrity. There's little point at examining bits until SI is solid! But after that, flipping tothe digital domain is often advantageous.

Something has to cause a receiver to synchronise on the bytes, and in many common cases that is sufficient to trigger a scope for an eye diagram. Obvious example with a UART is the leading edge of the start bit.

[nctnico]

I'm not entirely sure what use-cases you mean, but it sounds like an infinite-persistence eye diagram is appropriate.

It can work well if you have stable timing, but if your protocol have random delays between bytes or messages it's not really working well with the eye diagram or mask function.

You get deep memory and good search functions with the low cost digital bus decoders, but like nctnico points out you won't get the full analog picture of what's going on at the physical protocol layer. I just wanted to point out that not all scopes suck totally at serial decoding. If you've got a deep segmented memory with memory based decoding and flexible content based trigger and search functions, it sucks less than screen based decoding without search functions. There are degrees of totality.

The "full analog picture of what's going on at the physical protocol layer" is signal integrity. No doubt you have noticed that I have explicitly stated (reply #36) that my first step is to use a scope to ensure signal integrity. There's little point at examining bits until SI is solid! But after that, flipping tothe digital domain is often advantageous.

The problem in this reasoning is that it assumes there is no outside influence and the software is 100% bug free. Neither is the case so you can't discard the analog domain. Over the years I have come across several situations where looking at digital domain only confirmed there is a problem but doesn't tell what the problem is. A modern DSO with deep memory and decoding speeds up debugging these kinds of cases significantly.

[tggzzz]

I'm not entirely sure what use-cases you mean, but it sounds like an infinite-persistence eye diagram is appropriate.

It can work well if you have stable timing, but if your protocol have random delays between bytes or messages it's not really working well with the eye diagram or mask function.

You get deep memory and good search functions with the low cost digital bus decoders, but like nctnico points out you won't get the full analog picture of what's going on at the physical protocol layer. I just wanted to point out that not all scopes suck totally at serial decoding. If you've got a deep segmented memory with memory based decoding and flexible content based trigger and search functions, it sucks less than screen based decoding without search functions. There are degrees of totality.

The "full analog picture of what's going on at the physical protocol layer" is signal integrity. No doubt you have noticed that I have explicitly stated (reply #36) that my first step is to use a scope to ensure signal integrity. There's little point at examining bits until SI is solid! But after that, flipping tothe digital domain is often advantageous.

The problem in this reasoning is that it assumes there is no outside influence and the software is 100% bug free.

Nobody has suggested that, and most of my experience is with hardware/software systems where both are buggy!

Neither is the case so you can't discard the analog domain.

That's a strawman argument. I've always stated that if you have an analogue domain problem, use analogue tools.

Over the years I have come across several situations where looking at digital domain only confirmed there is a problem but doesn't tell what the problem is. A modern DSO with deep memory and decoding speeds up debugging these kinds of cases significantly.

I'm sure that's the case with specific DSOs and specific problems. But there are many DSOs and many problems where the tools' limitation make them less than helpful. Examples:

• where you have a, say, 8-bit bus to capture, or when specifying the trigger, or filtering out uninteresting data
• where the trigger is a sequence of states
• where the decoding is so slow that the input is ignored for a substantial proportion of the time
• where the decoding only covers a small proportion of the captured signal, e.g. merely what's on the screen at that time

Naturally a full-featured and correspondingly expensive "professional" DSO is more likely to avoid limitations, but this forum is biassed towards hobbyists with limited money.
 
In contrast, the strategy I outlined is pretty general purpose, provided you have minimal equipment of each type.

[nctnico]

Naturally a full-featured and correspondingly expensive "professional" DSO is more likely to avoid limitations, but this forum is biassed towards hobbyists with limited money.

Now you are just moving goalposts. Not everyone has to make-do. There are lots of people with money (or their boss' money) to buy scopes in the sub $10k range. Starting at around $2k you can buy a decent new scope which has good decoding and analysis features. Also the higher end scopes are available on the used market.

[tggzzz]

Naturally a full-featured and correspondingly expensive "professional" DSO is more likely to avoid limitations, but this forum is biassed towards hobbyists with limited money.

Now you are just moving goalposts. Not everyone has to make-do. There are lots of people with money (or their boss' money) to buy scopes in the sub $10k range. Starting at around $2k you can buy a decent new scope which has good decoding and analysis features. Also the higher end scopes are available on the used market.

You have chosen to comment on a tangential financial point, and to not comment on the substantive technical points. We presume that means you don't disagree with the technical points.

[Gandalf_Sr]

mctnico -

This isn't even a proper argument!

[nctnico]

Naturally a full-featured and correspondingly expensive "professional" DSO is more likely to avoid limitations, but this forum is biassed towards hobbyists with limited money.

Now you are just moving goalposts. Not everyone has to make-do. There are lots of people with money (or their boss' money) to buy scopes in the sub $10k range. Starting at around $2k you can buy a decent new scope which has good decoding and analysis features. Also the higher end scopes are available on the used market.

You have chosen to comment on a tangential financial point, and to not comment on the substantive technical points. We presume that means you don't disagree with the technical points.

Your technical points discussion is circular and now you try to justify your odd reasoning by moving the goalposts. Hint: it is not working.

The OP is asking what kind of amount of money he/she would need to spend to tackle a certain set of problems. Spending more money means getting the job done faster. Spending too much money means getting unnecessary features. Spending too little money could mean ending up with crap which takes all the fun out of building a circuit.

[SWR]

But there are many DSOs and many problems where the tools' limitation make them less than helpful. Examples:

• where you have a, say, 8-bit bus to capture, or when specifying the trigger, or filtering out uninteresting data
• where the trigger is a sequence of states
• where the decoding is so slow that the input is ignored for a substantial proportion of the time
• where the decoding only covers a small proportion of the captured signal, e.g. merely what's on the screen at that time

I fully agree. To maximize usability you need deep segmented memory, quick content triggers with wild cards and a search function with the same capabilities.

Naturally a full-featured and correspondingly expensive "professional" DSO is more likely to avoid limitations, but this forum is biassed towards hobbyists with limited money.

Yes, but the nice thing for us hobbyists is that these features are now becomming available in low cost scopes. The MDO-2204EX costs $1922 at Saelig.com.

If I wanted the same features in the Keysight scopes we use at work it would be more than 4 times that price - and I would still only have 1/10th of sample memory depth. These used to be expensive features, but some of the less known brands are putting some pretty useful bargins on the market compared to the better known brands.

[tggzzz]

But there are many DSOs and many problems where the tools' limitation make them less than helpful. Examples:

• where you have a, say, 8-bit bus to capture, or when specifying the trigger, or filtering out uninteresting data
• where the trigger is a sequence of states
• where the decoding is so slow that the input is ignored for a substantial proportion of the time
• where the decoding only covers a small proportion of the captured signal, e.g. merely what's on the screen at that time

I fully agree. To maximize usability you need deep segmented memory, quick content triggers with wild cards and a search function with the same capabilities.

Naturally a full-featured and correspondingly expensive "professional" DSO is more likely to avoid limitations, but this forum is biassed towards hobbyists with limited money.

Yes, but the nice thing for us hobbyists is that these features are now becomming available in low cost scopes. The MDO-2204EX costs $1922 at Saelig.com.

If I wanted the same features in the Keysight scopes we use at work it would be more than 4 times that price - and I would still only have 1/10th of sample memory depth. These used to be expensive features, but some of the less known brands are putting some pretty useful bargins on the market compared to the better known brands.

Agreed.

IMNSHO, while expensive full-featured equipment can be used, often if you use imagination and skill then the same ends can be achieved with cheap basic equipment. Plus, for non-repetitive tasks the time saved using full-featured equipment has to be balanced against the time taken to acquire and learn how to use such equipment.

Of course, you can't buy skill and imagination off-the-shelf.