Author Archives: Pete Lewis

Enginursday: Two-Wheeled Robot Precision Driving with Encoder Feedback

via SparkFun: Commerce Blog

My challenge seemed simple enough: I wanted to make a two-wheeled robot drive a straight line using feedback from a set of wheel encoders. Little did I know that this would open the doors into the vast world of PID motor control!

Two wheeled rover drives a straight line outward then turns around and returns

Background

Prior to starting this project, my experience with two-wheeled desktop robots had been pretty minimal. I had helped teach a few classes to educators using the SparkFun Redbot - this involved helping our participants get set up and coding challenges such as line-following and driving a pattern. We used manual “trial and error” to match motor speeds, and then used delays to control distance traveled. Although this is a wonderful introduction to coding and robotics, it’s not quite ideal for driving a very straight line and/or a precise distance. Seeing these challenges in the classroom planted the seed for this project. I knew there had to be a fun way to incorporate some high resolution encoders to augment driving control!

Hardware and approach

After researching many options, I ultimately decided to go with the Qwiic Motor Driver, a set of geared DC motors that included quadrature encoders, and a Raspberry Pi 4 as the master brain.

Using a Raspberry Pi 4 as the controller had two very handy benefits: First, my program would be written in Python, and second, I was excited to have the capability to adjust the code and see streaming data in real time via a Wifi and VNC viewer.

Choosing a method to read the encoders was a bit of a longer story. My previous experience with encoders involved user interfaces and turning knobs. This involved a lot of interrupts firing to keep track of the pulses and ultimately a “position from zero.” Although it would be possible to wire up the encoders directly to GPIO on the Raspberry Pi, I wasn’t interested in bogging down my Python program with interrupts.

I ultimately found the SparkFun Qwiic Twist, and decided to do something similar. The Twist utilizes an ATTiny84 to handle reading a single encoder. It keeps track of a count variable that is then easily read from the Twist via I2C. I chose to use this design and firmware as a starting point.

alt text

I stripped out the LED and button control and was able to utilize a second interrupt and more GPIO to read a second encoder. Wahoo! I had my dual encoder reader, and my counts would be available on the I2C bus!

alt text

To modify the Twist firmware I actually developed with an Arduino Redboard Qwiic first (acting as an alternative to the ATTiny84). This allowed me to use the UART port for debug while finishing up the modifications to the firmware (most importantly, adding support for a second encoder).

Let’s drive!

After wiring everything up, I simply set the motors to the same “power” and watched what happened. Wow, motors can vary a lot! My robot was turning sharply to the left, meaning that the right motor was actually out-performing the left motor by a lot. Now it was time to jump into some encoder counts and see if we could correct this difference!

This is the portion of my code that commands driving the straight line:

for i in range(0,300):
    count12_delta = myEncoders.count1 - (-myEncoders.count2)
    error_change = count12_delta - prev_count12_delta
    motor_speed_correction = count12_delta
    motor_speed_correction *= P_gain #proportional adjustment
    motor_speed_correction += (I_gain * error_change) #integral adjustment, looks at the change in error, if it gets smaller, than slow down the correction
    left_motor_speed -= motor_speed_correction
    myMotors.set_drive(L_MTR, L_FWD, (left_motor_speed))
    print("1:%d \t2:%d \tLS:%d \tRS:%d \tCD:%d \tEr:%d \tMC:%d" % \
                  (myEncoders.count1, -myEncoders.count2, left_motor_speed, right_motor_speed, count12_delta, error_change, motor_speed_correction))
    prev_count12_delta = count12_delta

As you can see here, I'm using a very simplified quazi-PID control system. You may also note that I'm not yet incorporating a derivative correction (this may come as a later improvement).

To start, I look at the delta between each count, and then deciding whether to adjust the left motor by a specific amount (motor_speed_correction). The correction is actually set initially as just the difference in counts, and then my proportional gain is amplifying this by a set gain (P_gain). The integral adjustment comes from looking at the change in the error. If the change in error is getting smaller, then it adjusts the amount of correction.

The turn around portion of the code looks like this:

