About Mary Wilson

Mary Wilson is Circuit Cellar's Managing Editor. You can reach her at mwilson@circuitcellar.com and @mgeditor_cc.

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.

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.

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)

 

All-Programmable SoC Solution

Anyone creating a complex, powerful digital design may want to turn to a single device that integrates high-speed processing and programmable logic.

In Circuit Cellar’s April issue, columnist Colin O’Flynn explores using the Xilinx Zynq  Z-7020 All Programmable SoC (system-on-a-chip) as part of the Avnet ZedBoard development board.

“I used a Xilinx Zynq SoC device, although Altera offers several flavors of a similar device (e.g., the Cyclone V SoC, the Arria V SoC, and the Arria 10 SoC), and Microsemi offers the SmartFusion2 SoC FPGA,” O’Flynn says in his article. “The Xilinx and Altera devices feature a dual-core ARM Cortex-A9 processor, whereas the Microsemi devices feature a less powerful Cortex-M3 processor. You may not need a dual-core A9 processor, so ‘less powerful’ may be an advantage.”

While O’Flynn’s article introduces the ZedBoard, he notes many of its specifics also apply to the MicroZed board, a less expensive option with a smaller SoC. Xilinx’s Zynq device has many interesting applications made highly accessible through the ZedBoard and MicroZed boards, he says.

O’Flynn’s discussion of the Zynq SoC device includes the following excerpt. (The April issue, which includes O’Flynn’s full article, is available for membership download or single-issue purchase.)

WHERE’S THE BEEF?
Originally, I had planned to describe a complete demo project in this article. I was going to demonstrate how to use a combination of a custom peripheral and some of the hard cores to stream data from a parallel ADC device into DDR memory. But there wasn’t enough room to introduce the tools and cover the demo, so I decided to introduce the Zynq device (using the ZedBoard).

A demo project is available at ProgrammableLogicInPractice.com. Several tutorials for the Zynq device are available at xilinx.com and zedboard.org, so there isn’t any point in duplicating work! I’ve linked to some specific tutorials from the April 2014 post on ProgrammableLogicInPractice.com. Photo 1 shows the hardware I used, which includes a ZedBoard with my custom OpenADC board connected through the I/O lines.

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

Photo 1: An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

FPGA PROCESSOR DESIGN 101
Even if you’re experienced in FPGA design, you may not have used Xilinx tools for processor-specific design. These tools include the Xilinx Platform Studio (XPS) and the Xilinx Software Development Kit (SDK). Before the advent of hard-core processors (e.g., Zynq), there have long existed soft-core processors, including the popular Xilinx MicroBlaze soft processor. The MicroBlaze system is completely soft core, so you can use the XPS tool to define the peripherals you wish to include. For the Zynq device, several hard-core peripherals are always present and you can choose to add additional soft-core (i.e., use the FPGA fabric) peripherals.

In a future article I will discuss different soft-core processor options, including some open-source third-party ones that can be programmed from the Arduino environment. For now, I’ll examine only the Xilinx tools, which are applicable to the Zynq device, along with the MicroBlaze core.

The ARM cores in the Zynq device are well suited to run Linux, which gives you a large range of existing code and tools to use in your overall solution. If you don’t need those tools, you can always run on “bare metal” (e.g., without Linux), as the tools will generate a complete base project for you that compiles and tests the peripherals (e.g., printing “Hello World” out the USART). To give you a taste of this, I’ve posted a demo video of bringing up a simple “Hello World” project in both Linux and bare metal systems on ProgrammableLogicInPractice.com.

The FPGA part of the Zynq device is called the programmable logic (PL) portion. The ARM side is called the processing system (PS) portion. You will find a reference to the SoC’s PL or PS portion throughout most of the tutorials (along with this article), so it’s important to remember which is which!

For either system, you’ll be starting with the XPS software (see Photo 2). This software is used to design your hardware platform (i.e., the PL fabric), but it also gives you some customization of the PS hard-core peripherals.

This is the main screen of the Xilinx Platform Studio (XPS) when configuring a Zynq design. On the left you can see the list of available soft-core peripherals to add to the design. You can configure any of the hard-core peripherals by choosing to enable or disable them, along with selecting from various possible I/O connections. Additional screens (not shown) enable you to configure peripherals addressing information, configure I/O connections for the soft-core peripherals, and connect peripherals to various available extension buses.

Photo 2: This is the main screen of the Xilinx Platform Studio (XPS) when configuring a Zynq design. On the left you can see the list of available soft-core peripherals to add to the design. You can configure any of the hard-core peripherals by choosing to enable or disable them, along with selecting from various possible I/O connections. Additional screens (not shown) enable you to configure peripherals addressing information, configure I/O connections for the soft-core peripherals, and connect peripherals to various available extension buses.

