Does a hobbyist need a Oscilloscope?

[tggzzz]

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.

I would do it as part of the normal development process; I regard it as the "hello world" of serial interfaces.

Clearly it could also be done with a LA, but I doubt I would bother to get mine out to do it. I would just eyeball the bitstream to see it was plausible.

[onesixright]

Need? Probably not (for hobby).  You need food, a roof and some clothes 

Should? I think yes!  It's a amazing tool, that allows you to look at signals in the time domain, and we talk nano seconds. Fascinating! 

You can measure a lot with your multimeter, but a scope makes clear what happens to a signal. At a certain point that's is what you want.

For looking at serial data ( and be able to decode it) you could also consider something like bus pirate (30$).

[Gary350z]

If you can afford a scope, get one.

It's one of the most amazing, fun, cool, tools you can have.

It will make you happy.

Grab some    and your scope and have fun!

[tggzzz]

For looking at serial data ( and be able to decode it) you could also consider something like bus pirate (30$).

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

[ez24]

Buying a used scope means you know what to look in potentially damaged or second hand scopes, in which case the buyer must have good knowledge of scope usage and performance.

So if the OP knew how to buy a used scope he would know to buy one or not.  I also recommend (as one who did it) not buy an used scope.  Unless the OP has a friend who can look at one and check it out.  The shipping is so high that probably the OP would not want to return it.  In my case the seller refunded my money but I paid the expensive shipping and the scope went into the trash (it was smashed in shipping because of poor packing).  The second analog has bad switches and is waiting for its trip to the dump.

I bought a $60 and a $400 scope and I use the $60 (5 meg) the most because it has a "fun" factor.  I use the $400 one to keep the $60 one honest.

Summary - OP stay away from used scopes

[janoc]

For looking at serial data ( and be able to decode it) you could also consider something like bus pirate (30$).

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

Err no. Buspirate can act as a sorta logic analyzer in a pinch, but you have 4 (or maybe only 3) channels at best and it is slow, because it is the onboard PIC doing all the work. It is not really designed for that role, it is primarily serial protocol testing tool. Any cheap Saelae Logic clone that sells for $10 on eBay will be running circles around a Buspirate when used as a logic analyzer - those have 24MHz sampling rate and 8 channels.

[tggzzz]

For looking at serial data ( and be able to decode it) you could also consider something like bus pirate (30$).

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

Err no. Buspirate can act as a sorta logic analyzer in a pinch, but you have 4 (or maybe only 3) channels at best and it is slow, because it is the onboard PIC doing all the work. It is not really designed for that role, it is primarily serial protocol testing tool. Any cheap Saelae Logic clone that sells for $10 on eBay will be running circles around a Buspirate when used as a logic analyzer - those have 24MHz sampling rate and 8 channels.

I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
Would the capture depth be sufficient?
Would there be any "dead time" between capturing-dumping and restarting the capture?
Would you see the messages as they occurred?
Would you be able to capture and then analyse the sequences of messages off-line?

OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.

[suicidaleggroll]

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

That IS a LA...what are you referring to when you say "LA" if it can't decode a huge batch of data and export it to a file?

I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
With Saleae the data is compressed, so it only takes up space on level transitions, which means sporadic high speed data is no problem.
Would the capture depth be sufficient?
depends on your definition of "enough".  Capturing minutes/hours/days of data at several tens of MHz (or seconds/minutes at several hundred MHz) has always been enough for me
Would there be any "dead time" between capturing-dumping and restarting the capture?
With Saleae, yes, can't speak for others
Would you see the messages as they occurred?
With Saleae, no
Would you be able to capture and then analyse the sequences of messages off-line?
With Saleae, yes
OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.
Only if you're dealing with low speed unidirectional async serial.  Throw a couple of SPI, I2C, or parallel busses in the mix and that method of debugging comes crashing down in a big ball of insufficiency.

[tggzzz]

Provided that can dump all the decoded information to a host computer's file, that is probably better than an LA.

That IS a LA...what are you referring to when you say "LA" if it can't decode a huge batch of data and export it to a file?

There are many devices with many characteristics that have been called an "LA". I don't think it would be profitable to split hairs about what an LA "really" is.

I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
With Saleae the data is compressed, so it only takes up space on level transitions, which means sporadic high speed data is no problem.

Sounds like compression wouldn't work with something involving a CLK, CE, DATA. The very cheap LAs I looked at didn't have a separate CLK input (or it was improperly terminated); instead they relied on asynchronously sampling to infer the DUT's clock.

