Digital Scope, how does memory depth translate to Serial Protocol Bits/Bytes

[imk]

Hello,
Was thinking of getting a digital oscilloscope and one the catches my eye is the Hantek DSO2C10 or DSO2D10.
Now i have never owned or used a digital scope my trusty Tektronix 2236 is enough for most of my retired EE needs.
In my career I have used some Hi End Data Scopes for tracing/sniffing serial protocol but can't really justify that expense or have space for at home.
Hence, as i am doing more and more microcontroller SPi, I2C, UART digital stuff these days I was thinking a modest digital scope would come in really handy.

My question is how does 8M memory depth translate into UART bps bytes storage please?
Also anything better than Hantek DSO2C10 or DSO2D10 for same buck please?
Many thanks imk

[nctnico]

There is no hard specification for that. There are 2 limitations: 1) the number of decoded packets a DSO can store inside the memory for decoded packets 2) the oversampling factor; the number of samples per bit of decoded data needed. The oversampling factor can depend on the memory length as well. A shorter memory needs less time to decode so the oversampling factor can become lower.

In general Hantek is not considered a brand worth buying. Most people buying the cheapest workable scope end up with GW Instek GDS-1054B, Micsig TO1000  / STO1000 series, Rigol DS-1054Z or Siglent SDS1000x+%E-@U$~.  This also depends on local pricing & availability of test equipment in certain countries.

[WattsThat]

Yes, a digital scope will be more useful than analog when working with the usual microprocessors. But, if protocol decoding is the goal, a digital scope isn’t the best solution. In fact, they’re kinda miserable and clunky in that department. That said, my experience is limited to the Rigol MSO5074.

A far cheaper (almost free) and easier to use solution is one of the eBay $5 8 channel usb logic analyzers and the sigrok open source software. All the common protocol decoders are available and storage size only limited by disk space. Capture speed is affected by number of active channels and usb speeds.

[imk]

Hello WattsThat and many thanks for the reply.

Had a look at couple of YT vids and found a number of useful guides.
So now i have the dilemma of which analyzer to buy with respect to number of channels/bandwidth for my buck.
As they seem to range from less that £10 to over a £1000, but a goodly number of device in the £40 to £60 pound range.
One that catches my eye is the  Kingst LA1010 100mhz 16 ch (100mhz by 3ch, 16mhz by 16ch)
Also -50v to +50v input range so this should cater for the odd probe slip hitting the 12v rail .

Any thoughts please on good bang for buck models?

Many thanks again Ian

[ledtester]

I have an original Saleae Logic Analyzer I got about 10+ years ago in and that time span I've used it about half a dozen or so times.

I would start out with the $10 version. Chances are that it will be perfectly adequate for your needs. And if it proves otherwise you've only spent $10 but gained a lot more insight into what you really need.

[nctnico]

Hello WattsThat and many thanks for the reply.

Had a look at couple of YT vids and found a number of useful guides.
So now i have the dilemma of which analyzer to buy with respect to number of channels/bandwidth for my buck.

One of the things a DSO can do is show decoded data in realtime. This is very handy to see data change based on input and thus verify device functionality. One of the problems with Rigol and Siglent DSOs is that they decode only what is on screen which makes it a little bit more clunky to get all the memory to show (can be forced using zoom but you lose a significant part of the screen and the zoom function becomes kind of useless in case you want to force using full memory). That leaves the GW Instek GDS-1054B or MicSig TO1000 series with decent decoding abilities in the low cost bracket.

[wizard69]

I have to agree that scopes can be “clunky” when it comes to this use. 

In the past I’ve used terminal emulators or a PC based port monitor to handle some UART issues.   This was mostly RS232 and involved otherwise operational hardware.   In some cases doing nothing more than taping into a cable.   It isn’t perfect by any measure but if your goal is to understand what is coming out of a port it can work. 

I believe somebody had a program that could monitor two ports on a PC at once to allow you to see transmit and receive.  Sadly I’m not sure if this app exists anymore.  It was free but that was years ago. 

You could likely do the same thing with USB to “other” serial port adapters.  I haven’t don’t that though, just monitored RS232 and RS485.   In the past when every PC had a serial port it was zero cost.   

Given that and the extremely low cost, the logic analyzer approach makes more sense today.   

[imk]

Hello and many thanks to all for your contributions.

I have been having a look at logic analyzers and concur that much better solution for my digital needs than a scope.
But have a question, how important is a trigger?
As it seems the low analyzers don't seem to have a trigger but rely on software and not having used one it is difficult to assess.
Many thanks imk

[nctnico]

Hello and many thanks to all for your contributions.

I have been having a look at logic analyzers and concur that much better solution for my digital needs than a scope.
But have a question, how important is a trigger?
As it seems the low analyzers don't seem to have a trigger but rely on software and not having used one it is difficult to assess.

If you want to debug I2C or SPI then being able to trigger on an address / specific data is very handy. That way you can focus on specific devices / addresses / registers being written. I strongly recommend to use a DSO for protocol decoding. That way you can see both analog and digital domain; most of the problems with busses stem from the analog domain. Contrary to what many think a logic analyser is not a very handy tool for doing protocol decoding because it can't show realtime data (and if it can't trigger it is next to useless). Once the analog domain is working OK then it is much easier to do high level protocol checks in the firmware (like printing received messages / data in a formatted way or doing checks automatically; you will want to have these features for field diagnostics anyway).

[Fungus]

Yep.
1) Use the scope to see if the bus signals are OK
2) Use the 'scopes serial triggers to check if individual data packets are correctly formed - not much memory required for that.
3) Use printf() to debug the protocol.

Logic analyzers are good for hacking unknown protocols. Gigs of memory with mouse and keyboard wins over twisty knobs.