Embedded Touch Interfaces for Scientific Equipment

Designing the user experience of scientific equipment teaches you that complex processes can be navigated easily if the flow is correct, and something super complicated made intuitive.

I joined the company when it was just beginning to create companion PC software for laboratory equipment. The early days were focused on bridging the gap between hardware and software, ensuring that scientific instruments could leverage digital tools to improve usability and efficiency. By the time I left, the company had advanced to using embedded touch screen interfaces, video intelligence for automated melting point analyses, cloud services and a range of sophisticated software applications that transformed the way laboratory equipment operated.

My involvement was the lead of the software team from the beginning, as it grew and as it became multi-site between Stone, Staffordshire and St Neots in Cambridge. I managed the teams and put in place the structure, both in terms of tech and software, but also the development of the people and the processes that helped things to run smoothly.

Baby Steps into Embedded Systems with Windows CE

The first major project involved developing a touchscreen interface for a range of PCR machines (made famous through Covid testing) using Windows CE, called the Techne TC-Plus.

A Polymerase Chain Reaction or PCR machine is a device which has a heatedable block of metal with wells in it. The wells house small plastic wells. These wells are filled with DNA samples and other chemistry which when heated and cooled in repetition (or cycles) causes the DNA to separate and potentially duplicate in a manner which can be used as a tool to, amongst other uses, look for specific sequences of DNA.

This marked the company's first foray into touch PC technology. Windws CE was popular at the time it ended up being a good choice for as the company had already started its journey into C# with its PC applications.

Windows CE didn't have very strong graphics framework so I designed the architecture of a reusable graphics library of components. We were then able to use these components to create interfaces on the entire product range, and accomodate differences in feature sets.

Over time we added web services to allow feature upgrades via unique keys, enabling remote upgrades. I helped both technical support in taking support phone calls in French and Italian, and also travelled out to Europe to accompany sales reps. I particularly remember a memorable visit to the Hospital Clinic of Barcelona, and the Centre Esther Koplowitz, to provide PCR machines working on curing type-1 diabetes. We also developed a companion application but this time using the (at the time) new Windows Presentation Foundation, WPF

As we prepared to start a new product, and expand other products with embedded touch screens, we took stock of what we'd learned up to that point. Windows CE was a capable platform, but it had some inherent issues with multi-threading, and the new product range required a webcam driver, which surprisingly Windows CE couldn't provide. Furthermore, this was around the time that Android was maturing and so animations and UI transitions were commonplace on phones and the dev team felt we should be incorporating them into the software.

To gather more options, I looked into other embedded systems and options which fit the projects budget. I found the Beaglebone Black embedded board, and it led us down the path of a Linux-based embedded PC. Not only did it allow us to move to Android, but it also could be configured to work with a open-source standard webcam driver, as well as the UI transitions we wanted.

Over time the company acquired another business that produced a thermal cycler and this became the first project to use the new Android platform. The PCR-core electronics and hardware was added to a new chassis, casing and touchscreen embedded board to become the PCR Max range of PCR machines. Alongside this upgrade, we implemented an iPhone/Android application called AlphaTrack which allowed users to get updates about their running experiments on their phone (and Apple Watch, for iPhone users).

Moving to Android and Custom Embedded Linux

The next upgrade was for new version of a previous melting point device, but this time an automatic melting point device, the Stuart SMP50.

An automatic melting point device is an instrument which uses a webcam to closely watch a small glass tube containing a material, which is then heated slowly. The webcam watches the material as it heats and as it starts to melt, the light levels start to drop. The vision algorithm looks specifically for the formation of a stable meniscus or surface to the melted liquid, and the light levels that are associated with it, to determine the specific temperature the material is considered melted. This method can be used, amongst other things, to check for the purity of a material or identify unknown powders by their melting point temperature.

For this project, the team took advantage of Android to provide a much more polished UI and switched to Java as a core development langauge. We enlisted the help of Linux kernel specialists to modify the firmware and incorporate the necessary webcam and video processing capabilities.

By this point I'd been able to lead the charge into implementing better software management, build and delivery. We used TeamCity and various build agents to pull all software and firmware developed across software and electronics firmware (written in C), to version control everything correctly. We implemented a release process that included accurate release notes, traceability from test version to code commits, and improvement the hand-over process between software and manufacturing (which took place in-house).

The Stuart SMP50 was well received and did well in the market and the team put in place a codebase in Java/Android which put them in good stead for the next product range.

Expanding to Spectrophotometers and Cloud Services

The next range to get an upgrade was the company's spectrophotometry brand, Jenway.

Spectrophometery is a technique used to measure the intensity of light absorbed or transmitted by a substance at specific wavelengths of light, to determine its concentration or other properties. A device has a precise light which it can shine at specific wavelengths through a liquid to take a reading. The Jenway product range had feature sets increasing from basic single readings, up to multiple simultaneous, or quantitation curves where multiple readings were taken between a start and an end to create a curve.

Towards the end of the previous SMP50 project, I had started to work with sales and marketing to reach out to universities, institutes and other customer segments to setup user experience research partners. Following the good work of Steve Krug and his books around user testing the team headed out to several places and carried out user testing on prototypes of interfaces and hardware built in cardboard.

I was lucky enough to go to the Birmingham Heartlands Hospital to visit their back offices to see where all regional blood work is completed and the automated conveyer belt systems that handles hundreds of readings each day. Samples travelled the conveyor belt which was pre-programmed to deliver the samples to specific machines for automated test and results gathering.

This user research was invaluable as the team started the spectrophometry product range upgrade. The range included a second Android-based embedded application, and a C-firmware based application which used a modified UI, similar to its Android counterpart in style but minimal for the reduced screen and C-based electronics platform the smaller device used.

The development for the spectrophotometry used the previous work and development on Android to decrease development time and create a more polished experience. The team used cloud services to provide shared online storage for results, remote upgrade capability and updates for improvemnets. The user research allowed us to validate the direction before we got started to reduce any costly mistakes.

The upgrade to the product range was again well received by customers, and is still on the market today.

Best Practices and Long-Term Impact

Throughout these projects, I introduced and implemented best practices that improved software quality and efficiency, and helped to build a software function for the company that helped it to grow and capture market share.

I enjoyed working with the teams, all the people I met through the work, and the achievements we shared together to make scientific techniques easier to do and to understand by those new to them. The company transformed from a business experimenting with companion software to a leader in embedded scientific interfaces, creating products that were more powerful, efficient, and user-friendly.

I felt that this evolution demonstrated the impact of a well-designed software strategy in scientific instrumentation, and the benefits of using best practice to improve the output, and the teams working together to achieve it. I'll forever look back fondly at these projects and carry forward the things I learned during them.