Would the capture depth be sufficient?
depends on your definition of "enough".  Capturing minutes/hours/days of data at several tens of MHz (or seconds/minutes at several hundred MHz) has always been enough for me
Would there be any "dead time" between capturing-dumping and restarting the capture?
With Saleae, yes, can't speak for others

OK, so stuff can be missed in an operating system; hit-and-miss for logging and post-mortem dumps.

Would you see the messages as they occurred?
With Saleae, no

So, fine for logging and post-mortem dumps (ignoring the downtime), but not good for interactive debugging or monitoring.

Would you be able to capture and then analyse the sequences of messages off-line?
With Saleae, yes
OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.
Only if you're dealing with low speed unidirectional async serial.  Throw a couple of SPI, I2C, or parallel busses in the mix and that method of debugging comes crashing down in a big ball of insufficiency.

All tools and techniques have their limitations. The extent of those limitations depends on the tools and the system being tested.

[janoc]

I haven't used either in that role, since my design and implementation strategies have circumvented any such requirement. The systems I've worked with over the decades have typically had series of messages that arrive occasionally and unpredictably.

How would that work with an asynchronous sampling clock and limited depth memory?
Would the capture depth be sufficient?
Would there be any "dead time" between capturing-dumping and restarting the capture?
Would you see the messages as they occurred?
Would you be able to capture and then analyse the sequences of messages off-line?

OTOH, sniffing characters as they go past and copying them to a computer's console and file is remarkably effective.

I think this is not the thread to argue about what is and isn't an LA. If Buspirate works for your needs (which seem fairly specific and not typical use cases for a logic analyzer, more a serial terminal, btw!), by all means, do keep using it. That's not the point. However, if someone is looking for an LA, Buspirate isn't the best first choice because that function is at best an afterthought in the design of that (otherwise very useful) tool.

I have both a Buspirate, two cheap logic analyzers (a cheap Saleae clone and the OpenBench Logic sniffer) and my scope can do some limited decoding as well, but I would never consider that these tools are somehow interchangeable. Each is good for one thing and sucks big time for another.

[suicidaleggroll]

Sounds like compression wouldn't work with something involving a CLK, CE, DATA.

Why not?

The very cheap LAs I looked at didn't have a separate CLK input (or it was improperly terminated); instead they relied on asynchronously sampling to infer the DUT's clock.

Yes it's asynchronous, but the sample rate is fast (Saleae is 500 MHz) and it only takes up space when the signal changes states, so does it really matter?

OK, so stuff can be missed in an operating system; hit-and-miss for logging and post-mortem dumps.

If you shut off logging, then yes you'll miss whatever happens while logging is shut off.  I wouldn't really call that "hit-and-miss".  If you tell it to grab 5 hours of data, it'll grab 5 hours of data gap-free, provided your system has enough memory to handle it given the activity level of the signals you're monitoring.  Something like 115k async serial could be recorded for days, a 50 MHz SPI running full tilt is another story.

All tools and techniques have their limitations. The extent of those limitations depends on the tools and the system being tested.

Sure, but dumping out everything you want/need to see over a slow uart plugged into a PC running minicom is incredibly limiting.  It's useful if your requirements fit within those ridiculously restrictive limits, but if not, that's where a LA comes in.

All I'm saying is that for somebody getting into microcontrollers, while ideally he would have both a LA and a scope, if it had to be one or the other he'd get far more use out of a decent LA than a scope IMO. Most of my work is with digital circuits, and while I have a scope, the LA gets far more use.  I can't even remember the last time I turned on the scope, it's been at least a year.

[tggzzz]

I think this is not the thread to argue about what is and isn't an LA.

Just so, as I pointed out in my one reply

If Buspirate works for your needs (which seem fairly specific and not typical use cases for a logic analyzer, more a serial terminal, btw!), by all means, do keep using it.

Well, I wasn't the one to raise the serial interfaces point. I don't agree that my points are limited to serial terminals; they are applicable to all comms where there is a series of bits/bytes/messages going in one or more directions.

There are too many counter-claims running around, with people claiming tool X is best/required/poor/unnecessary for serial comms. There's some truth in many statements, but too often the balances and caveats are omitted - which makes it seem as if the matter is cut-and-dried.

That's not the point. However, if someone is looking for an LA, Buspirate isn't the best first choice because that function is at best an afterthought in the design of that (otherwise very useful) tool.

