The Benchtool - Where Now?

The competition I originally started working on the Bench Testing Tool is now over (see this post for details) but the project is far from complete and I would like to finish it off - mainly so I can use it myself but also because a number of people have expressed interest in building (or buying) their own in the future.

The White Temple

I'm currently enjoying a few weeks break so I've had a bit of time to think about how I want to move ahead with the project and what changes I should make to the current design to improve performance and usability. I also have to give some thought to making it a bit easier to make a small production run or put together some kits.

Hardware Design Changes

My current implementation uses a common ground for the four voltage inputs which is fine for the purpose I had in mind but not very flexible in the longer run. What I'd like to do is to make each input have an independant ground with the option of tying all the ground inputs together to mimic the previous behaviour.

The reference voltage outputs will each have their own ground as well, although this will simply be tied to the common ground for the benchtester circuit itself.

The voltage range I'm supporting (0 to 15V) seems to be good enough and gives a reasonable resolution with 12 bit ADC's (around 3mV minimum step). This was never intended to be a high resolution piece of test equipment - there is already a wide range of those commercially available.

Component Selection

The two main modules I'm using (the Raspberry Pi and the Stellaris Launchpad) are readily available and reasonably priced so they will remain the same. Some of the discrete IC's I'm using (dual channel DAC, op-amps, I2C IO expanders, etc) will need to be reviewed so I'm sure I'm using components that are readily available in small quantities and at a reasonable price. The same applies to connectors and cables.

The final design will be based around a single dual layer PCB which will contain all the necessary glue logic and signal paths as well as the analog circuitry. If possible I'm going to use sockets on the board that allow the Raspberry Pi and the Launchpad to be mounted directly and try to minimise the number of data cables required.

Software Design Changes

At the time of the competition I had not completed the touchscreen interface so it was being simulated over a VNC connection from my laptop to the device itself. Although I thought this was a negative it seemed to be quite a popular feature. I had always planned a remote interface (through an Android application communicating over bluetooth) but the ability of the device to be operated remotely over a TCP network was commented on by several observers.

This means I'm going to change from my initial plan of using a Raspberry Pi Model A as the main controller to a Raspberry Pi Model B. This will give the option of wired or wireless networking as well as my original Bluetooth interface.

A public and well documented API for the device is also a must. Originally I had planned to have a simple serial based API purely for the remote application and have the ability to script operations (in order to simulate inputs and trigger data capture) purely on the device itself - with a network accessable API though and suitable bindings for Python, Java and C# this functionality can be controlled remotely and integrated with existing applications to automate tests and simulation scenarios.

The tool will still be able to operate in stand alone mode though, the full functionality will be available from the built in touch screen.

Physical Casing

Now that the device needs to be used by other people and isn't just a personal gadget the casing needs to be reviewed to make it a bit more robust. This means a fully enclosed casing and preferrebly one that can be completely 3D printed with minimal post processing to put the parts together.

I'm not very happy with the connectors I'm using on the front panel at the moment and I'll be looking for alternatives for those. I originally picked them because they were a combination of binding post (for a single wire connection) and banana socket (for test cables). Unfortunately they are far too bulky to use nicely in such numbers (the current design uses 11, adding separate ground connectors for the voltage inputs brings that up to 15) and add a lot of extra weight to the final product.


With the changes listed above my 3 month project is at best 50% complete at the moment. Not exactly what I was hoping for but to be fair the scope has now changed dramatically. My next step is doing up a reasonable schedule to have the first fully assembled device ready by the end of November 2013. The PCB fabrication service I use does a minimum of 10 boards in a run so I should have 9 available for sale as a kit or fully assembled in December 2013. If those turn out to be popular I'll look at what it will take to do a larger production run.

The hardware and software will remain fully open source - you are free to go ahead and build your own from scratch if you prefer.