Real, G. E., Florencia Jaure, M., & Vitali, A. O. (2018).

Data acquisition and industrial control system based on

Arduino Due using open-source hardware and software. 2018 XIII Technologies Applied to Electronics Teaching
Conference (TAEE). doi:10.1109/taee.2018.8476072

Data acquisition and industrial control system

based on Arduino Due using open-source
hardware and software
Gustavo Ernesto Real
Universidad Nacional de
General Sarmiento (UNGS)
Los Polvorines, Argentina
greal@ungs.edu.ar
María Florencia Jauré
Universidad Nacional de
General Sarmiento (UNGS)
Los Polvorines, Argentina
fjaure@campus.ungs.edu.ar
Amado Osvaldo Vitali
Universidad Nacional de
General Sarmiento (UNGS)
Los Polvorines, Argentina
avitali@ungs.edu.ar

Abstract. Different process automation requirements among
university students and researchers prompted the design and
development of a data acquisition and control board for use in
automation activities and for taking readings in educational
laboratories and industrial environments, using open-source
software and hardware. This study includes a detailed
description of the solution that was developed to respond to these
needs: it begins by presenting the different components that
make up the system, which was designed around the Arduino
Due platform. It then provides a detailed functional description
of these before discussing preliminary trials that were carried
out using the test board. These trials proved that the main
components function correctly and point to the need to continue
work on the prototype board to obtain more conclusive evidence
that the expected results have been achieved and to check all
component interactions on the final version.
Keywords: data acquisition, control loop, industrial
automation, open-source hardware, free software
I. INTRODUCTION
Toward the end of 2015, our workgroup successfully
built a data acquisition system (DAQ) based on open-
source hardware and software that is designed to be used as
a teaching tool in the Science and Engineering Laboratories
at the National University of General Sarmiento (UNGS),
Argentina[1]. To our satisfaction, the system is already
being used as part of different studies carried out by
students and researchers at UNGS. For example, (1) it was
used to control a solar tracker in a parabolic dish for
generating electricity; (2) it formed part of the automation
system for a composting plant developed by students
working on this case study; (3) it has been used for different
teaching purposes, and is included in the standard practical
exercises on the UNGS technical degree program in
Automation.
However, due to the varied requirements of the different
research teams and student groups, we decided to increase
the functionalities of this initial prototype.
Consequently, the new DAQ that is presented in this
paper is similar in essence to the original in that it uses both
open-source hardware and software, in keeping with current
global trends[2][3], but has greater capabilities that extend
its potential use to a larger community of users and
maximize opportunities for exchange and collaboration
with students and researchers from other universities
around the world working in a variety of fields. This board
will enable university students to learn about 32-bit
microcontrollers through a practical, concrete application
that can be used for data acquisition and control.
Another factor that spurred us on with developing
designs of our own, building on our experience to date, was
the realization that we have the tools and knowledge to
tackle any problems or issues that the system may pose and
the ability to modify it without depending on private
companies whose technical support services in Argentina
often leave much to be desired.
The development of the system is based on the Arduino
Due platform [4], which we chose because it is widely
developed, stable, and has a wealth of information available
on it. The main addition to the earlier model is the use of a
microcontroller with greater processing power. This makes
a larger number of entry and exit channels available and
orients the design toward taking readings and
measurements and industrial automation.
II. SYSTEM STRUCTURE AND COMPOSITION
Briefly, the system is made up of a hardware device,
based on a 32-bit microcontroller [5] (Arduino Due); the
firmware that runs on this; a set of signal sensors or
adapters that transform physical values of interest into the
appropriate electrical signals; and computer software that
communicates with the device to configure it and obtain
readings, the values of which it visualizes and stores. The
system can also be connected to central automation systems
via standard buses. Fig. 1 is a conceptual diagram of the
system.

978-1-5386-0928-6/18/$31.00 ©2018 IEEE

 o Two analog (DAC) outputs, 0 to 10V, 0 to 20mA,
