Years ago I had the opportunity to use a 16-channel Hewlett-Packard Logic Analyzer. I thought this would be a good tool for analyzing the circuit operation and perhaps troubleshooting TTL (Transistor-Transistor-Logic) circuits. This was during the 1970s and TTL was on the way out, while microprocessors were on the way in. I still clung onto diode-relay logic for one more year, but that was definitely obsolete, although a lot of fun to design with. The clicking of relays as they execute their hardwired "logic program" is pleasant to hear. (Life is short. Eat dessert first, and never work at a job where you are not allowed to have a little fun.)
Anyhoo, the H-P Logic Analyzer had these itty bitty test clips that attached nicely to wire-wrap socket pins, but didn't attach very well to much else. And the resulting "rat's nest" of wires between the data pods and the circuit-under-test was confusing and time consuming to attach correctly. I suppose in a production environment things would have been different, but our little shop only did "one off" projects. So it was a real PITA to set up the H-P. 16 channels was usually not enough to monitor all the "test points" I wanted to monitor, so one or more of the itty bitty clips had to be moved to new locations during troubleshooting and test. More PITA.
Eventually, I decided to give up on using the Logic Analyzer and went back to using my trusty dual-channel Tektronix oscilloscope and an H-P logic probe. Sometimes some creativity was required with external circuitry to "qualify" an oscilloscope external trigger input, but in retrospect I think I saved a lot of time and learned a lot about logic timing relationships. Then along came microprocessors. There was just no way our little laboratory could afford to upgrade to a 64-channel logic analyzer, plus I don't think the considerable effort needed to hook up all those address and data bits and clock or data qualifying bits would have been worth it.
So, I found other ways to troubleshoot and analyze microprocessor circuits, using just a single-channel logic probe and the two-channel oscilloscope, plus some judiciously inserted test code. All that was in the final thirty years of the 20th century. Fast forward now to the 21st century and August 2020.
I still "play around" with logic, although I have been retired from my "day job" since December 2014. But my microprocessors are now Arduino Unos or Texas Instruments or Microchip devices. I still use a single-channel H-P logic probe, but my oscilloscope is now a 200 MHz Hantek, solid-state, dual-channel, digital storage oscilloscope (DSO). The same fifty-something year-old troubleshooting paradigm that I used in the 1970s still works, but it is now updated with new hardware technology.
Rigol, Hantek and the other Asian DSO brands are all good (and virtually identical in functionality). It used to be that the manufacturers "crippled" their DSOs by offering bandwidth "tiers" so you had to pay more bux for more bandwidth. This didn't last long because hackers quickly discovered what was going on: same hardware, slightly different software distinguished the tiers of performance. Once the hack, and the "work around," was revealed world-wide, ALL the Asian DSO manufacturers began to offer their widest bandwidth 'scopes for the same price as the lowest bandwidth 'scope! So shop around for the best deal. IIRC I was able to purchase my
Hantek DSO5202P for less than $300, shipping included, but that was five years or so ago. Prices have come down for that model.
The bottom end of the price range for a DSO is less than thirty bux, but that is only for an entry-level 'scope for beginners. Sounds to me like you would quickly outgrow that. There are a lot of inexpensive used 'scopes available on ebay, but as usual:
caveat emptor. Buyer beware. Make sure you can get a full refund if things don't work as advertised. I bought one of my Tektronix 'scopes from an ebay vendor and never regretted it, but your mileage (or kilometers) may vary. My Hantek has less memory than many of its similarly priced competitors, which means I can't use slow sweeps to capture
delayed events with much
earlier trigger events as easily as I could if there was more memory to store the samples. This could be useful, for example, to examine data on a hard-disk track after sensing the beginning of the data stream. The disk rotates comparatively slowly and the track data is continuous, but there could be milliseconds of delay from the trigger event before a few microseconds of serial data that you want to see appears. So, you need a 'scope that can store a few bazillion bits before it displays the few dozen you need to examine.
You might want to take memory length into consideration if there is an opportunity to trade bandwidth for memory at the same basic price. Examining data streams on hard-disk drives is not something one would normally do every day, though, as a hobby exercise. However, there are other instances where "data" you want to display occurs much later than the trigger event preceding the data. You will have to decide whether the increased depth of memory is worth the extra money, for a given bandwidth. Confused?
Read this article.