MAKING THE CONNECTION
For example, clicking on the list of hard-core peripherals opens the options dialogue so you can enable or disable each peripheral along with routing the I/O connections. The ZedBoard’s Zynq device has 54 multipurpose I/O (MIO) lines that can be used by the peripherals, which are split into two banks. Each bank can use different I/O standards (e.g., 3.3 and 1.5 V).

Enabling all the peripherals would take a lot more than 54 I/O lines. Therefore, most of the I/O lines share multiple functions on the assumption that every peripheral doesn’t need to be connected. Many of the peripherals can be connected to several different I/O locations, so you (hopefully) don’t run into two peripherals needing the same I/O pin.

Almost all of the peripheral outputs can be routed to the PL fabric as well under the name EMIO, which is a dedicated 64-bit bus that connects to the PL fabric. If you simply wish to get more I/O pins, you can configure these extra pins from within XPS. But you can also use this EMIO bus to control existing cores in your FPGA fabric using peripherals on the Zynq device.

Assume you had an existing FPGA design where you had an FPGA core doing some processing connected to a microcontroller or computer via I2C, SPI, or serial. You could simply connect this core to the appropriate PS peripheral and port the existing code onto the Zynq processor by changing the low-level calls to use the Zynq peripherals. You may eventually wish to change this interface to the peripheral bus, the AMBA Advanced eXtensible Interface (AXI), for better performance. However, using standard peripherals to interface to a PL design can still be useful for many cores for which you have extensive existing code.

The MIO/EMIO pins can even be used in a bit-banging fashion, so if you need a special device or core control logic, it’s possible to quickly develop this in software. You can then move to a hardware peripheral for considerably better performance.

O’Flynn’s article goes on to discuss in greater detail the internal buses, peripherals, and taking a design from hardware to software. For more, refer to Circuit Cellar‘s  April issue and related application notes posted at O’Flynn’s companion site ProgrammableLogicInPractice.com.

MCU-Based Experimental Glider with GPS Receiver

When Jens Altenburg found a design for a compass-controlled glider in a 1930s paperback, he was inspired to make his own self-controlled model aircraft (see Photo 1)

Photo 1: This is the cover of an old paperback with the description of the compass-controlled glider. The model aircraft had a so-called “canard” configuration―a very modern design concept. Some highly sophisticated fighter planes are based on the same principle. (Photo used with permission of Ravensburger.)

Photo 1: This is the cover of an old paperback with the description of the compass-controlled glider. The model aircraft had a so-called “canard” configuration―a very modern design concept. Some highly sophisticated fighter planes are based on the same principle. (Photo used with permission of Ravensburger.)

His excellent article about his high-altitude, low-cost (HALO) experimental glider appears in Circuit Cellar’s April issue. The MCU-based glider includes a micro-GPs receiver and sensors and can climb to a preprogrammed altitude and find its way back home to a given coordinate.

Altenburg, a professor at the University of Applied Sciences Bingen in Germany, added more than a few twists to the 80-year-old plan. An essential design tool was the Reflex-XTR flight simulation software he used to trim his 3-D glider plan and conduct simulated flights.

Jens also researched other early autopilots, including the one used by the Fiesler Fi 103R German V-1 flying bomb. Known as buzz bombs during World War II, these rough predecessors of the cruise missile were launched against London after D-Day. Fortunately, they were vulnerable to anti-aircraft fire, but their autopilots were nonetheless mechanical engineering masterpieces (see Figure 1)

“Equipped with a compass, a single-axis gyro, and a barometric pressure sensor, the Fiesler Fi 103R German V-1 flying bomb flew without additional control,” Altenburg says. “The compass monitored the flying direction in general, the barometer controlled the altitude, and the gyro responded to short-duration disturbances (e.g., wind gusts).”

Figure 1: These are the main components of the Fieseler Fi 103R German V-1 flying bomb. The flight controller was designed as a mechanical computer with a magnetic compass and barometric pressure sensor for input. Short-time disturbances were damped with the main gyro (gimbal mounted) and two auxiliary gyros (fixed in one axis). The “mechanical” computer was pneumatically powered. The propeller log on top of the bomb measured the distance to the target.

Figure 1: These are the main components of the Fieseler Fi 103R German V-1 flying bomb. The flight controller was designed as a mechanical computer with a magnetic compass and barometric pressure sensor for input. Short-time disturbances were damped with the main gyro (gimbal mounted) and two auxiliary gyros (fixed in one axis). The “mechanical” computer was pneumatically powered. The propeller log on top of the bomb measured the distance to the target.

Altenburg adapted some of the V-1’s ideas into the flight control system for his 21st century autopilot glider. “All the Fi 103R board system’s electromechanical components received an electronic counterpart,” he says. “I replaced the mechanical gyros, the barometer, and the magnetic compass with MEMS. But it’s 2014, so I extended the electronics with a telemetry system and a GPS sensor.” (See Figure 2)

