Electronics Engineering Crossword (Issue 266)

The answers to Circuit Cellar’s September electronics engineering crossword puzzle are now available.

Across

3.     ZUSE—German engineer inventor and engineer (1910–1995) who is credited with creating the Z3, a program-controlled Turing-complete computer

5.     ROOTMEANSQUARE—Alternating voltage/current with the exact same energy content as the same value of direct current; a.k.a., quadric mean [three words]

10.   BLOB—Stores binary data; synonym: drop

13.   KLYSTRON—A specialized linear-beam vacuum tube

16.   ELECTROMAGNET—English physicist and inventor William Sturgeon (1783-1850) is credited with using electric current to develop the first one of these objects in 1825

17.   LACOSTE—Circuit Cellar columnist who frequently writes about frequency

18.   SMARTSWITCH—An energy-saving device that was the topic of Fergus Dixon’s article (Circuit Cellar, 263 2012) [two words]

19.   PICOAMMETER—Measures low current

Down

1.     PUBLICKEYCRYPTOGRAPHY—Decodes using two pieces of information, one public and one private [three words]

2.     COMPRESSIONDRIVER—A loudspeaker that achieves high efficiencies by using a consolidating technique [two words]

4.     SPIDER—The flexible collar that helps keep a voice coil magnetically centered

6.     MICROPOWERIMPULSERADAR—A pocket-sized radar that runs off AA batteries and is often used as a basic motion sensor for security applications [three words]

7.     ALPHATESTING—Check performed by an independent team on a system installed at a place other than the targeted customer’s site [two words]

8.     ATOMICOPERATION—An action that is non-interruptible by any other one and never presents partial results to an outside observer [two words]

9.     EMBEDDED—As Circuit Cellar prepares to celebrate its 25th anniversary, a  past, present, and future key theme of the magazine centers on this type of technology

11.   SIGNALPROCESSING—Involves measuring physical quantities with time and spatial variances [two words]

12.   FLOWCHARTING—Jeff Bachiochi describes how to use this technique to write code in this issue

14.   CONVOLUTION—Mark Csele’s article, “DSP-Based Color Organ” (Circuit Cellar, 249 2012), used this technique to create high-performance filters

15.   MULTIPLEXER—A device that combines input signals, shares a single transmission channel, and enables data compression

 

Q&A: Miguel Sanchez (Professor, Designer)

Miguel Sánchez (PhD, Computer Science) is Valencia, Spain-based computer scientist, embedded tech enthusiast, and professor who regularly challenges himself to design innovative microcontroller-based systems. Since 2005, Circuit Cellar has published six of his articles about projects such as a digital video recorder (Circuit Cellar 174) and a creative DIY image-processing system (Circuit Cellar 263).

This is a sample depth image projected in a 3-D space. It appeared in Sanchez’s article, “Image Processing System Development.” (Source: M. Sanchez, Circuit Cellar 263)

In the September issue of Circuit Cellar, Sánchez tells us about his background, his work at the Universitat Politècnica de València, his current interests, and his innovative designs. An abridged version of the interview follows.

NAN PRICE: How long have you been designing microcontroller-based systems?

MIGUEL SANCHEZ: I started using computers in 1978. I built my first microcontroller project in 1984 during my first year at Universitat Politècnica de València. I haven’t stopped designing embedded systems since then.

NAN: Tell us about the first microcontroller you worked with. Where were you at the time?

MIGUEL: Our university’s lab had Intel SDK-85 boards you could program in Hex using the built-in keyboard. I guess it wasn’t built well. You sometimes lost all your work while typing your code. I learned that schematics were available and a terminal monitor was built in too. So, I built my first microcontroller-based board around an Intel 8085 using the same software that was on the original ROM. But, I changed the serial port delay value so I could use 9,600 bps instead of the original 110 bps on the terminal port. This way, I could do the same labs as my mates, but I could do my work in 8080 Assembler, which was available in Control Program/Monitor (CP/M) computers. At the time, I had an Atari 1040 ST that could run CP/M on top of a Z-80 emulator. Assembly code could be uploaded to my board’s RAM memory and later executed using SDK-85 serial monitor code.

I used the 8085’s Wait signal to build an additional EEPROM socket in this same board that, with the aid of a 555 timer, was my first EEPROM programmer. I used the Wait signal to delay write operations. In fact, I used this programmer to change the original baud rate to the new one, as I originally did not know that was something I’d want to change later.

