The Open Logic Sniffer is a purpose-built logic analyzer board designed to be low cost but high speed. It sacrifices a lot of the features you’d look for in a full-scale development board to achieve our primary goals:

70MHz+ sample speeds

32 channels

16 buffered, 5volt tolerant channels

USB interface, USB powered

USB upgradable everything

Make it as DIY as possible

Make it as open source as possible

$30-$40 price range

We didn’t quite hit our initial price range, but we got really close.

You can get your own assembled Open Logic Sniffer at Seeed Studio for $45, including worldwide shipping. Continue reading about the design and collaboration below.

SUMP is a sampling logic analyzer. It reads the state of the input pins and stores the samples in internal ram. It then dumps the samples back to the computer client for analysis. The number of samples possible is limited by the RAM in the FPGA.

We like SUMP because it’s the best developed open source logic analyzer toolchain currently available. It has lots of professional features like multi-stage triggers, configurable pre-roll, external trigger and clock sync, and a few protocol analyzers (I2C, UART). It’s open source, so the potential to add cool new features is limited only by your imagination and coding skills.

SUMP is typically ported to a general-purpose FPGA development board. We took a different approach and designed hardware specifically for SUMP, while constraining costs wherever possible.

Other logic analyzers

Professional logic analyzers have tons of channels and super high speeds. We’re not trying to make a low cost DIY version of these tools, the OLS isn’t an alternative to these types of tools if you need to sniff 100MHz+ signals and have huge sample sizes.

Being an engineer’s tool, there are plenty of DIY logic analyzer designs. Parallel port based logic analyzers used to be all the rage, but with parallel ports and direct interrupt access disappearing from systems, these are just historical curiosities.

Another type of DIY logic analyzer is a microcontroller-based device. There are several with custom interfaces like the PIC Logix, Scanalogic, and AVR Logic Analyzer. The Bus Pirate works with SUMP. Microcontroller analyzers all have one thing in common: they’re really slow, usually sub-megahertz.

USB IO chip-based hobby logic analyzers are currently popular. We’ve always been fans of the Saleae Logic, the USBee is similar. These devices are just a USB IO chip like a CY7C68013A-56PVXC, with all trigger and processing logic done in software on a computer. The hardware part is just a datalogger. The top sampling speed is usually around 24Msps (24MHz), if the conditions on your USB bus are just right. They can take ‘unlimited’ samples because everything is stored on the computer. Current models tend to be 8 channels, more channels would reduce the maximum speed proportionately. These are commercial products with highly polished user interfaces, we don’t know of any that are open source.

The Open Logic Sniffer sits somewhere between hobby analyzers and professional analyzers. The OLS samples up to 200Msps, regardless of the USB bus traffic, and has true hardware triggers. The OLS has twice as many buffered channels as most hobby USB analyzers, and four times more channels overall. The major difference is that the OLS has a limited number of samples, while the hobby USB analyzers can theoretically take infinite samples. Most of our debugging is done with the first few hundred samples, so this feature isn’t usually important to our work, your situation may be different. Future versions of the OLS will definitely have more sample storage, and we can work an infinite sampling mode into a future firmware update too.

Our Design

Click for a full size circuit diagram [PNG]. This circuit diagram, maintained by Uwe Bannow, shows the basic elements of the Open Logic Sniffer hardware. The FPGA captures logic samples from 32 input pins into internal RAM. The samples are dumped out a serial port for analysis on a computer. The open source SUMP logic analyzer client is used to capture and visualize the samples.

The FPGA only communicates over a serial port, so we used a USB microcontroller to convert the serial IO to a USB virtual serial port. The entire chain is upgradable through the USB connection. The microcontroller can program updated logic analyzer designs into the SPI flash data chip, and the microcontroller can also be updated from its USB bootloader.

We chose a USB microcontroller over a dedicated USB interface chip. A low pincount PIC was cheaper than most other USB bridge options. It’s USB 2.0 compliant, and can transfer data at up to 12Mbps. We’re using it with the completely open virtual serial port CDC interface, so it will work on almost any platform without proprietary drivers. The PIC can also implement other USB transfer protocols with a firmware update, faster connection methods can be supported when someone adds support for them to the SUMP client software.