ARDUINO DUE
WIFI SAM3X8E (32 BITS)
POWER jumper selectable
RS232 SUPPLY

 Inputs
RS485 I2C DIGITAL
USB CAN
SPI I/O
CAN E2
WIFI USART
ADC PWM SD o Eight digital optocoupler inputs, 0 to 24V
PC USB FLASH
o Eight single-ended analog inputs, 0 to 10V, 0 to
20mA, jumper selectable
PDA
ANALOG ANALOG DIGITAL DIGITAL o Four programmable gain analog instrumentation
INPUTS OUTPUTS INPUTS OUTPUTS
inputs for special measurements, 0 to 3.3V @
0.5mA
CENTRAL
AUTOMATION
 Buses
o Generic I2C SPI GPIO bus (e.g., for 1-wire,
interrupts, and triggers)
 Communications
Fig. 1. Conceptual diagram of the system o RS485
o RS232
These components are described in more detail below.
o USB serial port (for Arduino Due board)
A. Specifications
The hardware specifications for the data acquisition and o CAN
control system based on Arduino Due were established o WiFi board connector (based on ESP8266)
based on the premise that the project is aiming to provide
solutions for or respond to industrial automation needs.  Storage
Consequently, our design provides analog outputs that o SD card connector
are used as control loops, as this allows the continuous o EEPROM (I2C) memory
modification of two actuators that can intervene in each
loop, within a range of specifications. The analog inputs o Flash memory (SPI)
and outputs are between 0 and 10 volts or 4 and 20 mA and
can be selected by the user. The device was also designed  RTC
to include RS485 and RS232 buses and WiFi. The latter o I2C, lithium battery
feature is not directly oriented toward automation but does
open up other development possibilities. Finally, to extend  Maximum sampling frequency
the potential uses of the system, the CAN communication o 52 us @ 12 bits. All selected channels are
protocol was included, making it possible to link it up with displayed every 52 us.
controls in the automotive sector. All in all, the 32-bit
microcontroller provides a wide range of features and  Power supply
significant processing power. o Transformer: 9Vac+9Vac, 40VA
Having analyzed the general features of the system that o Input in continuous: 15Vdc, 40VA
we have developed, in the following section we provide
detail descriptions of the components used in the system B. Architecture design
hardware and their respective technical specifications: Architecture design specifically involves defining how a
 PCB (printed circuit board) solution will work. Our analysis of the project objectives
and framework pointed to two different design options: a
o Surface-mounted modular design or an integrated design1. However, given
o Four layers the initial specifications described above, we decided that it
would make sense for the device to carry out some of its
o Material: FR4 functions autonomously and some connected to other
 Outputs equipment (such as a PC, automation center, etc.).

o Four relay outputs, 24V @ 1A
o Four Open Drain outputs, 24V @ 0.5A
o Four PWM outputs, 0 to 3.3V @ 10mA
Although a modular design would simplify each board,
the need for more connectors could increase potential
1
It is worth noting that very high profile international companies develop
both modular and integrated versions.
failure points. Likewise, as the board is designed for input tests, we used another test board that we made
automation and has sufficient inputs, outputs, and ourselves.
communication ports, we ultimately opted for an integrated
How the board will look when it is finished is displayed
design.
in fig. 3 and fig. 4, which show the top and bottom views,
Having established these basic features, we completed respectively, of the PCB with all components in position.
the system architecture, which included the following
design components:
a) Schematic and PCB hardware design
The hardware design began with diagramming the
schematic circuit (fig. 2).

Fig. 3. Top view of the PCB

Fig. 2. Schematic circuit diagram [6]