for i in range(0,300):
    count12_delta = abs(myEncoders.count1) - (-myEncoders.count2)
    error_change = count12_delta - prev_count12_delta
    motor_speed_correction = count12_delta
    motor_speed_correction *= P_gain #proportional adjustment
    motor_speed_correction += (I_gain * error_change) #integral adjustment, looks at the change in error, if it gets smaller, than slow down the correction
    left_motor_speed -= motor_speed_correction
    myMotors.set_drive(L_MTR, L_BWD, (left_motor_speed))
    print("1:%d \t2:%d \tLS:%d \tRS:%d \tCD:%d \tEr:%d \tMC:%d" % \
                  (myEncoders.count1, -myEncoders.count2, left_motor_speed, right_motor_speed, count12_delta, error_change, motor_speed_correction))
    if(myEncoders.count1 < -575):
        break
    prev_count12_delta = count12_delta

It is very similar to the straight line command, however I now flip the direction of the left motor and took the absolute value of its count. Then I also added in a check on count1 to break out of this for loop once the desired rotational travel has been reached. In this case, the value 575 seemed to be about a perfect 180-degree turn.

Going further

I have two things I'd like to try next:

  • I intend to look at each motor's speed (rather than just looking at the current count value). This would allow me to try and match each motors speed individually. I gave it a shot in the Python code, but I would really love to offload the speed calculations to the ATTiny84, so that will involve modifying that firmware again.
  • I would also like to improve upon my PID method. Currently, I am actually only incorporating the proportional and integral gains, so I would like to modify this eventually to include a derivative correction.

Do you have any experience with driving similar desktop rovers? Any ideas for improving my system would be much appreciated. Thanks, and happy driving!

comments | comment feed

Enginursday: Secure DIY Garage Door Opener

via SparkFun: Commerce Blog

Are you concerned with the security weaknesses found in most garage door openers? Join us as we highlight a DIY solution using the SparkFun Cryptographic Co-processor. Using all Qwiic boards, we created a super-secure garage door opener!

We've also written a complete tutorial on how to create your own. Check that out here:

New!

Secure DIY Garage Door Opener

January 16, 2020

Did you know that most garage doors are at risk of a roll jam attack? Here we make a DIY garage door remote-control system that is much more secure than most commercial-ready products using the latest in ECC cryptography.

At its core, this project is a wireless button controller, so it could be used for many other applications. The next step is upping the security of the car key FOB to avoid roll-jam attacks. What might you use this security for?

comments | comment feed

Enginursday: Ten Years of Testbeds

via SparkFun: Commerce Blog

Since SparkFun's humble beginnings, testbeds have been a vital part of our production. In the wake of innovation, many of them get retired. Every couple years, the quality control team looks through all of the testbeds down in production. During these audits, they usually find 50 or so that need to be retired.

I was always sad to see them get pulled from the shelves in production because there is usually a lot of blood, sweat and tears that go into each of these designs. I myself played a large part in a lot of their development, so I started collected them throughout the years. A lot of them were disassembled, and their parts were re-purposed in other designs, but I also kept some of the more unique ones in a box. I knew I'd put them on display someday, but I wasn't quite sure how. About a year ago, I got motivated and set them all out on my table:

alt text

"Wow. That's a lot of testbeds."

The Plan: Mount them to clear acrylic!

After spending some time organizing them on a big table, it became quite clear that they needed to be mounted to some acrylic with sweet laser etching and light up with hundreds of addressable LEDs. Let the scope creep begin!

The first challenging part was to build the files necessary to laser cut all of the mounting holes. A co-worker chatted with me about the project, and he had the most ingenious idea as to how to create the mounting hole files: use an old-fashioned copy machine!

alt text

"Don't mind me. Nothing to see here."

We got a few strange looks as co-workers walked by, but managed to make some great image files that came out looking like this:

alt text

Photocopy machine image for Panel 0.

This dramatically sped up the design process. There was no measuring or spacing required. We simply placed the beds on top of the copy machine with the desired spacing, and hit print to PDF! Then we could simply import these files into Paint.net and place drill hits as needed. Wahoo!

alt text

The first four panels with all the testbeds mounted. The process is working!

The Frame

alt text

The custom, 30"x96" frame mounted.

The frame was built with three layers of wood. The backing was a solid piece of 3/4-inch plywood. Then we built an "inner" frame.

alt text

Close up of a corner. We got really lucky with the "bend points" on the LED strips.

