This is an important consideration when selecting a Logic Analyzer or an Oscilloscope.
We are not talking about a single factor here, but some of the important ones are Bandwidth & Sample rate. Others that are important is Rise times, Trigger Slope Detection
So the first part you need to know (with a certain amount of certainty) is what you are trying to analyse and the expected bandwidth needed.
Purchase a product that does not have the bandwidth, or your Oscilloscope does not have a fast enough rise time to match what you are measuring, then you may have put a reasonable amount of money into something that will provide some reasonable shortcomings.
This is part of the issue when doing your research. In the many articles one person feels that this model of scope might be great for what they are using it for, whilst another person finds it not suitable. It really comes down to what you are measuring, and the purpose of your measurements. This can be a complete book in itself (or many books), so for the purpose of this article, we are going to talk about Raspberry PI and Arduino systems, and more specifically dealing with peripheral’s using the GPIO or Arduino’s Interface which gives us a starting point.
https://www.eetimes.com/how-much-bandwidth-does-your-logic-analyzer-need/#
https://www.eevblog.com/forum/beginners/bandwidth-of-logic-analyzer/
Before we look at the estimated Bandwidth/Sampling requirements, it is important the current maximum capability of the I/O (this is maximum clock frequency of the I/O – not the device itself) on these devices. For instance the Arduino Mega (and probably others) have a maximum Clock of 16Mhz. The Raspberry Pi has a maximum clock frequency of 400Mhz.
However this does not translate that these frequencies will be achieved on your I/O, in fact most cases it will depend on the method you use (i2c, SPI, 1wire, UART) and also the libraries that you use. In most cases, it will be a fraction of this, due to the design of the library, overhead of the language that you are using (e.g. something written in C is going to be faster than Python – but even something written in C will have overheads)
Combine this with the limitation of the device that you have attached the I/O (which becomes the limiting factor) , in many cases, you are dealing with 90% of components not able to handle anything above 20Mhz, with the majority between 200Khz and 3Mhz. Some common examples of typical frequencies are :
I/O Type | Rasp PI | Arduino Typ. Range | Comment | Software Variable |
UART | 115Khz | 115Khz | @115200 baud & 9.6Khz for 9600Bd | Slow Baud Rate down |
1Wire | 16.3 - 163Khz | 16.3 - 163Khz | This was a bus system developed by Dallas Semiconductor Corp which utilises a low speed (16.3kbps) data, signalling and power over a single wire plus it has an overdrive function (if supported of 10x that speed. | No |
I2C | 100khz - 400Khz | 100khz - 400Khz | The i2c has various speeds. The most common is 100Kbit/s or 400kbit/s but also 3.4Mbit/s is used. | No |
SPI | <1Mhz-25Mhz | <16Mhz | Can be drive in some cases 50Mhz-100Mhz. Absolute Max speed on Raspberry Pi is 125Mhz, but overheads limit this severely - but assume <24Mhz for general work and most cases much less. | Yes |
Direct | 20Mhz | 8Mhz | GPIO Toggling of the pins using C at its fastest is about 20Mhz - software overhead (Bit Banging) | Software delays |
PWM | <8Khz | <8khz | PWM on GPIO Pins - RPI - 8Mhz is possible | Yes |
Non-GPIO I/O Interfaces or Non-Standard Interfaces | ||||
DSI | 16Mhz | N/A | Can be drive in some cases 50Mhz-100Mhz - assume <20Mhz | No |
MIPI/CIS | 25Mhz-27Mhz | N/A | Varies - but understood that the clock comes from the camera (oscillator) example | No |
Note : Whilst figures have been quoted, they are typical only and mainly intended for the general user. Specs have per device, new techniques or methodologies are employed which mean these figures may not be accurate. They are to be used as a guide only
Now that you have a rounded understanding of the typical estimated I/O maximum speeds that we are dealing with, it should be also noted that you also have the ability to limit the speeds (on the GPIO) that these devices work at, so you can see them at lower bandwidth scopes and logic analysers. In most cases, you will find that they are being used at much lower speeds.
Keep these figures in mind when you look a the following pages on this website
Page Links
https://engineering.stackexchange.com/questions/3991/how-fast-should-i-sample-with-a-logic-analyzer
