Raspberry Pi for Data Acquisition by Michael Allan (F) Fourth-year undergraduate project in Group A, 2012/2013 I hereby declare that, except where specifically indicated, the work submitted herein is my own original work. Signed: Date: Raspberry Pi for Data Acquisition Michael Allan, Fitzwilliam College Technical Abstract This project aimed to develop a data acquisition (DAQ) system based on the Raspberry Pi. Existing DAQ systems depend on the procurement and maintenance of a computer, which can be very expensive, therefore a replacement for the computer is desirable. While a device such as a mobile phone has enough processing power to perform DAQ tasks, the Raspberry Pi presents an attractive prospect due to the combination of low cost and many options for connectivity. Several off the shelf DAQ solutions were examined to see how they could potentially perform when connected to a Raspberry Pi. While it was seen that significant cost savings could still be made, the performance of these systems was not very strong. A system based on custom hardware would more fully exploit the potential of the Raspberry Pi. A specification for this system was conceived that would be feasible but would out-perform current commercial offerings. The form this hardware would take was then designed – some form of analogue interface to take samples, and then a buffer to compensate for the Raspberry Pi’s lack of a Real-Time operating system. For communication between the custom hardware (the PiDAQ) and the Raspberry Pi, the SPI bus was selected from the available options. As the buffer, an ARM Cortex-M3 based microprocessor from STmicroelectronics was selected, since it had sufficient power for the application and would allow the buffer and analogue sampling stages to be integrated. The rest of the circuit was then designed around this chip; firstly the ancillary support circuitry, secondly the interface between the differential analogue inputs and the analogue to digital converters (ADCs) of the microprocessor, thirdly an additional digital interface, fourthly the various power supplies, and finally the connectors and physical interfaces. The software that would be required was then designed, falling into two parts: embedded software that would run on the microprocessor, and application software that would run on the Raspberry Pi. The embedded software was designed to make use of interrupts and DMA (Direct Memory Access) to minimise the load on the microprocessor and reduce the complexity of the program code. The application software designed such that the storage engine (responsible for interfacing with the custom hardware) and the controller (the user Raspberry Pi for Data Acquisition Michael Allan, Fitzwilliam College interface) would communicate over the network and be capable of being run on separate machines. The embedded software would be programmed in C using the CMSIS libraries, the application software would be written in Python using Twisted for networking, matplotlib for graph creation, and protobufs for data storage and interchange. With the design complete the hardware was sent to be manufactured, and prototyping began on the software using a Phidget interface. Once the hardware was completed development continued in stages as more features were added to the software. Much of the development time was spent attempting to improve the performance of the sample acquisition process and data displays on the Raspberry Pi, where the simple design choices made proved inadequate. During this process some errors in the hardware manufacture were discovered, but these did not impact significantly on the project. In the end it was not possible to achieve the full specification of 20 kHz sampling on four channels. It was possible to transfer 20 kSamples/s into the Raspberry Pi, which limits the system to 5 KHz per channel, or 20 kHz on one channel. There is scope to improve performance further, but there was not time to do so during the project. The difficulties encountered in achieving the target sample rate meant some of the more advanced targets of the project were not met: no revision was made to the hardware to add dedicated interfaces for thermocouples and the like, as originally planned, and the user interface is more rudimentary and has less features than was desired. Implementing these targets provides ample scope for future work. In conclusion, the project was a success in demonstrating that data acquisition could be performed with the Raspberry Pi with reasonable performance, but to exceed the performance of current commercial systems more development time would be needed. Contents 1 Introduction 3 1.1 The Raspberry Pi ............................................................................................................... 4 1.2 Potential Systems ............................................................................................................. 5 1.3 Specification ....................................................................................................................... 5 1.4 Project Plan ......................................................................................................................... 6 1.4.1 PiDAQ Mk I 1.4.2 PiDAQ Mk II 1.4.3 System Software 1.4.4 User Software 2 System Design 8 2.1 Hardware ............................................................................................................................. 8 2.1.1 Communication 2.1.2 Serial Peripheral Interface 2.1.3 Data Acquisition 2.1.4 Microprocessor Support Circuitry 2.1.5 Programming Interface 2.1.6 ADC Interface 2.1.7 Digital Input/output 2.1.8 Power Supplies 2.1.9 Physical Interfaces and PCB Design 2.2 Software ............................................................................................................................ 19 2.2.1 Programming Environment 2.2.2 Overall Structure 2.2.3 Embedded Software 2.2.4 Direct Memory Access (DMA) 2.2.5 Hardware Abstraction 2.2.6 Storage Engine 2.2.7 Communication Protocol 2.2.8 User Interface/Controller 2 Raspberry Pi for Data Acquisition 3 System Implementation Process 28 3.1 Phidgets ............................................................................................................................ 28 3.2 PCB Assembly .................................................................................................................. 28 3.3 Firmware Bootstrap ...................................................................................................... 29 3.4 Version Control ............................................................................................................... 30 3.5 Raspberry Pi Operating System ................................................................................ 30 3.6 Peripheral Configuration ............................................................................................. 31 3.7 Increasing the Sample Rate ....................................................................................... 32 3.8 16-bit Transfers ............................................................................................................... 34 3.9 Analogue Sampling ....................................................................................................... 34 3.10 User Interface .................................................................................................................. 35 3.11 Digital I/O ......................................................................................................................... 36 3.12 Final User Interface ....................................................................................................... 36 4 Testing 37 5 Conclusions 39 5.1 Future Work ...................................................................................................................... 40 6 Bibliography 41 Appendix A Circuit Schematic 42 Appendix B PCB Design 47 Appendix C Risk Assessment Retrospective 50 Introduction 3 1 Introduction The aim of the project was to build a laboratory data acquisition system, suitable for both teaching and research use, based on the Raspberry Pi. The motivation for this stemmed from the high cost of implementing a commercially available data acquisition system from scratch. The key (and most prohibitive) cost inherent in such a system is a computer to run the experiment. Most users of such systems are already equipped with a suitable machine, but this is probably used day-to-day for many other purposes and it is impractical to tie it up with running data acquisition for any length of time. Since the cost of an additional machine, both in capital and in support, is high, organisations are reluctant to fund them and even if they do it takes valuable resources away from areas where they are more required. The computing power required for performing data acquisition and rudimentary processing is not high, and a dedicated DAQ PC is likely to be using a fraction of its available power on the task. A second motivating factor is underutilisation of the interface part of the DAQ system, converting sensor signals and sending them to the computer to be recorded, or in some cases using instructions from the computer to control the experiment. Even the simplest interfaces cost more than $100 and require proprietary software for which an additional licence is required. In many experiments, particularly those used for teaching, this cost is seen as prohibitive and leads to the sharing of DAQ equipment between groups, or even avoiding its use entirely, thus reducing teaching labs to the tedium of watching a stop-clock while writing down the occasional reading. Given these two issues, we can attack the lack of a suitable DAQ system from both ends. There are some less well known examples of DAQ interfaces that are cheaper and are compatible with non-proprietary systems for recording, storing, and processing the data, but these still require a PC. The initial idea behind this project was to replace the computer with a device such as a smartphone. This would drastically reduce the size and complexity of the PC side of the DAQ system. However, when the Raspberry Pi was announced this was seen as an even better candidate. 4 Raspberry Pi for Data Acquisition 1.1 The Raspberry Pi The Raspberry Pi is the product of the Raspberry Pi foundation, a charity conceived at the University of Cambridge Computer Laboratory with the aim of producing a cheap, functional, self-contained computer that can be used by school students to learn programming in an interesting environment, isolated from school IT systems where such activities are not permitted [1]. It is based on an ARM microcontroller produced by Broadcom that was originally designed for use in set-top boxes, and hence it pairs a relatively weak CPU with a very capable GPU. Combined with the price, this means that it has (somewhat inadvertently) become wildly popular with hobbyists who use it in similar ways to the likewise popular Arduino while taking advantage of its credentials as a full PC. Applications include media centres, low-power file servers, and remote control of digital cameras. Figure 1: Overview of Raspberry Pi Hardware The price of the Raspberry Pi is particularly attractive for this project. Since the base computer costs $35, rather than ten or twenty times that, there is more scope to develop the interface part of the system while retaining a low overall budget. Like the Arduino, the Raspberry Pi allows low level access to the interfaces of the chip. Combined with the presence of the standard PC interfaces it offers a compelling platform for the design of a custom interface that can simply, cheaply, and reliably integrate with the Raspberry Pi using the GPIO header. Figure 1 shows the Raspberry Pi in diagram form with the various interfaces labelled. Introduction 5 1.2 Potential Systems Having established that the Raspberry Pi could support either the connection of a traditional DAQ interface, such as those made by National Instruments (NI), or a custom piece of hardware, a number of potential solutions were analysed to see what could be possible. From internet searching, some potential candidates were found and examined. NI produces a USB DAQ, the NI USB-6008 [2]. This supports 8 analogue inputs at 12 bit resolution and 10 kS/s (samples per second) and costs $99. To utilise its full functionality, however, requires NI LabVIEW which is not feasible for use with the Raspberry Pi. Another company, Phidgets Inc., produce devices that support a single specific kind of sensor on a USB port, or that have several analogue inputs like a traditional DAQ interface [3]. They have the advantage of being programmable with a Python API, which is a supported programming language for the Raspberry Pi. At $80, the interfaces are slightly cheaper than NI’s, but the sampling rate of 1 kS/s is not considered to be fast enough. A further company, DATAQ, produces similar types of devices to the Phidgets and with similar performance to the NI interface, but for an accordingly higher price [4]. Given the capabilities of the Raspberry Pi and the types of systems currently available on the market, it was felt that producing a custom interface was an appropriate option, both from the point of view of creating a system to fit the brief and from the point of view of making the project itself interesting and challenging. This custom system has been christened the PiDAQ. 1.3 Specification The following specification was chosen for the PiDAQ system: Hardware (Analogue Interface) Software (Internal and User Facing)  0-10V Input Voltage Range  ‘Open’ formats for data storage and  20 kS/s Sampling Frequency interchange  12 Bit Resolution  Compatible with MATLAB and LabVIEW  4 Input Channels  Use TCP/IP network communications to give a distributed system. 6 Raspberry Pi for Data Acquisition This specification was chosen to meet the needs of experiments in thermodynamics and to be comparable with the existing systems described above. It was initially desired that the final form of the project would exceed these specifications, for example by directly supporting sensors such as thermocouples or Wheatstone bridges without the need for an external amplifier. The software specification was more open-ended. At a minimum the data from the Raspberry Pi should be collected and then could be passed to a separate package for processing, which could vary in complexity from an Excel spreadsheet to MATLAB. It was desired, however, that the software would be able to intuitively control the system and present live data, and that the full functionality of the Raspberry Pi could be exploited. 1.4 Project Plan The project was divided into four milestones, two for hardware and two for software. It was expected that the hardware and software milestones would be worked on concurrently. 1.4.1 PiDAQ Mk I This was a basic PCB, supporting analogue input and connecting to the Raspberry Pi’s GPIO header. This milestone was intended to demonstrate the interface to the Raspberry Pi and provide a building block for the PiDAQ Mk II. It was targeted to be completed by the start of Lent term. 1.4.2 PiDAQ Mk II This was intended to be a more advanced PCB, an evolution of the Mk I to fix any issues and to add the capability to interface with specialist sensors directly, which would be a key advantage of the PiDAQ over the competing products. This milestone was targeted for the end of Lent term, but due to problems encountered with the software development the Mk II was never designed. 1.4.3 System Software This was the software that runs on the PiDAQ to send readings to the Raspberry Pi, and the software that runs on the Raspberry Pi to receive, store and distribute this data. This milestone was targeted for three weeks after the completion of PiDAQ Mk I, partway through Lent term.