Currently the SUMP FPGA design only transfers data over a 115200bps serial UART, the speed between the USB PIC and the computer isn’t a bottleneck. We routed several extra connections between the PIC and FPGA to implement a high-speed SPI interface in the future. The speed increase of an SPI interface can be supported in the SUMP client just by adding higher serial port speed settings.

An FTDI2232 chip was strongly considered as an alternative to the PIC. Here’s how we looked at it:

Benefits of the FTDI2232 with MSSP:

JTAG interface to debug the FPGA

SPI interface to program the ROM

SPI and UART interface to the FPGA

Cons:

Difficult to route

Expensive to place

Huge software development burden

Needs special drivers

USB interface not already supported by SUMP

With so much to accomplish already, major modifications to the client to work with untested hardware and custom drivers didn’t seem appealing. Not if the project were ever going to get finished. The PIC seemed like the best route for the first version.

A Xilinx Spartan 3E field programmable gate array (FPGA) is the central component of the logic analyzer. The FPGA samples data from 16 buffered and 16 unbuffered IO pins, and stores the samples in internal RAM. The samples are later dumped out a serial UART to the PIC, and from the PIC to a computer via USB.

The basic FPGA schematic and PCB layout is taken directly from the Gadget Factory’s Butterfly Platform main board. The OLS shows how versatile the Butterfly Platform is as a development tool. The initial designs where first tested on the Butterfly Platform, and then we used the base design to create a unique, purpose-build hardware based on the prototype. You can get a Butterfly platform to build your own prototypes at the Gadget Factory for $99.

The FPGA (IC3) requires three different power supplies. The core requires 1.2volts and 2.5volts, and the IO pins run at 3.3volts. Each supply pin gets a 0.1uF decoupling capacitor (C11-26). We brought the JTAG programming and debugging connection to a header in the interior of the PCB. The JTAG header provides 2.5V to external JTAG programmers to satisfy the Spartan 3E’s requirements for 2.5V on the dedicated JTAG pins.

Several control and indication signals require special attention. INIT_B enables the FPGA when high, it’s held to 3.3volts with a 4.7K pull-up resistor (R6). The DONE signal goes high to indicate that the FPGA is configured and ready to use after a reset. It’s held to 2.5volts by a 300 ohm resistor (R1).

PROG_B, held at 2.5volts by a 4.7K pull-up resistor (R5), can be pulled low to put the FPGA in programming mode. The HSWAP pin (not shown) determines if all pins have pull-up resistors in programming mode. We grounded HSWAP so that all pins have weak pull-ups when PROG_B is low.

FPGAs are volatile programmable chips, they lose their configuration without power. The FPGA configuration, called a bitstream, has to be loaded into the chip each time it starts. We configured the FPGA to automatically load a bitstream from an SPI ROM chip by wiring the mode select pins as follows: M0(3.3volts), M1(0volts), M2(3.3volts).

The FPGA runs from a 50Mhz oscillator(Q2). This is a complete clock generation module, no external capacitors are required. The 50Mhz clock is doubled to 100Mhz by an internal Digital Clock Manager (DCM) to provide the 100Mhz clock required by the VHDL core.

Two LEDs indicate the FPGA status. The ARM LED indicates when a trigger is set and the device is actively waiting for the trigger. The TRIG LED indicates when a trigger has been activated. We used 390R current limiting resistors (R8, R9) on the prototype, but the assembled board should ship with 1K1 resistors to make the LEDs dimmer.

Buffered inputs

The FPGA IO pins are powered by 3.3volts, and can tolerate no more than a 3.3volt signal. The M74LCX16245DTR2G buffer (IC4) allows 16 buffered pins to sniff 5volt logic and can tolerate voltages from -0.5 to +7V. This chip is also powered by the 3.3volt supply, and it gets a 0.1uF decoupling capacitor (C9) on the supply pin.

Clock/trigger headers

The logic analyzer can sync with other test equipment and should allow OLS’s to be daisy chained together for more channels. It can be driven by an external clock and trigger, and it also outputs its internal clock and trigger. You can tap these signals from the some-what awkwardly placed pin block in the middle of the PCB. The external clock input had to be on an FPGA global clock pin, this was the best possible location to access it because no sensitive high-speed signals were routed across other traces.

Wing header

A wing is an accessory for the Gadget Factory Butterfly Platform development board. It uses a standardized header and pinout. The header has 16bits of 3.3volt IO, and 2.5, 3.3, and 5volt power supplies.

