| General > General Technical Chat |
| Does a hobbyist need a Oscilloscope? |
| << < (10/17) > >> |
| nogood:
--- Quote from: david77 on October 12, 2010, 12:27:53 pm ---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. --- End quote --- 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:
--- Quote from: nogood on June 25, 2016, 01:53:47 pm ---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). --- End quote --- 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, compilerThe 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:
--- Quote from: nogood on June 25, 2016, 03:57:48 pm ---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. --- End quote --- If you can't change anything, then you are stuffed! Is there even any point in doing a test? --- Quote ---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). --- End quote --- 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. --- Quote ---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. --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |