Opening Up Instrumentation

John de Mello explains how scientific instrumentation is becoming more open, more affordable and easier to make

UNTIL recently, if you needed a scientific instrument, you had two options: you could buy a ready-made system or you could design and build one yourself. The first option was expensive, but the second was tricky and time-consuming. Even if you were fortunate enough to have detailed technical plans for the instrument taken from a book or a paper, there was no guarantee you could source the necessary parts or would have the workshop tools needed to make it. In addition, key pieces of information – eg circuit diagrams for the control electronics, assembly and alignment instructions, calibration procedures, and source code for the control software – were almost certainly missing, leaving a great deal of work to do before you had a working system. In most cases, any potential savings in hardware costs were outweighed by excessive labour costs and a significant risk of failure, inviting the obvious question: why on earth would you want to do it yourself?

Fortunately in the last few years the barriers to building your own scientific instruments have started to come down. More and more equipment designs are being released as open hardware (OH), ie on a royalty-free basis and with all the design files, source-code and support materials needed to build a fully-functional system. With the correct tools and components in hand, everything you need to know to build a working instrument is provided, avoiding much of the hassle and risk of designing a system from scratch. Importantly, many OH projects place a high priority on widening access to scientific equipment, especially in developing countries. Hence, they tend to use inexpensive and easily-sourced components, low-cost fabrication methods such as 3D-printing, and simple assembly and alignment procedures. They therefore turn the normally daunting task of building scientific equipment into a much simpler, guided process that is somewhat reminiscent of assembling flat-pack furniture or completing a hobbyist construction kit.

Open or closed?

While many OH projects prioritise low cost over all else (and are consequently willing to accept compromised performance in the interest of maximising affordability), others set their sights on achieving state-of-the art performance in terms of sensitivity, resolution or functionality. Hence, it should not be assumed that open hardware is necessarily a low-end choice. Even projects that start off with lacklustre specifications have the potential to reach laboratory-grade performance eventually, fuelled by multiple design tweaks from contributors across the globe. (The philosophy of the OH movement is that two heads are better than one – and for that matter three are better than two – so suggestions for improving performance and functionality are generally welcomed and encouraged).

From a user perspective, there are many reasons why it might make sense to choose open hardware over proprietary hardware. In many cases, the decision is motivated entirely by cost, as OH is usually much cheaper, often by a factor of ten or more. Running costs also tend to be lower since users are not locked into using vendor-specific consumables; nor are they forced to take out costly service contracts or software subscriptions. In addition, OH is less susceptible to obsolescence since it can more easily be repaired, modified or upgraded. Typical OH build-times are a few days, compared to potential lead times of months for non-stock proprietary hardware. Hence, when a solution is needed urgently, OH based on routinely-stocked parts may be the only choice.

For simple measurements, fully-featured commercial systems are often overkill, and a simple OH solution may be sufficient or even preferable. This is especially true in laboratory teaching, where using pared-back OH may expose the underlying measurement principles more effectively than a closed-box commercial product. The lower costs of OH may additionally allow equipment to be provided on a “one-per-person” rather than a “one-per-class” basis, enhancing the student experience. For complex measurements, OH is sometimes chosen because commercial systems lack essential functionality or the equipment needs to operate in a niche environment for which commercial systems are unsuited.

In some cases, people select OH simply because they enjoy the intellectual challenge of building equipment over which they have full control. Of course, for every person who relishes the idea of making their own kit, there are probably a dozen more who would rather stick needles in their eyes! If you fall into the second category, proprietary hardware is probably a better option for you. (Note, however, that a few vendors sell pre-assembled OH products that work straight out of the box, so in some instances OH can also provide a hassle-free solution).

Easy as pi?

The sharing of hardware designs in science is of course nothing new, and venerable journals like the Review of Scientific Instruments have been doing it for almost a century now. What is new, however, is the ease with which published hardware designs can be turned into functional equipment. Low-cost rapid prototyping techniques such as 3D printing, laser cutting, and desktop milling have placed sophisticated fabrication capabilities in the hands of the general engineer or scientist, and have reduced the process of replicating physical parts to little more than running a downloaded script.

At the same time, the availability of powerful but easy-to-use microcontroller and microprocessor platforms has made it easier than ever before to control and automate hardware. The best-known examples are the Arduino microcontroller development boards (MDBs) and the Raspberry Pi single-board computers, which were launched with the respective aims of simplifying hardware automation and encouraging teaching of computing in schools. The two platforms are similar in that they both offer complete “ecosystems” that combine affordable hardware with free and easy-to-use software tools, extensive documentation, dynamic communities of users who freely share ideas and advice, and a wide-range of third-party expansion boards that increase the functionality of the core hardware.

Modern MDBs have a lot of built-in functionality that can greatly simplify the job of the instrument developer. Useful features include timers for accurate scheduling of tasks, analogue-to-digital converters (ADCs) for reading analogue input signals, digital-to-analogue converters (DACs) for generating arbitrary voltage waveforms, and hard-wired digital communication protocols for easily exchanging data with other digital hardware. Missing functionality for tasks such as signal conditioning, motion control, wireless communication, and audio or image processing can often be added through inexpensive add-on boards, potentially avoiding the need to ever design a circuit board or pick up a soldering iron. In many cases, the need for complex analogue circuitry can be side-stepped by carrying out digital signal processing within the microcontroller source-code, using open-source software libraries to take care of the necessary calculations. In this way, it is quite feasible to assemble a complete scientific instrument from one or two off-the-shelf development boards and a handful of components and sensors, reducing development time, simplifying fabrication and keeping costs low.