I have both a Buspirate, two cheap logic analyzers (a cheap Saleae clone and the OpenBench Logic sniffer) and my scope can do some limited decoding as well, but I would never consider that these tools are somehow interchangeable. Each is good for one thing and sucks big time for another.

And that's the balance that is often missing.

An engineer will find a way to use whatever is available. Doing more with less is elegant.

[tggzzz]

Sounds like compression wouldn't work with something involving a CLK, CE, DATA.

Why not?

How much can you compress the CLK?

The very cheap LAs I looked at didn't have a separate CLK input (or it was improperly terminated); instead they relied on asynchronously sampling to infer the DUT's clock.

Yes it's asynchronous, but the sample rate is fast (Saleae is 500 MHz) and it only takes up space when the signal changes states, so does it really matter?

Yes, if it is a 10MHz clock and one message every millisecond; that's 10000 transitions per message

OK, so stuff can be missed in an operating system; hit-and-miss for logging and post-mortem dumps.

If you shut off logging, then yes you'll miss whatever happens while logging is shut off.  I wouldn't really call that "hit-and-miss". 

If it is capturing when a message arrives, that's a "hit". If it is dumping, the message will be "missed"!

If you tell it to grab 5 hours of data, it'll grab 5 hours of data gap-free, provided your system has enough memory to handle it given the activity level of the signals you're monitoring.  Something like 115k async serial could be recorded for days, a 50 MHz SPI running full tilt is another story.

Thank you for making my point!

All I'm saying is that for somebody getting into microcontrollers, while ideally he would have both a LA and a scope, if it had to be one or the other he'd get far more use out of a decent LA than a scope IMO. Most of my work is with digital circuits, and while I have a scope, the LA gets far more use.  I can't even remember the last time I turned on the scope, it's been at least a year.

LAs can't verify the signal integrity, which is a necessary pre-requisite before it is worth connecting an LA! I often see signal integrity causing problems in other people's circuits, because they haven't understood that there's no such thing as a digital signal.

A scope can, OTOH, do some of the things that an LA can - and with some understanding and imagination, is often sufficient.

Anyway, off to the Hackspace, where last week I came across exactly such a signal integrity problen: turning on a heater caused a USB link to lose sync. Good luck debugging that with an LA!

[System Error Message]

a DMM just doesnt compare to a scope, the reason is you can get a decent DSO and configure it as you like when measuring, my scope has an app that shows the measurement value just like a DMM. In my opinion a decent DSO should be the first thing on your list other than a decent soldering set. You still do need a DMM as the portable DSOs cost like gold per weight just for one as good as a bench DSO.

So whether you get a bench DSO or a DSO that relies on having a PC connected they can both be useful. If a DSO relies on a PC than all that matters is the bandwidth between device and PC and PC's hardware resources.

You will learn a lot from a decent DSO, get one you wont be disappointed as it is also a toy. Technically you could make game apps for DSOs but do EEEs play video games?

Some will say you can use peak detects to get accurate measurements but DSOs have them too.

[nctnico]

3 pages on this simple topic? 
Ofcourse a hobbyist needs a scope! Stupid question because a scope is the only instrument which lets you look at the shape of a signal and electronics is all about shapes of signals

[System Error Message]

3 pages on this simple topic? 
Ofcourse a hobbyist needs a scope! Stupid question because a scope is the only instrument which lets you look at the shape of a signal and electronics is all about shapes of signals

Thats what i've been trying to say, its not just about seeing waves as you can learn a lot from it. Its a must if you want to learn/do electronics.

[imidis]

Tools, toys, whats the difference? 

[suicidaleggroll]

How much can you compress the CLK?

A lot. You can compress it to what a synchronous sampling LA would do, instead of what you would get if you just sampled it at 500 MHz without any compression.

Yes, if it is a 10MHz clock and one message every millisecond; that's 10000 transitions per message

Uh huh, and that's different than synchronous sampling how?  Also the vast majority of clocked serial lines only run the clock when they're transferring data, so the point is moot.

If it is capturing when a message arrives, that's a "hit". If it is dumping, the message will be "missed"!

If you want to see a message, you sample.  You only stop and review when the event is done and you want to analyze the results.

Thank you for making my point!

What is your point?

LAs can't verify the signal integrity, which is a necessary pre-requisite before it is worth connecting an LA!

It's only a pre-requisite if there's a signal integrity problem.

A scope can, OTOH, do some of the things that an LA can - and with some understanding and imagination, is often sufficient.