We added a wing header to the OLS so it can use accessories developed on the Butterfly Platform, like a digital sampling oscilloscope. This has the added benefit of making the OLS compatible with a bunch of existing Butterfly Platform accessories.

ROM

The FPGA programs itself with a bitstream stored in a 4Mbit AT45DB041D SPI flash storage chip (IC2), we refer to it as a ROM. We previously demonstrated this chip with the Bus Pirate. It’s powered by the 3.3volt supply, and requires a 0.1uF capacitor (C10) on the supply pin. The XC3S250E bitstream will fit into a 2Mbit flash chip, but only 4Mbit chips were available when we sourced parts.

The ROM chip has an SPI interface that connects to the FPGA, the PIC microcontroller, and an external programming header.

The FPGA mode select pin configuration causes the FPGA to load a bitstream from the ROM chip. When the bitstream is finished loading, the DONE signal goes high, and the FPGA is programmed and active.

The PIC can (re)program the ROM with updated bitstreams. The PIC holds the FPGA PROG_B line low in this mode so the FPGA releases control of the ROM chip.

The external header can be used to program the ROM from a programmer. Place a jumper between the PGM and EN pins to manually place the FPGA in programming mode.

Provides a USB->serial connection from the SUMP Java client to the SUMP hardware in the FPGA

Puts the FPGA in programming mode and updates the ROM with a new bitstream

A USB bootloader can be used to update the PIC firmware

The 18xxJxx chips are really interesting, and seem like a hybrid of the 24F and 18F families. This PIC has the instruction set and 8bit core of the 18F family, but many enhanced features of the 16bit PICs. Half of the UARTs and SPI modules are assigned with peripheral pin select, it has flash configuration words, and it runs on 3.3volts, like a 16bit PIC.

The PPS features are really handy and make the clean layout of the PCB possible. The ROM SPI connection and FPGA UART connection are both assigned to custom pins with PPS. PPS can be used to implement a high-speed (10Mbit+) SPI connection between the PIC and FPGA in a future firmware upgrade.

The PIC is powered by 3.3volts, the supply pin gets a 0.1uF capacitor (C7). The USB peripheral has a separate 3.3volt supply pin that also needs a 0.1uF decoupling capacitor (C8). A 10uF capacitor (C4) is required for the internal 2.5volt core supply regulator.

An external oscillator provides an accurate USB clock, we used a 20MHz crystal (Q1) and two 27pF capacitors (C5, C6).

A 10K resistor (R3) holds the PIC reset pin high for normal operation, the RESET button (S1) grounds it to cause a hard reset. A second button (S2, R4) is available for simple user input.

The LED ACT is a general purpose indicator LED controlled by the PIC through current limiting resistor R7. The PWR (power) LED is connected to the USB supply though current limiting resistor R2, it illuminates whenever the board is powered.

We also brought the one of the hardware UARTs to a header. The pins are 5volt tolerant, and can be interfaced at up to 5volts without damaging the PIC. This header can be used for a ‘classic’ serial port connection. The board can also be powered through the UART header supply pins.

Power supply

The board is intended to be powered by the 5volt supply from a USB port. Three regulators provide the three supply rails required by the circuit. All the chips require a 3.3volt supply (VR1), the FPGA also requires a 1.2volt (VR3) and 2.5volt (VR2) supply. As recommended by the datasheet, there’s a 10uF capacitor (C27) on the supply line, and each regulator has a 1.0uF capacitor (C1-3) on the output pin.

Numbering

The OLS has two different numbering schemes, one on the inside of the board and one on the outside of the board. The inside numbering scheme starts with zero on the buffered header. The outside numbering scheme starts with zero on the Wing header. Currently the numbering scheme can be selected by loading a bitstream that implements either numbering scheme. Future updates will support selecting the numbering scheme through the Java Logic Analyzer client.

The PCB is nearly the maximum allowable size in Eagle. All the components are surface mount, but we stuck with traditional through-hole headers. It took us an hour or two to solder each prototype board by hand.

We had boards made with the $50 Seeed Studio Fusion board service. This design probably would have been ready a bit sooner, but the PCBs were delayed about a month by the major Hong Kong Post Christmas mail rush.

Partlist

Click for a full size placement image [PNG]. Uwe Bannow generously provided parts for the OLS prototypes. An extra special thanks to Uwe, his help was key to making this project what you see today.