Hints and tips for OH developers

If you’re thinking about releasing a product as OH, there are a few issues to bear in mind. Firstly, it’s worth considering the licensing terms before you publish your project: some open hardware is released without any restrictions, while other projects place limitations on how the licensed material is used, modified or distributed. For example they may preclude commercial use or mandate the publication of improvements. The licence terms you choose – if any – will to some extent determine how willing other people are to get involved and contribute ideas, with restrictive licences acting as a possible deterrent to participation. You should therefore decide how you would like to see your project operate and evolve, and then choose a licence accordingly. The CERN OH licences are a good starting point for many OH developers.

Before publishing your project, it’s a good idea to make sure it doesn’t infringe any existing patents as you can only license out what’s yours to give away in the first place. (Checking for infringements can be tedious but if – as is often the case with scientific instruments – your design is broadly based on ideas that have been in the public domain for 20 years or more, then you’re probably in the clear).

When you do come to release your design, try to make sure it will be permanently accessible, eg by uploading it to an established public repository or by publishing it as an open-access paper with all the necessary design files and supporting documents included as supplementary information. Don’t just post it on your personal website, because in ten years it will probably have disappeared without trace!

Secondly, as far as OH is concerned, it is worth heeding Einstein’s famous advice that everything should be “as simple as possible, but no simpler”. By stripping superfluous elements from your design and basing it on easily-made parts and standard off-the-shelf-components, you can simplify fabrication and lower costs, thereby ensuring your design is accessible to the widest possible user-base. Keep simplifying until performance starts to suffer unduly. Then stop. In OH projects – where products are typically intended to be affordable even on a one-off basis – bespoke components are rarely a viable option (although rapid prototyping has changed this a bit). Instead try to base your design on common off-the-shelf components, easily-made parts, and “re-purposed” standard hardware.

Thirdly, the need for costly precision-engineered mechanical or optical parts can sometimes be avoided through a careful selection of the measurement technique. The most intuitive techniques are not necessarily the easiest ones to implement in practice. Hence, where possible, it is best to select analytical procedures based on physical properties that are easy to measure. Timing-based measurements are particularly well suited to low-cost implementation on digital hardware (eg see Box 1). In addition, ratiometric and differential measurements – in which a reference signal is measured alongside the target signal – can significantly lessen hardware demands by compensating for fluctuations or drift in experimental parameters.

Fourthly, it’s a good idea to offer a few variants of your instrument based on different design trade-offs, eg a low-cost model for education and routine measurements, and a higher-performing model based on more costly components for more demanding applications. Ideally, all versions should be based on a common framework with a simple upgrade path from one version to the next by swapping out individual parts (eg see Box 2).

Finally, and this is perhaps the most important point of all, document your project well. An OH project lives or dies on the quality of its documentation. One reason the Raspberry Pi single-board computers are so popular is the exceptional quality of their supporting documentation. They’re not just a family of affordable, well designed computers. They’re also easy to use thanks to extensive tutorials, teaching materials, technical papers, and video guides (plus some user-friendly software). The more thoroughly you can explain issues such as how your instrument works, what performance trade-offs you’ve made in its design, the reasons for your component choices, common pitfalls in construction, and recommended operating protocols, the easier it will be for others to use it and improve it.

Will it fly?

There is of course no guaranteed formula for developing a successful OH project. Whether or not a project thrives depends on many factors, including: the extent to which it addresses a genuine need; the availability, cost and performance of competitor products; the reliability of the design; the ease of fabrication; the quality of the supporting files and documentation; and the “visibility” of the project. (It doesn’t matter how good your product is if no-one knows about it, which is another good reason not to leave it languishing on your personal website!)

Bear in mind too that the biggest impact of your project may not necessarily be at the level of the complete system you’ve created, especially if it’s a very specialised instrument with a small potential user-base. Instead, it might be a small element of your design (such as a translation mechanism or an optical mount) that turns out to be most important, solving a problem that is common to many other projects. Hence, if you want your OH project to be of maximum value to others, it pays to document every part thoroughly.

Finally, it is important to acknowledge that the OH movement is still in its infancy. Open hardware accounts for only a tiny fraction of scientific instruments in use today, performance typically falls short of the best commercial instruments, and coverage is sparse, with many types of scientific instrument having no open implementations at all. Hence, there is plenty of scope for the quality and reach of OH to increase. Fortunately, the ability of OH projects to learn and quite literally take from one another means improvements in one project can readily propagate to others, accelerating progress across the board. Likewise, new OH projects are not born into a vacuum but can use road-tested building blocks from older projects as the basis for new instrumental designs. Hence, as with open source software, it seems likely that the sophistication, coverage and uptake of OH products will increase steadily in the years to come. Ideally, OH versions of all commonly-used instruments will eventually become available, offering laboratory-grade performance at a far lower cost than proprietary hardware. If and when that point is reached, the question will no longer be “why would you do it yourself?” but “why wouldn’t you?”

---

This work is licensed under a Creative Commons Attribution 4.0 International Licence, see http://creativecommons.org/licenses/by/4.0