The initial idea for the PCB design was to organize all
the functions into a two-layer board. However, after
developing a preliminary design and reviewing it with the
PCB supplier [7], we concluded that the board needed a
four-layer design.
We should point out here that developing the control
system and data acquisition board required our contacting
several suppliers who carried out or will carry out different
stages in the manufacturing and assembly process for the
definitive prototype board. We communicated with
suppliers regarding: (1) board manufacture [7], (2)
component acquisition [8], and (3) the assembly of the final Fig. 4. Bottom view of the PCB
version of the board. Given that the board is surface-
mounted and that this type of assembly entails specific b) Firmware and software versions
expertise, we decided that the components should be In parallel to the above tasks, the development was
assembled by an external supplier [9]. monitored using GitHub [6] for the firmware and software
The project suffered some setbacks due to delays in versioning. This is a tool that allows components to be
deliveries of components from outside Argentina. For this systematically reviewed as they are developed.
reason, to avoid delays in the subtasks planned as part of c) Firmware
our initial schedule, we used an experimental board from
the firm Mikroelectronika [10], to which we adapted both In order to simplify the use of the board, it was decided
the power supply and signaling of the Arduino board. This that the board communicate with the peripherals through
allowed us to test the firmware modules of the SD memory, commands. Each command would be a specific
the clock, some of the digital inputs and outputs, the RS232 communication, but they are all structured similarly to
port, the USB port, and the logging modules. For the digital achieve a certain degree of standardization, which will
make it easier to add new commands or delete unwanted
ones. In accordance with our specifications, a generic
command format was defined, which is described in detail
in table I.
TABLE I. GENERIC COMMANDS
Generic command format
Esc Attention
Character or number Command type
Data Command data
Not only is this a versatile, concrete form of
communication, but any additional specifications that users
wish to incorporate and that entail a relationship with
peripherals can be implemented similarly, such that all
current and future communications are standardized.
The commands that are currently defined for all
communications are listed in table II.
TABLE II. COMMANDS
1. //Test installed EEPROM chips, (ESC 1 Value CR), Value => 0 to
255
2. //Test RS232 port, (ESC 2 Char CR), Char => any ASCII character
A. //Receive number of analog channels, (ESC A Number CR),
Number => 1 to 8
B. //Receive number of inAmp-type channels, (ESC B Number CR),
Number => 1 to 4
C. // Set inAmp amplification, (ESC C Amplification Input CR),
Input => 09 to 12, Amplification => 0 to 3
D. // Time between events, (ESC D Pin1 Pin2 CR), Pin1 and Pin2 =>
valid pins, can be the same. Valid pins: 49, 50, 51, 52, 53
||| Returns reading in ASCII in microseconds (Long
variable)
E. //Receive the unit working mode, (ESC E Mode CR), Mode => 1
to 5
F. //EEPROM deletion, (ESC F CR)
H. //Set real time clock via I2c, (ESC H hhmmssDDMMYYYY CR)
M. //Generate PWM, (ESC M Pin Duty CR), Pin => 02 to 13, Duty
=> 0000 to 4095
N. // Analog signal generation in DACs, (ESC N Pin Steps CR), Pin
=> 00 to 01, Steps => 0000 to 4095
O. // Transmit data from a file on the SD card, (ESC O File CR), File
format --> 15.3 maximum
P. //Stop unit modes, (ESC P CR)
Q. // Log a fixed piece of data in a file on the SD memory, (ESC Q
CR file), File format --> 15.3 maximum
R. // Timed logging of the set analog channels, (ESC R Time CR),
Time => 1 to 3600 seconds
S. //Set digital output, (ESC S Output Status CR), Output => 02 to
09, Status 0 or 1
T. //Timed transmission of the set analog channels, (ESC T Time
CR), Time => 1 to 10000000 microseconds || Time=0 ->
one transmission
(In analog data, the upper byte is transmitted first, then the lower
byte)
TABLE II. COMMANDS – (CONT)
U. //Transmission of digital input channels in a single binary byte,
(ESC U CR)
W. // Set WiFi network and Password, (ESC W Network 0xFF
Password 0xFF CR), Maximum 15 ASCII-character
network name and password
d. // Download EEPROM data, (ESC d CR)
e. //Transmit data from the unit, (ESC e CR), responds with basic
project data
h. //Transmit RTC day and time, (ESC h CR), responds with unit day
and time
Ref.:
ESC = Escape (0x1b)
CR = Carriage Return (0x0d)
The board functions in different modes. This is directly
associated with each of its features, depending on the
measurement and/or control function sought. These modes
are mutually exclusive.
It was decided that the board would work in the
following three modes:
 Data acquisition (DAQ)
 Automation (AUI)
 Time measurement (TMS)