Figure 2: This is the flight controller’s block structure. The main function blocks are GPS, CPU, and power. GPS data is processed as a control signal for the servomotor.

Figure 2: This is the flight controller’s block structure. The main function blocks are GPS, CPU, and power. GPS data is processed as a control signal for the servomotor.

His article includes a detailed description of his glider’s flight-controller hardware, including the following:

Highly sophisticated electronics are always more sensitive to noise, power loss, and so forth. As discussed in the first sections of this article, a glider can be controlled by only a magnetic compass, some coils, and a battery. What else had to be done?

I divided the electronic system into different boards. The main board contains only the CPU and the GPS sensor. I thought that would be sufficient for basic functions. The magnetic and pressure sensor can be connected in case of extra missions. The telemetry unit is also a separate PCB.

Figure 3 shows the main board. Power is provided by a CR2032 lithium coin-cell battery. Two low-dropout linear regulators support the hardware with 1.8 and 2.7 V. The 1.8-V line is only for the GPS sensor. The second power supply provides the CPU with a stable voltage. The 2.7 V is the lowest voltage for the CPU’s internal ADC.

It is extremely important for the entire system to save power. Consequently, the servomotor has a separate power switch (Q1). As long as rudder movement isn’t necessary, the servomotor is powered off. The servomotor’s gear has enough drag to hold the rudder position without electrical power. The servomotor’s control signal is exactly the same as usually needed. It has a 1.1-to-2.1-ms pulse time range with about a 20-ms period. Two connectors (JP9 and JP10) are available for the extension boards (compass and telemetry)..

I used an STMicroelectronics LSM303DLM, which is a sensor module with a three-axis magnetometer and three-axis accelerometer. The sensor is connected by an I2C bus. The Bosch Sensortec BMP085 pressure sensor uses the same bus.

For telemetry, I applied an AXSEM AX5043 IC, which is a complete, narrow-band transceiver for multiple standards. The IC has an excellent link budget, which is the difference between output power in Transmit mode and input sensitivity in Receive mode. The higher the budget, the longer the transmission distance.

The AX5043 is also optimized for battery-powered applications. For modest demands, a standard crystal (X1, 16-MHz) is used for clock generation. In case of higher requirements, a temperature-compensated crystal oscillator (TCXO) is recommended.

The main board’s hardware with a CPU and a GPS sensor is shown. A CR2032 lithium coin-cell battery supplies the power. Two regulators provide 1.8  and 2.7 V for the GPS and the CPU. The main outputs are the servomotor’s signal and power switch.

Figure 3: The main board’s hardware with a CPU and a GPS sensor is shown. A CR2032 lithium coin-cell battery supplies the power. Two regulators provide 1.8 and 2.7 V for the GPS and the CPU. The main outputs are the servomotor’s signal and power switch.

Altenburg’s article also walks readers through the mathematical calculations needed to provide longitude, latitude, and course data to support navigation and the CPU’s most important sensor— the u-blox Fastrax UC430 GPS. He also discusses his experience using the Renesas Electronics R5F100AA microcontroller to equip the prototype board. (Altenburg’s glider won honorable mention in the 2012 Renesas RL78 Green Energy Challenge, see Photos 2 and 3).

The full article is in the April issue, now available for download by members or single-issue purchase.

One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Photo 2: One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Photo 2: This is the well-equipped high-altitude low-cost (HALO) experimental glider.

Photo 3: This is the well-equipped high-altitude low-cost (HALO) experimental glider.

A Quiet Place for Soldering and Software Design

Senior software engineer Carlo Tauraso, of Trieste, Italy, has designed his home workspace to be “a distraction-free area where tools, manuals, and computer are at your fingertips.”

Tauraso, who wrote his first Assembler code in the 1980s for the Sinclair Research ZX Spectrum PC, now works on developing firmware for network devices and microinterfaces for a variety of European companies. Several of his articles and programming courses have been published in Italy, France, Spain, and the US. Three of his articles have appeared in Circuit Cellar since 2008.

Photo 1: This workstation is neatly divided into a soldering/assembling area on the left and developing/programming area on the right.

Photo 1: This workstation is neatly divided into a soldering/assembling area on the left and a developing/programming area on the right.

Tauraso keeps an orderly and, most importantly, quiet work area that helps him stay focused on his designs.

This is my “magic” designer workspace. It’s not simple to make an environment that’s perfectly suited to you. When I work and study I need silence.

I am a software engineer, so during designing I always divide the work into two main parts: the analysis and the implementation. I decided, therefore, to separate my workspace into two areas: the developing/programming area on the right and the soldering/assembling area on the left (see Photo 1). When I do one or the other activity, I move physically in one of the two areas of the table. Assembling and soldering are manual activities that relax me. On the other hand, programming often is a rather complex activity that requires a lot more concentration.

