Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Saleae Logic software includes the following protocol analyzers:
1-Wire
Asynchronous Serial
Atmel SWI (Single Wire Interface)
BISS-C
CAN (Controller Area Network)
DMX512
HD44780 Parallel LCD
HDLC (High-Level Data Link Control)
HDMI-CEC
I2C
I2S Audio / PCM
I3C (see section below)
JTAG
LIN (Local Interconnect Network)
MDIO (Management Data Input/Output)
MIDI
Manchester (Differential, Bi-Phase Space, and Bi-Phase Mark)
Modbus RTU & ASCII
PS2 Keyboard & Mouse
SMBus (includes PMBus and Smart Battery)
SPI (Serial Peripheral Interface)
SWD (ARM Serial Wire Debug)
Synchronous Parallel
USB Low Speed and Full Speed
We've worked closely with the team at Binho LLC to develop a 3rd party I3C Protocol Analyzer plugin for our Saleae Logic software! This plugin is developed by Binho LLC and will require a paid license to use it within our software. If you're interested in more details, !
We provide user guides for a handful of our protocol analyzers, which we have listed in the link below.
Some Logic users have created their own protocol analyzers. The following list of analyzers are available but not officially supported by Saleae.
Yes. However, you will need to use a device with sufficient bandwidth to record the original signal. For instance, Logic 4 simply does not have the bandwidth required to capture and decode USB full speed. Logic 4 has a maximum digital bandwidth of 3 MHz, and USB full speed requires a digital bandwidth of at least 12.5 MHz.
Unfortunately, we have not yet ported the UNI/O analyzer from Logic v1 into the newer Logic v2 software. Specifically, it requires separate API functions that we simply haven't had the chance to implement yet. It's not on the roadmap at the moment, though we would like to gauge user interest in this before we commit to it, as porting this analyzer into Logic v2 would require quite a bit of work as compared to porting our other analyzers.
You can vote for this idea .
Saleae Logic supports decoding of several protocol analyzers.
Check out Saleae's officially supported protocol analyzers below.
Our passionate users have also been kind to share several community-developed protocol analyzers. Although we don't officially support these analyzers, it's a great resource for sharing your work amongst engineers!
Can't find an analyzer you need? Develop your own protocol analyzer using our Protocol Analyzer SDK below.
The Saleae software includes a protocol analyzer for the I2C protocol.
The I2C protocol is a synchronous serial interface that uses one clock channel (SCL) and one data channel (SDA). The analyzer will parse the address, direction (read/write) data, and ACK/NAK frame from I2C transactions.
It will also use markers to indicate the start and stop conditions. This is indicated by a green circle and an orange square respectively, as shown in the image above.
In the settings, specify which input channels are used for the I2C signals SDA and SCL.
Please note that I2C addresses are displayed as 7-bit numbers. We share a support article below to help display I2C addresses as 8-bit if preferred.
If you notice that our I2C analyzer fails to decode data, a common failure point is typically glitches/noise around the SCL signal edges. I2C is particularly vulnerable to this issue due to the slow rise times caused by the open drain bus topology. The relatively slow signal rise time through the threshold region of the logic analyzer input buffer can sometimes cause these glitches to occur.
You may notice where the analyzer seems to decode less than 9 bits per frame, or incorrect results. If you notice this, carefully zoom in around each clock edge in the problem frame and check to see if there is a "glitch" or narrow pulse present next to the clock transition that is causing a clock edge to be detected as multiple edges.
This can happen for several reasons, and we've added a software feature to allow these "glitches" to be filtered out. See this article for instructions.
Besides using the glitch filter, you may also want to try reducing the sample rate of the capture, using a different IO voltage option if supported by your logic analyzer, or filtering the electrical signal at the hardware level.
If you're new to I2C, you may notice that a read operation may be preceded by a write transaction when one was not expected. That is most likely because the I2C slave you are using first expects the master to write the desired address that should be read back later. Since a read transaction is only unidirectional, the read transaction can't be used to inform the slave of the read address. In many cases, this is done by the master first starting with a write transaction where the target read address is sent to the slave, followed by a I2C "re-start" condition, which then allows the master to begin a read transaction. Now that the slave device is aware of the desired read address, it can transmit this data back to the master.
The Saleae Logic software includes a software protocol analyzer for the CAN protocol.
The Saleae CAN protocol analyzer supports standard and extended CAN identifiers.
Since the Saleae devices only have single-ended inputs and not differential inputs, the ideal way to record a CAN signal is after it has been converted to single-ended. If your design already includes CAN transceivers, you might be able to simply attach the probe on the single-ended side.
If you are unable to convert the CAN bus to single-ended, you may still be able to record one side of the CAN pair directly. See below.
Decode Differential and High Voltage DataOnce you have recorded the CAN signal and have added the CAN analyzer, there are three settings to select.
The first is the CAN channel. It just needs to be set to the input channel that you're using to record CAN.
Second is the bit rate. If you already know the bit rate your CAN bus is using, enter it here. If not, then there are several easy ways to measure this. Since the bit rate is the inverse (reciprocal) of the bit period, you simply need to measure a single bit period in the capture and take its inverse. You need to find a single bit by itself to do this, such as the pattern 010 or 101, where the center bit will have edges on each side. You can also place a measurement over an entire CAN transaction and turn on the measurement for the narrowest pulse width.
The last setting for CAN is the inverted option. If you are recording the single-ended version of CAN, you will not need this. If you are recording CAN Low, you will not need this. If you are recording CAN High or if for some other reason the CAN signal is inverted (nominally idle high, inverted would be idle low), then check this box.
Once these settings are correct, save the settings and check the results. You should see the following fields decoded: CAN identifier (standard or extended) Control field Data field(s) CRC value ACK or NAK
If you zoom in, you should see white dots in the center of each bit frame. These are added by the analyzer so you can see where an ideal CAN receiver set to the specified bit rate would sample the bus. It's most helpful when debugging baud rate error related issues.
The red X marks indicate stuffed bits. They are supposed to be there. The X simply lets you know that the bit is not included in the data and is only added for bit stuffing.
The Saleae I2S analyzer does not support any Mono formats.
Even when the I2S settings have signed number selected, unsigned numbers may always be shown.
This issue is solved by changing the display radix from ascii to decimal. Although a decimal number is shown, the single quotes indicate that the ascii display mode is active, but the number is considered a non-displayable character (in this case, outside of the low ascii range completely) so the text string defaults to unsigned decimal. Changing the display radix to decimal will show the signed number.
The analyzer result may also not display the data correctly. An image of the error is provided below.
In the image above, the data bits are transitioning during the clock falling edge, but the I2S/PCM Analyzer is also set to read on the clock falling edge as shown by the "down" arrows on the clock signal.
That means the bits are being decoded at the exact moment the bits are changing, which will cause errors and will be very sensitive to changes in the sample rate. Change the I2S/PCM Analyzer setting for CLOCK State to either Rising edge or Falling edge depending on the correct clock edge that your data requires.
For more information on this, please see the link below.
The Saleae software includes a protocol analyzer for the Serial Peripheral Interface (SPI) bus.
SPI uses a Clock signal, two data signals (MISO and MOSI), and an Enable signal. That is the most common configuration of SPI, but other variants exist.
Our SPI analyzer is generic enough to decode basic synchronous serial (at minimum, a clock signal and a data signal) without the need for a second data signal or an enable signal. In cases like this, one of the data signals and the Enable signal can be disabled from within the analyzer settings.
The Saleae Logic software includes a protocol analyzer for the DMX-512 interface. DMX-512 is a single data channel interface commonly used to control lighting in staged environments such as those found in concerts, theater, and other live performance events. At a minimum, the DMX-512 interface will have a Data- pin (D-), a Data+ pin (D+), and a ground pin.
Setting Up the DMX-512 Analyzer
To use the DMX-512 analyzer, first add it using the add analyzer menu on the right side.
In the analyzer settings, specify which input channel will be used for the serial data. You will also need to specify if the DMX-1986 4 μs MAB will be used.
Checking the "Accept DMX-1986 4us MAB" box will allow compatibility with legacy equipment that uses the DMX-512 original specification from 1986, which had a fixed 4 μs MAB. Most modern DMX-512 equipment will not need this setting checked, so we leave it unselected by default.
Common Causes for Decoding Errors
The signal is inverted. Currently, our DMX-512 analyzer cannot detect inverted signals. For example, if the signal looks inverted while D+ was being measured, try measuring D- instead. Please ensure that measurements are always done with respect to ground.
If you're still facing decoding errors, you can compare your signal with a simulated signal generated by our Logic software. You can read more about simulating data below.
Add the SPI analyzer to your capture. There are a number of settings for the analyzer. First, select the channels you are using. If you are not using an enable signal or if you only have one data signal, simply set the unused channels to "None". Only clock and one data channel (either MISO or MOSI) are required for the SPI analyzer to operate.
Next, select the remaining settings you are using. If you are unsure what settings are used for the data you captured, you can either visually identify them or you can guess and check.
MSB/LSB first. If you can't check which mode your data uses, you may need to guess.
Bits per transfer. This is almost always 8 bits but can be set up to 64 bits.
Clock polarity
Clock polarity is basically the idle state of the clock in between SPI transactions. Whatever the idle clock state is when the enable signal becomes active, use this value (high or low).
Clock phase
Clock phase selects which edge the data is read on. Please note that leading and trailing do not correspond to rising and falling, which can lead to confusion. The leading edge is defined as the first edge on the clock signal after the enable line becomes active. If the clock is idle high, then the leading edge is the falling edge. If the clock is idle low, then the leading edge is the rising edge. This is the edge where data will be read from the data lines.
Active low/active high enable
Only applies when an enable signal is used. Defines the state of the enable signal when the SPI analyzer will read the data signals.
When you have multiple devices on the same SPI bus, you will have multiple enable signals, one for each slave device. To decode data from each slave device, simply add more SPI analyzers. It's perfectly fine for all SPI analyzers to share the same clock, the MISO, and MOSI signals. Note that the GUI will indicate that those channels are already in use, but that does not mean you can't use them.
Different Settings for MISO and MOSI
In some cases, you may want to have different settings between the two data channels. That can easily be done by using two SPI analyzers. Analyzers in the Saleae software have no limit to the number of analyzers that can share the same channels, so just add two SPI analyzers using the same clock, and enable channels. Then, on each analyzer, disable one of the two data channels.
SPI analyzer 1
MOSI channel - MOSI input selected
MISO channel - "none"
SPI analyzer 2
MOSI channel - "none"
MISO channel - MISO input selected
Then assign the settings you like to each analyzer.
In many cases, there is no chip select signal available for an SPI bus that needs to be recorded.
The SPI analyzer included in the Saleae Logic software supports this case. In the event you record SPI data and there is no valid enable signal, simply change the "Enable" channel in the SPI analyzer settings to "None" as shown here:
In some cases (most commonly caused by ignoring the enable signal as described above), the analyzer will not decode the data correctly. That is because the SPI analyzer usually relies on the enable signal to align the data—that is, determine which bit of data should be the first bit in each byte and which bit should be the last.
Shown here is a typical issue where the alignment is off. You can clearly see that the pulses on the clock channel are in groups of eight—8 bits in each byte. There is a short gap between each byte.
However, even though the analyzer is decoding the data in groups of 8 bits, it is not starting on the correct bit. Instead, it is taking some bits from the end of the previous byte and adding them to the bits at the beginning of the next byte.
Here are the two most common causes of this:
The logic analyzer started recording in the middle of an SPI byte.
There are other erroneous transitions on the clock channel before the valid SPI data.
This is easy to fix. You will need to tell the SPI analyzer where the valid SPI data starts in the capture. The analyzer will then use that as the new starting point of the capture and decode data from that location.
Here's how this is done:
Place a timing marker just before the start of the first valid SPI byte.
Delete the data before the timing marker (please note this cannot be undone). Instructions are provided in the support article below.
If using the older Logic 1.x software, the following information applies.
First, add the timing marker by clicking the A1 button on the right side of the screen. Then click on the graph at the location where you would like to place it, as shown here:
Next, open the SPI analyzer settings menu and select "Re-run starting at timing marker...". From that list, select the timing marker you just placed.
Screenshots:
After a moment, the SPI analyzer will automatically reprocess the capture. The data should now be aligned correctly, as shown here:
A red square appears on the clock channel when the enable channel goes low. This can be accompanied by one of these messages: "The initial (idle) state of the CLK line does not match the settings" or "Settings mismatch" or "Error".
This occurs when the clock polarity setting is not set properly. For instance, in the image below, the clock channel is low while the enable signal is inactive. The correct setting should be "Click is low when inactive (CPOL=0)". In this case, the error is generated when "Clock is high when inactive (CPOL=1)" is selected. Simply swap the clock polarity and then double-check the clock phase to correct the issue.
The Saleae Logic software includes the ability to decode SMBus data. The SMBus Analyzer allows you to decode the SMBDAT and SMBCLK lines with some configuration settings which can change how the data can be viewed.
The SMBus Analyzer has the following settings.
First, select the channels for the SMBDAT and SMBCLK lines.
Then, select the SMBus decode level. This will change the way the decoded captured data is displayed on the Logic software.
Signals: This will show the data in single-bit format.
Changing the Display Radix setting in the Logic software will not change the way the SMBus data is displayed. Instead, you must change the display format using the SMBus decode level setting.
Bytes: This will show the data in hex format, decode it as a read or write operation, and will display the bytes as an ACK or NACK. If PEC on packets need to be calculated and shown on screen, then SMBus, PMBus, or Smart Battery should be selected.
SMBus, PMBus, & Smart Battery: Set this to the appropriate protocol you will be decoding. When enabling the "Calculate PEC on packets" setting, the PEC will be shown when the data is decoded.
Here is a quick summary of the symbol definitions in the waveform in order of them appearing in a single SMBus transaction. Note that a transaction can be made up of multiple 8-bit words.
Green circle = Start condition for the entire transaction
Circle matching color of waveform = Stop bit for an 8-bit word (except the last one)
Red circle = Stop bit for the last 8-bit word
I also wanted to add that it’s normal for the SDA line to go high briefly when the component driving the SDA line low switches between the master and the slave device. For example, when the master device finishes transmitting data, it will then release the SDA line, allowing the slave to pull it low to signal the ACK. There is sometimes a brief time during the switch where neither component is pulling the line low, which can produce short positive pulse. This is usually before or after a ACK/NAK bit.
The Saleae software includes a protocol analyzer for asynchronous serial communication.
Async serial communication is a very generic term that means any data that is transmitted serially (i.e., one bit at a time). The serial analyzer in the Saleae software is flexible, but it's ultimately designed to only decode serial data that uses the standard start bit and stop bit format. Many other features of the serial analyzer are flexible, though.
Below is a description of each setting and what it does.
Select which channel in your capture you would like to decode.
Looking to decode more than one channel? Just add a second serial analyzer!
This is the bit rate, or baud rate. If you don't know the bit rate, you can measure it manually. More information on this is described below.
This is the number of bits per word (default is "8 Bits per Transfer"). Note that this number is just the data payload and does not include the start, stop, or parity bits.
The async serial analyzer lets you select 1 stop bit, 1.5 stop bits, or 2 stop bits. The most commonly used setting is 1 stop bit.
Parity is a feature where the serial transmitter includes an extra bit of information after transmitting the data word but before the stop bit that helps the receiver detect possible bit errors caused by line noise. In Logic software, the parity bit is signified by the bolded square dot, as shown in the figure below.
No parity means no extra bit is transmitted.
Even parity means that the total number of binary ones in the data word, including the parity bit, is an even number. For instance, 0b10110101 would have an even parity bit of one because there is an odd number of ones in the data word. An extra one will make the total an even 6 ones.
Odd parity is similar to even parity, but the parity bit is used to make the total number of ones in the data word + parity bit and odd number.
Significant Bit
This simply states the order of bits on the bus, just like reading from left to right or right to left.
This is an important setting. Usually, TTL/CMOS level serial is active low, meaning that the bus idles high. Binary zeros are transmitted by pulling the line low, and binary ones are transmitted by pulling the line high. That is pretty common.
However, in some cases, such as recording RS-232 serial directly, the states are reversed. In RS-232, the line is idle low, and zeros are transmitted by pulling the line high. When recording RS-232 level signals directly, or in any other case where the channel is inverted, use this option.
MP Mode (also called multiprocessor mode, multi-drop, or 9-bit serial) is a version of serial where the most significant data bit (almost always the last bit) indicates if the preceding 8 bits is data or an address.
MDB Mode, also called multidrop bus, is basically the same as MP mode, but the address indicator bit is inverted.
In either mode, the normal serial word (usually 8 bits) is proceeded with an extra bit to distinguish address from data. In MP mode, the extra bit is set to indicate data and clear to indicate an address. The bit state is the inverse for MDB mode.
Hover your mouse over the fastest 2-bits, and then take the inverse. One way to do this is to find a 2 bits of data that are opposite in state so you can measure the distance between the two transitions and take the inverse of that measurement to get its bit rate.
The software will show auto-measurements like shown in the image below. In this case, the inverse measurement is shown to be 114.943 kHz, which is close to the bit rate of 115.200 kBits/s that the DUT was communicating at.
It's best to perform the measurement in several different spots and average the results.
As an alternative, you may also use a Baud Rate Estimate extension that was developed and kindly shared by a community user. The extension is available on our Extensions Marketplace.
In case you are unfamiliar with extensions and measurements, you may refer to the below support articles for more details on these features.
Decoded data may be offset if there are no gaps between data transactions. An example of this issue is shown in the image below. This is especially apparent when the Logic capture is started in the middle of data transmission. The workarounds would be as follows:
Make sure to start your capture before serial data transmission has begun.
Ensure that your transmitted data contains idle periods of at least 1 transaction wide. Our Async Serial will always resync on the next set of data after the idle period of 1 transaction wide.
How do I decode more than one channel of serial at once, such as RX and TX signals? To do this, add two instances of the Async Serial analyzer. More information on using multiple analyzers can be found below.
How can I set the Async Serial analyzer to decode the parity and stop bits separately from the data bits? To do this, you will need to use our Protocol Analyzer SDK to modify the behavior of the Async Serial analyzer. Currently, the software will decode an entire serial word as a single frame. The SDK can be downloaded below.
The data bus is idling low and the Async signal is inverted, causing the data to be decoded improperly. In this case, make sure the Async Serial analyzer settings are set to Inverted.
Auto baud might cause errors and may not be the most accurate method to decode data correctly. It is generally preferred to manually set the baud rate properly.
Check your data to see if parity should be enabled or disabled, and if the parity bit is even or odd. If selected incorrectly, the data will show parity errors. In the figure below, the Async Analyzer parity setting is set to odd parity, while the recorded data show an even parity.
If you're still facing decoding errors, you can compare your signal with a simulated signal generated by our Logic software. You can read more about simulating data below.
The Saleae Logic software supports decoding UART communications using the provided Async Serial Analyzer in the Logic software.
A UART (Universal Asynchronous Receiver/Transmitter) is a hardware block most commonly found in microcontrollers and processors. Its primary job is to send and receive asynchronous serial data to and from other UART devices via two data lines: TX and RX.
Typically, the serial data are organized in the following format:
If you are using the older Logic 1.x software, there are a couple differences as described below.
Autobaud attempts to automatically determine the bit rate used in your recording.
Autobaud accomplishes this by simply running the analyzer twice when you save the settings. First, it runs the analyzer using the baud rate set in the analyzer settings (default 9600). While it's running, it keeps track of the narrowest pulse in the entire capture. Then, it sets the baud rate accordingly, assuming that the narrowest pulse is exactly 1 bit wide.
If the narrowest pulse width is only 1 sample wide, the autobaud system will fail and not attempt to adjust the baud rate. That can happen when not sampling fast enough or when there is noise in the capture.
The Saleae Logic software includes a protocol decoder to read clocked (synchronous) parallel bus data. The analyzer supports between 1 and 16 bits of data bus, although realistically, only 15 bits are possible due to the relance of a clock signal taking up one channel. The example image below shows a 4-bit data bus and a clock signal, which requires 5 channels.
When using the Simple Parallel Analyzer, you will notice arrows and dots in the capture. You will also notice that the data is decoded above the Clock channel.
Arrows - These represent when the sampling of the data bus takes place. In the example image above, we have set the Simple Parallel analyzer to treat data as valid on rising edges.
Dots - The dots will be time-aligned with the arrows, and will give a representation of where data sampling takes place in the respective data bit channel.
An example is shown below for how a 4-bit data bus and a clock signal will be decoded using the Simple Parallel Analyzer. Note that the decoded data bubble (in this example, "0x0004") will always appear as a 16-bit hex number (i.e. 0x0000), even when a smaller data bus is decoded (in the case below, a 4-bit data bus).
Keep in mind that this isn't the "state" mode you may have seen in other logic analyzers. All Saleae units operate by over-sampling only and do not support a state/external clock mode. That means you will need to sample at least 4 times faster than the parallel clock frequency.
The settings for the parallel analyzer are described in this section. First, for all unused data bits, change the selected channel to "None". For instance, if you're using a 4-bit data bus, change D4-D15 to "None" in the settings as shown below.
Then, correctly assign the data bits you are using to the corresponding channels.
Finally, set the clock channel and the clock edge correctly and press Save.
The protocol export will create a file using the currently selected display radix (hex demonstrated here). The export format has a header row and then 1 row per recorded parallel value. The values are the same as displayed in the displayed frames over the clock channel. There is one row per valid clock edge, either rising or falling, as specified in the analyzer settings.
Here is a sample of a file:
Logic 4, Logic 8, Logic Pro 8, and Logic Pro 16 can be used to read and decode RS-232, RS-485, and RS-422 data up to +/- 25V.
Our older Gen1 products (Original Logic and Logic16) have a 0V to 5V absolute maximum range. Therefore, neither product can be used to measure signals outside of this range. That limits its usage for directly recording RS-232, RS-485, and RS-422, which exceed this range in many cases.
All four of the new Saleae devices include over-voltage protection to +/- 25 volts. It’s perfectly safe to connect any signal up to this range directly to its inputs.
The original Logic and Logic16 cannot be directly connected to these signals. They also have over-voltage protection, but it was not designed to be used with these signals continuously. Either use a voltage divider or a dedicated line transceiver/receiver to convert these signals to CMOS/TTL levels.
When recording any of these signals, it is important to properly connect the ground from the logic analyzer to either the ground of the transmitter or the receiver. Do not connect ground to one of the signal wires, as this could damage your equipment. Neither RS-232, RS-485, nor RS-422 are isolated, which means that all transmitters and receivers on the bus must share the same ground to operate. In most cases, a ground wire is included in the bus wiring, which could be tapped with Logic. Otherwise, you will need to find another ground connection nearby to connect to.
For RS-422 and RS-485, it's generally not necessary to record both the + and - signals. In most cases, recording only one-half of the differential pair is sufficient. However, it's usually a good idea to record both sides, at least at first, to evaluate the differences in the recording quality of the two signals. Because the threshold voltage of the logic analyzer is not matched properly for differential signals, it's likely that one side of the differential pair will have a cleaner recording than the other.
Connecting to higher voltage signals with the new Logic 4, Logic 8, Logic Pro 8, or the Logic Pro 16.
All four of the new Saleae devices include over-voltage protection to +/- 25 volts. It’s perfectly safe to connect any signal up to this range directly to its inputs.
This may work for most applications. However, keep in mind that the logic threshold (the trip-point voltage that determines if the input is a logic 0 or a logic 1) is very low compared to a 12-volt signal. If your signal does not swing all the way to ground or has a very slow transition speed, it may skew the results or simply not read correctly. In these cases, you may want to use a resistor divider to reduce the voltage level, so the trip point will appear to be higher relative to your signal. Keep the bandwidth requirements and Logic’s input capacity in mind when creating a resistor divider.
Connecting to higher voltage signals with the original Logic or Logic16.
Logic's and Logic16's inputs operate up to 5 volts and have over-voltage protection to protect against short transients up to higher voltages. However, neither product can be directly connected to signals outside the 0V to 5V range.
To connect Logic to a higher voltage signal, you have several options. In the general case, the best solution is to use a level shifting IC or adapter to convert to a lower voltage.
You may also be able to use a resistor divider. However, this will either reduce the input bandwidth of Logic or consume extra power from your circuit, depending on the resistor values.
Generally, we recommend converting CAN to a single-ended TTL signal before connecting it to Logic. However, in most cases, you can connect the CAN low signal directly to the Logic analyzer. CAN low is electrically similar to single-ended CAN and can be interpreted by our CAN analyzer.
Note: If you are using the original Logic16, make sure you have selected the lower voltage setting for 1.8V to 3.3V logic.
Note: If you are using 3.3 Volt CAN, you might not be able to record it directly with Logic 4.
Our products are most likely to work with recording CAN low. It is very unlikely that they will be able to record CAN high. Logic 4 requires CAN low to swing below 0.8 volts and above 2.0 volts. Logic 8 requires CAN low to swing below 0.6 volts and above 1.2 volts. Logic Pro 8 and Logic Pro 16 have comparator inputs instead of CMOS inputs, with selectable thresholds. For use with CAN low at 5 volts, the highest threshold setting is suggested. In the software, it is labeled as 3.3v+, and the threshold voltage itself is about 1.65 volts.
We recommend verifying that CAN low does swing below the required voltage before making a purchase. Otherwise, a voltage divider or a CAN adapter may be required.
The Saleae devices and CAN analyzer were designed with single-ended CAN in mind, for development of CAN devices that contain a CAN transceiver IC. The recommended way to record CAN data is to probe the single-ended signal between the CAN transceiver IC and the application processor.
ECL logic swings between -1.75 volts (logic low) and -0.9 volts (logic high). Because none of the Saleae products offer threshold options below ground, ECL cannot be directly recorded with digital inputs. The Logic Pro devices can record these signals in analog, but only at very low bandwidths, and the recorded signal can only be viewed in analog—protocol analyzers and digital measurements can't be applied.
PECL swings from +3.4 volts (logic low) to +4.2 volts (logic high).
The highest threshold option for a Saleae product is only 1.65 volts on the Logic Pro devices, which is not high enough to properly record the PECL signals using the digital inputs. You may want to consider level shifting the signal down or recording it with the analog inputs at a much lower bandwidth.
As mentioned before, none of the Saleae products have differential inputs. They are single-ended only. Ideally, LVDS signals should be recorded downstream of an LVDS line receiver or transceiver.
Recording directly with single-ended inputs: In situations with programmable drive strength or termination resistors, you may need to first check the signal voltages using the analog recording mode of the new Saleae products. Then check the recorded signals against the voltage threshold(s) for the product you are using.
It is not possible to directly record Ethernet signals with Saleae devices. However, it may be possible to record 10BASE-T data with some input circuitry.
10BASE-T Ethernet is a differential signal using Manchester encoding. Ethernet cable has an impedance of 100 ohms, and the signals swing between +1V and -1V, producing a peak-to-peak voltage of +/- 2 volts. Saleae devices do not directly support recording differential signals, so a differential to a single-ended receiver is recommended. Once the signal has been converted to single-ended, it can be recorded, and physical layer decoding can be performed using the Manchester protocol analyzer built into the Saleae software. Since Ethernet devices will not communicate unless a device is connected to receive data, you will most likely need to tap the signals on an existing Ethernet transceiver.
10 Mbit data with Manchester encoding has a bandwidth of 20 MHz. To record this with a Saleae device, a minimum sample rate of 80 MHz is required. For this, Logic 8, Logic Pro 8, Logic Pro 16, and the original Logic 16 would be suitable. Be sure to verify the IO standards of the device you will use before implementing the necessary single-ended conversion.
100BASE-T Ethernet and faster cannot be recorded because the signal is tri-state. (+1V, -1V, and 0V). No Saleae device is capable of recording digital signals with 3 states, and the analog inputs do not have the required bandwidth to record 100BASE-T signals. Also, protocol decoders cannot be used on analog signals.
If the narrowest pulse is within 5% of the user-entered baud rate, it will not attempt to adjust the baud rate.
If neither condition is true, the software will automatically change the baud rate to the new setting and re-run the analyzer.
To see if autobaud worked, re-open the analyzer settings. If the baud rate didn't change, then one of the above two conditions must have prevented it from working.
Time [s],Value
0.000020000000000,0x0000
0.000040000000000,0x0001
0.000060000000000,0x0002
0.000080000000000,0x0003
0.000100000000000,0x0004
0.000120000000000,0x0005
0.000140000000000,0x0006