My teacher, who is now one of my colleagues, was quite amused with my development and he gave me an A+. I learned a lot about microcontrollers, serial communications, Assembly language, monitor programs, and EEPROM programming algorithms. And, I learned it was not fun to design PCBs with system buses on only one copper layer. …

NAN: You designed a system to simulate strokes on a keypad to trigger modes on an alarm system (“Reverse-Engineered ECP Bus,” Circuit Cellar 201, 2007). Why did you design it and how have you used it?

MIGUEL: A local company wanted to give new life to old Ademco alarm units. These boards could only be programmed by a serial port socket once a certain service code was typed at the keyboard. I was asked whether an add-on board could be created to make these old boards Internet-enabled so they could be remotely managed and reconfigured over the ’Net.

The first thing I needed to do was to figure out how to simulate the required keystrokes. But I couldn’t find any information about the way that bus worked, so I figured that out myself. Later, I thought both the information itself and the way I figured it out might be useful to others, so I approached Circuit Cellar editors with a proposal to write an article.

That project ended up as a Rabbit-core powered board that connected the alarm board and the remote access to its serial port. Combined with a virtual serial port on the PC, it fooled the original management software into thinking the PC was directly connected to the alarm board, although it was all happening over the Internet. But the project never made it to the market for reasons unknown.

NAN: In “Three-Axis Stepper Controller” (Circuit Cellar 234, 2010), you describe how you built an Arduino-based, platform-independent driver board. Tell us about the design.

MIGUEL: When I discovered the Arduino platform, I was surprised by a few things. First, this development system was not designed by a chip vendor. Second, it was not intended for engineers but for artists! Third, I was shocked because it was multiplatform (which was possible because it was based on Java and GCC) and because none of the other development systems I was aware of were so easy to use. The price was low too, which was a plus for hobbyists and students.

The aim of that project was to show all that to the readers. The idea was also not only to show how to build a stepper controller and to explain the difference between the drive modes and the bipolar and unipolar designs, but to demonstrate how easy it was to work with Arduino.

In his 2010 article, “Three-Axis Stepper Controller,” Sanchez provided this controller circuit schematic to interface Arduino I/O headers with stepper motors. (Source: M. Sanchez, Circuit Cellar 234)

NAN: Your most recent Circuit Cellar article, “Image Processing System Development: Use an MCU to Unleash the Power of Depth Cameras” (263, 2012), describes how you used Microsoft’s Kinect motion-sensing device for an interactive art project. Tell us about the project and how you came to be involved.

MIGUEL: My university offers a master’s degree in fine arts. I met a professor from the drawing department who had seen a video of my vertical plotter on YouTube and was interested in contacting me, as we worked on the same campus. We became friends and he asked me to help him out with an idea for an installation.

The first approach used an RGB camera, but then Kinect was launched. From what I read on the ’Net, I was convinced it would be a better mousetrap. So, I bought one unit and started learning how to use it, thanks to the hack that had been made available.

The project required gathering visitors’ silhouettes and later drawing them on a big wall. The drawing was performed with a properly scaled-up version of my vertical plotter, which, by the way, was controlled by an Arduino board.

I have found working with artists is a lot of fun too, as they usually have a totally different vision than engineers.

The full article appears in the September issue.

Issue 266: EQ Answers

The answers to the Circuit Cellar 266 (July 2012) Engineering Quotient are now available. The problems and answers are listed below.

Problem 1—What’s the key difference between infinite impulse response (IIR) and finite impulse response (FIR) digital filters?

Answer 1—An infinite impulse response (IIR) filter incorporates feedback in its datapath, which means that any particular input sample can affect the output for an indefinite (infinite) time into the future. In contrast, a finite impulse response (FIR) filter uses only feedforward in its datapath, which means that any given input sample can only affect the output for a time corresponding to the number of storage (delay) stages in the filter.

Problem 2—Does the fact that the finite resolution of digital arithmetic effectively truncates the impulse response of an IIR filter turn it into an FIR filter?

Answer 2—While it’s technically true that the impulse response of an IIR filter implemented, say, with fixed-point arithmetic is effectively finite, this has no real bearing on its classification in terms of either its design or application. It’s still an IIR filter for all practical purposes.

