Efficiency is the name of the game these days, and the SparkFun QC team is all about it! We have successfully deployed a new test-fixture we are calling the “Qwiic Test-bed” and I am here to tell you all about it.
If you are new to SparkFun or haven’t stopped by for a while, you may not be aware of our Qwiic line of products, if so, check out this Qwiic explainer. Being a high variation electronics manufacturer, we in QC keep very busy designing testing hardware and software for new SparkFun originals. We are always trying to find and take advantage of efficiency gains to increase the bandwidth of our three-person team, and the new Qwiic Test-bed does just that. Below is a brief overview of the reasoning, technical details and results of developing with our new test-fixture.
We wanted to find a way that we, as a team, could increase our bandwidth by saving time developing. Typically we design a test-bed for a product, and that test-bed is only used to test that individual product. This means for each new product we have to: design new testing hardware, build the new test-fixtures, write the software to control the test-fixture and test the product, and maintain the test-fixture through ongoing Production use.
One of the easiest steps we can take to save time during our hardware design process is to repurpose past design files and make modifications to suit your current application, and the same can be done for testing software. But even with these efficiency gains we can’t outrun the turnaround time on test-fixture hardware. What we needed was a physical test-fixture that could be reused to test new products while still supporting the old.
The key to making this test-fixture possible was in part due to the standardization in form factor and pinout of the Qwiic breakout boards, and in part due to all of the boards utilizing the I2C communication protocol. One hard standard was set in regards to form-factor, this standard dictates the ordering of the four essential plated through holes (PTHs): ground (GND), power (VCC), I2C data (SDA), and I2C clock (SCL) (they must also be adjacent).
It should be said that this test-bed was never intended to be able to test every Qwiic breakout board, we just want to capture the majority - some designs just need to break the standard for one reason or another, and trying to design a fixture around all the imaginable deviations would have caused too much scope creep.
The point of the exercise was to expedite as much of the development process as possible when using the Qwiic Test-bed. We opted to use a collaborative firmware sketch that runs on the test-bed, allowing us to build on the test-bed firmware by easily adding new product source files and testing functions required to test new designs. This meant that we could now use the same physical test-fixtures to test multiple assemblies, thus saving time on building up hardware for each new design. By removing the need to design and assemble a physical fixture we’ve saved a bunch of our team’s time, and also allowed the product cycle to move quicker. As an added bonus, the fixture can also be used during the prototyping phase to test new hardware and software.
The Qwiic test-bed utilizes pogopins to make a temporary connection to the board’s PTHs while the board is held in place by the hinged acrylic bar on the top. A small nubbin can be spun to keep the bar clamped on the board during testing, or the user can manually hold the bar down. The processing and testing peripherals for the test-fixture are handled by our original testing development board called the “Flying Jalapeno.” Check out Pete’s posts about the development of the Flying Jalapeno here:
The test-fixture has two available capacitive sensor pads, four LEDs, and available serial debug for the user to interface with.
The fixture centers around the four main pogopins: GND, VCC, SDA and SCL, which are separated by a standard 100 mil spacing. Because many of these assemblies break out other signals such as interrupts, enables, analogs, PPMs, clocks and serial RX/TX, the four essential signal pogopins are straddled by eight extra pogopins - four above and four below. Five 74LVC4066 quad switches route the most functionally capable pins from the Flying Jalapeno’s ATmega2560 to the eight extra pogopins, giving the developer the ability to select which pins of the 2560 to connect to the test-board’s signals, and which to disconnect.
By making the acrylic mating surface for the PTH connections slim, a test-board can be placed on either side of the mating area to suit any PTH header orientation. Alignment is facilitated by matching the silk of the test-board with that of the test-bed. In most scenarios, the assembly being tested has fewer PTHs than the test-bed has pogopins; when a pogopin is not being used it’s pushed down by the PCB and separated from any signal by the mask. Reports about usage from our Production department have been positive, and the hardware is holding up well.
As a whole we’ve been very pleased with the results of using this test-fixture. The three of us in QC are getting a lesson in software collaboration, but with a few rules implemented, co-development has gone smoothly. As a rough calculation, the testing development process for the boards being tested with the Qwiic Test-bed took about 25 percent of the time they would have previously, and with all the projects in the pipes, saving any amount of time is welcomed.
I just want to say that, I really appreciate that you guys take the time to share some of your internal processes and learning experiences in development, not just things like product showcases. This is something I think a lot of people would never have exposure to, unless it was already their main line of work. And an article like this really shows that you guys strive for good design principles - design for manufacture, design for testing, etc. Thanks.
Great design, and great writeup!
But, there's always room for improvement...
I've been involved in testing electronics for about 45 years, ranging from being a low level "manual labor" of "put the part into the socket, push the button, then drop the part into the right box depending on whether the red light comes on or the green light", to being a group-leading engineer working on the electronic system archecture for multi-million-dollar testers.
Based on that, I have a few suggestions: I'd be inclined to build up a second QTB that has a "solid" acrylic (other than the openings for pogo pins and mounting holes) so that you can rig something to have mechanical "indexing" for the UUT -- if you have a big run for a particular circuit, this can be (a) faster, (b) less tiring for the operator, and (c) less error prone than visual alignment indexing. (I would have been tempted to make the QTB noticably larger, as well, for two reasons: one is that it would be more stable for testing things like the joystick or the rotary encorder, and two is to allow more room to deal with a mechanical indexing solution.)
Another suggestion would be to have a Qwiic connector on the QTB itself, with SDA and SCL lines that are separate from the ones for the UUT. There are several current Qwiic boards (and no doubt more to come) that have various "environmental" measurements, and this would allow having a "golden part" plugged in and have the Flying Jalepeno request measurements from both the golden part and the UUT, and do a "sanity check" comparison, for example, if the two reported temperatures that are, say, 50 degrees C apart, there's something wrong, but if the two are within a degree or two of each other, that's fine.
If I recall correctly, all boards built by SparkFun get an automated visual inspection. This should catch most soldering issues with the two Qwiic connectors (e.g., pins not soldered, or solder bridges). If the Flying Jalepeno detects the board, it seems a pretty good bet that the sensor isn't on backwards, or the pullup resistors are missing, etc.
And while I'm at it, I'll reitterate my comment from about a year ago on the "Qwiic explainer", that I'd really like to see what would amount to an ATtiny85 "breakout" board that we could use to build "one-off" Qwiic boards...
The Atto84 is pretty slick, but it's the ATtiny84 not the 85 and lacks a Qwiic connector ;)
Hey #773, Nice to hear from you! And thanks for your suggestions. Indeed, always room for improvements :) I really like your idea to create an even better indexing solution. It's crazy how hardware on test fixtures often requires the most creativity. Not to say that firmware isn't challenging in it's own right. As EROC mentions, keeping this testbed's firmware solid/flexible/expandable is pretty tricky and I comment the QC team for collaborating and making that happen.
Also like your idea for a qwiic connector on the testbed. There is actually a new revision to the FJ (headed up by EROC), that will include this connector in addition to many more improvements.
I, too, would love to see a qwiic-development-based ATtiny85 breakout. This would be very useful in designing new qwiic products. We often develop firmware on a ATMega328 (to allow for easier programming and serial debug), and then move over to the ATTiny85 for the final product design. There are a lot of things in the pipeline right now, and so I'm not sure how this falls in our greater priority. So many projects, so little time :) As mentioned by Ted M, in his comment here, the Qwiic Button Breakout might be a good option for hacking now. I might go this route in the future.
Thanks again and cheers to testbed innovation!
PS great post EROC, really love seeing this progress!!