If you’re just getting into hobby electronics chances are there are lots of tools you’d like to get you hands on but can’t yet justify the purchases. Why not build some of the simpler ones? Here’s a great example of a 4-channel logic analyzer that can be your next project and will add to your arsenal for future endeavors.

As you can see, [Vassilis'] creation uses a cellphone-sized LCD screen as the output. It is powered by four rechargeable batteries and driven by an ATmega8 microcontroller. He’s designed the tool without power regulation, relying on the ATmega’s rather wide range of operating voltages, and a few diodes to step down that voltage for the LCD screen.

As you can see in the clip after the break, alligator leads can be used to connect the test circuit to the inputs (don’t forget the ground reference!). Thee buttons at the bottom let you navigate the captured data by panning and zooming. Perhaps the best design feature is the single-sided circuit board which should be quite easy to reproduce at home.

[via Dangerous Prototypes]

Despite what this module says on the case, it’s certainly not official Saleae Logic Analyzer hardware. [Jack Andrews] picked up this Chinese knockoff on eBay for about $18. When plugged into the computer the Saleae software picks it up as the official hardware. But [Jack] has seen other knockoffs which have a jumper to select between Saleae cloning and USBee cloning so he found a way to switch software with this dongle.

He pulled the board out of the case and discovered a Cypress CY7C68013A microcontroller on a poorly-soldered board (imagine that). This is an 8051-compatible processor that includes USB functionality. There’s also an EEPROM on the bottom of the board which stores the VID/PID pair identifying it as Saleae Logic hardware. The trick to getting this working with the USBee software is to change that pair. [Jack] managed to do this without an external programmer. He uninstalled the Saleae driver and installed a Cypress driver. Then he wrote a bit of code for the CY7C68013A to rewrite the EEPROM and flashed it via the USB connection. Now the dongle enumerates as USBee Logic Analyzer hardware.

One thing we learned by watching [Alton Brown] on all of those Good Eats episodes is that a multitasker is way better than a unitasker. [Joost] is thinking along the same lines by taking a fantastic tool and adding a useful function to it. His software project turns a USB Saleae Logic Analyzer into a signal generator.

There are already a multitude of reasons to own one of these fantastic tools. But the ability to use it to generate up to 8 channels of PWM signals is a welcome addition. It is capable of producing frequencies from 1Hz up to 1MHz at a sample rate of 4 MHz. It uses the original SDK and doesn’t require any changes to the hardware (we would’ve thought new firmware was necessary, but happily that’s not the case). The one caveat is that right now this only works with Windows machines running the .NET version 3.5 or higher. It looks like an MSI installer package is all that’s available for download so the thoughts of easily porting this to other operating systems have been dashed unless [Joost] decides to share his source code.

[Craig] wanted to make the original Game Boy LCD screen do his bidding so he sniffed out the data protocol that it uses. We were amused when he mentions that there’s an army of people out there looking to build pointless crap as part of a hobby. Guilty. And he goes on to outline why this LCD screen is a great resource for hobbiests.

As you can see in the pinout above, it uses 5V logic, with a 4 MHz data clock. These traits are both very friendly to a wide range if inexpensive microcontrollers. If you know how to address the display it should be very easy to use. Furthermore, the low pin count is thanks the to a 4-shade grayscale screen, limiting the data pins to just two. [Craig] hooked up his Saleae Logic probe to capture communications and walks us through what he discovered. During this process he proved to himself that he had figured out the protocol by exporting captured data from the logic probe and reassembling it into an image on his computer.

[Christian Weichel] has been hard at work developing LogicAnalyzer, an open source tool that may interest you. It is designed with SUMP Logic Analyzers in mind but a main goal is expandability. What this means is that it plays nicely with things like the Open Workbench Logic Sniffer or you can do a bit of fiddling to get it to work with your own designs. The program is based on Eclipse so you should be familiar with how it works and you can get it running easily on multiple platforms. Take a look at the wiki for a quick start.

The Superprobe is a logic analyzer, multimeter, and much more rolled into a fun to build project. [Ben Ryves] didn’t come up with the original idea, but he definitely took a good thing and made it better. You can use it to test logic, inject logic into a circuit, read capacitors and resistors, test frequency, read the device address from 1-wire devices, and more. Interchangeable probes, choice of internal or external power, simple two-button operation, and a powerful PIC microcontroller at the heart of it all make this a fantastic tool for your electronics workbench. Check out the quality video after the break that  [Ben] put together to show off the results of his tinkering.

If you’ve got a graphic LCD lying around you can build this four-channel logic analyzer with a couple handfuls of cheap components. [Ronald de Bruijn's] design uses a PIC18F4580 to sample up to four logic inputs at a maximum resolution of 2 MHz. He’s included the PCB artwork so that you can etch your own board. Having a logic analyzer around can really make your life easier, allowing you to reverse engineer communication protocols and troubleshoot your own design problems.

[Thanks Juan]

Hackaday alum [Ian Lesnet] has been working in cahoots with a dedicated team of developers to produce the OpenBench Logic Sniffer. This caseless logic analyzer can operate at 100MHz and sample 32 channels at once. Better yet, a digital oscilloscope add-on is in the works. The pre-order comes in at $45, that’s a lot of functionality for just a few greenbacks. We’ve embedded a demo video after the break that details installing and using this device under Ubuntu.

[Thanks Drone via Dangerous Prototypes]

[Oliver] received the Telly Terminator as a gift and decided to take a closer look at it. This key fob has two buttons; one shines an LED like a flashlight and the other turns off televisions. Sound familiar? Yeah, it made [Oliver] think of the TV-B-Gone as well.

He cracked open the case to find just a few components. The brain behind the IR signals is a Helios H5A02HP. Only a few pins are used for outputs so he connected a logic analyzer and recorded the signals. His writeup covers the process quite well. He takes a known IR transmitter protocol and compares it to the capture from the logic analyzer. It turns out that the fob generates 46 different signals and with further analysis concludes that there’s a chance the code used here is from an older version of the TV-B-Gone source.

Hackaday alum [Ian Lesnet] tipped us off about some reverse engineering of the HVR-1600, an analog and digital television encoder/tuner. The project was spawned when [Devin] noticed his Hauppauge HVR-1600 didn’t tune channels in Linux quite as well as it did in Windows. He had a hunch this was due to improper initialization settings for either the tuner chip or the demodulator.

To fix this he used two test points on the board to tap into the I2C bus. Using a logic analyzer he captured the command traffic from the bus while running Linux, then while running Windows. By filtering the results with a bit of Perl, and comparing them by using diff, he tracks down and finds the variation in the commands being sent by the two drivers. After a bit of poking around in the Linux source and making the necessary changes, he improved the tuning ability of the Linux package.

[Devin's] work looks simple enough, and it is. The difficult part of this process is being smart enough to know what you’re looking for, and what you’ve got once you’ve found it.

[Jack Gasset] sends in the logic analyzer he’s been working on. The logic analyzer boasts an impressive array of features, it can sample 32 channels at 100MHz, 16 channels at 200MHz, SPI, UART, I2C and more. The analyzer’s maximum sample size is 4K for now, and it supports RLE to reduce the memory consumed. The analyzer connects to a java client on a standard PC via USB. The open source hardware based on a Xilinix FPGA can be purchased pre-assembled for $100 which makes it a direct competitor for the Salea logic analyzer we reviewed earlier this year.

A logic analyzer records bus communications between two chips. If you’ve ever had a problem getting two chips to talk, or wanted to reverse engineer a protocol, a logic analyzer is the tool you need to spy on the bus.

The Logic is a USB logic analyzer with eight channels and sampling rates up to 24MHz. Among hobby-level logic analyzers, the Logic has a good mix of features and decent sampling rates. We’ve been following Joe Garrison’s work on the Logic for a long time. If you’ve ever considered bringing a product to market, you can learn a lot from Joe’s blog that documents his development process.

When it debuted, the Logic was so popular that it was hard to buy one. It’s now widely available, and Saleae gave us one to try. Read our review below.

Logic Analyzers vs. Oscilloscopes

Most modern electronics projects will benefit more from a logic analyzer than an oscilloscope. An oscilloscope displays a graph of an analog voltage as it varies over time, such as the curve of a sine wave. A logic analyzer only detects high and low digital states, but it records many signals simultaneously. Logic analyzers dump data to a computer for analysis, very few oscilloscopes have this feature.

What you get

The Logic comes packaged in an external hard drive case. The analyzer is a small, anodized aluminum puck with laser etched signal markers. It’s much smaller than we expected, slightly smaller than a compact flash storage card. A mini-B USB cable is included.

A heavy-gauge cable and nine E-Z-Hooks (5 shown) connect the Logic to a circuit. The hooks are a really nice touch; press the back of the hook to expose a pair of tweezers, grab onto a signal wire, and retract to hold it in place. The retractable tweezers prevent accidental shorts on cramped test circuits.

Software isn’t included, instead you get instructions to download the latest version from the Saleae web site. We always download the latest software, so we appreciate that there’s one less CD headed to the landfill.

Right now, only Windows XP/Vista software is available, but Mac and Linux software should be ready soon. Warning: the Windows version requires .NET 3.5, download the redistributable off-line installer if you don’t want to give internet access to Microsoft’s online installer.

Using it

Using the Logic is simple. Connect the gray ground wire to the ground of the test circuit, then hook into the signal lines you want to record. We connected it to the 32K SPI SRAM that we demonstrated earlier this week. SPI has four important signals; enable, data in, data out, and clock. The E-Z-Hooks make it dead simple to tap into the signals without accidental shorts.

Be mindful of wire orientation. We associate a black wire with ground, but the Logic cable uses gray. Comments on SparkFun’s product page suggest that reversing the connections will damage the Logic.

The software analyzes and displays signal captures. The primary configuration options are the sampling rate (200KHz-24MHz) and number of samples (millions to billions). We were able to sample at 24MHz, but the top speed depends on how much other stuff is using the USB bus. A 24MHz sampling rate can capture signals up to 12MHz, we found this suitable for all the protocols we use. The total number of samples is limited only by the available PC RAM.

There’s a four level trigger that watches the signals, and waits for a specific combination before it starts recording samples.  Since we’re analyzing SPI, the most logical place to start capturing is when the SPI enable signal drops at the beginning of a bus transaction. We set the Logic trigger to start sampling when SPI enable is 0 by changing its trigger to ’0′.

We really like the profiles that decode most common serial protocols; 1-Wire, I2C, SPI, and asynchronous serial.  CAN and other protocols will be added eventually.

Profiles suggest names for each signal, and convert squiggly lines into readable byte values. This is a really awesome feature. Without it, you’d have to count clock pulses to identify byte boundaries, and then manually decode the values.

This transaction shows the host issue the read configuration register command (0×05), and the SRAM response (0×41).

We also tried the 1-Wire decoder with a DS2431 EEPROM. The software identified the 1-Wire reset command, and the 1-Wire ‘search rom’ command (0xf0).

A look inside

The Logic is based on the Cypress Semiconductor CY7C68013A-56PVXC, an Intel 8052 microcontroller with a USB peripheral. The 8052 is an enhanced version of the well-known 8051. We can also identify a 24MHz crystal, which is probably multiplied to 48 or 96MHz by an internal phase-locked loop.

Conclusion

Logic analyzers take the guess work out of debugging inter-chip communication. If you can’t see what’s going on, the best you can do is guess about the problem. When a project won’t work, 99% of the time we can solve the problem immediately by looking at the signals with a logic analyzer. Without it, there’s no easy way to know what’s happening.

The Logic records 8 channels at 24MHz. The Windows software has useful features, and there’s an SDK if you want to write your own apps. Linux and Mac versions are under development. We really like this logic analyzer, and plan to use it to illustrate future articles.

The Logic is $149 at the Saleae website and SparkFun, and Joe is working on EU distribution. If you’re interested in the Logic, but aren’t ready to buy, you can download the software and try it in demo mode.

Hack a Day review disclosure: We asked for a Logic and Saleae sent it to us

Now that we listen to MP3s, and watch XVIDs or x264s, a computer is the entertainment center in at least one room of most homes. Unless you have a special HTPC, though, you’re probably stuck using the keyboard to pause, change the volume, and fast-forward through annoying Mythbusters recaps. PC remote control receivers range from ancient serial port designs (who has one?) to USB devices not supported by popular software. In this how-to we design a USB infrared receiver that imitates a common protocol supported by software for Windows, Linux, and Mac. We’ve got a full guide to the protocol plus schematics and a parts list.

Design overview

Remote controls transmit data on an modulated infrared beam. An infrared receiver IC separates the modulated beam into a clean stream of 0s and 1s. The data stream is decoded by a microcontroller and sent to a computer over a USB connection. Software processes the codes and triggers actions on the computer.

Background

Computer infrared receivers

The oldest PC infrared receiver design uses a receiver IC to toggle a serial port pin, usually DCD. This design probably originated on Usenet, and it’s still the most popular on the web: Engadget, Instructables, etc. These aren’t true serial devices because they don’t send data to the PC. Instead, a computer program times pulses on the serial port and demodulates the signal. This is a super simple design, but it depends on direct interrupt access and timing precision that’s no longer available in Windows. Linux or Mac users can try this receiver, if you still have a serial port. We couldn’t get this type of receiver to work with the serial port on a modern Windows XP PC, and don’t expect the precise timing to transfer through a USB->serial converter.

Some more advanced infrared receivers are true serial port devices that measure or decoding infrared signals before sending data to the computer. The UIR/IRMan and UIR2 incorporate a classic PIC 16F84, but don’t provide firmware and/or source code. These devices should work on a modern computer, through a USB->serial converter if necessary. The USBTINY and USBIRBOY are native USB devices, but lack wide support.

Receiver software

Regardless of receiver type, the computer needs a program to listen for incoming remote commands and convert them to actions on the computer. Linux and Mac users have LIRC, which supports a bunch of different receiver types. Windows users are a bit less fortunate. WinLIRC is an abandoned Windows port of LIRC for simple interrupt-based serial port receivers; WinLIRC was last developed in 2003. Girder was originally a freeware PC automation utility, but has become expensive bloatware with a 30 day trial. Fortunately, the last freeware version of Girder (3.2.9b) is still available for download.

Working with IR remote protocols

Decoding IR signals

Remote controls encode commands in the spacing or timing of a 38KHz carrier pulse, [San Bergmans] has an explanation of the principals involved. An infrared receiver IC separates the data stream from the carrier. Our job is to decode the data stream with a microcontroller. There are dozens of remote control protocols, but Phillips’ RC5 is widespread and commonly used by hobbyists.

RC5 is stream of 14 equal length bits of exactly 1.778ms per bit time. A pulse during the first half of the bit time represents 0, a pulse in the second half represents 1. This scheme is called Manchester coding.

We used a logic analyzer to examine the output of a Happauge WinTV remote control, a known RC5 remote. The diagram shows two presses of the 1 button, and two presses of the 2 button; note that the output is inversed and the Manchester coding is backwards from the above description.

The first two bit times are start bits, followed by a toggle bit. The toggle bit inverses each time a button is pressed so the receiver can tell the difference between a hold and a repeated press. The next 5 bits are the address (0b11110=0x1E), followed by the command (0b000001=0×01, 0b000010=0×02). A backwards compatible extension to RC5 uses the second start bit as command bit 7.

Representing remote codes to the computer

Looking at previous designs, we saw three general methods of communicating remote commands to a computer:

• Protocol specific receivers decode one protocol, and send actual decoded commands to the PC
• A more general type of receiver measures the timing and spacing of each pulse and sends the full waveform to the PC for analysis.
• Some receivers create a unique hash for a signal, but don’t actually include enough data to fully recreate the waveform.

While our preference is towards the general hash method, our only remote uses RC5 and it was more interesting to build an RC5 specific decoder. We describe modifications for a more general version in the firmware section.

Computer interface protocol

We didn’t want to write our own receiver software or driver, so we looked for an existing, well established communication protocol to imitate. The UIR/IRMAN/IRA/CTInfra/Hollywood+ type receiver is supported by Girder and LIRC, and uses a simple serial protocol with handshake:

• The device is initialized by the DTS and DTR pins of the serial port. We don’t have these and don’t care.
• The computer sends “IR”, with an optional delay. The device replies “OK”. We’ll just send “OK” on every “R”
• Remote control codes are sent as a unique six byte hash. We’ll decode an RC5 signal and send the actual values, but a generic hash could be used instead.

This protocol is for a serial port device, but our USB receiver will appear as a virtual serial port and the program won’t know the difference.

Hardware

Click here for a full size schematic (png). Our receiver is based on a USB enabled PIC 18F2455 microcontroller, the smaller, cheaper version of the 18F2550. The 18F family is programmable with the hobbyist favorite JDM-style programmers if a diode is used to drop VPP to a safe level. The PIC gets one decoupling capacitor (C1), and a diode (D1) and resistor(R1) on the ICSP programming header. We exposed the serial port on a pin header for debugging or a mixed USB/serial port version using a MAX RS232 transceiver IC.

The USB peripheral requires a 20MHz external clock (Q1, C5,6), and a .220uF capacitor. We faked the capacitor using 2 x .1uF decoupling capacitors (C2,3). A 3mm LED (LED1) and a 330ohm current limiting resistor (R2) show USB connection status.

We used a TSOP-1738 infrared receiver IC which calls for a 4.7uF decoupling capacitor (C4). If you can’t find this particular IC, any receiver listed here should work. The TSOP-1738 output is the inverse of the received signal, it pulls to ground when a pulse is detected, so a pull-up resistor (R3) holds the pin high when no signal is present. Check if you use a different receiver, you may need to use a pull-down resistor and reverse the Manchester decoding routine in the firmware.

The circuit draws power from the USB bus, so we don’t need an additional power supply.

Parts list

Click here for a full size placement diagram (png). The PCB design is 100% through-hole and single sided. The schematic and PCB were made with Cadsoft Eagle, freeware versions are available for most platforms. All the files are included in the project archive (zip).

Firmware

The firmware is written in C using Microchip’s free demonstration C18 compiler. Firmware and source are included in the project archive (zip).

We used version 2.3 of Microchip’s USB stack to create a USB serial port using the default drivers already available on most systems. The USB stack has simple functions to enumerate the USB device and transfer data between device and host. It only took a few pin changes to get the CDC demonstration working on our custom hardware.

Our implementation of the UIR/IRMAN/IRA/CTInfra/Hollywood+ protocol simply responds to the letter ‘R’ with ‘OK’. This should satisfy the handshake requirements of any implementation of this protocol.

We chose to specifically decode RC5 (and RC5x) because it’s a widely used protocol, and the only type of remote we have to work with. Most of the decoding is done in the interrupt handler:

• The first signal change triggers an interrupt that starts a 889us (one-half bit period) timer.
• On each timer interrupt, one-half of a Manchester coded bit is sampled.
• Every other interrupt the measurements are compared, and the bit value is calculated to be 0, 1, or an error. Errors reset the decoding routing.
• At the end of each transmission the address and command bytes are decoded, and sent to the host with 4 buffer bytes(0). We discard the toggle bit because it would confuse the PC software into thinking every other press was a unique code. We append the second start bit to the command bit for RC5x compliance; this just adds 0×40 to non RC5x remote codes.

A more general version can be made by removing the Manchester coding step (3), and sending 48 sample bits (all 6 bytes) to the computer.

Installing the USB infrared receiver

Most operating systems already have drivers that support a virtual serial port device like the receiver. Windows XP has the required drivers, but needs help from an .inf file to properly associate them with our device.

Windows will show the new hardware dialog the first time you plug in the receiver. Choose to use a custom driver and point it to the .inf file included in the project archive (zip). This links the device to a driver already included in Windows, and adds the receiver as a COM port. You can check the COM port number in the control panel.

Mac and Linux users can use the receiver with LIRC, but Windows users will be faced with the choice of the old, freeware Girder, or the new, 30-day trial shareware version. We used the freeware version of Girder, but hope you guys can suggest a great, open source alternative that we overlooked.

Regardless of the computer-side control software you use, configure it for a UIR/IRMAN/IRA/CTInfra/Hollywood+ style receiver, and enter the COM port or serial address assigned to it. Our receiver is also compatible with any protocol options like ‘Fast UIR Init’ and ‘Skip UIR Init Check’, which shorten or eliminate the “IR”->”OK” handshake. Now test the receiver and add a remote according to the documentation for your software.

Manual terminal interface and debugging

If you have a problem with the receiver, or you’re just curious, try to interface it from a serial terminal. We really like the serial terminal on Hercules. Set the correct COM port, but the speed and configuration settings are ignored by the USB serial port driver.

A capital ‘R’ will prompt the receiver to reply ‘OK’. RC5 codes are returned as raw bytes, so be sure to set your terminal to show HEX values rather than interpret it as ASCII text. The first byte is the RC5 address byte (0x1E), followed by the command byte (0×41), and then four buffer 0s to comply with the UIR/IRman protocol. The image shows the handshake, and the output of a short press on the 1,2, and 3 buttons.

A free utility called Portmon logs COM port activity for review. This is helpful for spying on existing receiver protocols, and debugging the interaction of our custom hardware and closed/proprietary software. The image shows Girder sending the initialization string ‘IR’ (0×49,0×52), and the receiver reply ‘OK’ (0x4F,0x4B).

Taking it further

Our RC5x compliant receiver follows a widely used interface protocol. There’s a ton of possibilities for additional features in an open source infrared receiver:

• Support all remotes through a generic hash generator, like the original UIR/IRman hardware.
• Add additional remote protocol decoders, like RC6.
• Support multiple, configurable interface protocols.
• Implement the serial port I/O.
• Store configuration options in EEPROM, including protocol, interface mode, timing options, serial port, etc.

In a two-part series called “PS3 Fab-to-lab” on IBM’s awesome developerWorks website, [Lewin] explains how to use the Cell Broadband Engine in a PS3 to create an audio-bandwidth spectrum analyzer and function generator. The set up consists of Yellow Dog Linux, an NTSC television, and an external USB sound card to provide the inputs of the spectrum analyzer and the outputs of the function generator. The sound card driver is written to simply capture or send the info in question (audio range only) and the NTSC television as the graphical interface. This hack involves a lot of coding with hardly any example code provided. The article is more of a guide than anything. If anyone gets this working, let us know!

[via Digg]

[photo: Malcom Tredinnick]