It is important to note that the operating mode can be
stopped to start using another mode.
Table III describes each operating mode in detail.
For more information on how the firmware was
structured and coded, see the project page:
https://github.com/SADyCUNGSIDEI/Firmware
Although some of the available libraries used in the
Arduino environment may not have been sufficiently tested,
which may affect the reliability and stability of the
firmware, it should be noted that as our firmware is open
source, anyone who is interested in doing so can rewrite it
using appropriate libraries. In other words, if the firmware
is not sufficiently stable or reliable, the library that is
causing the problem can be rewritten, and so, indeed, can
the firmware in its entirety.
a) Software
To provide users with a preliminary interface2 for
communicating with the acquisition and control systems,
we developed software using Python 2.7 [11][12]. We
opted for this programming language because: (1) it is open
2
Given that the system was designed around the use of free hardware and
software, our decision to provide a preliminary interface is far from being
a limiting factor for future designs nor should it be considered in any way
closed or finishing. This interface is a preliminary component—an HMI or
a PDA are examples of possible interfaces that could be developed in the
future.
source, (2) it is supported by an active community of users We used the following graphics libraries: PyQt [14] to
and programmers, (3) it is well-documented, (4) the design the windows and PyQtGraph [14] for plotting data in
programs run on multiple platforms with virtually no two-axes Cartesian graphics.
modifications to the source code, (5) the research team was
The diagram of the software is presented in three layers:
very familiar with it, (6) it supports multiple programming
paradigms, (7) it allows complex applications to be  the presentation layer, in which the view is created in
developed, and (8) numerous open-source libraries are QtDesigner .xml files [15] and controlled by Python
available for specific applications such as 2D and 3D (which uses the .xml files from the view);
graphics, communications, graphical user interfaces,  the logic layer, in which part of the board’s logic and its
scientific calculations, and web development. state is represented; and
 the data access layer, where information is saved on the