This provided a nice, right-angled surface for the LEDs to stick to, and when we positioned the inner frame pieces, we were able to ensure that the LEDs were very tight up against the edge of each acrylic panel.

alt text

Escape channel for wiring.

On the bottom right corner, we cut the inner frame slightly short to allow for the power and control lines to escape.

alt text

Close up of the frame top layer.

The final layer is also made of 3/4-inch plywood blanks, and it was cut so that it would hang over the LEDs about 1/4-inch. This simply covers up the LEDs a bit and adds a nice finished look to the piece.

The Acrylic Etching

alt text

The large image etched behind all of the testbeds.

The design that is etched into the panels is actually the Flying Jalapeno Testbed brain. The left section is the top copper, the middle section is the bottom copper, and the far right is the schematic. We actually just printed to PDF straight from Eagle, then imported to Illustrator and did a little stretching to fit. We really loved how the ground pours came out as lines - unintentional, but nonetheless it looks awesome with the side-lit LEDs!

alt text

Our laser printer mid-print. Starting to look awesome!!

Each panel took over an hour to etch. We had five panels, so it took some time, but it was worth the wait! We had never done an Illustrator file with "panels," but it was actually quite easy to deal with and we used the "range" option to print each panel individually.

alt text

Here's the first panel etched with the testbeds staged for mounting.

It was so exciting to see it come together! Next up, we needed to mount all of the testbed. Even with just two screws per unit, it was quite a long time to get them all back on there!

The Lighting

To light up the acrylic, we mounted about six meters of our RGB LED strips of addressable APA102s. We needed 5.8 meters to make it all the way around the panels, so we combined a 5m strip and a 1m strip. They are pretty easy to solder together. Tip: cut the additional strip in the middle of the pads, but cut the preceding strip so that the entire pad is remaining. This way, when you overlap them before soldering, you have plenty of metal to get the solder to flow between sections.

alt text

In total, it was 498 LEDs. Running at 5V, we only saw our bench-top power supply showing up to 2.5A. We don't intend to ever turn on all LEDs at full brightness, so we opted for a small-ish power supply: the Mean Well LED Switching Power Supply - 5VDC, 5A, capable of providing 5 Amps of current at 5V, which should be plenty for our needs.

If you are interested in seeing some of the code that is currently controlling the LEDs, you can see it at the project GitHub repo here.

Testbed Bravo Charlie Echo Foxtrot

alt text

Close up shot of some of the earliest testbeds.

When I first started at SparkFun in 2007 as an assembly tech, most of the testing equipment was in a pile (including the testbed on the left: Testbed Bravo). If you needed to test something you just built (by hand), then you searched the shop for the testbed you needed, searched through a folder on the production computer (not backed up), and eventually found a paragraph of text that was the test procedure. If you couldn't find the testbed, you had to bug an engineer to help you get another setup going.

This was also in the days before using pogopins, so most of the connections made to a product during testing were made by holding a row of headers on the product onto a row of male headers on the breadboard. If you held it with just the right pressure, for just the right time, then you might get 50 percent of your boards to pass!

Most of the testing equipment was created by the engineer on the design, and it usually consisted of a breadboard setup and was only intended for testing the prototype. We didn't have time to design a better piece of hardware - we only had time to get the next little widget out. Eventually, the engineers helped design "testbed Alpha," which was a design intended to test many different products. Then came Bravo, then Charlie, all the way up to Foxtrot. Never made it to Golf!

These testbeds can be found on the bottom left of the installation. As you move right, you will see newer and newer designs.

The Edison Panel

alt text

An entire panel was dedicated to just the Edison testbeds.

The SparkFun Edison blocks were an ecosystem that supported the now retired Intel Edison. These testbeds required a large collaboration between the engineers and the quality control testbed design team. We worked together to keep the designs somewhat consistent. We even created custom Eagle parts for the "sub-board connectors."

The real challenge with this product (and testbed design) was the fine-pitched connector. We knew it was going to be difficult to get great yields in production, so we wanted to design testbeds that actually tested 100 percent of the pins for cold joints and jumpers. This requires some neat tricks with a technique we coined "saddle stitch" net testing. It was a slightly odd way to connect all of the unused pins so that you could quickly test for cold joints and jumpers.

alt text