Photo 2: The marble slab at the right of Tauraso’s assembling/soldering area protects the table surface and the optical inspection camera nearby helps him work with tiny ICs.

Photo 2: The marble slab at the right of Tauraso’s assembling/soldering area protects the table surface. The optical inspection camera nearby helps him work with tiny ICs.

The assembling/soldering area is carefully set up to keep all of Tauraso’s tools within easy reach.

I fixed a marble slab square on the table to solder without fear of ruining the wood surface (see Photo 2). As you can see, I use a hot-air solder station and the usual iron welder. Today’s ICs are very small, so I also installed a camera for optical inspection (the black cylinder with the blue stripe). On the right, there are 12 outlets, each with its own switch. Everything is ready and at your fingertips!

Photo 3: This developing and programming space, with its three small computers, is called “the little Hydra.”

Photo 3: This developing and programming space, with its three small computers, is called “the little Hydra.”

The workspace’s developing and programming area makes it easy to multitask (see Photo 3).

In the foreground you can see a network of three small computers that I call “the little Hydra” in honor of the object-based OS developed at Carnegie Mellon University in Pittsburgh, PA, during the ’70s. The HYDRA project sought to demonstrate the cost-performance advantages of multiprocessors based on an inexpensive minicomputer. I used the same philosophy, so I have connected three Mini-ITX motherboards. Here I can test network programming with real hardware—one as a server, one as a client, one as a network sniffer or an attacker—while, on the other hand, I can front-end develop Windows and the [Microchip Technology] PIC firmware while chatting with my girlfriend.

This senior software designer has created a quiet work area with all his tools close at hand.

Senior software engineer Tauraso has created a quiet work area with all his tools close at hand.

Circuit Cellar will be publishing Tauraso’s article about a wireless thermal monitoring system based on the ANT+ protocol in an upcoming issue. In the meantime, you can follow Tauraso on Twitter @CarloTauraso.

Embedded Programming: Rummage Around In This Toolbox

Circuit Cellar’s April issue is nothing less than an embedded programming toolbox. Inside you’ll find tips, tools, and online resources to help you do everything from building a simple tracing system that can debug a small embedded system to designing with a complex system-on-a-chip (SoC) that combines programmable logic and high-speed processors.

Article contributor Thiadmer Riemersma describes the three parts of his tracing system: 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 (p. 26).

Thaidmer Riemersma's trace dongle is connected to a laptop and device. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Thaidmer Riemersma’s trace dongle is connected to a laptop and DUT. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Riemersma’s special serial protocol overcomes common challenges of tracing small embedded devices, which typically have limited-performance microcontrollers and scarce interfaces. His system uses a single I/O and keeps it from bottlenecking by sending DUT-to-workstation trace transmissions as compact binary messages. “The trace viewer (or trace “listener”) can translate these message IDs back to the human-readable strings,” he says.

But let’s move on from discussing a single I/0 to a tool that offers hundreds of I/0s. They’re part of the all-programmable Xilinx Zynq SoC, an example of a device that blends a large FPGA fabric with a powerful processing core. Columnist Colin O’Flynn explores using the Zynq SoC as part of the Avnet ZedBoard development board (p. 46). “Xilinx’s Zynq device has many interesting applications,” O’Flynn concludes. “This is made highly accessible by the ZedBoard and MicroZed boards.”

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

An Avnet ZedBoard is connected to the OpenADC. (Source: C. O’Flynn, Circuit Cellar 285)

Our embedded programming issue also includes George Novacek’s article on design-level software safety analysis, which helps avert hazards that can damage an embedded controller (p. 39). Bob Japenga discusses specialized file systems essential to Linux and a helpful networking protocol (p. 52).

One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Jens Altenburg’s project

Other issue highlights include projects that are fun as well as instructive. For example, Jens Altenburg added an MCU, GPS, flight simulation, sensors, and more to a compass-controlled glider design he found in a 1930s paperback (p. 32). Columnist Jeff Bachiochi introduces the possibilities of programmable RGB LED strips (p. 66).

Wireless Data Links (Part 2): Transmitters and Antennas

If you built your own ham radio “back in the day,” you’ll recall the frustration of putting it together with components that were basic at best.

But as columnist George Novacek points out in the second installment of his series examining wireless data links: “Today you can purchase excellent, reasonably priced low-power gear for data communications off the shelf.”

Transmitter and receiver

Photo 1: SparkFun Electronics’s WRL-10524 transmitter and WRL-10532 receiver are low cost, basic, and work well.

Part 2 of Novacek’s series, appearing in the March issue, looks at transmitters and antennas.