Scopes suck ass at logic analysis.  I wouldn't wish it on my worst enemy.  And yes, a LA is useless for scope duties as well.  They're different tools for different jobs.  The question is which would be more useful for somebody connecting up COTS boards and writing firmware to communicate between them, and a LA is the clear choice IMO.  He will probably run into a signal integrity problem eventually, and a scope would be the right choice to debug it, but the other 99.9% of the time it's going to be a firmware problem and a scope will do next to nothing to help diagnose it.

[nctnico]

Let's just say that a scope with decoding goes a long way and an MSO can solve 99.9% of the logic analysis problems. What an MSO is very good at is displaying digital signals in realtime which can be a major advantage over a logic analyser.

[Howardlong]

Let's just say that a scope with decoding goes a long way and an MSO can solve 99.9% of the logic analysis problems. What an MSO is very good at is displaying digital signals in realtime which can be a major advantage over a logic analyser.

I'd agree with that, in fact a scope, MSO or DSO (or even a CRO if you are very patient) can help you solve 99.9%+ of logic analysis problems given enough time and effort. The same is not true the other way around, i.e., and LA cannot solve signal integrity problems.

If I had to choose either a scope or an LA, I'd always take the scope. While that's a facile statement for me to make nowadays, barely 10+ years ago, it was frequently the way it was.

This takes me back to the days of decoding software on microprocessor based systems with exposed parallel busses in the 70s, using a scope together with a piece of paper and a pen, forcing a reasonably tight software loop to reset and reproduce, find a trigger (never did I use holdoff so much!), decoding one string of bits at a time to figure out software bugs, which frequently, but not always, were causing a stack overflow.

Debugging with a scope compared to an LA is frequently a different workflow. Perhaps an analogy is the difference between using an in circuit debugger and printfs in your code to debug, both have value and some prefer one to the other, or use both. I hardly ever use a dedicated LA anymore but for some years, until fairly recently, I did so extensively. Nowadays I much prefer an MSO. Others have different opinions and workflows, but that's as much a personal choice as it is technical reasons (almost every project I do is real time mixed signal).

One of the joys of analytical skills is that there are almost always more than one way to skin the same cat. Or, to out another way, ask three engineers the same question and you'll get a dozen different answers, all of which may well have merit.

[rstofer]

3 pages on this simple topic? 
Ofcourse a hobbyist needs a scope! Stupid question because a scope is the only instrument which lets you look at the shape of a signal and electronics is all about shapes of signals

Thats what i've been trying to say, its not just about seeing waves as you can learn a lot from it. Its a must if you want to learn/do electronics.

This week my grandson is studying exponential equations. Like v(t) = v * (1-e^-t/T)  That certainly looks familiar!  I  put a resistor and capacitor on a breadboard, fed in a square wave about 6T wide from my Digilent Analog Discovery and displayed the result on a DS1054Z.  A neat way to reinforce the lesson plan.

Yes, hobbyists need a scope.  In my view, sooner rather than later.  Add in some kind of signal generator and they can really get a handle on low pass and high pass filters (as well as the more complex filters).  It's all too easy to just read about them and assume they are understood.  It's totally different when you can plot the results of amplitude and phase.  Yes, I know about LTSpice but the simulator isn't the hardware.  Amplifiers, oscillators, tuned circuits and that's before we even get to digital.  For the truly insane, displaying the output of an analog computer solving some 2d order differential equation.

[Galenbo]

Why would anyone that even doesn't invest 200->500 euro in electronics be called a hobbyist?
That's the price of a cheap bike, the price of a smartphone, the price of nintendo/xbox/..., a fishing outfit/set or a surfboard costs more.
In my area, a healthy 16-years old can make that amount of money in 2->4 saturdays of work.

[nctnico]

Nowadays the problem is that people spend a lot of their money on games, mobiles phones and so on that they don't have money to spend on their hobbies. Sad but true.

[Howardlong]

Nowadays the problem is that people spend a lot of their money on games, mobiles phones and so on that they don't have money to spend on their hobbies. Sad but true.

That's the difference between consumers and creators. I'm not sure if there's been a fundamental change that much in the last forty to fifty years, just that instead of the internet, phones and gaming everyone watched the TV.

Now consumers still have the TV on, they're just playing a game over the internet on their phone at the same time ;-)

[onesixright]

I think no. You need to eat, you need water. That fundamental.

But i think hobbyist wants a scope, if he/she wants to learn / understand!

To be a able to see (and understand) the invisible, electricity (signals), you want one (or two...) ;-)

And as someone wrote here, if a hobby doesn't cost money find another hobby