The OLS uses the open source (GPL) SUMP logic analyzer VHDL design. It’s synthesized with the free Xilinx ISE Web Pack tool suite. Our design is based on Jonas Diemer’s Spartan 3E SUMP port [ZIP]. The following modifications were made for the OLS hardware:

A new ucf (User Constraint File) was generated to map the pins of the FPGA to the layout of the OLS board and to support multiple numbering schemes.

Support for outputting the sample clock to an external pin was added.

Support for adding an external pin as a trigger was added.

Added support for Trigger and ARM LED’s.

Files for multiple BRAM memory configurations were added. The files were generated with the Xilinx Core generator and are Xilinx specific.

Memory

The OLS utilizes BRAM (Block Ram) that is embedded inside the Spartan 3E FPGA, the included XC3S250E chip has 216K of BRAM available. There are six bitstreams that allocate the available memory into different combinations of memory depth and sampling channels. Currently the following memory/channel configurations are available:

32 channels with 4k sample depth.

16 channels with 8k sample depth.

8 channels with 16k sample depth.

You may have noticed that the above numbers don’t add up to the 216K of BRAM that is available. With 8 channels we should be able to get 216k/8 = 27k samples. The first issue is that the published size of 216K of BRAM includes parity bits, without parity bits we actually have 192K of BRAM available. The second issue is that the Sump design is setup to require a power of 8 for its sample depth, so until the Sump design can be modified we are stuck with the above power of 8 sample depths. Once these two issues are resolved the possible memory/channel configurations will be:

32 channels with 6k sample depth.

16 channels with 13k sample depth.

8 channels with 27k sample depth.

Our future design plans do include working on adding 32-64Mb of SDRAM memory.

Bitstreams

The output of the Xilinx Webpack synthesis tools is a bitstream file that is used to configure the FPGA. We convert the bitstream (*.bit) file to an Intel Hex format (*.mcs) using the Xilinx Impact application. The bitstream is then loaded, by the PIC, into the Atmel SPI Flash chip. When power is applied to the OLS the FPGA configures itself by loading the bitstream from the SPI Flash chip.

There are currently six different bitstreams that provide for 3 different memory configurations and 2 different numbering schemes. Currently, the bitstreams have to be loaded with the pump-loader executable. Future revisions will load the desired bitstream from the Java Logic Analyzer client. The current bitstream options are:

32 channels with 4k sample depth, inside numbering scheme.

16 channels with 8k sample depth, inside numbering scheme.

8 channels with 16k sample depth, inside numbering scheme.

32 channels with 4k sample depth, outside numbering scheme.

16 channels with 8k sample depth, outside numbering scheme.

8 channels with 16k sample depth, outside numbering scheme.

RLE

Run Length Encoding (RLE) helps make the most efficient use of available memory. With RLE enabled memory is only filled when there is activity. If there is a period of inactivity it is represented in memory with a value instead of a large block of empty space. A practical example would be with capturing UART data. In many cases there is a burst of continuous activity while an 8 bit character is sent across the channel, but then there will be a very long period of inactivity before the next character is sent across the channel. Without RLE the available memory would quickly be filled up with empty space and you would only be able to capture one or two characters. With RLE only the activity is captured and the long pauses in between characters is represented with a value that indicates how long the pause is instead. This allows many more characters to be captured. RLE was added to the SUMP VHDL design by Jonas Diemer when he released a BRAM based design. RLE has worked very well with simple waveforms but needs further testing with more complex signals like the UART example outlined above.

Sampling

OLS supports sampling rates from 10Hz (10sps) to 200Mhz (200Msps) and has been able to capture perfect, generated waveforms up to 100Mhz. As a general rule of thumb you need at least twice the sampling rate of the waveform you are capturing. If you are trying to capture a 100Mhz waveform then you need a 200Mhz sampling rate, if you are trying to capture a 50Mhz waveform then you need a 100Mhz sampling rate. In practice this rule of thumb does not always hold up, some sources advise having at least 5 times the sampling rate of a captured waveform. In our tests with repeating, simple, perfect waveforms we have been able to use the twice the sampling rate rule of thumb.

We have seen that the results with the unbuffered 3.3V pins are better at higher speeds than the 5V buffered pins.

Triggering

The Sump VHDL core supports simple and complex triggering on all available channels. Complex triggering supports 4 stages of parallel or serial triggering. Triggers can be configured with how much of the waveform is captured before and after the trigger. A trigger ratio of 50/50 puts the trigger in the center of the captured waveform.