In one section, Novacek expands upon the five basic data-transmitter modules—a data encoder, a modulator, a carrier frequency generator, an RF output amplifier, and an antenna:

Low-power data transmitters often integrate the modulator, the carrier frequency generator, and the amplifier into one circuit. A single transistor can do the job. I’ll discuss antennas later. When a transmitter and a receiver are combined into one unit, it’s called a transceiver.

Modulation may not be needed in some simple applications where the mere presence of a carrier is detected to initiate an action. A simple push button will suffice, but this is rarely used as it is subject to false triggering by other transmitters working in the area in the same frequency band.

Digital encoder and decoder ICs are available for simple devices (e.g., garage door openers) or keyless entry where just an on or off output is required from the receiver. These ICs generate a data packet for transmission. If the received packet matches the data stored in the decoder, an action is initiated. Typical examples include Holtek Semiconductor HT12E encoders and HT12D decoders and Freescale Semiconductor MC145026, MC145027, and MC145028 encoder and decoder pairs. For data communications a similar but more advanced scheme is used. I’ll address this when I discuss receivers (coming up in Part 3 of this series).

Novacek’s column goes on to explain modulation types, including OOK and ASK modulation:

OOK modulation is achieved by feeding the Data In line with a 0-to+V-level  datastream. ASK modulation can be achieved by the data varying the transistor biasing to swing the RF output between 100% and typically 30% to 50% amplitude. I prefer to add a separate modulator.

The advantage of ASK as opposed to OOK modulation is that the carrier is always present, thus the receiver is not required to repeatedly synchronize to it. Different manufacturers’ specifications claim substantially higher achievable data rates with ASK rather than OOK.

For instance, Photo 1 shows a SparkFun Electronics WRL-10534 transmitter and a WRL-10532 receiver set for 433.9 MHz (a 315-MHz set is also available), which costs less than $10. It is a bare-bones design, but it works well. When you build supporting circuits around it you can get excellent results. The set is a good starting point for experimentation.

The article also includes tips on a transceiver you can purchase to save time in developing ancillary circuits (XBee), while noting a variety of transceiver, receiver, and transmitter modules are available from manufacturers such as Maxim Integrated, Micrel, and RF Monolithics (RFM).  In addition, the article discusses design and optimization of the three forms of antennas: a straight conductor (monopole), a coil (helical), and a loop.

“These can be external, internal, or even etched onto the PCB (e.g., keyless entry fobs) to minimize the size,” Novacek says.

Do you need advice on what to consider when choosing an antenna for your design?  Find these tips and more in Novacek’s March issue article.

A Personal Hackerspace in Lyon, France

Jean Noël Lefebvre, of Lyon, France, is the inventor of the Ootsidebox touchless technology, an innovative interface that enables adding touchless technology to an existing tablet. (Watch the Elektor.LABS video interview with Lefebvre to find out more about Ootside box and how it works).

Recently, Lefebvre shared with Circuit Cellar photos of his workspace, which he prefers to call his “personal hackerspace”  where he conceives inventive ideas and builds them.

Deskweb

Lefebvre’s desk reflects his new project.

His desk has an old oscilloscope, with only two inputs. “I have to upgrade it as soon as possible,” he says.

He is working on a shield for the Arduino UNO board on his desk, which is also where he keeps a Weller soldering iron with specific tools for surface mount devices (SMDs).

“On the screen of the computer you can see the logo of my project Ootsidebox and also the logo of Noisebridge, the San Francisco hackerspace.”

A diverse library

A diverse library

Lefebvre says his library is filled with “a lot of good books (old and modern)” covering many different topics and skills, including electronics, software, signal processing, cryptography, physics, biology, mathematics, and inventors’ biographies.

What is he currently working on in his hackerspace?

“I’m working on my own invention: a touchless gesture user Interface based on electric-fields (E-fields) sensing,” he says. “It’s an open-source  and open-hardware project, compatible with the Arduino environment.”

You can learn more about how his project is being shared on the Elektor.LABS website.

Storage for some of Lefebvre's stock components

Storage for some of Lefebvre’s stock components

Although Lefebvre is currently working alone in his “personal hackerspace” at his family’s home, his dream is to go to San Francisco, CA, and work out of the well-equipped Noisebridge hackerspace.

A few years ago, he says, big ideas and innovations in technology started in garages.  “Today this will take place in hackerspaces, where creativity and technical skills are omnipresent,” he says. “By making stuff in such a place, you are fully connected with a worldwide network of creative people of different backgrounds, and this synergy highly accelerates the innovation process.”

You can view pictures and video Lefebvre posted from his last Noisebridge visit.  And you can follow Lefebvre and his work on Twitter.

A Low-Cost Connection to the IoT