Schematic screenshot of the "saddle stitch" testing method.

ProtoSnap

alt text

The ProtoSnap Pro Mini testbed

The ProtoSnap product line was not only an interesting product to develop, but it also required some creative solutions in production testing. The version shown above uses a technique to hold the board in place called "nubbins." You simply place the board down, and then turn the nubbins to lock it down. This worked okay, but it eventually needed to have something more ergonomic, and these testbeds were revised to use another technique called the "waffle top," where a custom layer on a hinge would come down to hold the board in place on top of the pogo pins. Along with its testbed, this product has also been retired, but it's fun to see the known-good board is still attached to this testbed, and to think how the ProtoSnap idea has since been incorporated in other products such as the BITalino and gator snaps.

The Penguin

alt text

Retired and still smiling.

Ah yes, everyone always asks about the penguin. This little testbed was for the Easy Driver, a stepper motor driver. The tech would simply place the product down on the testbed, and it would cause the motor driver to move back and forth. Why not attach a little model penguin to the motor? It sure was a crowd pleaser!

Closing Thoughts

alt text

It's up and running!

Overall, we are really pleased with how this turned out. It is mounted on a wall near our big open space where we have our weekly, company-wide meetings, and our engineering group design reviews. It is nice to know that it will get a lot of day-to-day traffic and hopefully remind people of our accomplishments, inspire greatness and just generally brighten up their day.

So often, we launch a product and then we jump on the next project and don't spend much time thinking about the accomplishment. It's important to take a moment once in a while and reflect back.

We're also excited to see if anyone wants to help write some code for new modes on this thing. A few people around here have shown interest, and so we intend to build this out to have at least a few more modes. If you have any interest, or simply want to see what some of your blinky APA102 code looks like on this installation, please comment below or hit us up on GitHub. We'd be happy to try it out!

Hope you can stop on by for a tour some Friday and see it in person!

Resources

Products used:

GitHub links:

If you are interested in testbed design and general quality control topics, then you might like to read some of our past blog posts on the subject matter. Check them out here:

comments | comment feed

Enginursday: Aerofest 2019

via SparkFun: Commerce Blog

On June 1st, the Longmont Innovation Center (IC) hosted their first Aerofest event. The day was filled with airshows, battles, races, vendor tents and food trucks. Many R/C pilots are makers at heart, and it felt much like SparkFun’s AVC. Best of all, it was great to see lots of youngsters getting interested in aeronautics. My four-year-old son and I had a blast watching the airplanes, and he even had a chance to build his own laser-cut glider.

Aerofest banner add showing a bunch of pilots launching their DIY aircrafts at the runway together

The IC has a focus on STEM education though many awesome programs including robotics, aeronautics, computer science and much more. Check out their website to learn more. Some of SparkFun's employees have participated in their mentoring opportunities, and it's a wonderful way to share experiences and help some young engineers with their projects, including atmospheric research, shark wands and Aquatic Robotics.

Aerofest was hosted by the IC's aeronautics program. Check out their YouTube channel to see some of their DIY aircraft in flight. They have many opportunities for high school students to learn to design, build and fly their own aircraft. Through a variety of courses, they learn about the iterative design process and many aeronautic engineering principles.

two high school students are pluggin in wires and attaching a wing to a scratch build DIY design of their own during the event.

Two high school students building an airplane of their own design from scratch design during the event.

The two students above are mounting the wing to fuselage of an aircraft they designed and built themselves. It was, by far, the largest aircraft at the event. They designed it this way not only to test their engineering skills for larger airframes and motor systems, but to also compete in a battle event. Most of the airframe was cut from foam board using the IC's in-house laser cutter, and pieced together with a healthy amount of hot glue. It was quite ambitious to build an aircraft from scratch the morning of the event, but they pulled it off!

a few airplanes lined up on the taxiway for the audience to look at

Lots of planes on display to get a closer look.

In addition to the many DIY laser cut airframes flying at the event, there were also plenty of traditional remote control airplanes out on display - most of these also flew at some point during the day. There were a couple scheduled aerobatic airshows and flying challenges, but at any given moment, you could look up and see someone flying around with the occasional loop or roll.

Some pilots getting ready to fly the DIY dragon plane

Preflight check for a DIY Dragon airplane.

