Oscilloscope Bandwidth VS digital signal rates. - Page 1
Forum section: electronics / testgear

author: OleIB
author_rank: Newbie
timestamp: September 23, 2014, 11:00:20 am
content: HiI have searched around and read a lot of the existing posts but need some purchasing advice.I do a lot of hobby uC work and are looking for a scope for troubleshooting digital communication. (UART, I2C, Spi...) at typical uC speeds.What I am having trouble wrapping my head around is what the releation between bit/s and oscilloscope bandwidth.F.ex:- What bandwidth is needed to capture the data of a UART stream at 115200?- What bandwidth is needed to analyze the signal integrity of a UART stream at 115200?

author: AndyC_772
author_rank: Super Contributor
timestamp: September 23, 2014, 11:33:22 am
content: To capture the data, a bandwidth of a few times the data rate is fine. Any scope that isn't actually junk will do just fine.It's quite rare for signal integrity to be a big deal on a UART interface, because edge rates are very slow and there's no clock signal that has to be preserved or kept aligned with the data. If you genuinely do have an SI problem, then in order to see it correctly, you'd need a scope with at least as much bandwidth as the receiving device that's having a problem. That could be anything from 1MHz to 1GHz or more; it's hard to find out, and is unlikely to be relevant anyway.If I were in your position, I'd go for a reliable DSO with built-in serial decoding capability, and not worry too much about bandwidth per se.

