Our 8 channel USB logic analyser is a great piece of kit for analysing a variety of logic signals, both individually and when grouped as a bus. The hardware alone, however, is useless as such we recommend PulseView, part of the sigrok package. Windows, Linux and macOS X packages can be downloaded here.
The logic analyser featured can be purchased from the NIMO store.
Overview
Upon running PulseView for you will be greeted by the following screen.
There are a few key controls that will get you up and running, you can find them in the image below.
Device selection
Here you can choose the physical device to collect data from. After clicking on the drop-down, a dialog will open allowing you to choose the driver and interface. Select fx2lafw from the driver drop-down and USB as the interface. Next click “Scan for devices…”, you should then see your analyser appear in the list. Click OK to close the dialog.
(Note, that if you are running on Linux then you will either have to run PulseView as root or modify the device permissions via a udev rule to detect the device).
Device settings
This dialog allows you to set the “Pre-trigger capture ratio”. This defines how much data preceding the trigger event should be kept.
Channel settings
Channel settings provide a method of enabling and disabling channels (in other words hiding them from view). This is incredibly helpful if you are only using a couple of inputs such as when debugging an I2C interface.
Sample quantity, Sample rate
Sample quantity and Sample rate work together to control the amount and resolution of displayed data respectively. Sample quantity defines the size of the sample buffer (i.e. the total number of data points captured), while sample rate defines the number of samples captured per second. For example, a sample rate of 200kHz will fill a 1M sample buffer in 5 seconds.
Generally speaking, the sample rate should be around 10x higher than the fastest signal to be captured. Sometimes this isn’t possible for very fast signals so these settings may require some trial and error.
Decoders
The Decoders dropdown provides a vast array of protocol decoders, most if not all common data busses are provided for including but not limited to SPI, I2C, I2S, JTAG, Stepper motor and more. Decoders sit below the data lines in the main display window and provide human-readable interpretations of the captured data.
Here is an example of PulseView decoding an SPI bus.
Each channel can be customised by clicking on the tag to the left of the main data window. This allows you to customise the channel name, colour, trace height and trigger type.
Similarly, clicking on the tag for a decoder allows you to configure the specific settings for that decoder.
Triggers
We have mentioned triggers a couple of times now but haven’t yet defined them. The default configuration for PulseView is known as free-running. In other words, once you click the run button, it captures data until the buffer is full and then stops. This is great if you are just trying to measure the frequency of a clock, for example, however, it’s not always as useful when trying to capture specific data. This is where triggers come in…
By clicking on the tag for a particular channel you can select between the following trigger types:
- None
- Low level
- High level
- Rising edge
- Falling edge
- Rising and falling edge
Once you have selected a trigger condition for a particular channel, you can click run and PulseView will wait until it sees the required condition on that particular channel. This is incredibly useful when looking at data busses. For example, if you set a falling edge trigger condition on the Chip Select line of an SPI bus then Pulse View will only log data for that particular device rather than capturing all of the bus data.
During the overview, we mentioned the Pre-trigger capture ratio setting that can be found in the device settings dialog. Generally speaking, PulseView discards any data that occurs before the trigger condition. In some instances, however, it can be useful to see the state of the data lines just before the trigger condition occurred. The Pre-trigger capture ratio allows you to specify how much of the data buffer should be allocated to data that occurs before the trigger condition.