Some teams of students had fun with the look of their DIY airplanes. This dragon sure looked awesome!

picture of an airplane that looks like a black dragon and the tail is broken only held on by a control string

The cracked tail on display for the afternoon

Unfortunately they had a bit of trouble on takeoff and after a couple moments of flight it came down hard on the runway. This broke the tail off, and they decided to fix it another day. All part of the design process!

close up shot of the tables where the glider kits were geting built up some kids hands and grown up hand helping with hot glue

Glider kits getting built up

The STEM zone was a great opportunity for anyone to build a glider and to have some fun with flight. The tables were crowded and glue guns were hot. Kids were popping all the parts out of the foamboard and building them up as fast as possible.

a child holding up his complete glider with a big smile on his face

Ready to launch!

The glider kit was very well thought out, and was actually designed by one of their students. One of the nicest features: there was no necessary order of assembly. You simply popped out the parts and then started putting them together with hot glue. Everything lined up nicely and made sense. Well done!

hand launch glider flying up in the perfect blue sky

Negative Ghostrider, the pattern is full.

Word quickly spread that the tail pieces could be bent to affect the flight path and in no time, gliders were turning, rolling and flipping.

Two pilots stand holding the jet in place one pilot holds the transmitter getting ready to rev up the jet engine

The jet engine demonstration

Next up was a jet engine demonstration. As you can see in the pic above, the pit crew had their ears covered – that thing was loud. The plane can fly over 150 mph and requires a bit more airspace and runway, so this demo would only include a rev up of the engine to full throttle. They turned the smoke on too, which was pretty fun to see, although there was a small, accidental fire near the tail from an error in the smoke timing. The jet pilots made it seem as though this sort of thing happens sometimes, and I'm glad they had a working kill-switch and fire extinguisher nearby.

tail end of jet model with black burn marks

The tail fins got a little extra crispy from a small fire during this demo.

alt text

Preflight check before the aerobatic show

The fixed-wing aerobatic show was another highlight of the day. This plane was mostly made of lightweight balsa wood, with a thick wing for plenty of lift and a tall, thin fuselage for good knife edge performance. When he fired up the motor, I recognized the low pitched rumble and knew it was a four-stroke. I especially enjoyed the smell of the nitro airplane fuel exhaust. He revved up the motor to full throttle and leaned out the mixture - yet another ritual I used to love (in my gas-powered days).

Balsa lightwweight powered aerobatic show plane in straight vertical climb above perfectly blue sky

Then he nodded to the MC, Jake Marshall, and they turned on the music. Of course, it had to be the Top Gun classic, “Highway to the Danger Zone”. It took off in about two feet of runway, and he went into a spinning vertical climb. He did all the classic maneuvers too: rolls, loops, flat spins, hammerheads, snaps, knife edges and even some pretty low hovering. He ended with another classic move: a dead stick landing.

hand launching the biggest plane of the day

Launching "The big one" for its first ever flight: a battle!

After lunch, we watched the fixed-wing “battle.” It started with hand launching the big DIY plane (designed and built by the IC aeronautics team). The idea behind this competition was simply to have everybody launch their airplanes and then try to crash them into each other. The last plane flying wins. Let the mayhem begin!

smaller plane chasing down the big one

The mighty mini coming in for a hit!

An ideal “hit” is when one pilot will surprise another from above and quickly come down to hit the lower plane with its propeller. Usually, this cuts a piece of the airframe away, and it will come crashing down out of control. After a few minutes of the battle, it became quite apparent just how difficult it was to have an intentional hit.

Then the game became “try to take the big one down.” About halfway through the battle I saw one younger pilot launch his smallish World War II-era bomber. I don’t think he actually had a successful hit, but it was such fun seeing him try – fearless and not worried about damaging his plane. After all, there's always more foam to cut and plenty of hot glue!

The big DIY airplane coming in on final approach looking good

The big one on final approach looking good.

Then the time was up, and a handful of planes were down in the fields. It was time to land the big one. The young pilot flew a nice pattern and then gently touched down.

The big one after touchdown shoing a close up of the landing gear ripped off

Landing gear never likes to stay on airplanes!

Unfortunately, the landing gear still ripped right off. I don’t think any pilot could have avoided that. The attachment method (hot glue, I presume) was just not quite strong enough. Back to the drawing board, but that’s what it’s all about!