Simple triggering supports a Mask to indicate which channels to trigger on and a Value to indicate whether to trigger on a ‘1’ or ‘0’. Click on the image above to see how a trigger can be configured to trigger on a value of ‘1’ on channel 0.

The Sump VHDL core is driven by the external 50Mhz oscillator or an external clock connected to the CKI pin, the desired clock can be selected in the Java client. The default is to use the 50Mhz clock which is doubled internally to 100Mhz by one of four Digital Clock Managers (DCM). This 100Mhz clock is labeled as Internal in the Sump client options dialog. The external clock is connected without modification to the sampling section and the Sampling Rate option will be disabled.

When the Internal clock is used the sampling rate can be set from 10Hz up to 200Mhz. When 200Mhz is selected a Double Data Rate technique is used and the signal is sampled on both the rising and falling edge of the 100Mhz clock. In this mode the amount of available channels is cut in half to free up memory for the additional samples. For example, if the bitstream is configured to support 32 channels with 4k samples of memory then there is a 4k block of memory that is 32 bits wide allocated within the FPGA. Each channel corresponds to one of the 32 memory bits and is 4k deep. When 200Mhz is selected twice the amount of memory is required to store the samples, so in order to keep the 4k deep sampling space the available channels would be reduced to 16. The bottom 16 bits of memory store the samples at the rising edge and the top 16 bits of memory store the samples at the falling edge.

Proposed Changes

Changing the design to support all available BRAM memory.

There is a SRAM and a BRAM memory interface available, integrating a SDRAM controller is desirable since SRAM is much more expensive than SDRAM.

Replace the UART controller with a SPI controller to enable USB speeds up to 12Mb/s.

Add a register to indicate the memory depth, amount of supported channels, and numbering scheme of a bitstream. The Java client could then query the register and give a visual indication of what numbering scheme, how many channels, and amount of memory that the bitstream currently running on the FPGA supports.

We used Microchip’s free, but non-distributable, USB stack source code to provide USB support in this project. To compile the firmware you need to download the USB stack source directly from Microchip, then follow the directions at the top of main.c in the OLS source code. A major goal of this project is to create an open source virtual serial port code base to replace the non-distributable Microchip USB stack.

The PIC is the interface glue for the circuit. It has three operating modes:

Normal – a serial port to USB bridge for the SUMP logic analyzer

ROM Updater – upload a new FPGA bitstream to the ROM chip

Bootloader – update the main firmware in the PIC

Normal mode

The PIC usually operates in a transparent USB-> serial bridge that connects the SUMP build in the FPGA with the SUMP client on a computer. This is the default startup mode after a reset or power-up. Press the reset button to enter normal operating mode from any other mode.

After a reset, the ACT LED will blink while the FPGA loads the bitstream contained in the ROM chip. If the FPGA doesn’t load after a few seconds, because of an error or blank ROM chip, the PIC will automatically enter ROM update mode and the ACT LED will illuminate (see ROM updater below).

The ACT LED will turn off when the FPGA is configured and ready. The OLS then enumerates as a USB virtual serial port device. The first time you plug it in, you may need to feed Windows the .inf file in the project archive to assign driver to the device.

Once enumerated, the ACT LED blinks to indicate any USB activity.

ROM Updater

ROM updater mode is used to program a new FPGA bitstream into the flash storage chip.This feature lets us release FPGA design updates that can be loaded over the USB interface.

To enter ROM update mode, press the reset button while holding the update button. The PIC will also automatically enter ROM update mode if the FPGA doesn’t load correctly because of an error or blank ROM chip. The ACT LED will light in this mode.

The OLS enumerates as a USB virtual serial port in ROM update mode, this is the same connection type as the normal operating mode. The first time you plug it in, give Windows the .inf file from the project folder to assign the correct drivers to the device.

Use the pump-loader console utility for Windows, Linux, or Mac to load the updated FPGA bitstream. There’s also a pump-loader.pl Perl utility that we used during initial development.

ROM update procedure

Press the reset button while holding the update button.

The ACT LED will light and the OLS will enumerate as a USB virtual serial port.

We used the Diolan open source (GPL) USB bootloader in this project. The bootloader appears as a USB HID device, and a small utility uploads a new firmware to the PIC. We started with the bootloader source from the Dangerous Prototypes’ USB Infrared Toy and ported it to the 18F24J50.