In Circuit Cellar’s March issue, columnist Jeff Bachiochi tests the services of a company he says is “poised to make a big impact” on the Internet of Things (IoT).

This shows the I2C interface Bachiochi designed to enable available clamp-on current sensors to be monitored. He added four of these circuits to a PCB, which includes the circuitry for an imp card.

This shows the I2C interface Bachiochi designed to enable available clamp-on current sensors to be monitored. He added four of these circuits to a PCB, which includes the circuitry for an imp card.

Established in 2011, Electric Imp offers a flexible connectivity platform meant to enable any device to be connected to the IoT. The platform, called the “imp,” provides an SD-card sized module (including an 802.11b/g/n Wi-Fi radio package) that can be installed on any electronic device to go online. A powerful processor runs the imp OS.

“You only need to supply an SD card socket (and a few other components) to your product to give it connectivity,” Bachiochi says. “The imp’s processor has the power to run your entire product if you wish, or it can be connected via one of the supported serial protocols. The imp OS provides secure connectivity to the imp cloud. The imp cloud keeps your imp updated with the latest firmware, features online development tools, and provides cloud-side services for every imp in the field.”

“As with many cloud service organizations, development is generally free,” Bachiochi adds. “Once you’ve committed and have product rollout, the service will charge for its use. This could be a flat fee, a per-connection or data throughput fee, or a combination of fees. Basically you (or your customer) will have to pay to have access to the information, which pays for the support framework that keeps it all working.”

In his article, Bachiochi dives into a straightforward data-collection project to demonstrate how to use the imp in a product. The goal of his application was to log the activity of 220-V water pump and twin water softeners.  The project is the launching point for his comprehensive and detailed look at the imp’s hardware, software, and costs.

“It’s easy to design product hardware to use the imp,” he says. “There are two imp models, a card that can be inserted into an SD-type socket or an on-board module that is soldered into your product. Each version has advantages and disadvantages.”

Regarding software, Bachiochi says:

“Developing an imp application requires two parts to provide Wi-Fi access to your project: the device code (running in the imp) and the agent code (running on the imp cloud). The imp cloud, which is your connection to your device via the imp APIs, provides you with a development IDE. Web-based development means there is nothing else you need to purchase or install on your PC. Everything you need is available through your browser anytime and anywhere.”

Bachiochi also discusses the Electric Imp platform’s broader goals. While an individual can use the imp for device connectivity, a bigger purpose is to enable manufacturers to provide convenient Internet access as part of their product, Bachiochi says.

“The imp has two costs: The hardware is simple, it currently costs approximately $25 for an imp card or module. If you are using this in your own circuit within your own network, then you’re done,” he says. “If you want to roll out a product for sale to the world, you must take the next step and register for the BlinkUp SDK and Operations Console, which enable you to create and track factory-blessed products.”

BlinkUp, according to the Electric Imp website, integrates smoothly into apps and enables manufacturers and their customers to quickly connect products using a smartphone or tablet. The Operations Console enables tracking product activity and updating product firmware at any time, Bachiochi says.

The imp offers more than a low-cost way for DIYers and developers to connect devices to the Internet, Bachiochi says. A designer using the imp can save project costs by eliminating a microcontroller, he says. “Almost any peripheral can be easily connected to and serviced by the imp’s 32-bit Cortex M3 processor running the imp OS. All code is written in Squirrel.”

Bachiochi’s comprehensive article about his imp experience and insights can be found in the March issue, now available for membership download or single-issue purchase.

Bachiochi used the Electric IMP IDE to develop this code. Agent code on the top left runs on the imp cloud server. The device code on the top right is downloaded into the connected imp.

Bachiochi used the Electric IMP IDE to develop this code. Agent code on the top left runs on the imp cloud server. The device code on the top right is downloaded into the connected imp.

An Engineer Who Retires to the Garage

Jerry Brown, of Camarillo, CA, retired from the aerospace industry five years ago but continues to consult and work on numerous projects at home. For example, he plans to submit an article to Circuit Cellar about a Microchip Technology PIC-based computer display component (CDC) he designed and built for a traffic-monitoring system developed by a colleague.

Jerry Brown sits at his workbench. The black box atop the workbench is an embedded controller and is part of a traffic monitoring system he has been working on.

Jerry Brown sits at his workbench. The black box atop the workbench is an embedded controller and part of  his traffic monitoring system project.

“The traffic monitoring system is composed of a beam emitter component (BEC), a beam sensor component (BSC), and the CDC, and is intended for unmanned use on city streets, boulevards, and roadways to monitor and record the accumulative count, direction of travel, speed, and time of day for vehicles that pass by a specific location during a set time period,” he says.

Brown particularly enjoys working with PWM LED controllers. Circuit Cellar editors look forward to seeing his project article. In the meantime, he sent us the following description and pictures of the space where he conceives and executes his creative engineering ideas.