Problem 3—The following pseudocode represents an implementation of a single-pole low-pass IIR filter, using 16-bit input and output values and a 24-bit internal accumulator and a filter coefficient of 1/256:


  # The 32-bit accumulator holds 16 integer
  # and 16 fractional bits
  $acc = 0x00000000;

  # The input value is a 16-bit integer.
  $input = 0xFFFF;

  # Offset used for rounding the accumulator
  # to 24 bits.
  $offset = 0x80;

  while (1) {
    # acc = (255*acc + input)/256
    $acc -= ($acc >> 8);
    $acc += ($input << 8) + $offset;
    # limit acc to 24 bits
    $acc &= 0xFFFFFF00;
    # output is integer part of acc
    $output = $acc >> 16;
  }

An implementor of this filter complained that “the output never reaches 0xFFFF.” What was the flaw in his reasoning?

Answer 3—The accumulator in this filter eventually settles at the value 0xFFFE8100. If you simply take the upper 16 bits of this, then the output value appears to be 0xFFFE. But if you properly round the accumulator by adding 0x00008000 before dropping the LSBs, then the output value is the correct value of 0xFFFF.

Problem 4—The original implementor’s solution was to change the $offset value to 0xFF. Why did this work?

Answer 4—Changing the $offset value to 0xFF effectively adds a bias to each input sample, which averages out to 0x00007F00 in the accumulator. The effect of this is to add the required rounding offset to the accumulator so that truncating the LSBs to create the 16-bit output value comes up with the correct answer.

.

Issue 266: An Engineer’s Communication Protocol

Electrical engineers and embedded programmers can expect to work several different jobs over the course of their careers. In the mid- to late-20th century, an engineer could expect to find a job with a large company, work it for 25 or 30 years, and then retire with a pension. But today things are different. For instance, over a 20-year period, the average engineer or programmer who reads Circuit Cellar might work for a handful of different corporations, start a business, work on contract projects, and even bill hours as a consultant. Others will move between industry and academia, serve as managers, and hold positions on corporate boards.

To excel during the course of a long tech career in the 21st century, you’ll need to continuously hone your communication skills much like you do your hardware and software abilities. You must practice self awareness in order to assess your amiability, approachability, and listening skills. And you should continuously endeavor to keep your communication skills up to snuff by staying on top of advances in social media and business-standard communication protocols. While some jobs will require you to work long hours alone, the success of others will require you to check your ego at the door and let your client have his or her say. It won’t be easy. But the sooner you start focusing on strengthening your communication skills the better off you’ll be. As Steve Ciarcia notes in “Managing Expectations” (Circuit Cellar 266), your success will be based on “the art of managing expectation in the eyes of others.” Ciarcia writes:

I have a theory. People are a lot more comfortable when they can predict the future, or at least if they think they can. Look at all the resources we put into forecasting the weather or economic conditions, despite the fact that we know these are complex, chaotic systems whose sensitivity to initial conditions makes any long-term predictions less dependable. This applies on a personal level, too. We have developed protocols that help us interact with each other. We say “hello” when we pick up the phone. We shake hands when we meet for the first time. These protocols (i.e., “social customs”) help us control the process of learning about each other—what we need and what we can provide in a relationship.

Communication “protocol” is particularly important in the relationship between an engineer and his client. There is a huge amount of diversity in such a relationship. Unstated assumptions can lead to enormous gaps in expectations resulting in disappointment, frustration, anger, or even legal action in extreme cases.

Despite the fact that human resource types tend to treat engineers as interchangeable cogs in a machine, individual engineers may have distinctly different talents. Some have extensive expertise in a particular technology. Others have more general system-level design skills along with an ability to pick up the finer points of new technologies “on the fly.” Some are good at communicating with clients and developing system concepts from vague requirements, while others need to dig into the minutiae of functional specifications before defining low-level implementation details.

As an engineer, it is important to recognize where your talents lie in this broad spectrum of possibilities, and to be honest about them when describing yourself to coworkers and potential clients. Be especially careful with people who are going to represent you to others, such as headhunters and engineering services brokers. Resist the urge to “inflate” your capabilities. They’ll be doing that on your behalf, and you don’t want to compound the problem.

Similarly, engineering services customers come in all shapes and sizes. Some only have a vague product idea they want to develop, while others may have a specific description of what needs to be solved. Some small companies will want you to manage the entire product development process, while larger ones have management systems (i.e., bureaucracies) and will expect you to work within established procedures. Some will want you to work onsite using their equipment, while others will expect you to have your own workspace, support infrastructure, elaborate test equipment, and so forth.