The Diolan bootloader is intended for the PIC18F2550 family of USB PICs. We had to make several modifications to get it working on the 18F24J50:

Changed the configuration fuses

Added clock switching and PLL startup delay

Added register bank switches, where required.

Changed sleep mode to idle for 18fx4J50 PLL system

Changed page write (64bytes) to word write (2bytes)

One of the big issues we encountered with the port was a difference in flash page write size between the regular and ‘j’ PICs. The Diolan bootloader supports PICs that write flash memory in 32byte chunks (pages). The ‘j’ chip writes flash in 2byte or 64byte chunks. The bootloader is designed to send an entire page worth of data in a single USB HID packet. HID packets are 64bytes long, once you include a few bytes of header there’s not enough room in a single HID packet to transfer 64bytes of data to write to the flash memory.

Our quick solution was to take advantage of the 2byte word write mode and make a custom compile of the Diolan utility that sends only 2 bytes in each HID packet. This slows down the update because most of the USB HID packet is wasted. It would be far faster to use the 64byte write mode and send 64bytes of data over two HID packets with a flush flag in the second. We hope to improve this with a new upgrade utility, the functionality is already supported in the bootloader firmware.

If you’re working with a fresh chip, program the bootloader into the PIC using the 5pin ICSP header. You’ll need a PICKIT or ICD programmer to load the bootloader the first time.

Enter bootloader mode by placing a jumper between PGC and PGD pins and press the reset button, or run the pump-loader utility with the -b flag. The ACT LED will light when the bootloader is active. Use the fw_update.exe utility to load new PIC firmware with the bootloader.

Firmware update procedure

Place a jumper between the PGC and PGD pins of the ICSP header.

Plug in USB. ACT LED lights. Bootloader enumerates as an HID device.

Remove the jumper. If you remove it now the bootloader will reset into user mode automatically, if not it will just return to the bootloader.

A future hardware revision may include SRAM or a bigger FPGA chip to store more samples.

Get one!

You can get the assembled Open Logic Sniffer hardware for $45, including worldwide shipping. Seeed Studio is accepting preorders now, the hardware should be manufactured by March 31, 2010.

If you’re interested in FPGA development and designing your own prototypes, check out the Butterfly Platform we used to develop the Open Logic Sniffer. You can get the Butterfly Platform at the Gadget Factory now for $99.

Your support made this open source project possible. Thanks to everyone who contributed to this project with suggestions, advise, or by making a purchase. We couldn’t do it without you.

Comments

A shipped OLS is one-third the price of the Saleae (before shipping), but it doesn’t include a case, probe cable, or carrying case.

Saleae (and similar) devices are 24MSPS USB dataloggers with logic analyzer software. The top speed is limited by the USB bus conditions, if you’re running a debugger or something the top speed is much lower. The OLS will sample many times faster (200MSPS), and doesn’t rely on the USB bus speed.

A Saleae type device can take ‘infinite’ samples because they’re stored in the computer, OLS is limited by internal RAM. I only use the first few hundred samples in most of my debugging, but there are applications where long-term datalogging is more useful.

The SUMP client does have a few protocol analyzers and other professional features, but it’s not as flashy as the Saleae software (yet). Saleae has done a fantastic job with his interface, I believe the USBee people sell (or used to) their application in bits (certain features cost extra).

Saleae-like devices usually have 8 channels, the OLS has 16 buffered and 16 unbuffered channels.

The OLS is open source hardware, open firmware, open interface protocols, and a multi-platform open source Java client. As far as I know, the Saleae and USBee are both closed source and rely on proprietary system drivers for the USB chip.

I tend to refer it to it as the Open Logic Sniffer for short. Articles are always kind of a core dump about the process and design, we tried to be consistent but you never know what’s going what going to pop out during the process :)

“Buffered” channels means that those 16 I/O pins of the FPGA are connected via a transceiver chip (used as an unidirectional input buffer!) with the header.

“Buffering” allows sniffing of 5volt logic and is tolerant for voltages from -0.5 to +7V and inputs only while the 16 unbuffered lines can be used for max. 3.3V logic and as inputs and outputs. See “Buffered Inputs” above for more details.

Congratulations to Ian and Jack for putting this project together and making it available for purchase in such a short time! There is a lot of is a lot of unexplored potential in the Open Logic Sniffer design … :)