Jerry's garage-based lab.

Brown’s garage-based lab.

My workspace, which I call my “lab,” is on one side of my two-car garage and is fairly well equipped. (If you think it looks a bit messy, you should have seen it before I straightened it up for the “photo shoot.”)  

I have a good supply of passive and active electronic components, which are catalogued and, along with other parts and supplies, are stored in the cabinets and shelves alongside and above the workbench. I use the computer to write and compile software programs and to program PIC flash microcontrollers.  

The photos show the workbench and some of the instrumentation I have in the lab, including a waveform generator, a digital storage oscilloscope, a digital multimeter, a couple of power supplies, and a soldering station.  

The black box visible on top of the workbench is an embedded controller and is part of the traffic monitoring system that I have been working on.

Instruments in Jerry's lab include a waveform generator, a digital storage oscilloscope, a digital multimeter, a couple of power supplies, and a soldering station.

Instruments in Brown’s lab include a waveform generator, a digital storage oscilloscope, a digital multimeter, a couple of power supplies, and a soldering station. 

Brown has a BS in Electrical Engineering and a BS in Business Administration from California Polytechnic State University in San Luis Obispo, CA. He worked in the aerospace industry for 30 years and retired as the Principal Engineer/Manager of a Los Angeles-area aerospace company’s electrical and software design group.

Wireless Data Links (Part 1)

In Circuit Cellar’s February issue, the Consummate Engineer column launches a multi-part series on wireless data links.

“Over the last two decades, wireless data communication devices have been entering the realm of embedded control,” columnist George Novacek says in Part 1 of the series. “The technology to produce reasonably priced, reliable, wireless data links is now available off the shelf and no longer requires specialized knowledge, experience, and exotic, expensive test equipment. Nevertheless, to use wireless devices effectively, an engineer should understand the principles involved.”

Radio communicationsPart 1 focuses on radio communications, in particular low-power, data-carrying wireless links used in control systems.

“Even with this limitation, it is a vast subject, the surface of which can merely be scratched,” Novacek says. “Today, we can purchase ready-made, low-power, reliable radio interface modules with excellent performance for an incredibly low price. These devices were originally developed for noncritical applications (e.g., garage door openers, security systems, keyless entry, etc.). Now they are making inroads into control systems, mostly for remote sensing and computer network data exchange. Wireless devices are already present in safety-related systems (e.g., remote tire pressure monitoring), to say nothing about their bigger and older siblings in remote control of space and military unmanned aerial vehicles (UAVs).”

An engineering audience will find Novacek’s article a helpful overview of fundamental wireless communications principles and topics, including RF circuitry (e.g., inductor/capacitor, or LC, circuits), ceramic surface acoustic wave (SAW) resonators, frequency response, bandwidth, sensitivity, noise issues, and more.

Here is an article excerpt about bandwidth and achieving its ideal, rectangular shape:

“The bandwidth affects receiver selectivity and/or a transmitter output spectral purity. The selectivity is the ability of a radio receiver to reject all but the desired signal. Narrowing the bandwidth makes it possible to place more transmitters within the available frequency band. It also lowers the received noise level and increases the selectivity due to its higher Q. On the other hand, transmission of every signal but a non-modulated, pure sinusoid carrier—which, therefore, contains no information—requires a certain minimum bandwidth. The required bandwidth is determined by the type of modulation and the maximum modulating frequency.

“For example, AM radios carry maximum 5-kHz audio and, consequently, need 10-kHz bandwidth to accommodate the carrier with its two 5-kHz sidebands. Therefore, AM broadcast stations have to be spaced a minimum of 20 kHz apart. However, narrowing the bandwidth will lead to the loss of parts of the transmitted information. In a data-carrying systems, it will cause a gradual increase of the bit error rate (BER) until the data becomes useless. At that point, the bandwidth must be increased or the baud rate must be decreased to maintain reliable communications.

“An ideal bandwidth would have a shape of a rectangle, as shown in Figure 1 by the blue trace. Achieving this to a high degree with LC circuits can get quite complicated, but ceramic resonators used in modern receivers can deliver excellent, near ideal results.”

Figure 1: This is the frequency response and bandwidth of a parallel resonant LC circuit. A series circuit graph would be inverted.

Figure 1: This is the frequency response and bandwidth of a parallel resonant LC circuit. A series circuit graph would be inverted.

To learn more about control-system wireless links, check out the February issue now available for membership download or single-issue purchase. Part 2 in Novacek’s series discusses transmitters and antennas and will appear in our March issue.

Experimenting with Dielectric Absorption

Dielectric absorption occurs when a capacitor that has been charged for a long time briefly retains a small amount of voltage after a discharge.

“The capacitor will have this small amount of voltage even if an attempt was made to fully discharge it,” according to the website wiseGEEK. “This effect usually lasts a few seconds to a few minutes.”