author: Fungus
author_rank: Super Contributor
timestamp: September 23, 2014, 12:35:24 pm
content: Any non-junk scope on the market should cope with those signals.You should be looking at feature set, not bandwidth (eg. number of channels, does it have serial decoding...).Quote115200 HzQuoteThe same as the bandwidth of the receiving device.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 23, 2014, 06:22:54 pm
content: And to break that down by medium:UART: synchronized to a rising edge, so signal quality problems (leading edge bounce, extra transitions, poorly defined logic levels) are mostly a non-issue, except at extremely high rates (megs) which are rarely if ever available with this encoding. Moreover, general practice uses a purpose-made line driver (RS-232, 422/485, etc.) which includes limited bandwidth, and slew rate control (e.g. RS-232) or signal quality (e.g., terminated RS-422/485 lines) considerations. If you're following the standard correctly, you shouldn't have to worry about it (but it never hurts to understand and verify what's happening).I2C: bitrate is limited (specified in the standard), and rise time is limited by passive pull-ups. Falling edges can exhibit bounce, which would be a problem for SCL, not so much for SDA. Compliant devices should be reasonably well controlled, but given the popularity, better to check and make sure with the real thing.SPI (and other synchronous methods): usually available for bitrates up to 20M, perhaps more (generally similar approaches, like LVDS serdes blocks, go up into the gigs). Typically, pin drivers are HC or LVC range CMOS, with quick risetime (< 5 ns?) and full swing (GND to VCC). Data inputs won't be particularly sensitive to bounce, but SCK inputs depend critically upon good signal quality. CS pins may be edge or level sensitive, because they often serve to reset the serial register, or activate a power-down or dormant state, which would be a problem for cross-talk.SPI clock inputs may have sensitivity well into the 100s of MHz, so you will, in principle, need an oscilloscope capable of as much to verify the signal integrity. It's often better to just filter the signal at the pin, so the bandwidth is well defined, and then you don't have much to worry about. A comprehensive approach, controlling signal quality from end to end, and limiting bandwidth as needed, is always better, of course.Personally, I've had 8" (20cm) wire links between solderless breadboard areas, connecting an ATmega324 to an ADC, and when signal integrity is not observed, the ADC count becomes gibberish (the count even varies depending on where I touch the wires!). With proper consideration (grounding wire pairs, ferrite beads, R+C filters / terminators, etc.), signal quality is just fine. This was performed at 10Mbit, but because of the synchronous nature of the input registers, it does not depend on bitrate, only on signal quality. The ATmega pin drivers are approximately 50 ohms (5V supply) and 5ns risetime.Tim

author: timb
author_rank: Super Contributor
timestamp: September 23, 2014, 06:33:27 pm
content: Have a look at the Logic devices from Saleae. You can pry mine from my cold dead hands. (The new Logics even feature a low bandwidth scope function in addition to the logic channels.)The software is what makes it so powerful. Even a pricey MDO can't come close to the kind of functionality you can get in a good USB logic analyzer IMHO.Sent from my Smartphone

author: DanielS
author_rank: Frequent Contributor
timestamp: September 23, 2014, 07:05:41 pm
content: Quote from: OleIB on September 23, 2014, 11:00:20 amIf you want to have a relatively decent representation of your signal edges without having to get into the details of your transitions' "knee frequency," you need to see at least up to the fourth harmonic, which makes it 5X your data signal's worst-case fundamental and that would be half your bit rate.So if you want to look at a 20Mbps data signal, you want 20M/2*5 = 50MHz bandwidth as bare minimum.If you actually want to see the details of your signal's rising and falling edges, you will need bandwidth equal to Fknee which is 0.5 / (the shorter of Trise and Tfall) so if you have a 2ns rise time on your 20Mbps data stream's edges, you will need around 250MHz of bandwidth to see your signal in full details.

author: W7NGA
author_rank: Regular Contributor
timestamp: September 23, 2014, 07:40:04 pm
content: Quote from: timb on September 23, 2014, 06:33:27 pmI evaluated the Saleae demo and I must have missed something. Once captured, I need to search and find specific I2C packets. The depth of my data streams precludes me from manually scrolling and realistically finding what I need.Is there a serial Search function I missed? If no, I can hardly understand how this could be a useful diagnostic tool for anything but trivial applications.daniel W7NGA

author: timb
author_rank: Super Contributor
timestamp: September 23, 2014, 07:42:35 pm
content: The older versions didn't have a search feature built-in. You had to export as CSV and search.That's been since fixed. The current "beta" release has full search support.Sent from my Smartphone

author: nctnico
author_rank: Super Contributor
timestamp: September 23, 2014, 07:59:46 pm
content: Quote from: OleIB on September 23, 2014, 11:00:20 amAs a rule of thumb you need at least 3 times the datarate for bandwidth to get some idea about a digital signal.

author: mazurov
author_rank: Frequent Contributor
timestamp: September 23, 2014, 08:26:45 pm
content: Quote from: OleIB on September 23, 2014, 11:00:20 amYou want to see rising edges to evaluate signal integrity and you want decoding capability to see the data stream. The scope suitable for both tasks is going to be expensive, however, you can use old analog scope to see the signals and a logic analyzer to decode (when you already know the signal is good and you can actually trust the LA).There is a lot of cheap gear suitable for. that. From experience, the $50 "200 MHz" Openbench LA is good to about 40 MHz SPI. Low bandwidth analog scopes are often crappy - look at 200+ MHz ones.You can see some scope/LA shots here (last picture) ->https://www.circuitsathome.com/mcu/arduino/usb-shield/troubleshooting-arduino-usb-host-shield. The signal is SPI from an Arduino board (2 MHz?).

author: tggzzz
author_rank: Super Contributor
timestamp: September 23, 2014, 08:39:27 pm
content: Quote from: OleIB on September 23, 2014, 11:00:20 amDon't use an oscilloscope for this unless there is no alternative.If you are debugging the protocol+data then you are operating in the digital domain and should use a logic analyser (if you can put a probe on the digital signal), or logging the information by software. That tells you what the program is doing and avoids any possibility that an oscilloscope and UART interpret the data differently, e.g. due to noise,QuoteSee DanielS's response. Virtually any scope is sufficient for this, provided that it samples, say, five points per bit.If you are interested in signal integrity then you may care to understand "eye diagrams", traditionally used for high speed signals since it allows the sampling rate to be much lower than the bandwidt. Key term: equivalent time sampling, cf realtime sampling.

author: David Hess
author_rank: Super Contributor
timestamp: September 23, 2014, 08:51:42 pm
content: This problem is a lot easier to consider by looking at transition time instead of frequency.A typical fast (1 Mbaud) +/- 5 volt RS-232 driver will slew 12 volts in 80 nanoseconds at most which only requires a bandwidth of about 5 MHz to reproduce faithfully. The receiver transition time will only be a little faster so any oscilloscope you are likely to want will have an order of magnitude more bandwidth and higher sample rate than necessary.The digital logic from the UART or microcontroller will have transition times in the 3.5 nanosecond range implying a 100 MHz oscilloscope bandwidth but in practice a lower bandwidth is acceptable in most cases.

author: DanielS
author_rank: Frequent Contributor
timestamp: September 23, 2014, 10:05:09 pm
content: Quote from: David Hess on September 23, 2014, 08:51:42 pmEither way, it all boils down to how precise you want or your signal representation to be. 2X the data rate is good enough if all you want is a general idea of what is going on but if you are chasing signal/data/clock glitches, then you may need as much of FKneeas you can get.

author: David Hess
author_rank: Super Contributor
timestamp: September 23, 2014, 11:13:30 pm
content: Quote from: DanielS on September 23, 2014, 10:05:09 pmMy point is more that if you are interested in signal integrity, then transition time and the sample rate to support it is more relevant than bandwidth although it is easy enough in most cases to convert between them.If I have a much lower data rate but with an RS-232 data channel like I described which will support 1 Mbaud, then an oscilloscope that can follow transitions times faster than 80 nanoseconds is still needed no matter how low the data rate is. 2 times 115k baud implies a bandwidth of 250 kHz which is completely inadequate for displaying the 80 nanosecond rise and fall times that could be associated with an RS-232 transceiver. Going by the 5 times rule based on the 5th harmonic is still low.In this specific case however it would be difficult to find a desirable oscilloscope which is too slow even for the 3.5 nanosecond rise and fall times which might be associated with the UART and microcontroller itself. The slowest oscilloscopes I regularly use are 100 MHz but for looking at the actual RS-232 interface, even limiting the bandwidth to 20 MHz for a cleaner display is not a problem.

author: tggzzz
author_rank: Super Contributor
timestamp: September 23, 2014, 11:38:23 pm
content: Quote from: David Hess on September 23, 2014, 11:13:30 pmThe key word is clearly "desirable"There are many "sound card" or "arduino" scopes that may be just about sufficient the OP's requirements, particularly in non-challenging environments. To the extent they are small and cheap, they could also be classed as desirable.While I have considerable sympathy w.r.t. 100MHz scopes, they are probably overkill for these requirements. Presuming the computers are functioning, there is no real benefit to looking at the computer-bus side of a UART; it would be better to use a logic analyser or, more probably, use software to dump/log the tx/rx characters.

author: DanielS
author_rank: Frequent Contributor
timestamp: September 24, 2014, 03:21:59 am
content: Quote from: David Hess on September 23, 2014, 11:13:30 pmHence the reason why I went through the trouble of explicitly stating the distinction between wanting to have a general idea of what is happening (3rd-5th harmonic) VS FKneefor seeing exactly what is happening.You may not be able to accurately measure a 80ns edge with 3rd-5th harmonic on a 115kbps data streambut 5th harmonic (~300kHz) is still more than enough to quite clearly see and decode a binary data even if the edges look like crap since the five first harmonics will probably contain over 90% of the signal's total energy... I suppose I could do the fourrier integral to verify that as a revision exercise if I get bored tomorrow.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 24, 2014, 04:17:00 am
content: Decoding a signal, yes, little bandwidth is required (half the bitrate in the worst possible case). Does the circuit respond the same way? UARTs are timed to the data, and usually take multiple samples with a voting decision, so aren't as sensitive to noise as others. Clocked methods can have sensitivity into the 100s of MHz, and require as much to verify operation.Tim

author: DanielS
author_rank: Frequent Contributor
timestamp: September 24, 2014, 06:17:34 am
content: Quote from: T3sl4co1l on September 24, 2014, 04:17:00 amYou only need that much bandwidth when you have no idea what the signal integrity on the board is like and need to measure it.Once you know the clock and data are (or should be) reasonably clean, such as when dealing with existing production designs in a repair, everything else can be done with a fraction of the bandwidth. If something has gone wrong, it will usually be obvious even on a barely-adequate scope.

author: OleIB
author_rank: Newbie
timestamp: September 24, 2014, 07:09:04 am
content: I think its getting a bit clearerMaybe one of these will be a good compromise between bandwidth/price and channels?http://www.picotech.com/mixed-signal-oscilloscope.html25MHz Analog Bandwidth for signal integrity checking and a 16bit logic analyser for multiple capture points once the integrity is verified?I guess if I understand this, this scope would be suitable for signal integrity verifications up to 5Mbit / 5MHz for general purpose verifying of levels and +- 1Mbit/Mhz for more detailed looks at rise/fall and edges?Thanks for all the replies!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 25, 2014, 01:07:09 am
content: 25MHz isn't really enough for anything but the longest cable runs. The kind of signal integrity that happens on PCBs requires 100s of MHz to see. Which is a PITA, because scopes up there still aren't terrifically cheap.Just reading signals and verifying levels, 20MHz is fine, yeah.Lesson being, if you're doing new design, it doesn't hurt to filter everything a little, even though it's supposed to be just dumb logic signals floating around.Tim

author: Alex Eisenhut
author_rank: Super Contributor
timestamp: September 25, 2014, 02:45:45 am
content: Quote from: OleIB on September 23, 2014, 11:00:20 amYou'd be better off with a logic analyzer IMO. The software will usually help decode bitstreams and stuff.

author: DanielS
author_rank: Frequent Contributor
timestamp: September 25, 2014, 06:25:54 am
content: Quote from: Alex Eisenhut on September 25, 2014, 02:45:45 amBefore you can use a logic analyzer, you need to know if the signals, and especially the clock(s), are at least reasonably good. Otherwise, you end up with garbage-in, garbage-out and a logic analyzer will not help you much with the analog-domain part of your digital design.Once the analog part (transmission line stuff across your clocks and data lines) is at least sort-of-working, then the logic analyzer can start becoming useful.