In any case, from the customer’s point of view, there are risks to using outside engineering services. How much are they going to have to spend? What are the chances of success at that level of expenditure? Unless there are unusually large, nonrecurring engineering (NRE) charges associated with the project, labor will be the customer’s biggest expense. The obvious question is: How much time is it going to take? These are questions that are sometimes difficult to answer at a project’s inception, especially if the requirements are poorly defined. It may become necessary to guide the customer through a process of discovery that delineates individual project steps in terms of cost and accomplishment for each step. These early iterations could include things like a feasibility study or a detailed functional specification.

Generally, the customer is going to ask for a fixed-price arrangement, but beware. As the engineer, this means you are assuming all the risk. If the schedule slips or problems crop up, you are the one who will take the loss. Fixed-price contracts are a tough equilibrium. Invariably, they involve padding time estimates to balance the risk-benefit ratio, but not so much that you price yourself out of the job in the first place. A better consulting situation is a time and materials contract that puts more of the risk back on the customer and provides flexibility for unforeseen glitches. Knowledgeable customers should understand and be okay with this.

The point is, you need to be willing to take the lead and let the customer know what is happening now and every step of the way. That way, they don’t get surprised, particularly in a negative way. Since we can’t assume every consulting customer is reading my editorial, it’s up to you to explain these issues. Do it right, and you’ll have a positive foundation on which to build your relationship. And, even though I have been directing my remarks primarily to independent consultants and contractors, as an engineer, you are providing your services to others. Even as a full-time employee in a company where your only “customers” are other departments (i.e., manufacturing or testing), these principles still apply. While your present salary is a given, its future progress and longevity is all about the art of managing expectations in the eyes of others.

Circuit Cellar 266 (September 2012) is now available.

CC266: Microcontroller-Based Data Management

Regardless of your area of embedded design or programming expertise, you have one thing in common with every electronics designer, programmer, and engineering student across the globe: almost everything you do relates to data. Each workday, you busy yourself with acquiring data, transmitting it, repackaging it, compressing it, securing it, sharing it, storing it, analyzing it, converting it, deleting it, decoding it, quantifying it, graphing it, and more. I could go on, but I won’t. The idea is clear: manipulating and controlling data in its many forms is essential to everything you do.

The ubiquitous importance of data is what makes Circuit Cellar’s Data Acquisition issue one of the most popular each year. And since you’re always seeking innovative ways to obtain, secure, and transmit data, we consider it our duty to deliver you a wide variety of content on these topics. The September 2012 issue (Circuit Cellar 266) features both data acquisition system designs and tips relating to control and data management.

On page 18, Brian Beard explains how he planned and built a microcontroller-based environmental data logger. The system can sense and record relative light intensity, barometric pressure, relative humidity, and more.

a: This is the environmental data logger’s (EDL) circuit board. b: This is the back of the EDL.

Data acquisition has been an important theme for engineering instructor Miguel Sánchez, who since 2005 has published six articles in Circuit Cellar about projects such as a digital video recorder (Circuit Cellar 174), “teleporting” serial communications via the ’Net (Circuit Cellar 193), and a creative DIY image-processing system (Circuit Cellar 263). An informative interview with Miguel begins on page 28.

Turn to page 38 for an informative article about how to build a compact acceleration data acquisition system. Mark Csele covers everything you need to know from basic physics to system design to acceleration testing.

This is the complete portable accelerometer design. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

In “Hardware-Accelerated Encryption,” Patrick Schaumont describes a hardware accelerator for data encryption (p. 48). He details the advanced encryption standard (AES) and encourages you to consider working with an FPGA.

This is the embedded processor design flow with FPGA. a: A C program is compiled for a softcore CPU, which is configured in an FPGA. b: To accelerate this C program, it is partitioned into a part for the software CPU, and a part that will be implemented as a hardware accelerator. The softcore CPU is configured together with the hardware accelerator in the FPGA.

Are you now ready to start a new data acquisition project? If so, read George Novacek’s article “Project Configuration Control” (p. 58), George Martin’s article “Software & Design File Organization” (p. 62), and Jeff Bachiochi’s article “Flowcharting Made Simple” (p. 66) before hitting your workbench. You’ll find their tips on project organization, planning, and implementation useful and immediately applicable.

Lastly, on behalf of the entire Circuit Cellar/Elektor team, I congratulate the winners of the DesignSpark chipKIT Challenge. Turn to page 32 to learn about Dean Boman’s First Prize-winning energy-monitoring system, as well as the other exceptional projects that placed at the top. The complete projects (abstracts, photos, schematic, and code) for all the winning entries are posted on the DesignSpark chipKIT Challenge website.