While it’s certainly best for capacitors to have zero voltage after discharge, they often retain a small amount through dielectric absorption—a phenomenon caused by polarization of the capacitor’s insulating material, according to the website. This voltage (also called soakage) is totally independent of capacity.

At the very least, soakage can impair the function of a circuit. In large capacitor systems, it can be a serious safety hazard.

But soakage has been around a long time, at least since the invention of the first simple capacitor, the Leyden jar, in 1775. So columnist Robert Lacoste decided to have some “fun” with it in Circuit Cellar’s February issue, where he writes about several of his experiments in detecting and measuring dielectric absorption.

Curious? Then consider following his instructions for a basic experiment:

Go down to your cellar, or your electronic playing area, and find the following: one large electrolytic capacitor (e.g., 2,200 µF or anything close, the less expensive the better), one low-value discharge resistor (100 Ω or so), one DC power supply (around 10 V, but this is not critical), one basic oscilloscope, two switches, and a couple of wires. If you don’t have an oscilloscope on hand, don’t panic, you could also use a hand-held digital multimeter with a pencil and paper, since the phenomenon I am showing is quite slow. The only requirement is that your multimeter must have a high-input impedance (1 MΩ would be minimum, 10 MΩ is better).

Figure 1: The setup for experimenting with dielectric absorption doesn’t require more than a capacitor, a resistor, some wires and switches, and a voltage measuring instrument.

Figure 1: The setup for experimenting with dielectric absorption doesn’t require more than a capacitor, a resistor, some wires and switches, and a voltage measuring instrument.

Figure 1 shows the setup. Connect the oscilloscope (or multimeter) to the capacitor. Connect the power supply to the capacitor through the first switch (S1) and then connect the discharge resistor to the capacitor through the second switch (S2). Both switches should be initially open. Photo 1 shows you my simple test configuration.

Now turn on S1. The voltage across the capacitor quickly reaches the power supply voltage. There is nothing fancy here. Start the oscilloscope’s voltage recording using a slow time base of 10 s or so. If you are using a multimeter, use a pen and paper to note the measured voltage. Then, after 10 s, disconnect the power supply by opening S1. The voltage across the capacitor should stay roughly constant as the capacitor is loaded and the losses are reasonably low.

Photo 1: My test bench includes an Agilent Technologies DSO-X-3024A oscilloscope, which is oversized for such an experiment.

Photo 1: My test bench includes an Agilent Technologies DSO-X-3024A oscilloscope, which is oversized for such an experiment.

Now switch on S2 long enough to fully discharge the capacitor through the 100-Ω resistor. As a result of the discharge, the voltage across the capacitor’s terminals will quickly become very low. The required duration for a full discharge is a function of the capacitor and resistor values, but with the proposed values of 2,200 µF and 100 Ω, the calculation shows that it will be lower than 1 mV after 2 s. If you leave S2 closed for 10 s, you will ensure the capacitor is fully discharged, right?

Now the fun part. After those 10 s, switch off S2, open your eyes, and wait. The capacitor is now open circuited, at least if the voltmeter or oscilloscope input current can be neglected, so the capacitor voltage should stay close to zero. But you will soon discover that this voltage slowly increases over time with an exponential shape.

Photo 2 shows the plot I got using my Agilent Technologies DSO-X 3024A digital oscilloscope. With the capacitor I used, the voltage went up to about 120 mV in 2 min, as if the capacitor was reloaded through another voltage source. What is going on here? There aren’t any aliens involved. You have just discovered a phenomenon called dielectric absorption!

Photo 2: I used a 2,200-µF capacitor, a 100-Ω discharge resistor, and a 10-s discharge duration to obtain this oscilloscope plot. After 2 min the voltage reached 119 mV due to the dielectric absorption effect.

Photo 2: I used a 2,200-µF capacitor, a 100-Ω discharge resistor, and a 10-s discharge duration to obtain this oscilloscope plot. After 2 min the voltage reached 119 mV due to the dielectric absorption effect.

Nothing in Lacoste’s column about experimenting with dielectric absorption is shocking (and that’s a good thing when you’re dealing with “hidden” voltage). But the column is certainly informative.

To learn more about dielectric absorption, what causes it, how to detect it, and its potential effects on electrical systems, check out Lacoste’s column in the February issue. The issue is now available for download by members or single-issue purchase.

Lacoste highly recommends another resource for readers interested in the topic.

“Bob Pease’s Electronic Design article ‘What’s All This Soakage Stuff Anyhow?’ provides a complete analysis of this phenomenon,” Lacoste says. “In particular, Pease reminds us that the model for a capacitor with dielectric absorption effect is a big capacitor in parallel with several small capacitors in series with various large resistors.”