![](bg2.png)
2 BACKGROUND
Data logging is a common problem in many applicati-
ons, which has lead to the creation of several general-
purpose accessories. However, these are primarily
designed for use cases of relatively low data data ra-
tes, and where occasionally missing data is not trou-
blesome.
The OpenLog is one such accessory, based on the
ATmega328P 8-bit MCU and that can interfaced with
via a standard Universal Asynchronous Receiver-
Transmitter (UART) port. It supports an operating
voltage between 3.3-5.0V and has a current consump-
tion of approximately 5mAh while in idle state with
the SD card inserted, and of approximately 20mAh
when writing to the SD card. These specifications
mean that it can be directly powered from the most
common biomedical platforms, and interfaced with
them via the UART.
A problem with this device is that there may be
dropped bytes with baud rates equal or higher than
57600bps (Seidle, 2014), which is a severe limita-
tion for its use with biomedical data acquisition har-
dware, where the combination of the number of chan-
nels and sampling rate can easily reach baud rates of
115200bps. The class of card can help reduce and/or
eliminate this problem, although without guarantees
of reliability using the existing OpenLog hardware
and firmware options.
3 IMPLEMENTATION
Changes were made mainly to the method for confi-
guring the acquisition settings and management of the
read/write buffers to handle at least 115200 bps baud
rates in continuous logging mode. These will be des-
cribed throughout the following sections.
3.1 User-defined Configurations
The OpenLog is primarily designed to be controlled
via commands sent through the UART from an MCU
connected to it (e.g.). In LoggerBIT the user is able
to define the acquisition settings (e.g., sampling rate,
channels to be acquired, etc.), by placing a CSV con-
figuration file named config.txt at the root direc-
tory of the SD card. The configuration file has two
lines, one for the settings and the other for providing
a human-readable description of their definitions, as
can be seen in the following snippet.
1000 , live , 123 4 56 ,0 0 , 0 0
sa mp l i n g rate , mode , ch ann e ls , trigg e r ,
di gi ta l IO
3.2 Recording Loop
The main task of the recording loop is the retrieval
of a data stream from the UART, writing to the log
file and occasionally synchronizing the SD card (i.e.
flushing the buffer). We characterized the operational
demand of each task by measuring their completion
time, determining that, in average, writing approxi-
mately 128 bytes (the size of the read buffer) to the
file takes approximately 50uS, whereas the synchro-
nization lasts close to 5ms.
A major bottleneck is therefore having to periodi-
cally synchronize the card; however, this is a neces-
sary step to ensure that any bytes written to the file are
logically visible within the file system. In addition, it
needs to be performed periodically rather than on the
end of the recording, given that our goal for the Log-
gerBIT is that the user can stop the recording at any
time, by simply powering off the device without prior
announcement or action.
As such, we focused our efforts on improving this
process. When the file is being synchronized to the
SD card, LoggerBIT is blocked on that operation,
meaning that it will not be able to receive any inco-
ming data, potentially leading to a loss of packets.
With the flow-control mechanism, LoggerBIT signals
the transmitter to stop streaming and buffer the data
internally before the synchronization, and to resume
the streaming afterwards; in-between, LoggerBIT has
enough time to synchronize the file. We also modified
the synchronization cycle to have the synchronization
done based on the number of bytes written instead of
time and removed any calls that would put the MCU
in sleep mode, both being the standard approach fol-
lowed by the OpenLog.
3.3 Hardware Flow-control
Our proposed approach to mitigate the byte loss is-
sue is based on implementing UART hardware flow-
control, where LoggerBIT requests the transmitter to
stop sending data while it is executing its critical, i.e.,
time consuming operations. By default, the OpenLog
board does not have a RTS line, as the flow-control
mechanism requires; as such, we changed both the
hardware and firmware of the OpenLog to have one
GPIO working as the RTS line (Figure 1).
Having the OpenLog performing the synchroni-
zations based on the number of written bytes instead
of time (as previously described), provides us with
better control of the timming for card synchroniza-
tion. When the synchronization is happening, the RTS
line is set to the HIGH level, signaling the transmitter
to stop sending data and start buffering it internally.
LoggerBIT: An Optimization of the OpenLog Board for Data Logging with Low Cost Hardware Platforms for Biomedical Applications
601