You need a minimum of 2 times the maximum signal frequency in order to avoid aliasing.

Since this is a logic analyzer, all you care about is if the signal is high or low. This means that a 2x sample rate is fine.

If this were an oscilloscope, then you would also care about the exact curve the signal takes over the course of a cycle. Therefore, in that case you’d need a sample rate that is higher than just 2x the maximum signal frequency (oversampling). If you used a 2x sample rate for an oscilloscope, you wouldn’t be able to see any jitter in the signal.

I find it amusing how the actual meaning of the Nyquist rate has been garbled over the years, it states: To avoid aliasing a signal must be sampled at at least twice the highest frequency component frequency present in the signal, this only ensures that the signal can be reconstructed not even that your samples resemble the sampled signal when doing a plot.

Applying this principle to digital signals is utter rubbish, remembering that a time limited signal cannot be band limited a square wave is composed out of an infinite number of frequency components and can never be perfectly sampled.

Sampling a digital signal at twice the signal frequency ensures that we don’t miss a high or low period (assuming a 50% duty cycle), the sampled signal isn’t guaranteed to be in phase or even the exact same length as the real signal.

As for alexe’s comment about a 2x sampling rate not being enough to detect jitter this is way off, the Nyquist rate should include the jitter frequency and thus capture it perfectly. In practice sampling at more than twice the highest frequency component frequency is needed because of non ideal filters in reconstructing the signal etc.

Any thought on adding RAM to this for buffering? Even if it’s just some empty pads on the board to add a SRAM or SDRAM. opencores.org has a few RAM controllers for DDR and non-DDR variants that would keep with the “as open source a possible” rule and this would allow full transaction capture at the full sample rate.

Mine just arrived a few days ago. Tried out capturing some UART traffic going to my OMAP3530 Beagle board. The SUMP doesn’t recognize the 115K UART baud rate. Maybe a newbie user error. The SUMP is a really nice interface. Very happy with the purchase. Thinking now of getting the Bus Pirate.

Only negative was that I read somewhere that cables were included. OK, so I ordered some.

I really, really, really want to order one of these! The price is amazing!
Question: Is the SUMP logic analyzer the only software that can be used with this OLS? Is there any other logic analyzer program that supports the architecture of the OLS? Just wondering, although I see nothing wrong with the SUMP tool.

Back in the late 70’s, I did a lot of logic circuit debug using big, heavy 8-channel Biomation logic analyzers (model 8100-D?). They used 8 scope-style probes and had a separate Tektronix CRT tube display on which the recorded traces were shown. Basic 1-level triggers. Those were the days!

The sigrok project is working on a multi-platform client that supports the Logic Sniffer and a bunch of other analyzers. There’s also a Windows/.Net app in the forum that supports the Logic Sniffer protocol.

XILINX has long been noted for lack of parts in certain lines. They introduced the 500E in a VQ100 package and now it is difficult at best to find them in small quantities. If you want 100,000 pieces then X will bend over backwards to get you them. 50 pieces, we can’t be bothered with such small quantities. I was hoping that the XC6SLX9 LFQFP144 package would be available by now. That and the XC6SLX4 are the only parts listed in a QFP package. I really wonder what is going on in Corporate Headquarters for XILINX.

Forgive me for being noob about these things – I don’t have immediate need for LA but could see the need in future. What I’d like to know is could USB3 even theoretically enable much higher perf, comparable to this project, USB IO style capture with unlimited logging?

Is there a “how to” somewhere I can’t seem to find on how to get this thing setup step by step? I am kinda clueless apparently, and would really like to get this thing going, Win7 just refuses to find a driver for it.

I was following the “directions” on hackaday in their youtube vid to download and install the linux version of your logic analyzer software, I tried searching gadget forge, and don’t see any linux install or downloadable linux .gz files, where might I find these?

Hi – SUMP is an open source Java app, we didn’t write it, though Jack occasionally makes some updates. I’m not sure where the latest Linux version is, you can probably find more at the SUMP project homepage here, or on sourceforge.net:http://www.sump.org/projects/analyzer/client/

I’m sorry for being such a pain, I really want to get this thing up an running, but the link above is the link to the analyzer, but oddly enough, there doesn’t appear to be a download link, I see that I’ll need that rxtx program to just get access to the “serial” ports.

