LoggerBIT: An Optimization of the OpenLog Board for Data Logging

with Low Cost Hardware Platforms for Biomedical Applications

Margarida Reis

and Hugo Pl

acido da Silva

1,2

IT - Instituto de Telecomunicac¸

oes, Instituto Superior T

ecnico, 1049-001 Lisboa, Portugal

Polytechnic Institute of Set

ubal, Campus do IPS, Estefanilha, 2914-508 Set

ubal, Portugal

Keywords:

Biomedical Devices, Data Logging, Biosignal Acquisition, Real-time Applications.

Abstract:

Low cost hardware and open source software tools specialized in biomedical applications have recently seen

a signiﬁcant growth both in popularity and diversity. Within the current landscape of such tools, BITalino

is increasingly used by students and professors for educational activities and prototyping, due to its modular

design and ﬂexibility. However, there is currently no user-friendly way of storing data locally without setting

up a wireless connection to a receiver unit (e.g. a computer or smartphone). This poses a problem, especially

in uses cases where ambulatory data acquisition is needed. In this paper we present the LoggerBIT, a data

logging block to enable data recording onto a microSD card in biomedical development toolkits, without

requiring a connection to a receiver nor any particular programming or electronics skills to setup. Our work

builds upon the OpenLog serial data logger, to which multiple optimisations were made in terms of hardware

and ﬁrmware, overcoming limitations preventing its use in high data throughput applications. Our LoggerBIT

approach is suitable for high-speed data recording, with results showing that it can log data of up to 4 analog

channels at 1000 Hz for 24 hour periods without loss of packets, and from all analog channels with minimal

data loss. This work contributes to the state-of-the-art with a comprehensive description and validation of the

block, and with a set of supporting tools released in open source, thus available for the biomedical engineering

community at large.

1 INTRODUCTION

In the last decade, purpose-built biomedical hardware

platforms to support learning and prototyping follo-

wing a low cost and open source approach have be-

come a staple in the ﬁeld, as they are not limited

by proprietary hardware or software. Examples of

such platforms include the OpenBCI (Russomanno,

2014)(Frey, 2016) and BITalino (Silva et al., 2014),

the latter of which has been reported as one of the

most complete and versatile tools for biofeedback and

quality of life research (even when compared with

the latest wearables), hence being particularly popular

(Nogueira et al., 2017).

However, existing platforms are mostly designed

around the concept of real-time data streaming to a

receiver, which can be quite restrictive. In particular,

for data acquisition in ambulatory settings, streaming

has a direct impact on the battery lifetime (both of

the transmitter and of the receiver) due to the power

required by the radio. It also requires an additional

complexity on the receiver, for tasks such as mana-

ging reconnections when the device goes out of range.

In cases where a memory card is available, this con-

tributes to a higher energy consumption of the over-

all device, and has a direct impact on the achieavable

form factor size when prototyping wearable devices.

In this work we present LoggerBIT, which con-

sists of a hardware and ﬁrmware optimization to a

commercially available data logger, devised to enable

its use in high data throughput applications. This is

targeted at eliminating the need for a radio transceiver

and the dependency on a receiver in a user-friendly

way, when working with low cost and open source

biomedical platforms. We will use BITalino as a

test bed for benchmarking, due to its widespread use.

The remainder of the paper is organized as follows:

Section 2 provides the background, Section 3 descri-

bes the proposed solution, Section 4 presents experi-

mental results on the performance of LoggerBIT in

different testing conditions, and ﬁnally Section 5 out-

lines the main conclusions and future work perspecti-

ves.

600

Reis, M. and Silva, H.

LoggerBIT: An Optimization of the OpenLog Board for Data Logging with Low Cost Hardware Platforms for Biomedical Applications.

DOI: 10.5220/0006872306000604

In Proceedings of the 15th International Conference on Informatics in Control, Automation and Robotics (ICINCO 2018) - Volume 2, pages 600-604

ISBN: 978-989-758-321-6

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 speciﬁcations

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 ﬁrmware options.

3 IMPLEMENTATION

Changes were made mainly to the method for conﬁ-

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-deﬁned Conﬁgurations

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 deﬁne the acquisition settings (e.g., sampling rate,

channels to be acquired, etc.), by placing a CSV con-

ﬁguration ﬁle named config.txt at the root direc-

tory of the SD card. The conﬁguration ﬁle has two