Jake Marshall hand launches a DIY foam board plane its just about to break free from his hand

Jake Marshall, head of the aeronautics team, launches one of his favorite DIY airplanes.

The event was well attended, and much fun was had by all. The Longmont Innovation Center is planning on hosting the event again next year, so follow them on Twitter, YouTube, or their website to stay informed. Also, they do offer tours and have a retail store with glider kits available, so don't hesitate to reach out and arrange a visit. Next year, I am for sure bringing a couple airplanes to fly. Hope to see you all there!

comments | comment feed

Enginursday: The Qwiic Jukebox

via SparkFun: Commerce Blog

Over the past couple months, I have been working with my three-year-old son to create his own jukebox.

alt text

He wanted it to play some recordings we made of us reading books together.

alt text

It uses RFID tags as the selection process, and is totally Qwiic-based.

alt text

We have worked out most of the bugs. It is truly amazing how good a three-year-old is at beta testing. We ended up making a detailed hookup guide and video, so if you'd like to make one yourself, please check those out and share in the comments. Enjoy!

comments | comment feed

Thirty Years of Test Controller Design Progression

via SparkFun: Commerce Blog

Pete Lewis here! This blog was written by a guest author, Kelly Small. We really appreciate his contributions to our community, and are very excited to help spread his extensive knowledge here on our homepage. The conversation about testbed design has been a great one, and if you'd like to read more about SparkFun's own testbed design history, please check out our previous posts here:

And now, onto the amazing story that covers more than thirty years of testbed progression in Kelly's career. Enjoy!


Working as a test engineer for many decades, I have seen remarkable changes and advancements in the field of electronics. My job is to develop test systems that our factories use to verify our products are built correctly and function as expected. These products include everything from a simple cable to a complex module composed of multiple PCB’s with as many as 16 layers. The circuitry can consist of multiple processors, FPGAs and complex analog systems.

Test Architecture

To test our products, which we refer to as UUT’s (Unit Under Test), our test flow consists of several steps. The first test step is in-circuit testing (ICT), where all the UUT’s are tested with a fixture that presses pogo pins into test points on the board, and makes test measurements of all the components on the board. This type of testing can weed out a lot of possible problems with the UUT, such as solder bridges and open runs, as well as wrong parts, missing parts or bad parts.

The next step is programming stations that program unique information into each UUT, such as serial numbers and MAC addresses. Next are the functional testers, which vary somewhat with the product, from a simple bench test to environmental tests, which use a chamber to rapidly heat and chill the UUTs while electrically testing its functions.

While the ICT testers are commercial systems that are purchased and installed at the factories, most of our other test systems are designed, programmed and built within our test engineering group. The heart of these various testers is what we refer to as a test controller. The test controller is a standalone embedded platform that controls power, input stimulus, output measurements and communication with the UUTs being tested.

The Test Controller

Around 1985, we developed the first test controller to support functional testing of a new product line, which included I/O modules of various types. These included Digital Inputs, Digital Outputs, Analog In, Analog Out and others. Modern test systems would most likely be comprised of a PC with a host of data collection modules, but in 1985 very few PCs existed. Those that were in use were 8-bit XT systems with very little in the way of hardware and software for test purposes. We selected the Intel 8051 microcontroller for the brains of our test controller, which has very few peripherals on board. The rest of the kernel consisted of a 32KB SRAM and a 32KB EEPROM. This EEPROM is where the code was stored, typically a 27C256. This chip was programmed one time and then you had to use a UV eraser to erase the chip before you could program it again. This erase process took 20-30 minutes, so you wanted a tube of chips on hand to make constant code changes during a debug session. The rest of the electronics were a group of I/Os used for connection to the UUTs being tested.

  • 21 digital outputs
  • 8 digital inputs
  • 16 analog inputs with 12-bit resolution
  • 8 analog outputs
  • On-board power sources +5, +15, -15, +24
  • 24-volt power supply, adjustable from 10-24 volts
  • 2-channel RS-485 ports running 375KBaud
  • 1 RS-232 port that communicates with a PC

This group of I/Os is referred to as the common electronics; the intent was to use it as a starting point for each test design and add additional circuitry (point logic) as needed.