Are you aware of a “how to” for apparently clueless people (which I must be)?

I have a windows setup on my netbook which I think I could get working, the problem is that the window isn’t resizable, so I can’t click capture, so I’m forced to use my linux box to try to get this work.

I’m a tad confused how the 32 channels works, looking at the board I see one row of pins and on the actual board above them, it has the numbers 0-15 and also 16-17, but there are only one set of pins, I might be having issues counting, but I’m not sure how I can actually use all 32 channels (if needed) at once. I am assuming maybe depending on which ground you use? Is this explained somewhere?

thanks Ian
Just dream of usb2 sniffer in around $100 mark. but just a dream i will save up :)
would you or anybody here know of a usb1or2 sniffer other then beagle usb. i am looked at the “zeroplus logic cube” but i like open source if possible.
Thanks

FPGA which one?..
something like “Kitty USB Protocol Analyzer” USD$ 875.00 is bet expensive. i need something to analyze in this situation (A-blackbox) -> (B-Analyzer) ->(C-plug&playDevice). where Analyzer will bridge A&C and ether store communication or send it to a D-computer.
any leads or forums ..etc
maybe this is not the best place to ask… let me know
Thanks,

This is cool! I found it when I was looking for cheap logic analyzer. I think I’ll buy one!

My fist idea was to build (because everything need windows or is expensive; over $250 and i’m Mac/Ubuntu guy) something similar as DIY project using PIC24FJ128GB206 — 9 input capture channels (with many triggers/sync modes), USB and 96kb of RAM. Input capture can detect rising and falling edge and it stores timestamp (16 bit value from a counter) which is sort of RLE for free :) and there is no need to choose the sampling frequency but signal frequency is limited to ~10MHz (CPU is 32MHz). I see a way how to achieve almost unlimited number of samples and channels (but everything needs to be done the PC side…)

i became aware of OLS yesterday, and besides the missing memory it looks just awesome, thumbs up!
i did not order yesterday, which was an error: there were 5 or so left at seeedstudio, not they are out of stock. also the european sparkfun distris are sold out. are there any sources right now (important: low delivery costs to EU)? i read in the forum (http://dangerousprototypes.com/forum/index.php?topic=1491.0) that 1000 new units are getting tested. any ETA on that?
thanks!

I’m still a student and completely new to fpga. I wanted to make sure whether I can use Openbench as a normal fpga board. I had a look at the schematic where the WINGA* pins were connected to Bank 1 IO_L* pins. I was also thinking of buying some other fpga board and making it work as a logic analizer. If you have any suggestion of another board with more outgoing pins, you can also tell me. However, as of yet I found no other project which would be more time and money saving.

Here’s an idea for a additional front end for the OLS: take say 8 input signals, and apply RLE to them, generating a 16-bit signal (8 data + 8 counter since last change). This would support even higher rates, but more importantly it would be able to store more events. Only restriction would be that the average rate of changes is within what the OLS can capture. Such a front end would work with any logic analyzer – you basically just have to sacrifice a few data bits for a RLE counter. One benefit of very fast sampling is that it lets you analyze glitches and uneven propagation delay problems.

ISO 9141-2. This protocol has an asynchronous serial data rate of 10.4 kBaud. It is somewhat similar to RS-232; however, the signal levels are different, and communications happens on a single, bidirectional line without additional handshake signals. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.

Why did you decide to record every clock cycle to store the captured data? Why not have a 32 bit counter and comparator and store only after a change have been detected each cycle? That way you can make better use of the limited memory on the FPGA. In the worst case, if the signal changes every cycle, you will cut your recording length by 50%. But in the best case, you will have (2^32)-1 times longer recording length.

Hi there,
I’ve run into buying Logic Sniffer Analyzer from Seeedstudio and now wondering if I have bought everything I need.
My intention is to sniff not just 3.3V signals but 5V as well. My question is:
1) Standard product (50USD) comes with 16 buffered inputs which are 5V tolerant with headers present on pcb ?
2) On PCB there are another 16 input/outputs which are not 5V tolerant and can act as inputs or outputs as well – headers not present on pcb ?
3) If I want to have this additional 16 inputs to be 5V tolerant (wing side of pcb) I need to buy Buffer Wing?
4) If I want to sniff some signal which comes and goes occasionally it is possible to configure LSA to shiff only when signal is present and this way I can have recording length extended for significant persent?