lines, one for the settings and the other for providing

a human-readable description of their deﬁnitions, 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

ﬁle and occasionally synchronizing the SD card (i.e.

ﬂushing 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

ﬁle 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 ﬁle are

logically visible within the ﬁle 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 ﬁle 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 ﬂow-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 ﬁle. We also modiﬁed

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 ﬂow-

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 ﬂow-control

mechanism requires; as such, we changed both the

hardware and ﬁrmware 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

Figure 1: OpenLog with UART hardware ﬂow-control line

support.

Once the synchronization is completed, the RTS line

is set to LOW, signaling the transmitter to resume the

data streaming.

4 EXPERIMENTAL RESULTS

As previously mentioned, we used the BITalino plat-

form as test bed for benchmarking, due to its characte-

ristics and growing adoption. To evaluate the perfor-

mance of the LoggerBIT we tested the loss of samples

for different conﬁgurations of the memory card, num-

ber of channels to acquire and sampling rate, analyzed

the acquisition reliability, and performed a signal dis-

tortion test against a common use case of streaming

over standard Bluetooth.

4.1 Sample Loss

Our LoggerBIT approach was benchmarked against

the standard OpenLog minimal ﬁrmware. To better

understand the effects of the hardware ﬂow-control

mechanism we also evaluated a version of LoggerBIT

that does not use hardware ﬂow-control. The evalua-

ted metrics were the total number of CRC fails and the

total estimated number of lost packets associated with

those fails, based on the sample sequence number.

We started by testing data acquisition sessions

with 8h duration, for which the results are presented

in Table 1. The tests were done until a zero loss conﬁ-

guration of the system was found for each version and

for each card, starting from the most demanding use

case (acquisition of 6 channels at 1kHz) and descen-

ding to the less demanding use case (which would be

the acquisition of 1 channel at 1Hz). Analyzing ﬁrst

the Class 3 card, with the highest write speed (UHS-I

U3 PRO), we can see that, for the original (OpenLog)

version of the ﬁrmware and without hardware ﬂow-

control, there was loss of samples using the most de-

manding acquisition settings. For both versions, we

observed that this ﬁrmware and card combination can

be used reliably for 8h periods, to acquire 4 channels

at 1kHz and 6 channels at 100Hz.

It is important to note that, even though the ﬁrm-

ware without ﬂow-control has registered sample loss,

there was approximately a 50% reduction in the num-

ber of CRC fails and associated number of lost pac-

kets when compared with the original version. This

conﬁrms that the option to enter sleep mode when the

SD card synchronization takes place (followed in the

original ﬁrmware), introduces a signiﬁcant overhead

when dealing with high throughput data received via

the UART. As for the LoggerBIT ﬁrmware, this test

demonstrates how incorporating the hardware ﬂow-

control mechanism improves the performance, consi-

dering that it is capable of being used in the most de-

manding conﬁguration possible for the BITalino de-

vice, without any CRC failure.

The card within the same class rating but with a lo-

wer write speed (UHS-I U3) only worked without any

losses in the most demanding conﬁguration with the

LoggerBIT ﬁrmware. For the remaining versions, the

card proved to be stable only for the same conﬁgura-

tions previously mentioned (4 channels at 1kHz and

6 channels at 100Hz). For acquiring all channels at

the maximum sampling rate, this card had more CRC

fails than the one previously examined, which is li-

kely associated with the lower writing speed.

As can be observed, the card with the lowest speed

class rating (UHS-I U1) is also the less reliable. We

started by testing it with the LoggerBIT ﬁrmware at

the most demanding conﬁguration, and progressively

reduced the number of channels to 2 until no data loss

events occurred while recording data at 1kHz. Be-

cause LoggerBIT is the most effective version of the

ﬁrmware, we only started to test the remaining ver-

sions also from 2 channels, since other channel con-

ﬁgurations would certainly exhibit higher data loss.

For both ﬁrmwares, sampling 2 channels at 1kHz also

appears to be a stable conﬁguration with no associ-

ated CRC failures. As for the possibility to log the

maximum number of channels, this card is capable of

doing so at 100Hz for all versions of the ﬁrmware.

Once we conﬁrmed that the LoggerBIT approach

is the best performing one, we decided to test its re-

liability in long term recordings, by doing a 24-hour

long test of 6 channels at 1kHz using the identiﬁed

optimal SD card (UHS-I U3 PRO). We ran multiple

iterations of this test and veriﬁed that there are always

CRC fails (between 2 to 5), which is fairly acceptable,

but led us to determine a more reliable conﬁguration.

As such, we tested the acquisition of 4 channels at

1kHz, consistently obtaining recordings for 24h wit-

hout any data loss, which enabled us to conclude that

this is the most stable conﬁguration and the one to be

used by default for long-term logging.

ICINCO 2018 - 15th International Conference on Informatics in Control, Automation and Robotics

602

Table 1: Performance of the LoggerBIT while continuously recording data for 8h.

Firmware Version / Card Type / # of Channels

Standard Without hardware ﬂow-control With hardware ﬂow-control

Sampling UHS-I U1 UHS-I U3 UHS-I U3 PRO UHS-I U1 UHS-I U3 UHS-I U3 PRO UHS-I U1 UHS-I U3 UHS-I U3 PRO

Rate [Hz] 2 CH 6 CH 4 CH 6 CH 4 CH 6 CH 2 CH 6 CH 4 CH 6 CH 4 CH 6 CH 2 CH 6 CH 6 CH 6 CH

Decoding 100 - 2.84 - 2.85 - 2.68 - 2.92 - 2.36 - 2.32 - 3.06 - -

time [min.] 1000 21.44 - 22.59 40.31 24.57 39.07 22.63 - 23.41 35.13 23.09 32.38 20.19 38.67 24.02 26.97

# of CRC 100 - 0 - 0 - 0 - 0 - 0 - 0 - 0 - -

fails 1000 0 - 0 13 0 6 0 - 0 4 0 2 0 34 0 0

# of lost 100 - 0 - 0 - 0 - 0 - 0 - 0 - 0 - -

packets 1000 0 - 0 97 0 38 0 - 0 32 0 15 0 227 0 0

4.2 Acquisition Reliability

To test the acquisition reliability we used the most sta-

ble conﬁguration previously determined, connected

BITalino to a function generator and injected a square

wave with a frequency of 1Hz, peak-to-peak ampli-

tude of 3V and DC offset of 150mV into one of the

analog channels. The goal of this test is to com-

pare basic statistics of the parameters of the gene-

rated function against the data actually recorded to

the SD card by the LoggerBIT. During an 8h re-

cording, the average pulse width was approximately

502.2 ± 0.45ms, indexing a maximum of 504ms and

a minimum of 498ms.

We repeated a similar test, but instead of using the

function generator, we connected the RTS line of the

LoggerBIT to one of the digital input pins on BITa-

lino. This way, we can evaluate the effective time

of writing to the SD card, i.e., measure the synchro-

nization process. Results during an 8h test showed

that the average synchronization takes approximately

5.2 ± 1.13ms, with a recorded maximum of 79ms and

minimum of 4ms.

RMSE(x, y) =

∑

k=1

(x [k] − y [k])

(1)

∑

k=1

x [k]

− nµ

(2a)

∑

k=1

y[k]

− nµ

(2b)

∑

k=1

x [k]y [k] − nµ

(2c)

(2d)

4.3 Signal Distortion

Lastly, we tested LoggerBIT in a common usage sce-

nario, that is, recording real-world physiological sig-

nals. For experimental comparison, we performed si-

multaneous acquisition, with optical synchronization,

of an Electrocardiography (ECG) signal sampled at

1kHz while it was being recorded by the LoggerBIT

from one BITalino, and also by a second BITalino

with standard Bluetooth connectivity, streaming all

data to a computer. We analized our data based on the

methodology used in (Batista et al., 2017), where the

suggested comparison metrics to quantify the simila-

rity between acquisitions are the RMSE (Equation 1)

and the coefﬁcient of determination R

(Equation 2,

where µ corresponds to the data mean).

We synchronized the ECG signals by removing

the initial temporal offset, with the support of data

collected by optical sensors in both devices. The syn-

chronized ECG signals were normalized, ﬁltered with

a 300

order bandpass FIR ﬁlter with cutoff frequen-

cies of 3Hz and 45Hz, and segmented using the algo-

rithm by Hamilton (Hamilton, 2002) as implemented

in the BioSPPy

toolbox.

Afterwards, we aligned the segmented heartbeat

waveforms by the R-peak between both ECG sig-

nals and, for each paired segment, we calculated the

RMSE and the coefﬁcient of determination R

of the

corresponding templates. Figure 2 shows part of the

time domain representation of the segmented heart-

beat waveforms as extracted from the ECG signals

acquired by the different devices.

We concluded this morphological comparison by

aggregating the results per segment in an single va-

lue, in the form of the overall average and stan-

dard deviation across all segments, for each compa-

rison metric. As such, for the RMSE the result was

0.00715 ± 0.00195 and for the coefﬁcient of determi-

https://github.com/PIA-Group/BioSPPy

LoggerBIT: An Optimization of the OpenLog Board for Data Logging with Low Cost Hardware Platforms for Biomedical Applications

603

Figure 2: Partial time domain representation of the supe-

rimposed segmented heartbeat waveforms as they were re-

corded by the BITalino (r)evolution and the LoggerBIT.

Figure 3: BITalino (r)evolution board in a dual MCU setup

allowing simultaneous Bluetooth streaming and data log-

ging with LoggerBIT.

nation R

it was of 0.984 ± 0.0194. As we can see,

there is a high correlation between both ECG signals,

as the value for the RMSE is low and the value for

is high and close to 1. This allows us to demon-

strate that the signals acquired through LoggerBIT are

in agreement with those collected using the standard

approach.

5 CONCLUSIONS

In this paper we presented LoggerBIT, a hardware

and ﬁrmware optimization of the OpenLog serial data

logger, with the goal of making it usable with low

cost and open source biomedical data acquisition plat-

forms with the best performance possible. We then

evaluated the performance of our approach, using the

BITalino platform as a test bed, for different variati-

ons of the data acquisition settings (i.e. channels and

sampling rate) and SD cards with diverse speed class

and write speed ratings. Figure 3 shows an example

deployment of LoggerBIT on our test bed.

Results show that the LoggerBIT can operate reli-

ably in the most demanding conﬁguration of BITalino

(6 channels at 1kHz) using Class 3 UHS-I U3 PRO

cards. In 8h recordings no data loss events appear to

occur, and for longer periods minimal data loss is de-

tected (e.g. 2 to 5 packets loss over a 24h period),

outperforming the other approaches under testing. In

terms of battery life, our tests have shown that the

LoggerBIT is able to operate for approximately 40h

using a 3.7V 700mAh battery, which is a signiﬁcant

gain when compared with the approximately 12h of

operation in the Bluetooth streaming approach.

Future work will focus on further characterizing

the overall LoggerBIT architecture in order to prevent

packet loss as the memory card has more space occu-

pied (as shown by the 24h tests) and on benchmarking

our approach using commonly used biomedical plat-

forms other than BITalino as a test bed.

ACKNOWLEDGMENTS

This work is funded by FCT/MEC through natio-

nal funds and when applicable co-funded by FE-

DER PT2020 partnership agreement under the pro-

ject UID/EEA/50008/2013 “SmartHeart”. The deve-

lopments herein described have been publicly relea-

sed and made available to the community at large

in alignment with the open hardware and open source

software movement.

REFERENCES

Batista, D., Silva, H., and Fred, A. (2017). Experimen-

tal characterization and analysis of the BITalino plat-

forms against a reference device. In Proc. IEEE Eng.

in Medicine and Biology Society Annual Int’l Conf.,

pages 2418–2421.

Frey, J. (2016). Comparison of an open-hardware electroen-

cephalography ampliﬁer with medical grade device in

brain-computer interface applications. In Int’l Conf.

on Physiological Comp. Syst., pages 105–114.

Hamilton, P. (2002). Open source ECG analysis. Computers

in Cardiology, pages 101–104.

Nogueira, P., Urbano, J., Reis, L., Cardoso, H., Silva, D.,

and Rocha, A. (2017). A review between consumer

and medical-grade biofeedback devices for quality of

life studies. In Recent Adv. in Inf. Syst. and Tech.,

volume 570, pages 275–285. Springer.

Russomanno, C. (2014). Open BCI: Rise of the brain-

computer interface. Make:.

Seidle, N. (2014). OpenLog: Open source data logging.

GitHub.

Silva, H., Fred, A., and Martins, R. (2014). Biosignals for

everyone. IEEE Pervasive Computing, 13(4):64–71.

https://github.com/BITalinoWorld/ﬁrmware-loggerbit

ICINCO 2018 - 15th International Conference on Informatics in Control, Automation and Robotics

604