hard drive and communication with the series port takes
TABLE III OPERATING MODES place.
Basic specifications for each The layers are ordered as followed: presentation, logic
Description
mode and data access. Each layer only makes use of the layer
DAQ1 "Online" (Mode 1): The board will be asked in real time via immediately below it, so the view layer only sees the logic
- Analog input channels the available communications channel
- Maximum of 8 (e.g. RS232) for the status of the layer, and the logic layer only sees the data access layer.
- Digital input channels analog and digital channels that were
- Maximum of 8 set when the readings were configured.
Fig. 5 shows an example of one of the visualizations
The board will log the status of the that have already been generated, representing a random
analog and digital channels that were variable simulated by the software itself.
DAQ1 "Logging" (Mode 2):
set when the readings were configured
- Analog input channels
on one of the available memory cards.
- Maximum of 8
When required, the data log for the
- Digital input channels
readings can be downloaded via the
- Maximum of 8
chosen communications channel and
processed accordingly.
The board will be asked in real time via
DAQ2 "Online" (Mode 3):
the available communications channel
- Analog input channels
(e.g. RS232) for the status of the
- Maximum of 4
analog and digital channels that were
- Instrumentation-type
set when the readings were configured.
The board will log the status of the
analog and digital channels that were
DAQ2 "Logging" (Mode 4): set when the readings were configured
- Analog input channels on one of the available memory cards.
- Maximum of 4 When required, the data log for the
- Instrumentation-type readings can be downloaded via the
chosen communications channel and
processed accordingly.
AUI (Mode 5): Fig. 5. Screenshot of the software’s graphic interface
The board must be capable of taking
- Analog input channels
readings from all the input channels
- Maximum of 8
specified in the configuration and act
III. PRELIMINARY TESTS
- Analog output channels
- Maximum of 2
on the corresponding output channels We have already discussed the difficulties we faced
as per its programming. regarding the availability of components for the assembly
- Digital input channels
This implies the existence of a control
- Maximum of 8
group, be it remote (the decision- of the prototype board. Consequently, we decided to carry
- Digital relay output channels out our preliminary trials on test boards to analyze
making takes place at an automation
- Maximum of 4
- Digital Open Drain output
center) or local (the board itself makes fundamental aspects such as the behavior of device drivers,
the decisions in question). ADC speed, USB and RS232 communications, and signal
channels
- Maximum of 4
NOTE: This project did not include the reading without the setting and/or amplification stages.
- PWM outputs
implementation of a local control loop
- Maximum of 2
but includes everything necessary to
Although we were fully aware that these types of
- RS232 and RS485
implement a remote one. readings would not show how the actual device would
communication work, they would be useful for adjusting the individual
The board must be capable of
measuring the times between events.
functioning of components such as those already described.
TMS (Mode 6): These are manifested through a change At the time of writing, the entire set of commands had
- Between 2 inputs in the status of a single digital input or
-From a single input between two different digital inputs.
been tested; satisfactory USB and RS232 communications
The result will be reported through the had been established between a PC running the software
appropriate communications channel. and the device firmware; and continuous data transmission
had even been tested. Only basic commands had been tried
via WiFi as the limited bandwidth prevented continuous
transmission readings from being taken. We also carried out
data transfer tests via RS485 without a ModBus protocol, as
we only wished to test up to the connectivity layer without
having to use protocols that make these preliminary tests
more complex.
For the analog signal sampling tests, a Rigol DG1022
signal generator and a Tektronix TDS2001C Oscilloscope
were placed at the input, in order to have all the information
of the signal injected into the test board (Figs 6 and Fig. 7).
Furthermore, the PC software was asked to show the signal
that it detected on the corresponding channel in real time,
and this data was collected via a USB port.
Fig. 6. Trial using the test board
Fig. 7. Test readings
The results were satisfactory for sinusoidal and square
signals on frequencies of up to 100Hz (fig. 8), confirming
that all the components involved in the test were
functioning correctly. It is important to point out that the
curves obtained were within the expected ranges for the
results, but we did not carry out a valid measurement of the
total system error since the final board is not yet available,
so an evaluation of this sort would not provide relevant
data.
When the same test was carried out at higher
frequencies (>1KHz), two problems began to manifest
themselves: (1) the software had stability problems, and the
buffers assigned to data reception and graphing crashed; (2)
an incompatibility in the firmware was detected between
the ADC operating mode and attention to serial events.
Fig. 8. Image of system output during the test at 100Hz
After a detailed analysis of the firmware problems that
arose during these preliminary tests, we concluded that the
ADC’s attention task would have to be restructured to be
able to reduce sampling times to under 1ms. This analysis
led to the rewriting of the ADC driver and the elimination
of the Scheduler (Arduino library) [16], which enabled us
to move past the 100Hz hurdle.
IV. HUMAN RESOURCE DEVELOPMENT
The development of the prototype board described
above entailed focused training of two university students.
The first to join the project was Leandro Funes, a
student from the degree program in Systems who mainly
worked on the integrated development of the system
software. This enabled us to work not only with Mr. Funes
himself but also with the entire Systems department, as we
had to define two sets of criteria: one for building suitable
software for the needs that had been defined and one for the
work Mr. Funes would carry out to ensure that it implied
incremental educational development for him. The tasks in
question gave Mr. Funes the opportunity to write software
using a different programming language to those he was
using as part of his degree course.
Gonzalo Ribera, a student from the technical degree in
Automation and Control, also joined the project and
contributed to developing the firmware modularization.
This brought Mr. Ribera into direct contact with 32-bit
microcontrollers, enabling him to become familiar with
their architecture and create libraries for the different
drivers in question.
Another student from the degree program in Systems,
Agustín Alexander, has also joined the project and will
carry out activities related to the future uses that are being
planned for the board. He will initially assist with the use of
the board for automation and the automatic control of the
movement of a parabolic dish to track the sun, which will
activate a Stirling motor to produce electrical energy on a
small scale.
One of the prototype boards will also be used in
practical exercises on the Advanced Development with
Microcontrollers course, which is part of the degree instruments during the laboratory test phase, and for their
program in Automation and Control. patience.
V. CONCLUSIONS AND FUTURE WORK VII. REFERENCES
We have reached certain milestones that suggest that [1] https://www.researchgate.net/publication/305305142_Data_acquisiti
on_system_for_didactic_laboratories_based_on_open-
this research project is on the right track, namely: source_hardware_and_free_software
 all the system hardware, firmware, and software [2] A. Gibb, Building Open Source Hardware: DIY Manufacturing for
