Does a hobbyist need a Oscilloscope?

[dendennis]

I have two of the jyetech pocket DSO scopes, with the latest firmware it now does 20Msa/s.
(before it was about 2msa/s but it now incorperates equiv time sampling.)
Now I agree it is a "toy" but a reasonable starter for learning the basics.
[I'd rather let the kids learn scope basics on the pocket DSO than the rigol.]
It only has a 1Mhz bandwidth and is only really useful for signals up to 500Khz.
The built in frequency counter can be used up to 5Mhz so for the money it's ok,
(and the FFT function on it is .... well it's there but not really useful).
Now I'm not endorsing this as a serious scope, but it's a reasonable beginner scope
for learning triggering etc and is a fun (but frustrating due to poor instructions)
project to build.
This is the real reason why I got some for the construction fun.
Daisy chaining both scopes (trigger out to in) I found them quite useable for basic pic work, until I wanted to measure the clock signal  .

Obviously though if you can get a proper bench scope do it, I got the rigol 1052E and do not regret it at all.

now my experience as a hobbyist, I found a few times when a scope would be handy (prompting the "toy scope" purchase)

and soon hit the limitations of them, prompting the purchase of the Rigol, end of the day most hobbyists do not "Need" to own a scope but it's nice to have one, and once you have a proper one you won't do without it.

[bloddybrian]

What do you use an oscilloscope for?

[Brumby]

Observing electrical signals in a graphic format.

[lapm]

Personally i would say you will know when you start to need oscilloscope. When that multimeter just docent cut it anymore when trying to solve mystery of not working correctly in some device you built.

[dannyf]

"Does a hobbyist need a Oscilloscope? "

Some do and some don't.

I have two. The last time I used one of them was about 6 months ago. For analog work, I rely heavily on meters - I have an army of el cheapo dt830 clones. For digital work, debuggers and logic analyzers.

[ebclr]

If you have a computer you can get into the scope world without to much money

check this

https://www.zeitnitz.eu/scope_en

[tggzzz]

"Does a hobbyist need a Oscilloscope? "

Some do and some don't.

I have two. The last time I used one of them was about 6 months ago. For analog work, I rely heavily on meters - I have an army of el cheapo dt830 clones. For digital work, debuggers and logic analyzers.

That's sane; with imagination and understanding you can use very simple tools to do things that aren't advertised in the instrument's manual Personally I'd add switches, LEDs and potentiometers, and printf statements to your "essential" list. I built my first computer (6800 based, inspired by the Altair-8080) with switches, LEDs and a multimeter.

The one area with "digital" circuits where a scope can be essential is "signal integrity". To save repetition, see why in https://www.eevblog.com/forum/testgear/question-about-analog-oscilloscopes-vs-digital-oscilloscopes/msg968290/#msg968290 N.B. that in no way invalidates your approach.

[Galenbo]

Does a hobbyist need a Oscilloscope?...

Depends on what kind of Hobbyist your are. A Cycling hobbyist doesn't need one, but without Oscilloscope you cannot be an Electronics hobbyist.
Plugging in the connectors of an arduino/pic/... and clicking upload only makes you an operator.

[tggzzz]

Does a hobbyist need a Oscilloscope?...

Depends on what kind of Hobbyist your are. A Cycling hobbyist doesn't need one, but without Oscilloscope you cannot be an Electronics hobbyist.

I managed perfectly well without a scope for >10 years, until I was able to use those at university and then work.

Plugging in the connectors of an arduino/pic/... and clicking upload only makes you an operator.

Agreed.

[CatalinaWOW]

Of course you don't need an oscilloscope.  You don't need a DMM either.  You can debug a great many problems and do a lot of projects just using an LED and a resistor.

But an oscilloscope will give you insight into problems you didn't know were there, insight into how your circuits really work, and lead you into deeper understanding of electronics.  The real question is can you afford an oscilloscope, and what projects will you have to forgo to afford it.  If you are happy with those answers, go for it.  (By the way I would get a DMM too.  A basic one that will meet most of your lifetime needs will be a small fraction of the oscilloscope cost).

[daybyter]

https://github.com/pingumacpenguin/STM32-O-Scope/wiki

[suicidaleggroll]

If you're doing digital/MCU work, I think a logic analyzer is far more valuable than a scope.

With a scope: "Yep, it's sending something"
With a LA: "Oh crap, the 57th byte was 0xFA when it should have been 0xFE" *find and fix firmware problem on MCU*

[mcinque]

Definitely yes: you can learn many things using it IMO.
Forget DSO nanos and similar things, their bandwith is ridiculos.

[apis]

All you really need is a barrel to sleep in and some onions to keep the hunger away.

[tggzzz]

If you're doing digital/MCU work, I think a logic analyzer is far more valuable than a scope.

With a scope: "Yep, it's sending something"
With a LA: "Oh crap, the 57th byte was 0xFA when it should have been 0xFE" *find and fix firmware problem on MCU*

With LAs you have to be sure that the LA is interpreting the analogue signal in the same way as the circuit's receiver. Problems can arise with different thresholds, especially with the probe leads, and with setup/hold time variations.

Those problems are worse with modern logic families, and it is notable that nowadays LAs are relatively  little used for professional electronic systems.

[ebclr]

A scope is a must have, but not at early stages, You will improve your knowledge exponentially after the scopes start to be used

[suicidaleggroll]

If you're doing digital/MCU work, I think a logic analyzer is far more valuable than a scope.

With a scope: "Yep, it's sending something"
With a LA: "Oh crap, the 57th byte was 0xFA when it should have been 0xFE" *find and fix firmware problem on MCU*

With LAs you have to be sure that the LA is interpreting the analogue signal in the same way as the circuit's receiver. Problems can arise with different thresholds, especially with the probe leads, and with setup/hold time variations.

Those problems are worse with modern logic families, and it is notable that nowadays LAs are relatively  little used for professional electronic systems.

Scopes are used for investigating analog problems (noise, voltage levels, and other layout or component selection problems), LAs are used for investigating digital problems (communication errors, timing errors, and other firmware issues).  While he can, and likely will eventually have analog problems on a digital circuit, such as the issues you mentioned, incorrectly sized pullup resistors for I2C, etc., for a beginner he is FAR more likely to have digital/firmware/communication problems, and a traditional scope will be next to useless for those.  Ideally he'd have both, but for a beginner getting into MCUs, a LA will be far more useful IMO.

[tggzzz]

If you're doing digital/MCU work, I think a logic analyzer is far more valuable than a scope.

With a scope: "Yep, it's sending something"
With a LA: "Oh crap, the 57th byte was 0xFA when it should have been 0xFE" *find and fix firmware problem on MCU*

With LAs you have to be sure that the LA is interpreting the analogue signal in the same way as the circuit's receiver. Problems can arise with different thresholds, especially with the probe leads, and with setup/hold time variations.

Those problems are worse with modern logic families, and it is notable that nowadays LAs are relatively  little used for professional electronic systems.

Scopes are used for investigating analog problems (noise, voltage levels, and other layout or component selection problems), LAs are used for investigating digital problems (communication errors, timing errors, and other firmware issues).  While he can, and likely will eventually have analog problems on a digital circuit, such as the issues you mentioned, incorrectly sized pullup resistors for I2C, etc., for a beginner he is FAR more likely to have digital/firmware/communication problems, and a traditional scope will be next to useless for those.  Ideally he'd have both, but for a beginner getting into MCUs, a LA will be far more useful IMO.

Your overall approach (1: signal integrity, 2: logic) matches mine, but I've always found it possible (even easy) to debug the kind of "logic" problems you mention with a imagination, a scope plus for(;{} and printf statements.

Whether an LA with MCU will be sufficient depends on what the MCU is being used for and how it is constructed. I think I'll shortly do a "teach in" where I get people to make a logic circuit on a solderless breadboard - with long leads and no decoupling. That'll teach 'em there's no such thing as a digital circuit

Only last night someone came to me with "when I switch the heater on, the USB link loses sync". Clearly switching (he thinks) 0.5A is causing EMI problems. Given there was only 5 minutes and he didn't know whether his PSU output was earthed or floating, we didn't have time to investigate it.

[janoc]

Those problems are worse with modern logic families, and it is notable that nowadays LAs are relatively  little used for professional electronic systems.

All that is true, but then you also have a fancy mixed signal scope that will do that decoding for you, when needed, effectively replacing that LA.

For us mere mortals a LA is a must, because, even though my Rigol has serial decoding, it is fairly basic and pain to use.

[System Error Message]

after getting my scope all i can say is if you are into electronics you definitely want a decent one. Even if you dont use it it will make an awesome interactive toy/decoration.

[nogood]

Dave's with Dave on this one .
I'd rather buy a used analog scope instead of these toys.
Dave gave all the reasons in his drive time rant a while back.

Chances are that as a hobbyist today you are going to do lots of digital circuitry.
And if you need to debug that with no one-shot function on a scope, then that is going to be a huge pain in the ass.
You cant even see if a serial protocol is working correctly (maybe a job for a cheap logic-analyzer but still not for a analog oscilloscope).
Edit: This assumes that your built up hardware even works, because if you messed up somewhere or broke a part a logic analyzer is not necessarily going to cut it.

If you are talking about hobbyists that do audio and maybe rf-stuff then above points are not so valid, but still...

PS: I could track down some weird clock issue on my Atmel STK500 with my Rigol, so that paid for part of the scope itself since the STK500 isn't exactly dirt cheap.
If you can make use of your scope as a hobbyist in that manner, it basically pays for itself.

[tggzzz]

You cant even see if a serial protocol is working correctly (maybe a job for a cheap logic-analyzer but still not for a analog oscilloscope).

Well, I've done many such things in the last few decades. It does require imagination and a disciplined development technique, but that's all.

Depending on what your environment provides, some of these can be omitted:

• verify that your software can change the output on to the relevant pin. Equipment: voltmeter, plus either a debugger or a C main function that sets the voltage. Then repeat with a different value
• verify that your software can output a character to the pin. Equipment: scope, plus C code that loops outputting a single character
• verify that your software can read the input from a relevant pin. Equipment: resistor, plus either a debugger or a C main function that reads and printfs the voltage. Then repeat with a different input value
• verify that your software can input a character from the pin. Equipment: external character generator, plus C code that loops reading and printing a single character
• repeat 2 and 4 ensuring that the software correctly detects error conditions
• connect to any other equipment and use scope to assure signal integrity. Equipment: scope
• write your application, taking care to include asserts printfs or other logging functionality, plus the application coded properly[1] as an FSM that reflects and records important actions based on the comms protocol and what your application does. Equipment: brain, compiler

The last is highly desirable during design and implementation, and more importantly it greatly simplifies the system integration phases. In particular it can be used to demonstrate that your code is working correctly and that the fault is in someone else's code. I've used that to prevent lawyers becoming involved.

[1] i.e. not nested if-then-else nor nested switch statements. See any good book on Design Patterns for examples.

[nogood]

Granted that you can work around such issues, but depending on what you are trying to test you can't always write software for what you are testing.
Then you need another workaround for that and at some point you might want to make life easier.
Your workarounds also only work, if your problem is not some oddball intermittent hardware issue (I admit that this doesn't happen that often, not to me at least).

In the end it all depends on what you are more comfortable with and what you can afford.
Given the analog scope prices I know and the amount of scopes that are thrown away that I don't know off (because they are never given away, if you dont' know somebody who can hook you up) it might be worth just buying something recent, if you can.

At some point I did do research on buying an analog oscilloscope, but didn't find anything worth the effort.
Maybe sometimes they are sold for a reasonable price on forums etc., but even then you might need to do at least a basic adjustment, which might not be so easy.
So in my case it was the easier choice to just buy a (at the time) recent oscilloscope -- with warranty -- and be done with it.

[tggzzz]

Granted that you can work around such issues, but depending on what you are trying to test you can't always write software for what you are testing.

If you can't change anything, then you are stuffed! Is there even any point in doing a test?

Your workarounds also only work, if your problem is not some oddball intermittent hardware issue (I admit that this doesn't happen that often, not to me at least).

I disagree, based on long hard-won experience. In particular, they aren't "workarounds", they are good engineering practice.

I always presume that intermittent issues (hardware and/or software) will occur - and structure my applications accordingly. That defensiveness has save me and my companies a lot of aggravation in the past, because we have been able to instantly demonstrate that my application was "doing the right thing" - and theirs wasn't.

If the problem is intermittent and hardware, then signal integrity is the key - and you need a scope to see that. Long persistence helps there, which favours digital scopes, but you have to turn off interpolation.

If the problem is intermittent and a software/protocol problem, then it is probably the consequence of the sequence of a large number of messages, and an LA is probably insufficient to do the filtering and capture. Definitely not the interpretation, of course.

So in my case it was the easier choice to just buy a (at the time) recent oscilloscope -- with warranty -- and be done with it.

Easier choice - yes. Best choice - I can't say. Only choice - no. Best choice in other circumstances - undecidable.

[nogood]

I wrote workaround, but I mainly meant those looping out character writes.
You wouldn't necessarily need to do that if you could just look at the output as it appears in a logic analyzer or a dso.
But yeah, the rest are just things you would do to verify what your code is doing etc.