Build an Adequate Test Bench (EE Tip #127)

It’s in our makeup as engineers that we want to test our newly received boards as soon as possible. We just can’t wait to connect them to a power supply and then use our test bench equipment (e.g., generators, oscilloscopes, switches or LEDs, and so on) for simulation.

Circuit Cellar columnist Robert Lacoste's workspace in Chaville, France.

Circuit Cellar columnist Robert Lacoste’s clean, orderly workspace in Chaville, France.

But due to our haste, the result is usually a PCB under test lying on a crowded workbench in the middle of a mesh of test cables, alligator clamps, prototyping boards, and other probes. Experience shows that the probability of a short circuit or mismatched connection is high during this phase of engineering excitement.

Test Board

Rather than requiring a mesh of test wires, it is often wise to develop a small test PCB that will drastically simplify the test phase. Here the ancillary board provided a clean way to connect a Microchip Technology ICD3 debugger, a JTAG emulator, a debug analyzer, and a power supply input.

Take your time: prepare a real test bench to which you can connect your board. It could be as simple as a clean desk with properly labeled wires, but you might also need to anticipate the design of a test PCB in order to simplify the cabling.—Robert Lacoste, “Mixed-Signal Designs,” CC25:25th Anniversary Issue, 2013. 

 

COM Express Module With 2nd-Generation Intel Core

DynatemThe CPU-162-14 is a high-performance COM Express module based on the Intel Core i7 Processor. The COM is designed to work in harsh environments. It includes features to provide extra resilience to vibrations, making it well suited for transportation applications.

The CPU-162-14 includes extended temperature versions for –40°-to-85° operation; direct-mounted RAM and a CPU to withstand stress and vibration; up to 8 GB double data rate type three synchronous dynamic RAM (DDR3 SDRAM); and three video ports including video graphics array (VGA), Intel’s Serial Digital Video Out (SDVO), and low-voltage differential signaling (LVDS).

Contact Dynatem for pricing.

Dynatem, Inc.
www.dynatem.com

Specialized Linux File Systems

Since Linux was released in 1991, it has become the operating system for “98% of the world’s super computers, most of the servers powering the Internet, the majority of financial trades worldwide, and tens of millions of Android mobile phones and consumer devices,” according to the Linux Foundation. ”In short, Linux is everywhere.”

Linux offers a variety of file systems that are relatively easy to implement. Circuit Cellar columnist Bob Japenga, co-founder of MicroTools, writes about these specialized Linux file systems as part of his ongoing series examining embedded file systems. His latest article, which also discusses the helpful Samba networking protocol, appears in the magazine’s April issue.

The following article excerpts introduce the file systems and when they should be used. For more details, including instructions on how to use these file systems and the Samba protocol, refer to Japenga’s full article in the April issue.

CRAMFS
What It Is—Our systems demand more and more memory (or file space) and a compressed read-only file system (CRAMFS) can be a useful solution in some instances.

CRAMFS is an open-source file system available for Linux. I am not sure where CRAMFS gets its name. Perhaps it gets its name because CRAMFS is one way to cram your file system into a smaller footprint. The files are compressed one page at a time using the built-in zlib compression to enable random access of all of the files. This makes CRAMFS relatively fast. The file metadata (e.g., information about when the file was created, read and write privileges, etc.) is not compressed but uses a more compact notation than is present in most file systems.

When to Use It—The primary reason my company has used CRAMFS is to cut down on the flash memory used by the file system. The first embedded Linux system we worked on had 16 MB of RAM and 32 MB of flash. There was a systems-level requirement to provide a means for the system to recover should the primary partition become corrupt or fail to boot in any way. (Refer to Part 3 of this article series “Designing Robust Flash Memory Systems,” Circuit Cellar 283, 2014, for more detail.) We met this requirement by creating a backup partition that used CRAMFS.

The backup partition’s only function was to enable the box to recover from a corrupted primary partition… We were able to have the two file systems identical in file content, which made it easy to maintain. Using CRAMFS enabled us to cut our backup file system space requirements in half.

A second feature of CRAMFS is its read-only nature. Given that it is read-only, it does not require wear leveling. This keeps the overhead for using CRAMFS files very low. Due to the typical data retention of flash memory, this also means that for products that will be deployed for more than 10 years, you will need to rewrite the CRAMFS partition every three to five years…

RAM FILE SYSTEMS
What It Is—Linux provides two types of RAM file systems: ramfs and tmpfs. Both are full-featured file systems that reside in RAM and are thus very fast and volatile (i.e., the data is not retained across power outages and system restarts).

When the file systems are created with the mount command, you specify the ramfs size. However, it can grow in size to exceed that amount of RAM. Thus ramfs will enable you to use your entire RAM and not provide you with any warning that it is doing it. tmpfs does not enable you to write more than the space allocated at mount time. An error is returned when you try to use more than you have allocated. Another difference is that tmpfs uses swap space and can swap seldom used files out to a flash drive. ramfs does not use swapping. This difference is of little value to us since we disable swapping in our embedded systems.

When to Use It—Speed is one of the primary reasons to use a RAM file system. Disk writes are lightning fast when you have a RAM disk. We have used a RAM file system when we are recording a burst of high-speed data. In the background, we write the data out to flash.

A second reason to use a RAM file system is that it reduces the wear and tear on the flash file system, which has a limited write life. We make it a rule that all temporary files should be kept on the RAM disk. We also use it for temporary variables that are needed across threads/processes.

Figure 1: An example of a network file system is shown.

Figure 1: An example of a network file system is shown.



NETWORK FILE SYSTEM (NFS)
What It Is—In the early 1990s I started working with a company that developed embedded controllers for machine control. These controllers had a user interface that consisted of a PC located on the factory floor. The company called this the production line console (PLC). The factory floor was hot, very dirty, and had a lot of vibration. The company had designed a control room console (CRC) that networked together several PLCs. The CRC was located in a clean and cool environment. The PLC and the CRC were running QNX and the PLC was diskless. The PLC booted from and stored all of its data on the CRC (see Figure 1).

This was my first exposure to a Network File System (NFS). It was simple and easy to configure and worked flawlessly. The PLCs could only access their “file system.” The CRC could access any PLC’s files.

QNX was able to do this using the NFS protocol. NFS is a protocol developed initially by Sun Microsystems (which is now owned by Oracle). Early in its lifetime, Sun turned the specification into an open standard, which was quickly implemented in Unix and its derivatives (e.g., Linux and QNX).

When to Use It—One obvious usage of NFS is for environments where a hard drive cannot easily survive, as shown in my earlier example. However, my example was before flash file systems became inexpensive and reliable so that is not a typical use for today.
Another use for NFS would be to simplify software updates. All of the software could be placed in one central location. Each individual controller would obtain the new software once the central location was updated.

The major area in which we use NFS today is during software development. Even though flash file systems are fast and new versions of your code can be seamlessly written to flash, it can be time consuming. For example, you can use a flash memory stick over USB to update the flash file system on several of our designs. This is simple but can take anywhere from several seconds to minutes.

With NFS, all of your development tools can be on a PC and you never have to transfer the target code to the target system. You use all of your PC tools to change the file on your PC, and when the embedded device boots up or the application is restarted, those changed files will be used on the device.

SAMBA
What It Is—Although we don’t like to admit it, many of us still have Windows machines on our desks and on our laptops. And many of us are attached to some good development tools on our Windows machines.

Samba is not exactly a file system but rather a file system/networking protocol that enables you to write to your embedded system’s file system from your Windows machine as if it were a Windows file system. Samba can also be used  to access your embedded system’s files from other OSes that support the SMB/CIFS networking protocol.

When to Use It—Although I primarily see Samba, like NFS, as a development tool, you could certainly use it in an environment where you needed to talk to your embedded device from a Windows machine. We have never had a need for this, but I can imagine it could be useful in certain scenarios. The Linux community documents a lot of Samba users for embedded Linux.
 

Raspberry Pi-Based Network Monitoring Device

In 2012, Al Anderson, IT director at Salish Kootenai College in Pablo, MT, and his team wired the dorms and student housing units at the small tribal college with fiber and outdoor CAT 5 cable to provide reliable Internet service to students. “Our prior setup was wireless and did not provide very good service,” Anderson says.

The 25 housing units, each with a small unmanaged Ethernet switch, were daisy chained in several different paths. Anderson needed a way to monitor the links from the system’s Simple Network Management Protocol (SNMP) network monitoring software, Help/Systems’s InterMapper. He also wanted to ensure the switches installed inside the sun-exposed utility boxes wouldn’t get too hot.

The Raspberry Pi is a small SBC based on an ARM processor. Its many I/O ports make it very useful for embedded devices that need a little more power than the typical 8-bit microcontroller.

Photo 1: The Raspberry Pi is a small SBC based on an ARM processor. Its many I/O ports make it very useful for embedded devices that need a little more power than the typical 8-bit microcontroller.

His Raspberry Pi-based solution is the subject of an article appearing in Circuit Cellar’s April issue. “We chose the Raspberry Pi because it was less expensive, we had several on hand, and I wanted to see what I could do with it,” Anderson says (see Photo 1).

The article walks readers through each phase of the project:

“I installed a Debian Linux distro, added an I2C TMP102 temperature sensor from SparkFun Electronics, wrote a small Python program to get the temperature via I2C and convert it to Fahrenheit, installed an SNMP server on Linux, added a custom SNMP rule to display the temperature from the script, and finally wrote a custom SNMP MIB to access the temperature information as a string and integer.”

Setting up the SBC and Linux was simple, Anderson says. “The prototype Raspberry Pi has now been running since September 2012 without any problems,” he says in his article. “It has been interesting to see how the temperature fluctuates with the time of day and the level of network activity. As budget and time permit, we will be installing more of these onto our network.”

In the following excerpt, Anderson discusses the project’s design, implementation, and OS installation and configuration. For more details on a project inspired, in part, by the desire to see what a low-cost SBC can do, read Anderson’s full article in the April issue.

DESIGN AND IMPLEMENTATION
Figure 1 shows the overall system design. The TMP102 is connected to the Raspberry Pi via I2C. The Raspberry Pi is connected to the network via its Ethernet port. The monitoring system uses TCP/IP over the Ethernet network to query the Raspberry Pi via SNMP. The system is encased in a small acrylic Adafruit Industries case, which we used because it is inexpensive and easy to customize for the sensor.

The system is designed around the Raspberry Pi SBC. The Raspberry Pi uses the I2C protocol to query the Texas Instruments TMP102 temperature sensor. The Raspberry Pi is queried via SNMP.

Figure 1: The system is designed around the Raspberry Pi SBC. The Raspberry Pi uses the I2C protocol to query the Texas Instruments TMP102 temperature sensor. The Raspberry Pi is queried via SNMP.

Our first step was to set up the Raspberry Pi. We started by installing the OS and the various software packages needed. Next, we wrote the Python script that queries the I2C temperature sensor. Then we configured the SNMP daemon to run the Python script when it is queried. With all that in place, we then set up the SNMP monitoring software that is configured with a custom MIB and a timed query. Finally, we modified the Raspberry Pi case to expose the temperature sensor to the air and installed the device in its permanent location.

OS INSTALLATION AND CONFIGURATION
The Raspberry Pi requires a Linux OS compiled to run on an ARM processor, which is the brain of the device, to be installed on an SD card. It does not have a hard drive. Setting up the SD card is straightforward, but you cannot simply copy the files onto the card. The OS has to be copied in such a way that the SD card has a boot sector and the Linux partitioning and file structure is properly maintained. Linux and Mac OS X users can use the dd command line utility to copy from the OS’s ISO image. Windows users can use a utility (e.g., Win32DiskImager) to accomplish the same thing. A couple of other utilities can be used to copy the OS onto the SD card, but I prefer using the command line.

A Debian-based distribution of Linux seems to be the most commonly used Linux distribution on the Raspberry Pi, with the Raspbian “wheezy” as the recommended distribution. However, for this project I chose Adafruit Learning Systems’s Occidentalis V0.2 Linux distribution because it had several hardware-hacker features rolled into the distribution, including the kernel modules for the temperature sensor. This saved me some work getting those installed and debugged.

Before you can copy the OS to the SD card, you need to download the ISO image. The Resources section of this article lists several sources including a link to the Adafruit Linux distribution. Once you have an ISO image downloaded, you can copy it to the SD card. The Resources section also includes a link to an Embedded Linux Wiki webpage, “RPi Easy SD Card Setup,” which details this copying process for several OSes.

The quick and dirty instructions are to somehow get the SD card hooked up to your computer, either using a built-in SD reader or a peripheral card reader. I used a USB attached reader. Then you need to format the card. The best format is FAT32, since it will get reformatted by the copy command anyway. Next, use your chosen method to copy the OS onto the card. On Linux or Mac OS X, the command:

dd bs=4M if=~/linux_distro.img of=/dev/sdd

will properly copy the OS onto the SD card.

You will need to change two important things in this command for your system. First, the
if parameter, which is the name the in file (i.e., your ISO image) needs to match the file you downloaded. Second, the of device (i.e., the out file or our SD drive in this case) needs to match the SD card. Everything, including devices, is a file in Linux, in case you are wondering why your SD drive is considered a file. We will see this again in a bit with the I2C device. You can toast your hard drive if you put the wrong device path in here. If you are unsure about this, you may want to use a GUI utility so you don’t overwrite your hard drive.

Once the OS is copied onto the SD card, it is time to boot up the Raspberry Pi. A default username and password are available from wherever you download the OS. With our OS, the defaults are “pi” and “raspberry.” Make it your first mission to change that password and maybe even add a new account if your project is going to be in production.

Another thing you may have to change is the IP address configuration on the Ethernet interface. By default, these distributions use DHCP to obtain an address. Unless you have a need otherwise, it is best to leave that be. If you need to use a static IP address, I have included a link in the Resources section with instructions on how to do this in Linux.

To access your Raspberry Pi, hook up a local keyboard and monitor to get to a command line. Once you have the network running and you know the IP address, you can use the SSH utility to gain access via the network.

To get SNMP working on the Raspberry Pi, you need to install two Debian packages: snmpd and snmp. The snmpd package is the actual SNMP server software that will enable other devices to query for SNMP on this device. The second package, snmp, is the client. It is nice to have this installed for local troubleshooting.

We used the Debian package manager, apt-get, to install these packages. The commands also must be run as the root or superuser.

The sudo apt-get install snmpd command installs the snmpd software. The sudo part runs the apt-get command as the superuser. The install and snmpd parts of the command are the arguments for the apt-get command.

Next we issued the
sudo apt-get install snmp command, which installed the SNMP client. Issue the ps -ax | grep snmpd command to see if the snmpd daemon is running after the install. You should see something like this:

1444 ? S 14:22 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid

If you do not see a line similar to this, you can issue the sudo /etc/init.d/snmpd command start to start the service. Once it is running, it is time to turn your attention to the Python script that reads the temperature sensor. Configure the SNMP daemon after you get the Python script running.

The Raspberry Pi’s final installation is shown. The clear acrylic case can be seen along with the Texas Instruments TMP102 temperature sensor, which is glued below the air hole drilled into the case. We used a modified ribbon cable to connect the various TMP102 pins to the Raspberry Pi.

The Raspberry Pi’s final installation is shown. The clear acrylic case can be seen along with the Texas Instruments TMP102 temperature sensor, which is glued below the air hole drilled into the case. We used a modified ribbon cable to connect the various TMP102 pins to the Raspberry Pi.

Pulse-Shaping Basics

Pulse shaping (i.e., base-band filtering) can vastly improve the behavior of wired or wireless communication links in an electrical system. With that in mind, Circuit Cellar columnist Robert Lacoste explains the advantages of filtering and examines Fourier transforms; random non-return-to-zero NRZ signaling; and low-pass, Gaussian, Nyquist, and raised-cosine filters.

Lacoste’s article, which appears in Circuit Cellar’s April 2014 issue, includes an abundance of graphic simulations created with Scilab Enterprises’s open-source software. The simulations will help readers grasp the details of pulse shaping, even if they aren’t math experts. (Note: You can download the Scilab source files Lacoste developed for his article from Circuit Cellar’s FTP site.)

Excerpts from Lacoste’s article below explain the importance of filtering and provide a closer look at low-pass filters:

WHY FILTERING?
I’ll begin with an example. Imagine you have a 1-Mbps continuous digital signal you need to transmit between two points. You don’t want to specifically encode these bits; you just want to transfer them one by one as they are.

Before transmission, you will need to transform the 1 and 0s into an actual analog signal any way you like. You can use a straightforward method. Simply define a pair of voltages (e.g., 0 and 5 V) and put 0 V on the line for a 0-level bit and put 5 V on the line for a 1-level bit.


This method is pedantically called non-return-to-zero (NRZ). This is exactly what a TTL UART is doing; there is nothing new here. This analog signal (i.e., the base-band signal) can then be sent through the transmission channel and received at the other end (see top image in Figure 1).


Note: In this article I am not considering any specific transmission channel. It could range from a simple pair of copper wires to elaborate wireless links using amplitude, frequency and/or phase modulation, power line modems, or even optical links. Everything I will discuss will basically be applicable to any kind of transmission as it is linked to the base-band signal encoding prior to any modulation.

Directly transmitting a raw digital signal, such as this 1-Mbps non-return-to-zero (NRZ) stream (at top), is a waste of bandwidth. b—Using a pulse-shaping filter (bottom) reduces the required bandwidth for the same bit rate, but with a risk of increased transmission errors.

Figure 1: Directly transmitting a raw digital signal, such as this 1-Mbps non-return-to-zero (NRZ) stream (top), is a waste of bandwidth. Using a pulse-shaping filter (bottom) reduces the required bandwidth for the same bit rate, but with a risk of increased transmission errors.


Now, what is the issue when using simple 0/5-V NRZ encoding? Bandwidth efficiency. You will use more megahertz than needed for your 1-Mbps signal transmission. This may not be an issue if the channel has plenty of extra capacity (e.g., if you are using a Category 6 1-Gbps-compliant shielded twisted pair cable to transmit these 1 Mbps over a couple of meters).


Unfortunately, in real life you will often need to optimize the bandwidth. This could be for cost reasons, for environmental concerns (e.g., EMC perturbations), for regulatory issues (e.g., RF channelization), or simply to increase the effective bit rate as much as possible for a given channel.


Therefore, a good engineering practice is to use just the required bandwidth through a pulse-shaping filter. This filter is fitted between your data source and the transmitter (see bottom of Figure 1).


The filter’s goal is to reduce as much as possible the occupied bandwidth of your base-band signal without affecting the system performance in terms of bit error rate. These may seem like contradictory requirements. How can you design such a filter? That’s what I will try to explain in this article….


LOW-PASS FILTERS

A base-band filter is needed between the binary signal source and the transmission media or modulator. But what characteristics should this filter include? It must attenuate as quickly as possible the unnecessary high frequencies. But it must also enable the receiver to decode the signal without errors, or more exactly without more errors than specified. You will need a low-pass filter to limit the high frequencies. As a first example, I used a classic Butterworth second-order filter with varying cut-off frequencies to make the simulation. Figure 2 shows the results. Let me explain the graphs.

Figure 2: This random non-return-to-zero (NRZ) signal (top row) was passed through a second-order Butterworth low-pass filter. When the cut-off frequency is low (310 kHz), the filtered signal (middle row) is distorted and the eye diagram is closed. With a higher cutoff (410 kHz, bottom row), the intersymbol interference (ISI) is lower but the frequency content is visible up to 2 MHz.

Figure 2: This random non-return-to-zero (NRZ) signal (top row) was passed through a second-order Butterworth low-pass filter. When the cut-off frequency is low (310 kHz), the filtered signal (middle row) is distorted and the eye diagram is closed. With a higher cutoff (410 kHz, bottom row), the intersymbol interference (ISI) is lower but the frequency content is visible up to 2 MHz.

The leftmost column shows the signal frequency spectrum after filtering with the filter frequency response in red as a reference. The middle column shows a couple of bits of the filtered signal (i.e., in the time domain), as if you were using an oscilloscope. Last, the rightmost column shows the received signal’s so-called “eye pattern.” This may seem impressive, but the concept is very simple.

Imagine you have an oscilloscope. Trigger it on any rising or falling front of the signal, scale the display to show one bit time in the middle of the screen, and accumulate plenty of random bits on the screen. You’ve got the eye diagram. It provides a visual representation of the difficulty the receiver will have to recover the bits. The more “open” the eye, the easier it is. Moreover, if the successive bits’ trajectories don’t superpose to each other, there is a kind of memory effect. The voltage for a given bit varies depending on the previously transmitted bits. This phenomenon is called intersymbol interference (ISI) and it makes life significantly more difficult for decoding.


Take another look at the Butterworth filter simulations. The first line is the unfiltered signal as a reference (see Figure 2, top row). The second line with a 3-dB, 310-kHz cut-off frequency shows a frequency spectrum significantly reduced after 1 MHz but with a high level of ISI. The eye diagram is nearly closed (see Figure 2, middle row). The third line shows the result with a 410-kHz Butterworth low-pass filter (see Figure 2, bottom row). Its ISI is significantly lower, even if it is still visible. (The successive spot trajectories don’t pass through the same single point.) Anyway, the frequency spectrum is far cleaner than the raw signal, at least from 2 MHz.

Lacoste’s article serves as solid introduction to the broad subject of pulse-shaping. And it concludes by re-emphasizing a few important points and additional resources for readers:

Transmitting a raw digital signal on any medium is a waste of bandwidth. A filter can drastically improve the performance. However, this filter must be well designed to minimize intersymbol interference.

The ideal solution, namely the Nyquist filter, enables you to restrict the used spectrum to half the transmitted bit rate. However, this filter is just a mathematician’s dream. Raised cosine filters and Gaussian filters are two classes of real-life filters that can provide an adequate complexity vs performance ratio.

At least you will no longer be surprised if you see references to such filters in electronic parts’ datasheets. As an example, see Figure 3, which is a block diagram of Analog Devices’s ADF7021 high-performance RF transceiver.

This is a block diagram of Analog Devices’s ADF7021 high-performance transceiver. On the bottom right there is a “Gaussian/raised cosine filter” block, which is a key factor in efficient RF bandwidth usage.

Figure 3: This is a block diagram of Analog Devices’s ADF7021 high-performance transceiver. On the bottom right there is a “Gaussian/raised cosine filter” block, which is a key factor in efficient RF bandwidth usage.

The subject is not easy and can be easily misunderstood. I hope this article will encourage you to learn more about the subject. Bernard Sklar’s book Digital Communications: Fundamentals and Applications is a good reference. Playing with simulations is also a good way to understand, so don’t hesitate to read and modify the Scilab examples I provided for you on Circuit Cellar’s FTP site.  

Lacoste’s full article is in the April issue, now available for membership download or single issue purchase. And for more information about improving the efficiency of wireless communication links, check out Lacoste’s 2011 article “Line-Coding Techniques,” Circuit Cellar 255, which tells you how you can encode your bits before transmission.

Arbitrary Waveform Generator

The AWG18 is an arbitrary waveform generator designed for use with Applicos’s ATX-series of test systems. The waveform generator features an 18-bit resolution at a 300 megasamples-per-second (MSPS) data rate and oversampling at a 600-MSPS or 1.2 gigasamples-per-second (GSPS) rate.

Testing analog systems with high-speed 14- and 16-bit data converters requires extremely clean signals. The traditional approach of filtering away the harmonics is insufficient when dealing with a high signal-to-noise ratio (SNR), maintaining a high spurious-free dynamic range (SFDR), or when a low “close-in carrier noise” is preferred. In these cases, the extra precision from an 18-bit signal value can create a reliable test-stand operation and reduce random failures.

ApplicosMany applications need to use signals other than sine waves to make additional time domain measurements. To accommodate this, the AWG18 has two signal paths: one path starts at DC for time domain and general-purpose measurements that require high-level accuracy. The other path runs from 10 to 100 MHz and is optimized for dynamic signal generation in this frequency range. The typical total harmonic distortion (THD) for frequencies up to 50 MHz is above 100 dBc.

Contact Applicos for pricing.

Applicos BV
www.applicos.com

A Trace Tool for Embedded Systems

Tracing tools monitor what is going in a program’s execution by logging low-level and frequent events. Thus tracing can detect and help debug performance issues in embedded system applications.

In Circuit Cellar’s April issue, Thiadmer Riemersma describes his DIY tracing setup for small embedded systems. His system comprises three parts: a set of macros to include in the source files of a device under test (DUT), a PC workstation viewer that displays retrieved trace data, and a USB dongle that interfaces the DUT with the workstation.

Small embedded devices typically have limited-performance microcontrollers and scarce interfaces, so Riemersma’s tracing system uses only a single I/O pin on the microcontroller.

Designing a serial protocol that keeps data compact is also important. Riemersma, who develops embedded software for the products of his Netherlands-based company, CompuPhase, explains why:

Compactness of the information transferred from the embedded system to the workstation [which decodes and formats the trace information] is important because the I/O interface that is used for the transfer will probably be the bottleneck. Assuming you are transmitting trace messages bit by bit over a single pin using standard wire and 5- or 3.3-V logic levels, the transfer rate may be limited to roughly 100 Kbps.

My proposed trace protocol achieves compactness by sending numbers in binary, rather than as human-readable text. Common phrases can be sent as numeric message IDs. The trace viewer (or trace ‘listener’) can translate these message IDs back to the human-readable strings.

One important part of the system is the hardware interface—the trace dongle. Since many microcontrollers are designed with only those interfaces used for specific application needs, Riemersma says, typically the first step is finding a spare I/0 pin that can be used to implement the trace protocol.

In the following article excerpt, Riemersma describes his trace dongle and implementation requiring a single I/O pin on the microcontroller:

This is the trace dongle.

This is the trace dongle.

Photo 1 shows the trace dongle. To transmit serial data over a single pin, you need to use an asynchronous protocol. Instead of using a kind of (bit-banged) RS-232, I chose biphase encoding. Biphase encoding has the advantage of being a self-clocking and self-synchronizing protocol. This means that biphase encoding is simple to implement because timing is not critical. The RS-232 protocol requires timing to stay within a 3% error margin; however, biphase encoding is tolerant to timing errors of up to 20% per bit. And, since the protocol resynchronizes on each bit, error accumulation is not an issue.

Figure 1 shows the transitions to transmit an arbitrary binary value in biphase encoding—to be more specific, this variant is biphase mark coding. In the biphase encoding scheme, there is a transition at the start of each bit.

Figure 1: This is an example of a binary value transferred in biphase mark coding.

Figure 1: This is an example of a binary value transferred in biphase mark coding.

For a 1 bit there is also a transition halfway through the clock period. With a 0 bit, there is no extra transition. The absolute levels in biphase encoding are irrelevant, only the changes in the output line are important. In the previous example, the transmission starts with the idle state at a high logic level but ends in an idle state at a low logic level.

Listing 1 shows an example implementation to transmit a byte in biphase encoding over a single I/O pin. The listing refers to the trace_delay() and toggle_pin() functions (or macros). These system-dependent functions must be implemented on the DUT. The trace_delay() function should create a short delay, but not shorter than 5 µs (and not longer than 50 ms). The toggle_pin() function must toggle the output pin from low to high or from high to low.

For each bit, the function in Listing 1 inverts the pin and invokes trace_delay() twice. However, if the bit is a 1, it inverts the pin again between the two delay periods. Therefore, a bit’s clock cycle takes two basic “delay periods.”

Listing 1: Transmitting a byte in biphase encoding, based on a function to toggle an I/O pin, is shown.

Listing 1: Transmitting a byte in biphase encoding, based on a function to toggle an I/O pin, is shown.

The biphase encoding signal goes from the DUT to a trace dongle. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation (see Photo 2 and the circuit in Figure 2).

Photo 2: The trace dongle is inserted into a laptop and connected to the DUT.

Photo 2: The trace dongle is inserted into a laptop and connected to the DUT.

This trace dongle interprets biphase encoding.

Figure 2: This trace dongle interprets biphase encoding.

The buffer is there to protect the microcontroller’s input pin from spikes and to translate the DUT’s logic levels to 5-V TTL levels. I wanted the trace dongle to work whether the DUT used 3-, 3.3-, or 5-V logic. I used a buffer with a Schmitt trigger to avoid the “output high” level of the DUT at 3-V logic, plus noise picked up by the test cable would fall in the undefined area of 5-V TTL input.

Regarding the inductor, the USB interface provides 5 V and the electronics run at 5 V. There isn’t room for a voltage regulator. Since the USB power comes from a PC, I assumed it might not be a “clean” voltage. I used the LC filter to reduce noise on the power line.

The trace dongle uses a Future Technology Devices International (FTDI) FT232RL USB-to-RS-232 converter and a Microchip Technology PIC16F1824 microcontroller. The main reason I chose the FT232RL converter is FTDI’s excellent drivers for multiple OSes. True, your favorite OS already comes with a driver for virtual serial ports, but it is adequate at best. The FTDI drivers offer lower latency and a flexible API. With these drivers, the timestamps displayed in the trace viewers are as accurate as what can be achieved with the USB protocol, typically within 2 ms.

I chose the PIC microcontroller for its low cost and low pin count. I selected the PIC16F1824 because I had used it in an earlier project and I had several on hand. The microcontroller runs on a 12-MHz clock that is provided by the FTDI chip.

The pins to connect to the DUT are a ground and a data line. The data line is terminated at 120 Ω to match the impedance of the wire between the dongle and the DUT.

The cable between the DUT and the trace dongle may be fairly long; therefore signal reflections in the cable should be considered even for relatively low transmission speeds of roughly 250 kHz. That cable is typically just loose wire. The impedance of loose wire varies, but 120 Ω is a good approximate value.

The data line can handle 3-to-5-V logic voltages. Voltages up to 9 V do not harm the dongle because it is protected with a Zener diode (the 9-V limit is due to the selected Zener diode’s maximum power dissipation). The data line has a 10-kΩ to 5-V pull-up, so you can use it on an open-collector output.

The last item of interest in the circuit is a bicolor LED that is simply an indicator for the trace dongle’s status and activity. The LED illuminates red when the dongle is “idle” (i.e., it has been enumerated by the OS). It illuminates green when biphase encoded data is being received.

After the dongle is built, it must be programmed. First, the FT232RL must be programmed (with FTDI’s “FT Prog” program) to provide a 12-MHz clock on Pin C0. The “Product Description” in the USB string descriptors should be set to “tracedongle” so the trace viewers can find the dongle among other FTDI devices (if any). To avoid the dongle being listed as a serial port, I also set the option to only load the FTDI D2XX drivers.

To upload the firmware in the PIC microcontroller, you need a programmer (e.g., Microchip Technology’s PICkit) and a Tag-Connect cable, which eliminates the need for a six-pin header on the PCB, so it saves board space and cost.

The rest of the article provides details of how to create the dongle firmware, how to add trace statements to the DUT software being monitored, and how to use the GUI version of the trace viewer.

The tracing system is complete, but it can be enhanced, Riemersma says. “Future improvements to the tracing system would include the ability to draw graphs (e.g., for task switches or queue capacity) or a way to get higher precision timestamps of received trace packets,” he says.

For Riemersma’s full article, refer to our April issue now available for membership download or single-issue purchase.

A Workspace for Microwave Imaging, Small Radar Systems, and More

Gregory L. Charvat stays very busy as an author, a visiting research scientist at the Massachusetts Institute of Technology (MIT) Media Lab, and the hardware team leader at the Butterfly Network, which brings together experts in computer science, physics, and electrical engineering to create new approaches to medical diagnostic imaging and treatment.

If that wasn’t enough, he also works as a start-up business consultant and pursues personal projects out of the basement-garage workspace of his Westbrook, CT, home (see Photo 1). Recently, he sent Circuit Cellar photos and a description of his lab layout and projects.

Photo 1

Photo 1: Charvat, seated at his workbench, keeps his equipment atop sturdy World War II-era surplus lab tables.

Charvat’s home setup not only provides his ideal working conditions, but also considers  frequent moves required by his work.

Key is lots of table space using WW II surplus lab tables (they built things better back then), lots of lighting, and good power distribution.

I’m involved in start-ups, so my wife and I move a lot. So, we rent houses. When renting, you cannot install the outlets and things needed for a lab like this. For this reason, I built my own line voltage distribution panel; it’s the big thing with red lights in the middle upper left of the photos of the lab space (see Photo 2).  It has 16 outlets, each with its own breaker, pilot lamp (not LED).  The entire thing has a volt and amp meter to monitor power consumption and all power is fed through a large EMI filter.

Photo 2: This is another view of the lab, where strong lighting and two oscilloscopes are the minimum requirements.

Photo 2: This is another view of the lab, where strong lighting and two oscilloscopes are the minimum requirements.

Projects in the basement-area workplace reflect Charvat’s passion for everything from microwave imaging systems and small radar sensor technology to working with vacuum tubes and restoring antique electronics.

My primary focus is the development of microwave imaging systems, including near-field phased array, quasi-optical, and synthetic-aperture radar (SAR). Additionally, I develop small radar sensors as part of these systems or in addition to. Furthermore, I build amateur radio transceivers from scratch. I developed the only all-tube home theater system (published in the May-June 2012 issues of audioXpress magazine) and like to restore antique radio gear, watches, and clocks.

Charvat says he finds efficient, albeit aging, gear for his “fully equipped microwave, analog, and digital lab—just two generations too late.”

We’re fortunate to have access to excellent test gear that is old. I procure all of this gear at ham fests, and maintain and repair it myself. I prefer analog oscilloscopes, analog everything. These instruments work extremely well in the modern era. The key is you have to think before you measure.

Adequate storage is also important in a lab housing many pieces for Charvat’s many interests.

I have over 700 small drawers full of new inventory.  All standard analog parts, transistors, resistors, capacitors of all types, logic, IF cans, various radio parts, RF power transistors, etc., etc.

And it is critical to keep an orderly workbench, so he can move quickly from one project to the next.

No, it cannot be a mess. It must be clean and organized. It can become a mess during a project, but between projects it must be cleaned up and reset. This is the way to go fast.  When you work full time and like to dabble in your “free time” you must have it together, you must be organized, efficient, and fast.

Photos 3–7 below show many of the radar and imaging systems Charvat says he is testing in his lab, including linear rail SAR imaging systems (X and X-band), a near-field S-band phased-array radar, a UWB impulse X-band imaging system, and his “quasi-optical imaging system (with the big parabolic dish).”

Photo 3: This shows impulse rail synthetic aperture radar (SAR) in action, one of many SAR imaging systems developed in Charvat’s basement-garage lab.

Photo 3: This photo shows the impulse rail synthetic aperture radar (SAR) in action, one of many SAR imaging systems developed in Charvat’s basement-garage lab.

Photo 4: Charvat built this S-band, range-gated frequency-modulated continuous-wave (FMCW) rail SAR imaging system

Photo 4: Charvat built this S-band, range-gated frequency-modulated continuous-wave (FMCW) rail SAR imaging system.

Photo 5: Charvat designed an S-band near-field phased-array imaging system that enables through-wall imaging.

Photo 5: Charvat designed an S-band near-field phased-array imaging system that enables through-wall imaging.

Photo 5: Charvat's X-band, range-gated UWB FMCW rail SAR system is shown imaging his bike.

Photo 6: Charvat’s X-band, range-gated UWB FMCW rail SAR system is shown imaging his bike.

Photo 7: Charvat’s quasi-optical imaging system includes a parabolic dish.

Photo 7: Charvat’s quasi-optical imaging system includes a parabolic dish.

To learn more about Charvat and his projects, read this interview published in audioXpress (October 2013). Also, Circuit Cellar recently featured Charvat’s essay examining the promising future of small radar technology. You can also visit Charvat’s project website or follow him on Twitter @MrVacuumTube.

WIZnet Announces WIZ550io & W5500 Discounts at EELive

Today at EELive! in San Jose, CA, WIZnet announced a special promotion tied to the WIZnet Connect the Magic 2014 Design Challenge, which it is sponsoring. For a limited time, WIZnet is offering discounted WIZ550io Ethernet controller modules and W5500 chips via its webshopWiznet-Challenge-EELive

Disclosure: Elektor International Media and Circuit Cellar comprise the challenge administration team.

At this time, WIZnet’s WIZ550io is on sale for $9.95 (original price, $17.00) and the W550 cost $1.49 (original price, $2.87).

WIZnet’s WIZ550io is a module for rapidly developing ’Net-enabled systems. It is an auto-configurable Ethernet controller module that includes the W5500 (TCP/IP-hard-wired chip and PHY embedded), a transformer, and an RJ-45 connector. The module has a unique, embedded real MAC address and auto network configuration capability.

WIZnet's WIZ550io auto configurable Ethernet controller module includes a W5500, transformer, & RJ-45.

WIZnet’s WIZ550io auto configurable Ethernet controller module includes a W5500, transformer, & RJ-45.

The W5500 is a hardwired TCP/IP embedded Ethernet controller that enables Internet connection for embedded systems using Serial Peripheral Interface (SPI).

W5500

W5500

Visit the WIZnet Connect the Magic 2014 Design Challenge webpage for more information about participation and eligibility.

New 8-bit PIC Microcontrollers: Intelligent Analog & Core Independent Peripherals

Microchip Technology, Inc. announced Monday from EE Live! and the Embedded Systems Conference in San Jose the PIC16(L)F170X and PIC16(L)F171X family of 8-bit microcontrollers (MCUs), which combine a rich set of intelligent analog and core independent peripherals, along with cost-effective pricing and eXtreme Low Power (XLP) technology. Available in 14-, 20-, 28-, and 40/44-pin packages, the 11-member PIC16F170X/171X family of microcontrollers integrates two op-amps to drive analog control loops, sensor amplification and basic signal conditioning, while reducing system cost and board space.

PIC16F170X/171X MCUs reduce design complexity and system BOM cost with integrated op-amps, zero cross detect, and peripheral pin select.

PIC16F170X/171X MCUs reduce design complexity and system BOM cost with integrated op-amps, zero cross detect, and peripheral pin select.

These new devices also offer built-in Zero Cross Detect (ZCD) to simplify TRIAC control and minimize the EMI caused by switching transients. Additionally, these are the first PIC16 MCUs with Peripheral Pin Select, a pin-mapping feature that gives designers the flexibility to designate the pinout of many peripheral functions.

The PIC16F170X/171X are general-purpose microcontrollers that are ideal for a broad range of applications, such as consumer (home appliances, power tools, electric razors), portable medical (blood-pressure meters, blood-glucose meters, pedometers), LED lighting, battery charging, power supplies and motor control.

The new microcontrollers feature up to 28 KB of self-read/write flash program memory, up to 2 KB of RAM, a 10-bit ADC, a 5-/8-bit DAC, Capture-Compare PWM modules, stand-alone 10-bit PWM modules and high-speed comparators (60 ns typical response), along with EUSART, I2C and SPI interface peripherals. They also feature XLP technology for typical active and sleep currents of just 35 µA/MHz and 30 nA, respectively, helping to extend battery life and reduce standby current consumption.

The PIC16F170X/171X family is supported by Microchip’s standard suite of world-class development tools, including the PICkit 3 (part # PG164130, $44.95), MPLAB ICD 3 (part # DV164035, $189.99), PICkit 3 Low Pin Count Demo Board (part # DM164130-9, $25.99), PICDEM Lab Development Kit (part # DM163045, $134.99) and PICDEM 2 Plus (part # DM163022-1, $99.99). The MPLAB Code Configurator is a free tool that generates seamless, easy-to-understand C code that is inserted into your project. It currently supports the PIC16F1704/08, and is expected to support the PIC16F1713/16 in April, along with all remaining microcontrollers in this family soon thereafter.

The PIC16(L)F1703/1704/1705 microcontrollers are available now for sampling and production in 14-pin PDIP, TSSOP, SOIC and QFN (4 x 4 x 0.9 mm) packages. The PIC16F1707/1708/1709 microcontrollers are available now for sampling and production in 20-pin PDIP, SSOP, SOIC and QFN (4 x 4 x 0.9 mm) packages. The PIC16F1713/16 MCUs are available now for sampling and production in 28-pin PDIP, SSOP, SOIC, QFN (6 x 6 x 0.9 mm) and UQFN (4 x 4 x 0.5 mm) packages. The PIC16F1718 microcontrollers are expected to be available for sampling and production in May 2014, in 28-pin PDIP, SSOP, SOIC, QFN (6 x 6 x 0.9 mm) and UQFN (4 x 4 x 0.5 mm) packages. The PIC16F1717/19 microcontrollers are expected to be available for sampling and production in May 2014, in 40/44-pin PDIP, TQFP and UQFN (5 x 5 x 0.5 mm). Pricing starts at $0.59 each, in 10,000-unit quantities.

Source: Microchip Technology, Inc.

Mandalas Blend Technology and Spirituality

Multimedia artist Leonardo Ulian’s work includes his stunning “Technological Mandala” series, in which he precisely arranges tiny electrical and computer components to create colorful and symmetrical mandalas. In Hindu and Buddhist cultures, a mandala is a geometric and spiritual artwork representing the universe and is used in meditation. In this interview, Leonardo discusses his background, artwork, and inspiration for blending technological and ephemeral themes.—Mary Wilson, Managing Editor

 

MARY: Where were you born and how long have you lived in London?

LEONARDO: I come from a little village called Ruda, situated in the northeast region of Italy, Friuli-Venezia Giulia. I have lived in London since 2004.

Technological Mandala 17: Electronic components, copper wire, paper, 72 cm x 72 cm, 2013 (closeup),

Technological Mandala 17: Electronic components, copper wire, paper, 72 cm x 72 cm, 2013 (closeup). (Photo courtesy of Leonardo Ulian)

MARY: I understand you started out pursuing a degree in micro-electronics, then trained as a graphic designer before earning a fine arts degree. Can you tell me about your education and what made you turn your training toward the arts?

LEONARDO: My first attempt to do art was more related to the activity of just making things. Since I was very young, I always liked to play with hammers, nails, pieces of wood, and other bits and pieces in order to make my own little toys. But more than anything else, I liked to open old radios to see what was hiding inside.

In the 1980s, I attended an electronics school, also because I was fascinated by the new technology revolution of that period. I do remember myself stuck in front of the television watching an American TV series about robots, computers, and all that sort of stuff. While I was studying electronics I attended an art course and I specialized in airbrush hyper-realistic painting techniques. I then studied graphic design and I worked as a graphic designer and photo-retoucher for several years until I moved to London where I obtained my BA degree in fine art.

Technological Mandala 17: Electronic components, copper wire, paper, 72 cm x 72 cm, 2013.

Technological Mandala 17: Electronic components, copper wire, paper, 72 cm x 72 cm, 2013.

MARY: How did you come up with the idea for the “Technological Mandala” series? What was your inspiration and what are you trying to convey with these pieces that solder together electrical components, circuitry, and microchips?

LEONARDO: I liked the idea of combining different worlds such as spirituality and mandalas with technology and underlining the fact that electronic technology devices have become fundamental for our daily lives, almost something to worship.

I am also fascinated by the pure exercise of geometry used for the construction of the traditional mandalas—an ordered representation that is used to explain something that probably has nothing to do with geometry, which is the meaning of everything we perceive around us as living beings. I guess my artistic and spiritual research have led me to discover the world of mandalas.

I am not a spiritual person, or at least not in the traditional manner. And I am not particularly polarized with a specific belief. But I do like the idea of a world made with infinite connections among persons, objects, or places, like the connections I make in my technological mandalas. I also like to believe that what happens in one of the parts of the connection can affect the others as well.

Electronic components have always fascinated me; there was something in them that has attracted my fantasy since I was very young. I always asked myself how these little things were able to do what they do within electronic devices. After my studies in fine art, I started to think about my old passions and interests in a different way. This is why now, in my eyes, the electronic components have lost their real functionality in order to become ephemeral objects able to trigger the eyes and minds of the viewers, but in a different manner.

Technological Mandala 38: Electronic components, white Perspex, triple mounting board, 60 x 60 cm, 2013 (close up).

Technological Mandala 38: Electronic components, white Perspex, triple mounting board, 60 cm x 60 cm, 2013 (close-up). (Photo courtesy of Leonardo Ulian)

MARY:  Can you describe how you created the pieces? The materials and techniques you used?

LEONARDO: I make the basic geometry design in a computer. I print the resulting image onto paper, and then I bring in countless electronic components—some recycled but most bought from online websites—to fill in the shape I have created. I spend hours online researching nice and colorful electronic components. The difficulty is that nowadays technology is moving toward miniaturizing the electronic components, and quite often they do not have any color code.

MARY: You started the series two years ago. Is it now complete?

LEONARDO: The series isn’t yet completed, it’s a work in progress and I do not know when it will be finished. I guess the series is evolving as the technology—especially the electronic one—is changing rapidly.

Technological Mandala 02 (the beginning). Electronic components, microchip, wood frame, 120 x 20 cm, 2012.

Technological Mandala 02 (the beginning). Electronic components, microchip, wood frame, 120 cm x 20 cm, 2012. (Photo courtesy of Leonardo Ulian)

MARY: Do you have other artwork, such as “Technological Mandala,” that presents technology in an unconventional and thought-provoking way? Can you tell me more about that work?

LEONARDO: One of my early pieces is called “Now and Forever.” It’s an old petrol lantern modified in order to have, instead of the real flame, a mini-LCD screen with a video of it. The virtual flame within the mini screen is powered by a DVD player instead of the petrol, and it could run forever—or at least until there is no longer electricity available.

"Now and Forever" (Photo courtesy of Leonardo Ulian)

“Now and Forever” (Photo courtesy of Leonardo Ulian)

MARY: What technologies most interest you? Do any of them intrigue you as inspiration for future projects? If so, how might you use them?

LEONARDO: I do not have a particular interest in a specific piece of technology; I like to pick up things that stimulate my imagination. But, among other things, I am fascinated by magnetic fields and how the spectator could interact with them in order to generate art.

The piece “Close to the Essence” explores my interest in magnetic fields. It is a system of elements, like a hi-fi system, that becomes a totem able to interact with the spectator. The whole structure becomes a giant theremin I made using three simple AM radios, and the sound generated by the sculpture varies according to the proximity of the viewers.

"Close to the Essence" (Photo courtesy of Leonardo Ulian)

“Close to the Essence” (Photo courtesy of Leonardo Ulian)

MARY: What project are you currently focusing on?

LEONARDO: At the moment I am focused on further developing the idea started with the “Technological Mandala” series.

MARY: Do you have a dream project, something you are resolved to do sometime during your artistic career?

LEONARDO: I do not have a specific dream project, although my sketchbooks are full of ideas. I try to work day by day in order to produce things I am happy with. I have to say that almost always I have doubts about the things I make, but this keeps me going forward to create the next piece.

Technological Mandala 05: Electronic components, microchip, wood frame, 60 x 57 cm, 2012. (Photo courtesy of Leonardo Ulian)

Technological Mandala 05: Electronic components, microchip, wood frame, 60 cm x 57 cm, 2012. (Photo courtesy of Leonardo Ulian)

'Dardoby"

“Dardoby” (Photo courtesy of Leonardo Ulian)

MARY: You are a self-described multimedia artist. Can you tell me about some of your other artistic pursuits, including The Apathy Band you co-founded?

LEONARDO: I do like to think that art can explore different fields, as the great master Leonardo da Vinci did in his practice. The Apathy Band is an open project created by the artists Bob and Roberta Smith and I am one of the co-founders. The instruments I play in the band are toys I have accurately modified, like old electronic keyboards or electronic gizmos and animated toys. Two examples are the Dardomin, a theremin I created using AM radios, and the Dardoby, a circuit-bent Furby toy puppet I use to generate unexpected sound. I have also collaborated with the artistic duo Marotta & Russo to create the soundtracks of their videos. (Refer to “Timeline” and “Netopia.”)

Leonardo Ulian has had numerous solo exhibitions in London and elsewhere. He is the recipient of the Owen Rowley Award, London (UK), and the Italian national prize Stamps of the XX Century. You can follow Leonardo on Twitter at @ulianleonardo.

Technological Mandala 29: Electronic components, copper wire, paper, 120 cm x 120 cm, 2013. (Photo courtesy of Leonoard Ulian)

Technological Mandala 29: Electronic components, copper wire, paper, 120 cm x 120 cm, 2013. (Photo courtesy of Leonardo Ulian)

 

Centrical Bonsai Tree: Electronic components, cement and steel base, 135 cm x 35 cm x 35 cm, 2013 (close-up).

Centrical Bonsai: Tree, electronic components, cement and steel base, 135 cm x 35 cm x 35 cm, 2013 (close-up). (Photo courtesy of Leonardo Ulian)

Centrical Bonsai Tree: Electronic components, cement and steel base, 135 cm x 35 cm x 35 cm, 2013 (close-up).

Centrical Bonsai: Tree, electronic components, cement and steel base, 135 cm x 35 cm x 35 cm, 2013. (Photo courtesy of Leonardo Ulian)

 

Real-Time Processing for PCIe Digitizers

Agilent U5303A PCIe 12bit High-Speed DigitizerThe U5303A digitizer and the U5340A FPGA development kit are recent enhancements to Agilent Technologies’s PCI Express (PCIe) high-speed digitizers. The U5303A and the U5340A FPGA add next-generation real-time peak detection functionalities to the PCIe devices.

The U5303A is a 12-bit PCIe digitizer with programmable on-board processing. It offers high performance in a small footprint, making it an ideal platform for many commercial, industrial, and aerospace and defense embedded systems. A data processing unit (DPU) based on the Xilinx Virtex-6 FPGA is at the heart of the U5303A. The DPU controls the module functionality, data flow, and real-time signal processing. This feature enables data reduction and storage to be carried out at the digitizer level, minimizing transfer volumes and accelerating analysis.

The U5340A FPGA development kit is designed to help companies and researchers protect their IP signal-processing algorithms. The FPGA kit enables integration of an advanced real-time signal processing algorithm within Agilent Technologies’s high-speed digitizers. The U5340A features high-speed medical imaging, analytical time-of-flight, lidar ranging, non-destructive testing, and a direct interface to digitizer hardware elements (e.g., the ADC, clock manager, and memory blocks). The FPGA kit includes a library of building blocks, from basic gates to dual-port RAM; a set of IP cores; and ready-to-use scripts that handle all aspects of the build flow.

Contact Agilent Technologies for pricing.

Agilent Technologies, Inc.
www.agilent.com