Hackers and Makers, Addison-Wesley Professional, 2015
modules have been designed;
[3] J. M. Pearce, Building Research Equipment with Free, Open-Source
 the PCBs are ready to be assembled; Hardware, Science, 337, 1303–1304, 2012.
 70% of the modules have been tested as part of trials [4] https://store.arduino.cc/usa/arduino-due
with test boards assembled for this purpose; [5] http://www.microchip.com/wwwproducts/en/ATsam3x8e
 the preliminary test results were satisfactory; [6] https://github.com/SADyCUNGSIDEI/
 firmware errors that would be essential to obtaining [7] Printed circuit boards: http://www.mayerpcb.com/
correct readings of analog signals were corrected. [8] Electronic components: http://www.farnell.com/
[9] Electronic board assembly: http://www.assisi.com.ar/
The work ahead in the short term entails different
facets, the most significant of which are: [10] Test board: https://www.mikroe.com/uni-ds
[11] http://python.org
 assembling the final components on the intended boards [12] J.M. Hughes, Real World Instrumentation with Python, Sebastopol:
(the delivery of the components has been delayed once O’Reilly, 2010.
more so it is estimated that this will not be complete [13] http://goo.gl/jFU0Bv
until early June 2018); [14] http://www.pyqtgraph.org/
 verifying that both the reading and communication [15] http://doc.qt.io/archives/qt-4.8/designer-manual.html
functions of the unit are operating correctly; [16] https://www.arduino.cc/en/Reference/Scheduler
 characterizing the reading or measurement errors for [17] J. M. Pearce, Open-Source Lab: How to Build Your Own Hardware
and Reduce Research Costs, Oxford: Elsevier, 2014.
each of the operating modes, contrasting the results with
[18] M. Gopalakrishnan y M. Gühr, A low-cost mirror mount control
ones delivered by standard instruments; system for optics setups, American Journal of Physics, 83, 186, 2015.
 exhaustively documenting the system architecture and [19] K. Zachariadou et al., A low-cost computer-controlled Arduino based
use to facilitate user involvement in the project and educational laboratory system for teaching the fundamentals of
foster use of the system. photovoltaic cells, European Journal of Physics, 33, 1599, 2012.

Once we have made progress on these issues and

published the relevant information and results on the
project website, the vital next step will be engaging
university and research communities and encouraging them
to contribute to a system that has been designed to be
improved, expanded, and enriched by the addition of new
components, both hardware and software.
The values we have recorded to date for the
manufacture of the board and components confirm that the
development costs are within the estimated values, which
suggests that the final version of the system will cost less
than a standard, ready-made version while providing
comparable functionality [17][18][19].
VI. ACKNOWLEDGMENTS
We would particularly like to thank the two
undergraduates who worked as assistants on this research
project for all their hard work and commitment: Leandro
Funes from the degree program in Systems and Gonzalo
Ribera from the technical degree program in Automation
and Control.
We would like to say a special thank you to the staff at
the Engineering Laboratory at the UNGS Institute of
Industry for providing us with technical assistance and