The test controller is connected to a PC via the serial port, but while the test controller runs the test sequences, the PC is only used to monitor test operation and report test results to the human operators. As mentioned earlier, PCs were uncommon and very expensive, so one PC was connected to 10 test controllers, and each test controller was capable of testing eight UUTs. This allowed one PC to monitor testing of up to 80 UUTs at the same time.

The test controller was built on a 9”x11” PCB, with a pair of 96-pin DIN connectors at one end.

alt text

From 1986, the first test controller (top side view)

This first test controller, shown above, had an 8051 kernel and no programmable logic!

alt text

From 1986, the first test controller (bottom side view)

As you can see in the picture above, all of the connections were made with 100 percent wire-wrap.

Around 1987, we created a new PCB that had all the common electronics in a copper artwork section, while the rest of the board was laid out to support wire-wrapping of .3” DIP sockets for the point logic. This reduced the amount of wire-wrapping by a considerable amount.

alt text

From 1988, the test controller with "copper artwork section" (top side view)

alt text

From 1988, the test controller with "copper artwork section" (bottom side view)

This 1988 design served us well, and we still have fixtures today using these test controllers. One of the benefits of this setup is that we’re immune to all the changes in PCs over the years, including the introduction of Windows. We continued to use our DOS software until around 2012, when a Windows version was finally introduced.

In 1996, a new product was introduced, so we took the opportunity to make a new test controller design. We switched to an 80C251 processor (16-bit), and other features included an analog section that was self-calibrating, and the introduction of a pair of CPLDs. These CPLDs were used for some of the common logic, but were mainly intended for use in building the point logic with software, rather than a mass of wire-wrapping.

alt text

From 1996, the test controller with CPLDs to further reduce wire wrapping (top side view)

Technology marched on, and in 2004 we were once again looking at a new product to test, and so went after a new test controller as well. The 82C251 never caught on, and there were better 8051 variants available. We went with a P89C51RD2, which had SRAM, FLASH and EEPROM on board. Running at 24MHZ and six clock cycle instructions instead of the original 12, we also saw some decent speed improvements. The RS-485 links were bumped to 750K to support faster speeds that the newer product was using. It was getting difficult to find through-hole logic, so some of the common area were now surface mount. We continued to use socketed parts for the buffered signals going to and from the product being tested, which allowed for easy repair at the factory. If damage occurred to the SMT common electronics, field repair was difficult to do, and the test controller was typically sent back to our facility for repair.

alt text

From 2004, the test controller with many advancement including more SMD parts (top side view)

alt text

From 2004 the test controller with even fewer wire wrap connections (bottom side view)

In 2012 I started using PCB-based daughter boards for the point logic. This reduced the wire-wrapping to very little, if any.

alt text

From 2012, the test controller with daughter boards (top side view)

My most recent design was driven by parts obsolescence. The 8051 variants were disappearing, as well as supported development tools. The CPLDs were end of life (EOL), so it was time for a new design. I selected the Atmel ATMega1281 and the Xilinx XC95144XL, one of the few remaining CPLDs that was 5-volt tolerant. Except for buffered outputs, all of the common electronics are surface mount. A second processor (ATTiny1634) is used for communication, either the 375/750K RS-485 or other protocols. The layout is designed to support daughter board add-ons, but you can still use the wire-wrap area, with selectable 3.3V or 5V power.

alt text

From 2016, the test controller with nearly 100 percent SMD parts and no wire wrap connections (top side view)

The Future

What do I see for the future? Our electronics world is governed by supply and demand – these days that means smartphones. Most of our IC vendors are dropping 5-volt and 3.3-volt parts in favor of 1.8 or lower voltages. Large capacitors and other parts are becoming less common as well. Our next generation test controller will probably move to an ARM-based processor, and the CPLDs will be replaced with FPGAs.


Kelly Small is a principle test engineer with a Honeywell division in Phoenix, AZ. He’s been employed there for over 40 years, with 38 years in test engineering. Kelly has also been a participant in SparkFun's Autonomous Vehicle Competition, and his high-tech treasure chest was featured on our blog.

We greatly value not only Kelly's participation in our events, but also his involvement in the open source community. Please feel free to ask any questions below in the comments section, and thanks for reading!

comments | comment feed