Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet

gnipökrroN 47 106 nedewS ,gnipökrroN 47 106-ES

LiU-ITN-TEK-A--17/057--SE

Implementation of vital signdetection algorithms on ahigh-performance digital

signal processorTobias Pettersson

2017-10-27

LiU-ITN-TEK-A--17/057--SE

Implementation of vital signdetection algorithms on ahigh-performance digital

signal processorExamensarbete utfört i Elektroteknik

vid Tekniska högskolan vidLinköpings universitet

Tobias Pettersson

Handledare Adriana SerbanExaminator Qin-Zhong Ye

Norrköping 2017-10-27

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Tobias Pettersson

Abstract

This thesis investigates the possibility of detecting weak vital signs, such as heart-beat and respiration rate, through the implementation of quadrature demodula-tion and frequency spectrum algorithms on a high performance digital signal pro-cessor. This thesis has been part of an ongoing research project at Linkoping Uni-versity, with the aim to develop a sensor platform for wireless measurements ofthese vital signs. This sensor platform has been expected to consist of two majorphysical devices, a RF-radar front-end including a quadrature multi-port and aprocessing back-end which holds the implementation of the algorithms to detectthe vital signs. The back-end consists of a data acquisition- and a processing-partwhich together forms the digital signal processor.

The results show that the implemented algorithms works in terms of beingable to find artificial vital signs from quadrature signals. This result also confirmsthat the hardware solution proposed during this thesis, has been considered asviable for the aim of the project.

i

Acknowledgements

Thanks to Qin-Zhong Ye, Adriana Serban and Gustav Knutsson at the depart-ment of science and technology at Linkoping University for equipment, guidanceand help.

Special thanks to the student Henrik Kalver at Linkoping University for pro-viding motivational speeches and occasionally being a much needed soundingboard that helped provide new angles towards solving problems.

ii

Acronyms

Abbr. Description

ADC Analog to Digital ConverterDMA Direct Memory AccessDSP Digital Signal ProcessorFFT Fast Fourier TransformFIR Finite Impulse ResponseFPGA Field Programmable Gate ArrayGUI Graphical User InterfaceIDE Integrated development environmentIIR Infinite Impulse ResponseMATLAB Matrix LaboratoryMCU Micro Controller UnitPCB Printed Circuit BoardRF Radio FrequencyRMII Reduced Media-Independent InterfaceUSB Universal Serial Bus

iii

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 System overview 52.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 The multi-port correlator . . . . . . . . . . . . . . . . . . . . 62.1.2 Demodulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 The sensor platform . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 The Nucleo board . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 The ADCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 The Ethernet controller . . . . . . . . . . . . . . . . . . . . . . 11

3 Data acquisition 123.1 Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Defining the sampling clock . . . . . . . . . . . . . . . . . . . 133.2.2 Dual-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.3 Configure the DMA . . . . . . . . . . . . . . . . . . . . . . . 163.2.4 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Processing 184.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 The frequency spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iv

4.2.2 Peak detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Demodulation with arc-tangent . . . . . . . . . . . . . . . . . . . . . 22

4.3.1 Adjusting the error . . . . . . . . . . . . . . . . . . . . . . . . 234.3.2 Rotating into first octant . . . . . . . . . . . . . . . . . . . . . 254.3.3 The Taylor approximation in code . . . . . . . . . . . . . . . 264.3.4 The frequency spectrum with a phase-shifted signal . . . . . 28

5 Pre-processing 305.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.1 Generating coefficients . . . . . . . . . . . . . . . . . . . . . . 315.2.2 Implementing the filter . . . . . . . . . . . . . . . . . . . . . 32

5.3 Decimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Sliding window effect . . . . . . . . . . . . . . . . . . . . . . . . . . 365.5 Data buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.5.1 The ADC-buffer . . . . . . . . . . . . . . . . . . . . . . . . . . 365.5.2 The ring buffer . . . . . . . . . . . . . . . . . . . . . . . . . . 375.5.3 Other buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Communication link 396.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2 UART-communication . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2.1 Communication protocol . . . . . . . . . . . . . . . . . . . . 406.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Graphical User Interface 457.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.1 Describing the GUI . . . . . . . . . . . . . . . . . . . . . . . . 457.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 467.2.3 Finalized GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8 Test benches 508.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.2 Signals generated in MATLAB . . . . . . . . . . . . . . . . . . . . . 50

8.2.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528.3 Time estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

9 Results 549.1 Concept and result outline . . . . . . . . . . . . . . . . . . . . . . . . 549.2 Testing the algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9.2.1 ADC measures . . . . . . . . . . . . . . . . . . . . . . . . . . 649.3 Measuring the algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 66

9.3.1 The processing loop . . . . . . . . . . . . . . . . . . . . . . . 669.3.2 ADC and data collection . . . . . . . . . . . . . . . . . . . . . 67

v

9.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

10 Discussion 6910.1 Tests of the algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.1.1 Addition of noise . . . . . . . . . . . . . . . . . . . . . . . . . 6910.1.2 The use of decimation . . . . . . . . . . . . . . . . . . . . . . 7010.1.3 Artificial vital signs . . . . . . . . . . . . . . . . . . . . . . . . 7010.1.4 Usage of the ADCs . . . . . . . . . . . . . . . . . . . . . . . . 7010.1.5 The GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

10.2 Time consumption of the algorithm . . . . . . . . . . . . . . . . . . . 7110.2.1 The processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7110.2.2 The communication link . . . . . . . . . . . . . . . . . . . . . 7110.2.3 The data collection . . . . . . . . . . . . . . . . . . . . . . . . 72

11 Conclusion 7311.1 In general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

11.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7311.1.2 The algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 7311.1.3 Test and verification . . . . . . . . . . . . . . . . . . . . . . . 74

11.2 Further development . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

References 75

vi

List of Figures

2.1 Translation of a quadrature mixer into a multi-port [4]. . . . . . . . 62.2 Blockdiagram describing the entire sensor platform. . . . . . . . . 82.3 Flowchart of the expected data through the DSP-kernel. . . . . . . 9

3.1 Sample code showing the configuration of the timer. . . . . . . . . 15

4.1 Sample code showing the FFT-implementation. . . . . . . . . . . . 194.2 Reference spectrum calculated in MATLAB of the super-position

signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Spectrum calculated using the DSP-FFT functions from ARM. . . . 214.4 Sample code showing the calculation of peaks in the output spec-

trum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Comparing the MATLAB atan2 to three different orders of Taylor

expansions for arctan. . . . . . . . . . . . . . . . . . . . . . . . . . . 224.6 Showing the error at t = 1 compared to the atan2. . . . . . . . . . . 234.7 Comparing the adjusted Taylor expansion to the old one and to

atan2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.8 The implemented code for arctan approximation in the first octant. 244.9 The unit circle divided into four quadrants. . . . . . . . . . . . . . . 254.10 The implemented code to rotate any coordinate into the first octant. 264.11 The implemented code for approximation arctan with Taylor ex-

pansion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.12 The reference frequency spectrum for the phase-shifted signal. . . 284.13 The frequency spectrum for the phase-shifted signal, calculated

with the Taylor approximation in MATLAB. . . . . . . . . . . . . . 294.14 The frequency spectrum for the phase-shifted signal, calculated on

the DSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Frequency response of the implemented Butterworth filter. . . . . 325.2 The implemented filter in C-code. . . . . . . . . . . . . . . . . . . . 325.3 The super position signal in the time domain. . . . . . . . . . . . . 335.4 The filtered result of the super position signal, in the time domain. 335.5 The filtered result from the DSP, in the time domain. . . . . . . . . 345.6 The filtered frequency spectrum from the DSP. . . . . . . . . . . . . 34

vii

5.7 Sample code for the decimation of data. . . . . . . . . . . . . . . . . 355.8 Illustration of the data flow into the ADC-buffer. . . . . . . . . . . 375.9 A linear buffer in a ring buffer configuration. . . . . . . . . . . . . . 38

6.1 Illustration of the packet structure sent between devices. . . . . . . 416.2 Skeleton for the uartSend-function. . . . . . . . . . . . . . . . . . . . 436.3 The if-statement to determine the amount of packets to send. . . . 44

7.1 The first computerized sketch of the GUI. . . . . . . . . . . . . . . . 467.2 Setting up the figure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.3 The figure window, generated by the sample code. . . . . . . . . . 477.4 Sample code for initializing the serial connect button in MATLAB. 477.5 Sample code for the callback connected to the serial connect but-

ton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.6 The final GUI-window with all the elements added. . . . . . . . . . 49

8.1 A simple illustration of a 32-bit word and its sub-components. . . 518.2 An illustration of how to measure the on time of the signal. . . . . 53

9.1 The algorithm response from test signal 1, without arc-tangent de-modulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.2 The algorithm response from test signal 1, with arc-tangent enable. 559.3 The algorithm response from test signal 2, without any arc-tangent

demodulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569.4 The algorithm response from test signal 2, with arc-tangent enable. 569.5 The algorithm response from test signal 3. The arc-tangent module

is disabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579.6 The algorithm response from test signal 3, with arc-tangent enable. 579.7 The algorithm response from test signal 4, without arc-tangent. . . 589.8 The algorithm response from test signal 4, with arc-tangent enable. 589.9 The algorithm response from test signal 5, without arc-tangent. . . 599.10 The algorithm response from test signal 5, with arc-tangent enable. 599.11 The algorithm response from test signal 6, with the arc-tangent de-

modulation disabled. . . . . . . . . . . . . . . . . . . . . . . . . . . 609.12 The algorithm response from test signal 6, with arc-tangent enable. 619.13 The algorithm response from test signal 8. Arc-tangent is disabled. 629.14 The algorithm response from test signal 8, with arc-tangent enable. 629.15 The algorithm response from test signal 10, without arc-tangent

demodulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639.16 The algorithm response from test signal 10, with arc-tangent en-

able. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639.17 The algorithm response to a 10 Hz sine wave, with arc-tangent dis-

abled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.18 The algorithm response to a 1 Hz sine wave, with arc-tangent dis-

abled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.19 The algorithm response to a 100 mHz sine wave, with arc-tangent

disable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

viii

List of Tables

3.1 The sampling characteristics for the ADCs . . . . . . . . . . . . . . . 143.2 ADC sampling and trigger frequencies . . . . . . . . . . . . . . . . . 17

4.1 Considered requirements for the FFT-implementation . . . . . . . . 184.2 Modified constants for arctan approximation . . . . . . . . . . . . . 234.3 Rotation of coordinates in the unit circle . . . . . . . . . . . . . . . . 25

5.1 Butterworth coefficients for the filter . . . . . . . . . . . . . . . . . . 315.2 Butterworth coefficients sorted into a linear buffer . . . . . . . . . . 32

6.1 Requirements on the communication protocol . . . . . . . . . . . . 416.2 Types of messages sent through the UART-communication . . . . . 44

8.1 Summary of the different configurations for test signals . . . . . . . 52

9.1 Time consumed by the three main modules . . . . . . . . . . . . . . 669.2 Time consumed by the two different fputc-functions . . . . . . . . . 669.3 Time needed per byte sent through the UART . . . . . . . . . . . . . 679.4 Time consumed by the entire processing loop . . . . . . . . . . . . . 679.5 Time used to copy data into the processing loop . . . . . . . . . . . 679.6 Total time needed to process new data . . . . . . . . . . . . . . . . . 689.7 Total idle time with the desired update frequency of 2 Hz . . . . . . 68

ix

1Introduction

1.1 Background

Multi-port transmitters and receivers have been investigated at Linkoping Uni-versity, by the Communication Electronics research group, to be used in systemsfor high data rate transmission. Due to the nature of the correlator component,the multi-port technique has excellent phase-discriminating capabilities, whichmakes them appropriate for use in radar devices in special industrial, automo-tive and medical applications.

Among this variety of applications, the wireless detection of weak, low fre-quency vital signs such as heartbeat and respiration rate are of particular interest.Using the multi-port technique for such applications, benefits from low-powerconsumption, good linearity and low circuit complexity. However, as with anyradar device or application, the Radio Frequency (RF) front-end should be com-plemented by a Digital Signal Processor (DSP) back-end in order to present thedata to the user.

Currently there is a research project at Linkopings University, with the aim todesign and optimize a sensor platform, to measure these vital signs. The sensorplatform can be divided into three parts/subsystems with the following func-tions:

• Multi-port radio/radar system

• Acquisition board consisting of A/D conversion in real time

• Digital signal processor for processing and windowing data

Furthermore this sensor platform should have a communication link towardsa computer or server, in order to present the data to the user. This communicationlink should be included as a module in the DSP-subsystem.

1

1.2 Purpose

This master thesis aims at implementing the acquisition- and DSP-part of thedescribed sensor platform. How these two parts are implemented and whetherthey are put together in one unit or not, is left for the thesis to answer. The twoparts should be fast enough to measure and process the output ports from multi-port radar, while also being able to transfer this data to another location/device.If successful, the outcome of this thesis could be used to further aid the ongoingresearch project.

To also enhance the possible outcome of this thesis, a Graphical User Inter-face (GUI) or a similar interface has been requested. This interface should allowthe data collected to be easily evaluated, using for instance a diagram or a plot.This interface should however be separate from the DSP-part but continuouslyreceive new data, to keep itself updated. A suggestion has been made towardsimplementing this GUI in Matrix Laboratory (MATLAB).

1.2.1 Problem statement

This thesis will be built upon answering these questions, where the first one con-cerns what type of hardware to use. The last question is considered as secondaryand will only be evaluated if time is still available.

• How should the data acquisition and the DSP-part be implemented? Asseparate units put together into a standalone device or as an already existingsolution?

• How should the DSP-kernel with its different modules be implemented inthe available hardware?

• What kind of communication link between the sensor platform and thecomputer should be used?

• (Secondary objective) How should the computer or server be utilized inorder to present the data to the user? Should MATLAB as suggested beused, or is there another way such as using a C/C++ implementation?

1.2.2 Delimitation

The sensor platform should also include the RF-part with the multi-port corre-lator and the radio/radar system to become the intended platform. This partwill not be covered in this thesis but is instead part of another students thesis.However, since this thesis and a big part of the acquisition system is heavily de-pendent on the levels of signals generated by the multi-port correlator, there willbe a close development together with this other student.

2

1.3 Outline

This report will describe the work and procedures done by the author duringthis master thesis. This includes all information relevant to the results and to theconclusion of the thesis.

The Introduction-chapter will provide the reader with a basic understandingof the task upon which this thesis has been conducted, in terms of purpose andproblem formulations. This chapter will also describe what this thesis contains interms of outline.

The System overview-chapter will describe the approach made towards solvingthe task at hand. It will also provide brief theory for the entire sensor platformalong with necessary theory for the data acquisition- and DSP-parts. This chapterwill also provide information about the hardware used to hold the implementa-tion of the data acquisition- and DSP-parts.

The Data acquisition-chapter describes how the collection of data has been im-plemented, together with tests and evaluations of how the implementation wasworking. From a development point of view, the Data acquisition-chapter was firstin a chronological order, and also included the first tests made to verify whetherthe chosen hardware was enough in terms of collecting data or not.

The Processing-chapter contains the implementation of the two major algo-rithms used in this thesis, the phase-demodulation and the frequency spectrumcalculation. This chapter was also the second in chronological order, and testedwhether the performance of the hardware was enough.

The Pre-processing-chapter describes the implementation of a digital filter inorder remove undesired components. This chapter also describes the decimationthat followed the filtering in order to reduce the sampling speed of the system, aswell as the implementation of the storage of data along the execution loop.

The Communication link-chapter will provide the reader with insight on howthe communication between the DSP-part and a computer is implemented. Thisincludes the design of a protocol for transmitting larger chunks of data, as wellas the re-targeting of some standard C-library functions.

The Graphical User Interface-chapter describes the implementation and designof a GUI in MATLAB, where data will be presented towards the user in a MAT-LAB plot.

The Test benches-chapter contains the description of test made in MATLAB,to verify the implemented algorithms. The chapter also describes performancemeasures that should be done onto the algorithm in order to determine the timeconsumption.

The Result-chapter contains the results collected from the tests made accordingto the Test benches-chapter. These results are mainly presented as figures of theimplemented GUI with the corresponding results.

The Discussion-chapter does just that. It discusses the results presented, butalso the overall performance and drawbacks of the implemented system.

Finally the Conclusion-chapter summarizes this master thesis by answeringthe problem statement from above, along with some suggestions for further de-velopment.

3

1.4 Method

During this thesis several different sources of information have been used in or-der to gather the necessary knowledge needed to implement the task at hand.Where needed, these external sources for information will be cited to give thereader the possibility to verify decisions and approaches made. Alongside thisinformation, decision regarding what kind of hardware and software to use hasbeen made. Some of these decisions have been influenced by the needs of theresearch project.

1.4.1 Hardware

The hardware used in this project consists of an evaluation platform and testequipment. The evaluation platform is the STM32 Nucleo board from ST [1],upon which the developed algorithms has been deployed on, while the test equip-ment is separated into two devices. The first device is an 33120A Abritrary Wave-form Generator from Hewlett Packard (Agilent) [2] and the second device is anDSO-X 2012A Oscilloscope from Agilent Technologies [3].

1.4.2 Software

The software used in this project consists of a programming Integrated devel-opment environment (IDE) from ST, called STM Workbench, which is a modifi-cation to the freely distributed Eclipse IDE. Along with this workbench, followsalso a compiler targeting the previously mentioned evaluation platform. Thiscompiler is embedded into the STM Workbench IDE. ST also provides a firmwarepackage for the evaluation platform, which has been used.

In order to test the algorithms, MATLAB from MathWorks has been used.MATLAB has also been used to develop and test the GUI, which is responsiblefor collecting the data sent from the evaluation platform. The use of MATLABhas been available through Linkoping University.

4

2System overview

2.1 Concept

In order to measure vital signs, without any physical contact to the patient, aradar device will be implemented using the specified frequency of 5.8 GHz. Theradar device will send out this signal towards the patient and then also collectthe reflected signal. Upon hitting the patient and being back scattered, the origi-nal signal will be modulated with a phase that contains the relevant informationabout the vital signs. Eq. 2.1 shows the outgoing SLO and the phase-modulatedSRF, both carrying the 5.8 GHz signal denoted as fLO.

SLO = A1 cos(2π fLO)

SRF = A2 cos(2π fLO + φ(t))(2.1)

As can be seen in the equations, the reflected SRF contains an unknown phasecalled φ(t). This phase is expected to contain the vital signs gathered from thepatient together with potential noise. Eq. 2.2 shows the expected contents of theunknown phase.

φ(t) = cos(2π fRR) + cos(2π fHR) + θ(t) (2.2)

Apart from θ(t), which is considered as noise, the two vital signs respira-tion and heartbeat rate, denoted fRR and fHR respectively, are hidden within thisphase. The frequency of the respiration rate and the heartbeat rate, could herebe determined by translating the phase-signal from the time domain into the fre-quency domain. This translation could be performed by the use of Fourier trans-form.

5

2.1.1 The multi-port correlator

The receiver front-end using the multi-port technique is shown to the right inFigure 2.1. This multi-port correlator is compared, for clarity of operation, to theclassical receiver front-end, to the left in Figure 2.1. The multi-port correlator con-sists of a Wilkinson power divider and three quadrature couplers, and is usuallyimplemented with transmission lines on a Printed Circuit Board (PCB).

Figure 2.1: Translation of a quadrature mixer into a multi-port [4].

To perform the operation of a mixer, diodes and filters are connected at thefour outputs of the multi-port correlator. Moreover, the use of the multi-porttechnique in conjunction with the diodes, will perform quadrature demodulationof the incoming SRF-signal by the means of the coherent SLO-signal.

The multi-port correlator will split the input signals SRF and SLO along dif-ferent paths so that, at the output of the correlator, linear combinations with dif-ferent phase delays are generated. Through the squaring operation of the diodesfollowed by filtering of harmonics, the in-phase I and quadrature phase Q sig-nals are obtained, at the output of the multi-port front-end. Moreover, the signalsobtained are differential such that the in-phase signal consists of I− and I+ whilethe quadrature phase signal consists of Q− and Q+. With the input signal SRF

and SLO from Eq. 2.1, at the port P1 and P2 in Figure 2.1, the output at ports P3and P4 can be written as Eq. 2.3, in phasor-form.

P3signal =A2

2ei(2π fLO+φ(t)−180) +

A1

2ei(2π fLO−360)

P4signal =A2

2ei(2π fLO+φ(t)−270) +

A1

2ei(2π fLO−270)

(2.3)

6

In a similar way, the output at ports P5 and P6 can be written as Eq. 2.4.

P5signal =A2

2ei(2π fLO+φ(t)−270) +

A1

2ei(2π fLO−180)

P6signal =A2

2ei(2π fLO+φ(t)−180) +

A1

2ei(2π fLO−270)

(2.4)

After performing the squaring operation using the diodes along with filtering,the expected output signals are shown in Eq. 2.5.

I− = −A1A2

4cos(φ(t))

I+ =A1A2

4cos(φ(t))

Q− = −A1A2

4sin(φ(t))

Q+ =A1A2

4sin(φ(t))

(2.5)

The output signals can be further processed, either as differential signals oras single-ended signals. A differential to single-ended amplifier can be used toaccomplish the signals in Eq. 2.6.

I =A1A2

2cos(φ(t))

Q =A1A2

2sin(φ(t))

(2.6)

At this point, the 5.8 GHz carrier has been removed through down conversionof the SRF-signal to the base band. This ideally means that only the phase, thatincludes the information about the vital signs remain.

2.1.2 Demodulation

The quadrature signals at the output of the multi-port front-end needs furtherdemodulation in order to extract the phase from the signal. This can be done bythe use of the arc-tangent function as shown in Eq. 2.7.

φ(t) = arctanQ

I⇔ φ(t) = arctan

sin(φ(t))

cos(φ(t))(2.7)

7

This would result in the unknown phase φ(t), being represented as the super-position signal described in Eq. 2.2. However, in order to get a valid φ(t), both thequadrature signals have to be collected from the output of the multi-port front-end at the same time.

The acquisition-part

The collection of this data is done by the acquisition part of the sensor platform.Since the acquisition part also is the connection to the DSP-part of the platform,this will be some sort of Analog to Digital Converter (ADC). Furthermore, sincethere are at least two outputs from the multi-port front-end, there has to be atleast two separate ADCs in order to collect the data simultaneously.

The DSP-part

When the ADCs have collected a pair of samples from the output of the multi-port front-end, this will be sent to the DSP-part. The DSP-part will then demod-ulate the incoming samples according to Eq. 2.7 to get the desired φ(t). Thedemodulated phase will finally be translated into the frequency domain with theuse of Fast Fourier Transform (FFT) in order to get a spectrum of the frequenciesthat the signal consists of. The result from the FFT, will be transferred through acommunication link, to a computer or server where the data will be presented tothe user in plot.

2.1.3 The sensor platform

To summarize the above sections and theory into a graphical perspective, theblock diagram in Figure 2.2 was made. The block diagram briefly describes thesensor platform in terms of hardware.

Figure 2.2: Blockdiagram describing the entire sensor platform.

8

2.2 Task

As mentioned, the task of this thesis is to implement the acquisition- and DSP-part of the sensor platform, together with an interface that can present the finaldata to the end user.

The acquisition part of the sensor platform should include two separate ADCsfor sampling of the I and Q signals of the multi-port. These two signals have tobe sampled simultaneously in real time, to not get skew in the data. Furthermore,these two ADCs have to have enough resolution and enough speed to give accu-rate samples. The DSP-part of the sensor platform should include the followingfeatures:

• Filtering and decimation

• Arc-tangent calculation between the I and Q signals to determine the phase

• Fast Fourier Transform (FFT) to be able to determine the frequency of theincoming signals

• Peak detection and windowing of data

• Communication link (Ethernet/USB) to computer or server

The flowchart in Figure 2.3 shows the expected flow of data from ADCs touser, with the previously mentioned features to the DSP-part.

Figure 2.3: Flowchart of the expected data through the DSP-kernel.

9

2.3 Hardware

The first part of this thesis was put into deciding what kind of hardware thatshould be used in order to implement the acquisition- and DSP-part described inthe previous section. The most important points included the need of at least twoADCs, either Universal Serial Bus (USB) or Ethernet connectivity for the commu-nication link and finally enough processing speed to perform the rather heavyFFT.

Together with the participants of the research project, the decision was madeto use an existing evaluation platform such as the STM32 Nucleo-F767ZI. Thediscussion had previously been to use an Field Programmable Gate Array (FPGA)system as the DSP-algorithms, in order to efficiently build a pipe lined structurethat could process data very fast. This was however rejected mainly becauseof the high price of such a device, but also because this particular evaluationplatform included many of the peripherals needed.

2.3.1 The Nucleo board

The Nucleo development board contained a STM32F767ZI Micro Controller Unit(MCU), which is essentially an ARM 32-bit Cortex-M7 [5]. Furthermore, it con-tained both USB and Ethernet connectors which were possible to program andsetup through the MCU. ST, who has developed the platform, also provided aprogramming IDE based on Eclipse, which made it possible to program and alsodebug the code with minor additional setup steps.

The MCU itself included several needed perks for this project. First of all, theprocessor core could run at 216 MHz and had dedicated DSP instructions, whichwould make the FFT calculations among other things more efficient. The amountof available memory on the device was up to 2 MB of flash together with 512 kBof SRAM. The MCU also had three separate ADCs which could be configured towork in parallel. These ADCs could also be configured to use the on-board DirectMemory Access (DMA) controller in order to reduce the number of calls to theprocessor.

Finally, since the board was an evaluation platform, it included an on boardUSB-to-serial controller acting as a debugging interface between the computerand the board. This allowed the board to be powered from the USB-port of acomputer, regardless if the board was being debugged or not.

2.3.2 The ADCs

As previously mentioned, the STM32F767ZI MCU contained three separate ADCs.All of these had a maximum resolution of 12-bits, but could be configured forlower resolutions if necessary. The result from each conversion was stored into a16-bit data register, from where it then could be collected either by the processoritself or by a DMA-unit. Each one of these ADCs allowed a maximum sample rateof 2.4 MSa/sec, which was considered more than enough for this application.

10

The ADCs could also be configure in dual or triple mode which allowed themto work in parallel. This kind of configuration would also increased the totalamount of Sa/sec. Together with the DMA-unit it was also possible to generateuser-defined interrupts such as on each conversion from the ADCs or when theDMA-unit has collected a certain amount of samples. By using the second typeof user-defined interrupts it would be possible to buffer data into larger chunksof data that all could processed at once.

2.3.3 The Ethernet controller

One of the many features this Nucleo board had, was the Ethernet connectionport which allowed the device to be connected to an Ethernet network. Thisessentially meant, that when properly configured, the device could send and re-ceive data from the internet or a local area network, which was likely to exist ator close to the installation of the future finished device.

The Ethernet controller supported 10M/100M communication speed, and wasconnected to the MCU through a Reduced Media-Independent Interface (RMII).ST did not provide any own software when using the Ethernet device, but wasinstead relying on the lightweight TCP/IP protocol suite, that was made availablethrough LwIP-project [6]. This suite was included as a third-party software in thegeneral firmware package that ST made available for the Nucleo board.

11

3Data acquisition

3.1 Sampling

As previously mentioned, the vital signs that should be monitored was the heart-beat and the respiration rate. Both of these signals are relatively low in frequency.

The heartbeat rate varies between different persons and depends on severalfactors. However, a general rule for the maximum heartbeat rate of a person isshown in Eq. 3.1.

HEARTBEATMAX = 220 − age, where age is years (3.1)

This sets the highest frequency for the heartbeat to about 3.6 Hz, when dis-regarding the age. On the contrary, the lowest frequency of the heartbeat goestowards zero [7].

The respiration rate of a person is also varying between persons, but in gen-eral an adult person at rest takes about 12 breaths per minute [8]. This rate willincrease with increased activity, however this will never reach the fast pace ofthe heart. Therefore, the low rate of 12 breaths per minute can be used to set thelower limit of the frequency span, where the vital signs is expected to be. Thisspan reaches from 0.2 Hz, from the respiration rate, to 3.6 Hz, from the heart rate.

According to the Nyquist sampling criterion, the minimum sampling frequencyneeded, in order get a correct representation of the analog signal in the digital do-main, must be two times the highest frequency we want to represent. This wouldmean that, this system needs to gather at least 7.2 Sa/sec, to fulfill the criterion.

The three ADCs on the Nucleo board could sample at a maximum speed of2.4 MSa/sec. Since this sampling speed was more than enough to fulfill the pre-viously mention criterion, the real challenge would be to reduce the samplingspeed to a somewhat more reasonable amount. However, the low sampling speedstated by the criterion, was not ideal either. Therefore, in order to allow filtering

12

and decimation in the pre-processing steps, the sampling rate was decided to be2048 Sa/sec.

3.2 Implementation

As previously mentioned, the MCU mounted on the Nucleo board ships withthree ADCs that can run in parallel. This allows three samples to be gathered atthe same time.

This project was designed with the intention of gathering two samples at thesame time, which then also means that only two ADCs are in use. Gatheringthese two samples at the same time, is however crucial because of the arc-tangentdemodulation.

The ADCs can be used together with a DMA in order to offload the processorwhen continuously sampling. The DMA could then be configured to alert theprocessor by triggering an interrupt, when a certain amount of samples has beencollected. These samples could then be gathered by the processor and put intothe algorithm. This way would also allow the processor to work with blocks ofdata rather than single samples, which is needed for the FFT-algorithm.

3.2.1 Defining the sampling clock

One of the most important steps when configuring the ADC, was to define theclock to which each ADC sample would be triggered. This would essentiallydetermine the sample rate of the ADCs and would need to be low enough, inorder to reach the desired sample rate.

The ADC-clock

The ADC-modules includes an ADC-clock which among other things, sets thetime used to collect each sample. This means, the ADC-clock sets the sampletime used during a single measure by the ADC. If the ADCs would be configuredto continuously sample, this clock also sets the sample rate.

According to the reference manual of the STM32F767ZI [9], the ADC-clockwas derived from the APB2 clock through a programmable pre-scaler. The APB2clock was in turn derived from the system clock, which also could be configurethrough a programmable pre-scaler. This defined the ADC-clock as described inEq. 3.2. However, according to the datasheet of the STM32F767ZI, the maximumADC-clock was 36 MHz, which makes the equation only valid for ADC-clocksthat are below this value.

fADC =fSYSCLK

APB2DIVIDER · ADCDIVIDER(3.2)

The conversion time needed for the ADC to make one measurement, wasfirstly determined by the resolution used by the ADC. This resolution was set

13

to the maximum of 12-bits as previously stated, which then resulted in 12 ADC-clock cycles, as each bit needed one clock cycle to process the value. Secondly, theADCs could be configured with a sampling time, which would define how longthe ADC would allow the input capacitor to charge. The lowest sampling timeallowed by the processor was three ADC-clock cycles while the longest samplingtime was 480 ADC-clock cycles. The sample time for one ADC conversion couldthen be calculated using Eq. 3.3

tconversion =tS · NR OF BITS

fADC(3.3)

If the ADCs would be configured for continuous sampling, the conversiontime would equal to the time period for the sample rate. This means the samplerate would be the inverse of the conversion time, as in Eq. 3.4.

fS =1

tconversion(3.4)

By using this relation together with the two previous equations, the maxi-mum and minimum sample rate for a 12-bit ADC, using the ADC-clock can besummarized as in Table 3.1.

Table 3.1: The sampling characteristics for the ADCs

APB2DIVIDER ADCDIVIDER fADC fs

Max. sample rate ∼ ∼ 36 MHz 2.4 MSa/secMin. sample rate 16 8 1.687 MHz 3.43 kSa/sec

Since the minimum sample rate according to Table 3.1 was only 3.43 kSa/sec,the ADCs can not be run in continuous mode and have to be triggered by anexternal source, like a timer, to reach the desired sample rate of 2048 Sa/sec.

Using a timer

The ADC-clock will still be used to define the conversion time for a single sample,since it is needed for the ADCs to work. Furthermore, since the lowest conversiontime for a single sample still is faster than the desired conversion time, the ADC-clock will be configured according to the minimum sample rate in Table 3.1.

Triggering of the ADCs will be done by configuring a timer to run and gener-ate an interrupt with the desired frequency. The interrupt will then be forwardedto the ADCs, by configuring these to use an external event as trigger.

To configure the timer to work with an interrupt and the ADCs, only a fewthings needed to be done. Firstly, a timer that can be used to trigger the ADCsthrough the hardware, has to be used. Secondly, this timer has to be configuredwith a period that generates an interrupt with the desired frequency.

14

According to the reference manual for the STM32F767ZI, TIM2TRGO can beused to trigger the ADCs. Furthermore, TIM2 which this refers to, has a 32-bitauto-reload counter which can be used to set the period without further scalingto the clock of the timer. Since this counter can support numbers of size equal tothe system clock itself, the Eq. 3.5 shows how the period can be calculated.

Period =TIM2 CLK

DESIRED CLOCK SPEED(3.5)

Apart from setting the period and the counter mode to up, the only remainingthing to do was to configure the timer to generate a trigger signal when the periodhas been reached. Figure 3.1 shows the code used to configure the timer.

Figure 3.1: Sample code showing the configuration of the timer.

According to the figure, the period depends on a variable called SystemCore-Clock, which is set during the configuration of clocks used by the device. In thiscase the SystemCoreClock will be configured for the highest speed of the device,216 MHz. The TIM2-module is connected to the APB1 bus, which in this case hasa clock frequency of half the SystemCoreClock. The calculation for the timer periodthen matches that of Eq. 3.5.

3.2.2 Dual-mode

To measure the two separate input signals simultaneously, two separate ADCswill be used. Furthermore, these two ADCs must be configured to measure theirinput at the same time. This is done by configuring the ADCs in dual-mode,which is one of the available multi-mode configurations. The dual-mode shouldfurther be configured to use the regular simultaneous conversion, in order toachieve the desired configuration.

This dual-mode is essentially configuring the ADCs to work in a master-slaveconfiguration, with ADC1 as master while ADC2 is slave. This also means thatthe master will automatically trigger the slave, when a conversion is initiated.

15

When a conversion is done, the two 12-bit values, one from each ADC, whichare stored in a 16-bit vector (half-word) gets put together into a 32-bit vector. The32-bit vector contains the ADC1 value in the lower 16-bits, while the ADC2 valueis stored in the upper 16-bits. The resulting 32-bit vector can be read out from theconversion register connected to the master, ADC1.

3.2.3 Configure the DMA

As previously mentioned, one of the DMA-modules was used to offload the pro-cessor of the device. This would allow the processor to work without interruptionfor each conversion made by the ADCs. However, the DMA was configured tointerrupt the processor after a specified amount of conversions had been done,which then allowed the processor to grab this data as a block.

According to the reference manual, only the DMA2-module was connected tothe ADCs. Furthermore, out of the eight streams that the DMA2-module had,only the lower five had an actual channel to any of the ADCs. Since the twoADCs used were configured in dual-mode, only the master needed to be con-nected to the DMA. This resulted in the use of stream zero on DMA2, since thiswas connected to ADC1.

The DMA-buffer

Apart from configuring the DMA2-module to work with the ADCs, the interfacetowards the processor also had to be configured. This was done by defining aglobal memory space as a buffer, that the DMA could fill with data. The DMAwas then configured to generate an interrupt for each half of the buffer. That is,an interrupt would be generated when the buffer was half full, and another inter-rupt would be generated when the buffer had been completely filled. In order torepeat this process each time the buffer has been filled, the DMA is configured totreat the provided buffer as circular. This option will force the DMA to start fromthe beginning of the buffer when it has reached the end.

3.2.4 Verification

To get the desired sampling rate for the data acquisition part of the algorithm,three peripherals has been linked together. The two ADCs that makes the mea-surement of the input signals are triggered by the timer TIM2, which has beenconfigured for a frequency of 2048 Hz. When a conversion has been performedby the ADCs, the DMA2-module transfers this data into a global buffer withoutinterference of the processor. The DMA2-module also generates two interruptsto alert the processor that a new chunk of data is available for processing.

To verify the functionality of the ADC, two measurements were done. Thefirst one, estimates the actual trigger frequency generated by the timer, whilethe second one estimates the interrupt frequency of the DMA2-module. For thesecond measurement, the size of the global buffer has been set to two times thesampling frequency of 2048 Hz. This would in theory generate an interrupt ev-

16

ery second because of the relation to the sample rate. Table 3.2 summarizes themeasurements compared to theory.

Table 3.2: ADC sampling and trigger frequencies

tINTERVAL f

TimerCalculated 488.28 µs 2048 HzMeasured 488.3 µs 2047.9 Hz

DMACalculated 1 s 1 HzMeasured ∼ 1 s ∼ 1 Hz

17

4Processing

4.1 Concept

As previously mentioned, the processing part of the project, refers to two majoroperations. First, the last part of the demodulation of the signal has to be donewith the use of arc-tangent calculation, in order to extract the phase from thephase-shifted signal. Secondly, the frequency spectrum of the phase has to be cal-culated in order to determine which frequencies the phase consists of. When thishas been done, a simple magnitude calculation to find the peaks of the frequencyspectrum will remain before the signal can be plotted for the end-user.

The majority of these two operations has been implemented using the DSP-functions provided by the CMSIS library from ARM [10].

4.2 The frequency spectrum

The CMSIS library contains an example implementation of how to calculate thefrequency spectrum using their predefined transform, magnitude and peak-detectionfunctions. This example was used as a start point in the FFT implementation.

Table 4.1 contains the few requirements stated before starting the implementa-tion of the FFT.

Table 4.1: Considered requirements for the FFT-implementation

Description Requirement

Number of points 1024 (minimum)Frequency resolution [Hz] 0.1 Hz

Peak detection At least 1 ideally several

18

4.2.1 FFT

The CMSIS library function for the FFT, supports lengths from 16, 32, 64 etc upto a maximum of 4096 points. This made the first requirement fairly simple toreach. The library also provides predefined constants to setup the correct FFT-configuration. Furthermore, the library function operates on complex data andalso returns complex data.

Figure 4.1 shows the initial FFT-implementation. The arm cfft f32-call is the callto the CMSIS-library function for calculating the FFT-spectrum. The first input-argument to this function defines the setup for the FFT, as can be seen in thefigure. The second argument is the data that should be transformed into thefrequency domain, while the two last arguments defines how the function shouldexpect this data.

Figure 4.1: Sample code showing the FFT-implementation.

To get the correct spectrum in a human readable format, the complex magni-tude also had to be calculated in order to convert the complex output vector fromthe FFT into real values. This is done through the function call to arm cmplx mag f32,which also only returns a vector of half the size of the input.

Frequency resolution

In order to present a valid spectrum for the incoming signals, the scaling hadto be correct. As previously mentioned, the expected signals had a very lowfrequency (less than 10 Hz) which made it reasonable to only show a spectrum inthat region.

The previously stated requirement for a frequency resolution of 0.1 Hz, thenimplies that each bin of the FFT-result contains an increase of 0.1 Hz frequency.In order to reach this, the sample-rate needs to be adjusted with regards to thelength of the FFT. Eq. 4.1 shows the simple relation between sampling frequencyand FFT length [11][12].

FFT resolution =Fs

N, where N = FFT SIZE (4.1)

This suggests that the sample rate needs to be one tenth of the length of the FFTto reach the required resolution. As mentioned earlier, the sampling goal for the

19

ADC:s were set to 2048 samples per second which made it reasonable to increasethe length of the FFT to 2048. This would by default then mean that the FFT-resolution would be 1 Hz and also easier to reduce with decimation of the inputsamples after the filtering has been done.

Testing the FFT

To verify that the FFT worked as expected, a reference signal was created in MAT-LAB and then written to a header-file that could be compiled with the C-code.The signal generated was a super-position of the four frequencies 10 Hz, 40 Hz,50 Hz and 500 Hz. The equation used to calculate the signal is seen in Eq. 4.2.The vector generated from this signal contained 2048 real samples, equal to thelenght of the FFT, and 2048 imaginary values simply set to zero.

superPosSign = 0.5(sin(a f0) + ... + sin(a f3)), where a = 2πt (4.2)

To verify the output spectrum from the DSP, the same signal was also plottedusing only MATLAB in order to get a reference spectrum. Figure 4.2 shows thereference spectrum from MATLAB. Here you can see a total of four peaks at thecorrect frequencies, and nothing else.

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.1

0.2

0.3

0.4

0.5

0.6FFT Spectrum (only FFT)

X: 500

Y: 0.5

X: 50

Y: 0.5

X: 40

Y: 0.5

X: 10

Y: 0.5

Figure 4.2: Reference spectrum calculated in MATLAB of the super-position signal.

In comparison the calculated spectrum using the DSP can be seen in Figure4.3. Comparing the two plots lead to the conclusion of the FFT-functionality inthe DSP was working as expected.

20

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.1

0.2

0.3

0.4

0.5

0.6FFT spectrum (DSP)

X: 500

Y: 0.5

X: 50

Y: 0.5

X: 40

Y: 0.5

X: 10

Y: 0.5

Figure 4.3: Spectrum calculated using the DSP-FFT functions from ARM.

4.2.2 Peak detection

From a user perspective, the full frequency spectrum is not interesting more thanfor debugging purposes. The user wants fast and accurate information about theheartbeat and respiration rate, and therefore there is a need of peak detectionfrom this spectrum.

In Figure 4.1, the last function call to arm max f32 calculates the highest peakin the signal. However, there is at least two peaks that needs to be found. Fig-ure 4.4 shows the code used to find multiple peaks in the spectrum. The num-ber of peaks to find is specified at compile time of the code, through the macroNR OF PEAKS.

Figure 4.4: Sample code showing the calculation of peaks in the output spectrum.

21

4.3 Demodulation with arc-tangent

Before the frequency spectrum of the input signal can be calculated, the last partof the demodulation has to be done, by extracting the phase from the incom-ing signal. This was done by using the trigonometric function arc-tangent. TheCMSIS-library however, did not contain this function and therefore it had to beimplemented.

This was done by implementing the fourth order Taylor series expansion ofarc-tangent that can be seen in Eq. 4.3 [13]. However this series is only validfor t ≤ 1 because above this it will start to diverge. Also the accuracy for thisexpansion at t = 1 is limited.

arctan(t) = t − t3

3+

t5

5− t7

7+

t9

9(4.3)

Figure 4.5 shows the accuracy issue at t = 1 for three different orders of the Tay-lor expansions. The comparison was made towards the MATLAB implementedatan2.

t

0 0.2 0.4 0.6 0.8 1 1.2

ph

i [r

ad

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Comparing atan2 to Taylor expansion

atan2

Taylor O(2)

Taylor O(3)

Taylor O(4)

Figure 4.5: Comparing the MATLAB atan2 to three different orders of Taylor expansions forarctan.

The error for each of the orders can be seen in Figure 4.6 which is a zoomed inversion of the previous figure. It is obvious here that increasing order of the Tay-lor expansion gives a smaller error, which corresponds to the series being infinitefor a correct result. However, an infinite series is not practical in the program-ming world and therefore the fourth order was used.

22

t

0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 1.05 1.1

ph

i [r

ad

]

0.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1Comparing atan2 to Taylor expansion [zoomed]

atan2

Taylor O(2)

Taylor O(3)

Taylor O(4)

X: 1

Y: 0.8667

X: 1

Y: 0.8349

X: 1

Y: 0.7854

X: 1

Y: 0.7238

Figure 4.6: Showing the error at t = 1 compared to the atan2.

The Eq. 4.3 was not practical to implement into the code in its current form,therefore it was re-written into Eq. 4.4.

arctan(t) = t(1 − t2(1

3− t2(

1

5− t2(

1

7− t2

9)))) (4.4)

As can be seen this equation now only has a t2-term instead of a t7-term. Thismade it possible to calculate t2 one time and then simply iterate it for each bracket.Furthermore, the negative sign can be applied when calculating the t2-term, mak-ing the code only contain addition [14].

4.3.1 Adjusting the error

Eq. 4.4 contains a total of five constants that can be pre-calculated in order to getrid of their respective division. Also, if Figure 4.5 is studied, the error only startsto occur closer to t = 1 for all the different orders of the Taylor expansion. Thisindicates that the smaller constants could be adjust to reduce the error at t = 1.Table 4.2 contains these new modified constants.

Table 4.2: Modified constants for arctan approximation

Order Value Approximation

1 1 1.000 (1/1)2 1/3 0.33316 (1/3)3 1/5 0.19048 (4/21)4 1/7 0.09916 (12/121)5 1/9 0.02723 (7/257)

As can be seen, the first two constants are basically the same as before, whilethe three following constants has been adjusted. The result of this adjustment canbe seen in Figure 4.7.

23

t

0 0.2 0.4 0.6 0.8 1 1.2

phi [r

ad]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Comparison of atan2 to Taylor expansion and Taylor approximation

atan2

TaylorApprox

Taylor O(4)

Figure 4.7: Comparing the adjusted Taylor expansion to the old one and to atan2.

As can be seen in the figure there is no noticeable error compared to atan2with the modified constants. And compared to the standard constants for theTaylor expansion, there is a rather large improvement.

Implementing in code

When implementing Eq. 4.4 into code, an iteration from the inner most bracketand out was made. Figure 4.8 show the equation written in C-code, starting byadding the inner most constant to the output angle phi.

Figure 4.8: The implemented code for arctan approximation in the first octant.

Notice that this code expects two inputs, x and y, in order to first calculate t.After that, t2 can be calculated and the iteration can start in an un-rolled loop byadding the first constant.

24

4.3.2 Rotating into first octant

As previously mentioned the Taylor expansion in Eq. 4.4 was only valid for t ≤ 1.In the unit circle, this is only true in the first octant where x ≥ y. However, theinput values could be anywhere on the circle, and therefore some rotation of thecoordinates was needed.

Figure 4.9 displays a unit circle cut into the four quadrants with the first quad-rant divided into two octants.

π2

y

π

3π2

0x

π4

Figure 4.9: The unit circle divided into four quadrants.

The coordinate rotation applied uses a maximum of three rotations to moveany coordinate into the first octant. It is implemented by simple if-statementsthat check which of x and y is greatest and rotate according to that. The threestatements check whether the coordinate is in quadrant three or four, quadranttwo or if the coordinate is in octant two. Table 4.3 show the rotation performedfor each of these three statements.

Table 4.3: Rotation of coordinates in the unit circle

Coordinate position Condition Rotation

3 or 4 [Quadrant] y < 0 180 ◦

2 [Quadrant] x ≤ 0 90 ◦

2 [Octant] x ≤ y 45 ◦

These three statements were applied into the C-code in a separate functioncalled octantify, which can be seen in Figure 4.10. The resulting number of octantsthat the coordinate has been rotated with is returned in the parameter octant.

25

Figure 4.10: The implemented code to rotate any coordinate into the first octant.

During the last rotation in the first quadrant, that is from octant two into oc-tant one, there is a scaling that gets added to the coordinates during the rotation.

The scaling factor is 1/√

2, however this scaling is added to both x and y and willbe eliminated during the calculation of t, in the first steps of arctan-calculation.

4.3.3 The Taylor approximation in code

The full Taylor approximation of arc-tangent, implemented in the C-code can beseen in Figure 4.11. The function starts with a simple test to see whether we havea simple case that does not need any calculation.

26

Figure 4.11: The implemented code for approximation arctan with Taylor expansion.

After rotation the coordinate, the actual rotation angle is saved in radians inthe variable angleShift and later added to the calculated angle before the functionreturns.

Also notice the last if-statement of the code, which checks if the angle is largerthan π. This is due to the arc-tangent function by definition is defined for [−π,π], and a larger angle than this simply would introduce a DC-offset in the result.

27

4.3.4 The frequency spectrum with a phase-shifted signal

The fully implemented arc-tangent was tested in a similar way to the previouslymentioned FFT. Furthermore the frequency spectrum was calculated with theDPS-implemented FFT before plotting in MATLAB. As a reference, the corre-sponding spectrum were calculated in MATLAB, both by using atan2 and theapproximated Taylor expansion.

As for input signal to the DSP, a phase-shifted signal containing the previouslyused super-position signal, was created in MATLAB and transferred in a header-file to the DSP. The base signal was generated in MATLAB using Eq. 4.5 with theinput from Eq. 4.2, and then transformed into a complex I- and Q-signal usingthe Hilbert-transform function [15].

phaseShi f tSignal = sin(superPosSign) (4.5)

The reference output spectrum created in MATLAB can be seen in Figure 4.12,were four distinct peaks can be seen. These also corresponds to the four inputfrequencies in the super-position signal.

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.2

0.4

0.6

0.8

1

1.2FFT Spectrum (atan2)

X: 500

Y: 0.8543

X: 50

Y: 1.028

X: 40

Y: 0.9189X: 10

Y: 0.8807

Figure 4.12: The reference frequency spectrum for the phase-shifted signal.

The corresponding frequency spectrum generated in MATLAB but for theTaylor expansion can be seen in Figure 4.13. This spectrum also has the four fre-quencies in distinct peaks, as the reference.

28

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.2

0.4

0.6

0.8

1

1.2FFT Spectrum (TaylorApprox)

X: 500

Y: 0.8543

X: 50

Y: 1.028

X: 40

Y: 0.9189X: 10

Y: 0.8807

Figure 4.13: The frequency spectrum for the phase-shifted signal, calculated with the Taylorapproximation in MATLAB.

Finally Figure 4.14 shows the frequency spectrum calculated on the DSP usingthe Taylor series expansion approximation for arc-tangent calculation.

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.2

0.4

0.6

0.8

1

1.2FFT spectrum (DSP)

X: 500

Y: 0.8543

X: 50

Y: 1.028

X: 40

Y: 0.9189X: 10

Y: 0.8807

Figure 4.14: The frequency spectrum for the phase-shifted signal, calculated on the DSP.

As for the frequency spectrum for the super-position signal, this spectrum isidentical to the reference spectrum. The spectrum shows all the peaks in correctposition, but compared to only the super position signal, all these spectrum’shave an increase in amplitude of each peak, which should be centered at 0.5 V.

29

5Pre-processing

5.1 Concept

Before the data is processed by the arc-tangent demodulation and the FFT calcu-lation, potential unwanted components in the signal should be removed. Thisis done by filtering the signal through a digital filter. Furthermore, since thesampling rate of 2048 samples per second is quite high, the signal can be down-sampled by the use of decimation. But since the FFT-module required a certainamount of samples before a valid result could be generated, this decimated datahad to be stored in wait for further processing.

This chapter describes the steps performed to prepare the data for processingin the FFT-module. This includes the description of storing data between steps,and the generation of the sliding window effect.

5.2 Filtering

As previously mentioned, the heartbeat and respiration rate are very low fre-quency signals, typically less than 5 Hz. This leads to the conclusion, that a low-pass filter should be used in order to remove higher frequency components thatmight affect the resulting frequency spectrum.

The CMSIS-library offered several type of base filters, however two of thesewas of particular interest, namely Finite Impulse Response (FIR) and Infinite Im-pulse Response (IIR). In general IIR-filters are more efficient and requires lessmemory, compared to FIR-filters, when used in DSP applications. This is dueto FIR-filters having a frequency resolution similar to the FFT, but also becauseIIR-filters can be implemented in a recursive manner. In this particular applica-tion, the FIR-filter would have required a very long coefficients vector in order toachieve a good resolution at lower frequencies. Therefore, the filter implementedwas decided to be of IIR-type with Butterworth coefficients to achieve a frequencyresponse close to a box.

30

5.2.1 Generating coefficients

In order to implement a Butterworth filter, using the CMSIS-library, a Biquad Cas-cade Direct Form II-transposed structure was used with coefficients generated inMATLAB. These coefficients were then written to a separate header-file and in-cluded in the C-code implementation.

According to the CMSIS documentation of the Biquad Cascade Direct Form II-transposed structure, the Eq. 5.1 is applied for each stage of the filter [16].

y[n] = b0x[n] + d1

d1 = b1x[n]− a1y[n] + d2

d2 = b2x[n]− a2y[n]

(5.1)

And, as can be seen, each stage can as maximum represent a second order filter, soin order to achieve a filter of higher order, several stages are necessary. This givesa1..a2 and b0..b2 as the coefficients that needs to be generated for a Butterworthfilter of second order. Furthermore, according to Eq. 5.1 the a1 and a2 coefficientsneeds to be negated in order to give a correct result.

In MATLAB a filter of third order was generated using the function butter().This resulted in a total of ten coefficients as can be seen in Table 5.1, and also thatthe filter then consists of two stages with one of the stages having a d2 = 0.

Table 5.1: Butterworth coefficients for the filter

Coefficient Value

a11 0.8706641a12 0.0a21 1.8534351a22 −0.8712398b10 0.0002878b11 0.0002878b12 0.0b20 1.0b21 2.0000105b22 1.0000105

The filter was designed for a cut-off frequency of 45 Hz, to remove high fre-quency components but could possibly be set at an even lower cut-off frequencyif necessary.

Figure 5.1 shows the frequency response of the generated filter in MATLAB.As can be seen from the marker, the cut-off frequency is at 45 Hz.

31

Frequency (Hz)

10 0 10 1 10 2 10 3

Re

so

po

nse

(d

B)

-300

-250

-200

-150

-100

-50

0

Frequency response for Butterworth order 3

X: 45

Y: -3.01

Figure 5.1: Frequency response of the implemented Butterworth filter.

5.2.2 Implementing the filter

In the C-code, the implementation of the filter was similar to the implementationof the FFT. The CMSIS library offered a function to filter the data as can be seenin Figure 5.2 as the call to arm biquad cascade df2T f32-function.

Figure 5.2: The implemented filter in C-code.

The first argument of this function, the parameter butterworth f32, defines thestructure of the filter. In the init-call, this structure is initialized to use, the numberof stages specified in the macro N STAGES, the filter coefficients provided andalso a state buffer to record the state d1 and d2 from Eq. 5.1. The filter coefficientswas provided in a linear buffer as shown in Table 5.2 and would follow the samepattern for any higher order filter.

Table 5.2: Butterworth coefficients sorted into a linear buffer

Index 0 1 2 3 4 5 6 7 8 9Coefficient b10 b11 b12 a11 a12 b20 b21 b22 a21 a22

Testing the filter

To test the implementation, the super position signal generated (Eq. 4.2) for theFFT test was used. Furthermore, the filtered signal was returned both as a time

32

domain signal and as a frequency spectrum, using the FFT implementation. Fig-ure 5.3 shows the original time domain signal, that is the super position signalfrom Eq. 4.2.

Time (t)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Vo

lta

ge

(t)

-2

-1.5

-1

-0.5

0

0.5

1

1.5

2Super position signal

Figure 5.3: The super position signal in the time domain.

As previously has been said, the super position signal contained a total offour frequencies, where one of these frequencies was significantly higher thanthe other ones. By testing the filter design in MATLAB, the filtered reference inFigure 5.4 was obtained. As can be seen, the high frequency component of thesignal has been removed.

Time (t)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Vo

lta

ge

(t)

-0.6

-0.4

-0.2

0

0.2

0.4

0.6Super position signal filtered

Figure 5.4: The filtered result of the super position signal, in the time domain.

The result from the DSP-implemented filter in Figure 5.5, showed that the im-plementation was working correctly.

33

Time (t)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Vo

lta

ge

(V

)

-0.6

-0.4

-0.2

0

0.2

0.4

0.6Filtered signal (DSP)

Figure 5.5: The filtered result from the DSP, in the time domain.

This result was also further validated by looking at the output frequency spec-trum from the DSP, in Figure 5.6. Where the high frequency peak at 500 Hz hasbeen removed from the signal, and the 50 Hz peak has been weakened.

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4FFT spectrum (DSP)

X: 50

Y: 0.3459

X: 40

Y: 0.3501

X: 10

Y: 0.3531

Figure 5.6: The filtered frequency spectrum from the DSP.

It can be noted in the spectrum that the amplitudes of the peaks has beenreduced by the filter compared to the non-filtered peaks seen under the Process-ing-chapter for the super position signal. This was however not considered aproblem during the development of the filter.

34

5.3 Decimation

By using decimation to reduce the effective sample rate of the input signal, sev-eral benefits can be found. The major benefit is that, it will reduce the amount ofmemory space needed during the remainder of the program. Another benefit isthat, by decimating after the filtering has been applied, there is no longer any riskof having a higher frequency component play a role in the decimated result, sincethese have been removed by filtering. And for this particular usage, decimationwill effectively increase the resolution of the FFT because of the relationship be-tween sampling rate and FFT size, described under the Processing-chapter.

The negative aspects of decimation in this case, is that there will be a delaybefore the actual processing can start, since the FFT needs a certain amount ofsamples to give a correct result.

5.3.1 Implementation

The decimation in this case, means that only a fraction of the input data willactually be saved for later processing. This fraction was calculated by Eq. 5.2 andcan be described in words as, only every value that appears on a slot that is amultiple to the DECIMATION FACTOR, will be saved.

n =length(indata)

DECIMATION FACTOR(5.2)

In code, this was implemented as a for-loop that only visited and saved themultiples of DECIMATION FACTOR, as can be seen in Figure 5.7.

Figure 5.7: Sample code for the decimation of data.

The resulting vector, data, would then contain a number of valid items equal tothe value of index. Note that the variable decFactor is equal to DECIMATION FACTOR.

35

5.4 Sliding window effect

As mentioned during the Processing-chapter, the FFT has a specified length, whichcorresponds to the amount of samples needed in order to produce a correct result.But in order to receive a higher frequency resolution, decimation was used toreduce the sampling speed further. These two factors would then introduce adelay between each new frequency spectrum, which in turn could result in anon-smooth transition. The delay would depend on the decimation used, andthe transition between each spectrum would depend on sudden changes in themeasurements (the vital signs of a patient). This constant delay was consideredto be non-viable and also violated the desirable update frequency of the spectrumevery 0.5 second.

To solve this problem, an effect of a sliding window was considered. Thesliding window would always contain the latest data but also the next latest dataand so on, until the window contained enough samples to do the FFT. Each timenew data was available, the sliding window would be updated with this data,while the oldest data would be removed. This method would remove the staticdelay between each update of the spectrum, but would instead need a start uptime, depending on the decimation used.

5.5 Data buffers

The program utilizes several buffers to store data between the different process-ing steps that was required before a frequency spectrum had been reached. Thesliding window described previously was implemented using a structure basedon a ring buffer and this buffer acts as the main storage between the pre-processingand processing steps. Furthermore, there is the ADC-buffer which contains thedata from the two ADCs and is emptied on a regular basis in order to get newdata. A few more buffers are used to store data before it is filtered and decimatedand also to store the result containing the frequency spectrum that has been cal-culated.

5.5.1 The ADC-buffer

The first major buffer in the system, was the ADC-buffer. This buffer is continu-ously filled with measurement data from the ADCs, while the main-loop of theprogram does other computing. The DMA, that is aligning the data from theADCs into this buffer, generates an interrupt whenever one half of the buffer hasbeen filled. This means that for each rotation in this buffer, the DMA will generatetwo interrupts.

The size of this buffer was equal to the length of the FFT, which means that itcontained 2048 elements. However, since the samples collected, came from twoADCs packed into a 32-bit element, the actual amount of samples contained inthe buffer would be twice the length of the FFT. This also meant that for eachhalf buffer interrupt, the amount of actual samples would be 2048 or 1024 pairs,

36

as they should be considered as complex numbers because of the quadrature de-modulation in the multi-port. Figure 5.8 shows the flow of data from the twoADCs into this buffer.

Figure 5.8: Illustration of the data flow into the ADC-buffer.

As can be seen in the figure, the DMA will generate an interrupt every 0.5second, which means that each half of this buffer is valid for that amount of time.During this time, the valid data needs to be copied into the main program-loopfor further processing.

5.5.2 The ring buffer

The sliding window effect that has been used in the program was implementedusing a ring buffer that during normal operation, always should be filled withdata. The ring buffer contains the same amount of data needed to do the FFT,and is updated with new data directly after filtering and decimation. This meansthat the amount of incoming data will determine when the buffer is first full, andtherefor also when FFT-processing can take place.

The ring buffer is essentially a linear buffer in a structure, allowing the pro-gram to keep track of the head and the tail of the ring buffer. Furthermore, somespecial functions are associated with this structure in order to ”roll-over” whenthe end of the linear buffer has been reached. This is necessary in order to startfrom the beginning of the linear buffer when it has been filled once. Figure 5.9shows an illustration of how a linear buffer is used as a ring buffer.

37

Figure 5.9: A linear buffer in a ring buffer configuration.

As can be deduced from the figure, the Tail is the index of the last slot in thearray, while Head is the index of the first slot. The Head index is the latest receiveddata, since the ring buffer is working in a FIFO-manner, which also means thatdata will be fed into the FFT from Tail to Head.

5.5.3 Other buffers

Apart from the two buffers previously described, there are a few more for tempo-rary storage. The first one is the temporary storage, named inData, between theADC-buffer and the ring buffer. When data from one half of the ADC-buffer ismoved into the main program, it is first copied into a this buffer. During the copy,the ADC-values who is stored as a single 32-bit unsigned integer, gets separatedand converted into two 32-bit floating point values, that represents the complex I-and Q-data. When the copy is done, the data is filtered and reduced through dec-imation and again stored into the buffer inData. This data is then de-modulatedusing the arc-tangent function and stored as new samples in the ring buffer.

Since the FFT-algorithm in the CMSIS-library does not support buffers that isnot a linear buffer, the data that is going to be processed in the FFT, first needsto be copied into a linear buffer. This temporary buffer, called fftInData, containsthe data from the ring buffer between the Tail and Head and is sent into the FFT-algorithm. After the FFT is done, the double sided frequency spectrum is thenavailable in this buffer.

38

6Communication link

6.1 Concept

As mentioned during the hardware chapter, the platform included an ethernetport to connect and communicate with other network devices. As the work withthe communication link started, the intention was to use this port to connect tonetworks and send data this way. However, time and complications stopped thedevelopment of this, which resulted in the use of the USB debugging port thatwas already mostly configured for the device. This communication which usesthe UART-protocol, was speed up in order to send the required amount of datawithin the time limit.

6.2 UART-communication

The debugging connection to the Nucleo board uses a USB-serial interface thatis further connected to the DSP using one of the available UART-modules. Thismakes it possible to send data, from the running application, through the UART-module to another serial connected device. This can be used to monitor outputof the program, if a computer would be connected to the board using a serialconsole.

Per standard the firmware provided by ST, has implemented a re-targetingof several standard C library functions, such as fputc and fgetc. These functionsnormally output or receives character to a command line interface, but in there-targeting these functions has been replaced, to instead output characters to theUART-interface. This allows the software developer to print debugging messagesusing the C-function printf. It also allows the developer to provide his own im-plementation of fputc, so that it sends packets of data instead of single characters.

The reason for creating packets that should be sent instead of single charac-ters, was to be able to send larger amounts of data, as bytes, in a shorter amountof time. The re-targeted function provided by ST, sent characters as the origi-

39

nal fputc function did. This would not be a problem if the data to send wheremostly characters. However, most of the data produced by the algorithm wereeither floating point numbers or integers, that was represented in memory usingat most four bytes. Sending this data through an fputc-like function, would firstconvert the actual value represented in these four bytes, to a string of chars thatthen would be printed to the serial console. As soon as the converted value wouldexceed four characters, the function would then instead start to create more datathan actually existed. To illustrate this issue, consider the following three exam-ples, represented in the Eq. 6.1.

n = 10, represented on 4 bytes

f putc(n) => 10, which is 2 chars

n = 1.03, represented on 4 bytes

f putc(n) => 1.03, which is 4 chars

n = 10000, represented on 4 bytes

f putc(n) => 10000, which is 5 chars

(6.1)

The first example, would allow the fputc-function to spare two bytes since thevalue of n can be represented using two characters. However, the following twoexamples shows the fputc-function, creating more data to print the values of n, inorder to produce an output that corresponds to a string.

For the implementation used with the algorithm described in this report, thispotential extra data put on the communication link was considered a waste oftime and resources, that should be better put to use in the algorithm itself.

6.2.1 Communication protocol

To only send the amount of data that actually existed, a function was developedthat sent the data as bytes from memory. This function was initially created withtwo considerations in mind. Firstly, it should be able to send any kind of dataas it is stored in memory, and secondly it should be able to send any amount ofdata that was presented to it. These two considerations lead to problems whenlooking from the receiving end. The receiving function, in this case on a com-puter, would receive a stream of bytes of unknown length. What these bytesrepresented would also be unknown to the receiving function unless some sortof protocol was established. This lead to the communication protocol describedin Table 6.1, which determined how data should be packed into pre-defined bytestreams.

40

Table 6.1: Requirements on the communication protocol

Description Requirement

DatainfoKind of data AnyAmount of data Any

Header infoData type 1-2 bytesPacket nr 2 bytesPayload size 2 bytes

Packet infoHeader size 6 bytesPayload size 256 bytesTotal size 262 bytes

The lower part of the table describes packages that defines the byte stream.This means that any kind of data that will be sent should be divided and sentas 262 bytes long packets. These packets contains a header and a payload asdescribed in Figure 6.1, where the actual data is put into the payload part of thepacket.

Figure 6.1: Illustration of the packet structure sent between devices.

As can be seen, each packet creates an extra six bytes of data that describeswhat kind of data and how much is sent to the receiving device. This allows thereceiving device to decipher the byte stream into the actual data sent, as the datatype is described in the first byte of the header. Furthermore, the packet number,described in byte three and four, indicates which packet was received in orderto keep track of potentially missed packets. Finally the size of the payload, de-scribed in byte five and six, contains the total size of all the payloads that matches

41

the current transmission, which then allows the receiving device to know whenall data has been received.

Working example

The frequency spectrum calculated by the FFT-module, produces a data vector of1024 elements. Each of these elements was a 32-bit floating point number, whichsums up the total length of the data vector to 4096 bytes in memory. Sendingthese bytes using the communication protocol described above, equals to a totalof 16 packets, where each packet then generates an extra six bytes as over head.The total length of the data sent, will then equal 4192 bytes with a total overheadof 96 bytes. If there was no errors during the communication stream, the resultingdata on the receiving end will be equal to the data sent, as all the bytes (and bits)are the same.

If these floating point values, instead was sent using the fputc-function, thedecimal precision had to be specified for each value. If a precision that includedmore than three decimal digits as 1.234 would be used, each floating point valuesent would equal to five bytes. This results in a total of 5120 bytes needed in orderto send the entire vector of 1024 elements. Furthermore, the data received wouldbe altered from the original data, since a decimal precision had been specified tothe fputc-function.

42

6.3 Implementation

The function that was developed to replace the fputc-functionality, was nameduartSend. The goal of this function was to transfer the data presented to it. Inorder to do this, the function needed to know the data type of the data to be sent,the actual data vector and the size of this data vector. The function will then splitthe data vector over the needed amount of packets, and format these packets withthe correct data type, packet number and part of data to be sent.

The function was built around a nested loop functionality, such that the outerloop formatted and sent the header part of each packet, while the inner loop sentthe 256 byte of the data vector. Figure 6.2 contains the skeleton used to imple-ment the function. This skeleton was complemented by a simple if-statement tocalculate the amount of packets the data would reassemble and that had to besent.

Figure 6.2: Skeleton for the uartSend-function.

Figure 6.3 shows the if-statement used to calculate how many packets wouldbe needed, in order to send the data.

43

Figure 6.3: The if-statement to determine the amount of packets to send.

The nested if-statement was used to take care of potential rest that could havebeen lost by the division. The if-statement also made sure that there was nothingsent, if there was no size of data attached.

6.3.1 Types

As previously mentioned, the header of each packet contained a byte definingthe type of data, that the packet contained. This types were defined as ASCIIcharacters and can be seen in Table 6.2.

Table 6.2: Types of messages sent through the UART-communication

Description Requirement

A Debugging messages, data vector in ASCIIB Spectrum, data vector in floatsC Peak data, data vector in floats

44

7Graphical User Interface

7.1 Concept

In order to present the result from the DSP to the user, a simple graphical userinterface (GUI) was implemented in MATLAB. This interface provided a plot to-gether with the option to show data tips on the peaks in the plot. Furthermore,the interface added options to connect to the serial device, plot the result andchoose an appropriate decimation to get a correct frequency axis of the plot.

7.2 MATLAB

MATLAB provides several ways to create a GUI from nothing. One of these wayswas to programmatically build a GUI by using a figure. This was done by simplycreating a figure, which is normally used to plot data, and then change some ofthe parameters of this figure.

The idea of using MATLAB to implement the GUI, was based on the possi-bility to easily create cross-platform programs, that could run inside MATLABwithout any significant changes. Also, since MATLAB had been used through-out the majority of this project, several of the already existing scripts could beused to speed up the development process.

7.2.1 Describing the GUI

Since the purpose of the GUI was to ease debugging as well as provide feedbackabout the measured frequencies, one of the major elements had to be a plot. Thisplot would then show the frequency spectrum generated by the DSP, and eachpeak could then be marked to determine the value measured. Furthermore, theGUI should have the possibility to indicate whether it was connected to the seriallink, or not. This together with the possibility of manually connecting the GUI tothe serial link, could be implemented with a button.

45

Figure 7.1 shows an early drawing of how the GUI would look like. This draw-ing contained two buttons, a plot with two axis and a possibility to provide in-formation about the expected scaling of the incoming data.

Figure 7.1: The first computerized sketch of the GUI.

The second button Plot, would allow the user to indicate whether the GUIshould plot or not, which could be useful when debugging, as this would freezethe current plot when it was not used. Also, the first button Serial connect, couldbe used in a similar way to allow the GUI to disconnect from the serial link.

7.2.2 Implementation

As previously described, the GUI could be programmed by using a figure inMATLAB. The figure was setup as described in the sample code of Figure 7.2.

Figure 7.2: Setting up the figure.

46

This setup would first get the handle to the figure 10, and then turn the visi-bility of this figure off. Then a name for the figure was specified together with theposition that the figure would first show up too on screen. Finally, the tool barsthat are normally part of the figure, was turned off and the visibility of the figurewas toggled to on.

This sample code generated an empty window from MATLAB, as can be seenin Figure 7.3.

Figure 7.3: The figure window, generated by the sample code.

This empty figure window was then populated with the elements describedin the early sketch, to generate the target GUI.

Each of the elements added, was also tied to a callback-function for that spe-cific element. As an example, Figure 7.4 shows how the Serial connect-button wasimplemented with the last parameter defining the callback for the element. Thiscallback would then be called each time the button was pressed, which then gavethe possibility to program the functionality of the button.

Figure 7.4: Sample code for initializing the serial connect button in MATLAB.

In the case of the Serial connect-button, this meant the callback-function shouldcheck whether a serial connection was already up or not. If there was no connec-tion, the callback should then initiate such a connection and update the text on

47

the button. However, if such a connection already existed, the callback should in-stead close that connection and update the text on the button accordingly. Figure7.5 shows the callback as it was implemented in MATLAB.

Figure 7.5: Sample code for the callback connected to the serial connect button.

Apart from the elements described in the early sketch, there was also a timeradded in order to update the plot on a regular basis. The update frequency wasset to a 0.5 seconds interval, to match the update frequency of the spectrum fromthe DSP.

48

7.2.3 Finalized GUI

The final GUI-window contained most of the elements described by the sketch,with some modifications. First of, the axis for the plot did not have descriptionsin text by default. This text was set to show only when the GUI was actuallyplotting data. Secondly, the GUI did not use datatips by default, since the addeddatatips in the plot was rather large and could prevent a clear view of the spec-trum. Thirdly the Ref. Data-part of the sketch was removed and replaced by aDecimation-menu instead to be able to scale the frequency axis to the proper reso-lution. With all these changes in mind the final GUI turned out as in Figure 7.6.

Figure 7.6: The final GUI-window with all the elements added.

The text on the two buttons Serial Connect and Plot, changes depending onin which state they are. As for example, pressing the Plot-button will change thetext to Stop plot and also invoke the timer that continuously updates the plot-area.However, if the button is pressed again, the text will return to the previous stateand the timer will be stopped, resulting in no further updates of the plot until thebutton is pressed again.

49

8Test benches

8.1 Concept

During the later part of the project, there was need of testing the modules togetherto verify that they produced a correct result. As mentioned during the previouschapters about the individual modules, such as the filter and the FFT, these weretested separately during their respective implementation, but as they later onwhere tied together with the use of different buffers, the overall output had to bemeasured.

The tests implemented and described here, were mostly created using MAT-LAB and then deployed onto the DSP using C-header files containing data for thesignals used. There were also measurements done on the DSP during run time,to estimate the time used for the modules and also the entire algorithm.

8.2 Signals generated in MATLAB

In MATLAB, a separate function called testbenches.m, were created with the goalof being able to output a test vector of a user specified length. The output wouldbe in a return variable, that could be verified in MATLAB, but also a C-header filethat could be included in the build for the DSP. The signal that had been saved inthis C-header file could then be included with a few lines of code in the DSP build,and then also pass through the algorithm. If the algorithm worked correctly, theoutput should then be a clean spectrum with frequencies of the signal, as peaksin the spectrum.

Two separate phases

All of the signals generated by the function testbenches.m, followed the same pat-tern. They were all phase shifted signals with the frequency information hiddenwithin the phase of the signal that is the output of the function. These signals

50

were also created in a similar fashion to the previous test signal for the arc-tangentdemodulation, described in Eq. 4.5. The difference was instead in the phase ofthis signal where two types of super position signals were used. The first one,was the same as in Eq. 4.2 with the same frequencies as well, to verify that theoutput could still be obtained as it was after the filter implementation. The sec-ond signal contained two frequencies that should be in the range of the vital signsthat the system should try to find, while the two other frequencies were added asnoise higher up in the spectrum.

Signal length versus decimation

Apart from using two different phases for test signals, they also varied in length.This refers to the time base used to generate each of the signals in MATLAB. Aspreviously mentioned, the system used decimation of the sampled input signal,in order to reduce the sampling rate and to get a higher resolution in the resultingfrequency spectrum. This however, then needed a longer time before the amountof samples had been collected that was needed for the FFT to work. Therefore,signals were generated for a user specified length in seconds.

Byte packing the signals

One way that the signals were written to the C-header file, was by packing theminto 32-bit numbers with the imaginary data in the upper 16-bit word, while thein-phase data would be in the lower 16-bit word. Figure 8.1 shows a 32-bit vectordivided into its byte components.

Figure 8.1: A simple illustration of a 32-bit word and its sub-components.

51

A signal saved like this to the C-header file, would take up less space since iteffectively would be half as long as an unpacked signal. This could be an efficientway of saving long signals that span over several seconds. However, this wouldalso require some sort of unpacking in the DSP, when the signal is copied into thealgorithm, and this unpacking might then affect the execution of the algorithmby adding extra code. Furthermore, since the signals are implemented as dou-ble precision floats in MATLAB this reduction to essentially half precision floatsmight also introduce some unreliability to the tests.

Writing the signals as strings

The other way the signals were written to the C-header file, was by simply notmodify the signals at all. The signal would then stay as a double precision floatin MATLAB, and this was also how the signal would be returned in MATLABfor verification. For both the packed signal and the unpacked signal, they werewritten to a file as a string. This means, the file output function fprintf were usedwhere the signals were written to file with the specified amount of digits. In thecase of the packed signals, a large integer number were written to file, while inthe case of floats, a 15-decimal precision were used.

8.2.1 Summary

To summarize the configuration of signals used, Table 8.1 contains the differentmodifications tested for the entire algorithm apart from the ADC.

Table 8.1: Summary of the different configurations for test signals

Test signal f1 f2 f3 f4 tsignal 1 10 Hz 40 Hz 50 Hz 500 Hz 1 ssignal 2 10 Hz 40 Hz 50 Hz 500 Hz 2 ssignal 3 10 Hz 40 Hz 50 Hz 500 Hz 4 ssignal 4 10 Hz 40 Hz 50 Hz 500 Hz 8 ssignal 5 10 Hz 40 Hz 50 Hz 500 Hz 16 s

signal 6 0.26 Hz 1.167 Hz 40 Hz 500 Hz 1 ssignal 7 0.26 Hz 1.167 Hz 40 Hz 500 Hz 2 ssignal 8 0.26 Hz 1.167 Hz 40 Hz 500 Hz 4 ssignal 9 0.26 Hz 1.167 Hz 40 Hz 500 Hz 8 s

signal 10 0.26 Hz 1.167 Hz 40 Hz 500 Hz 16 s

As can be seen in the table, this resulted in 10 different signals, that mostlydiffered in length. The difference in length corresponds to the different decima-tion used during testing and how the decimation would affect the resolution ofthe output spectrum.

52

8.3 Time estimation

Being able to measure the time consumed by the individual modules in the algo-rithm allows for verification of the overall algorithm, as the sum of all the timeconsumed, would tell whether the algorithm can be run fast enough between thesampling periods. This also gives the knowledge to know which module needsthe most optimization in order to reduce the total time.

These measurements were performed using an oscilloscope attached to anI/O-pin, that was toggled on before the module started to operate and toggled offright after the module was done. The resulting wave on the oscilloscope wherethen examined and the time the signal was high, was measured in order to esti-mate the time consumed by the module.

Figure 8.2 illustrates how to measure the on time of the signal between the twodotted lines.

Time [t]

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Voltage [V

]

-1.5

-1

-0.5

0

0.5

1

1.5Time measurement

Figure 8.2: An illustration of how to measure the on time of the signal.

The toggling of the I/O pin needs to be done in the C-code. However, thisintroduces very little extra code, that should not interfere with the normal execu-tion of the code.

53

9Results

9.1 Concept and result outline

The result section will display results from tests of the entire algorithm that aredescribed in the Test benches-chapter. These tests will be presented with figures ofthe implemented GUI, for the algorithm tests, and with tables for the measure-ments done on time consumption.

9.2 Testing the algorithm

As mentioned during the Test benches-chapter, the algorithm has been tested witha total of ten different signals generated in MATLAB and transferred to the MCUthrough the use of a header file. This means that for one test, the program hasbeen compiled together with one of these signals, and the data from this signalhas replaced the values collected with the ADCs. Furthermore, during the tests ofthe algorithm, one observation resulted in a slight modification to the algorithm.This modification lead to further tests with the arc-tangent calculation disabled inorder to compare the results. Apart from these two modifications, the executionof the program remained unchanged.

According to Table 8.1 the first five test signals contains the four frequencies10 Hz, 40 Hz, 50 Hz and 500 Hz. The difference between these signals is thedecimation used which also determines the length of the signal. The decimationstarts at 1 s and ends at 16 s. Figure 9.1 to Figure 9.10 displays the results achievedby the implemented algorithms running on the MCU.

54

With a decimation of 1 s, the expected signals can be seen as peaks in the GUIaccording to Figure 9.1.

Frequency [Hz]

0 200 400 600 800 1000 1200

Ma

gn

itu

de

[V

]

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2Frequency spectrum of vital signsX: 10

Y: 0.1917 X: 40

Y: 0.1849

X: 50

Y: 0.1811

Serial disconnect

Plot

Decimation

1

Show datatips

Figure 9.1: The algorithm response from test signal 1, without arc-tangent demodulation.

If the arc-tangent demodulation is enabled in the MCU, the spectrum changesto Figure 9.2.

Frequency [Hz]

0 200 400 600 800 1000 1200

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Frequency spectrum of vital signs

X: 10

Y: 0.5909

X: 50

Y: 0.9153

X: 40

Y: 0.5587

Serial disconnect

Plot

Decimation

1

Show datatips

Figure 9.2: The algorithm response from test signal 1, with arc-tangent enable.

55

When using twice the decimation, 2 s, the resolution of the spectrum doubles,according to Figure 9.3.

Frequency [Hz]

0 100 200 300 400 500 600

Ma

gn

itu

de

[V

]

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2Frequency spectrum of vital signsX: 10

Y: 0.1918

X: 40

Y: 0.1849X: 50

Y: 0.1811

Serial disconnect

Plot

Decimation

2

Show datatips

Figure 9.3: The algorithm response from test signal 2, without any arc-tangent demodulation.

However, with phase estimation through arc-tangent, the spectrum changesagain to a more noisy one according to Figure 9.4.

Frequency [Hz]

0 100 200 300 400 500 600

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Frequency spectrum of vital signs

X: 10

Y: 0.5866

X: 50

Y: 0.9237

X: 40

Y: 0.5605

Serial disconnect

Plot

Decimation

2

Show datatips

Figure 9.4: The algorithm response from test signal 2, with arc-tangent enable.

56

Increasing the resolution further, separates the peaks as can be seen in Figure9.5.

Frequency [Hz]

0 50 100 150 200 250 300

Ma

gn

itu

de

[V

]

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2Frequency spectrum of vital signsX: 10

Y: 0.1905

X: 40

Y: 0.1839

X: 50

Y: 0.1798Serial disconnect

Plot

Decimation

4

Show datatips

Figure 9.5: The algorithm response from test signal 3. The arc-tangent module is disabled.

Even with the arc-tangent demodulation enabled, the peaks are clearly visiblein Figure 9.6.

Frequency [Hz]

0 50 100 150 200 250 300

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Frequency spectrum of vital signs

X: 10

Y: 0.5791X: 40

Y: 0.5604

X: 50

Y: 0.9384

Serial disconnect

Plot

Decimation

4

Show datatips

Figure 9.6: The algorithm response from test signal 3, with arc-tangent enable.

57

If the decimation is yet again doubled, so is also the resolution according toFigure 9.7.

Frequency [Hz]

0 20 40 60 80 100 120 140

Ma

gn

itu

de

[V

]

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2Frequency spectrum of vital signsX: 10

Y: 0.1889

X: 40

Y: 0.1816X: 50

Y: 0.1789

Serial disconnect

Plot

Decimation

8

Show datatips

Figure 9.7: The algorithm response from test signal 4, without arc-tangent.

Apart from extra noise and an overall stronger level of the peaks, the spectrumin Figure 9.8 is similar to that without arc-tangent demodulation.

Frequency [Hz]

0 20 40 60 80 100 120 140

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Frequency spectrum of vital signs

X: 40

Y: 0.5552

X: 50

Y: 0.915

X: 10

Y: 0.5878

Serial disconnect

Plot

Decimation

8

Show datatips

Figure 9.8: The algorithm response from test signal 4, with arc-tangent enable.

58

When current maximum decimation of 16 s is used, the spectrum looks likeFigure 9.9.

Frequency [Hz]

0 10 20 30 40 50 60 70

Ma

gn

itu

de

[V

]

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2Frequency spectrum of vital signs

X: 10

Y: 0.1849

X: 40

Y: 0.1762X: 50

Y: 0.1739

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.9: The algorithm response from test signal 5, without arc-tangent.

If this spectrum is compared to the spectrum in Figure 9.10, there are a fewdifferences in form of extra peaks.

Frequency [Hz]

0 10 20 30 40 50 60 70

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9Frequency spectrum of vital signs

X: 10

Y: 0.5799 X: 40

Y: 0.5593

X: 50

Y: 0.8807

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.10: The algorithm response from test signal 5, with arc-tangent enable.

59

The second part of Table 8.1, that is the five last signals, uses four differentfrequencies that should be more close to the actual data the system will sample.These four frequencies are 0.26 Hz, 1.167 Hz, 40 Hz and 500 Hz, and representsrespiration and heartbeat rate together with two disturbing frequencies. Againthe major difference between these signals is the decimation used, which starts at1 s and ends at 16 s.

Figure 9.11 shows the output from the MCU with a decimation of 1 s. Asexpected from the earlier tests, the high frequency of 500 Hz has been filteredaway. However, the lower frequencies representing the respiration and heartbeatis impossible to see in this spectrum since they all merge in the lower frequencybins.

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05Frequency spectrum of vital signs

X: 40

Y: 0.04543

X: 6

Y: 0.01411

Serial disconnect

Plot

Decimation

1

Show datatips

Figure 9.11: The algorithm response from test signal 6, with the arc-tangent demodulationdisabled.

60

The corresponding spectrum, with arc-tangent demodulation enabled can beseen in Figure 9.12. Similarly to the previous spectrum without arc-tangent, thisspectrum can not show the lower frequencies. However, this spectrum insteadshows several other peaks above the expected 40 Hz. Furthermore, the 40 Hzpeak is no longer a single peak, but rather several peaks in close proximity to the40 Hz. All these peaks also have a similar amplitude according to the spectrum.

Frequency [Hz]

0 200 400 600 800 1000 1200

Magnitude [V

]

0

0.1

0.2

0.3

0.4

0.5

0.6Frequency spectrum of vital signs

X: 0

Y: 0.5551

X: 42

Y: 0.2307X: 40

Y: 0.2053

X: 79

Y: 0.2406

X: 120

Y: 0.1369

Serial disconnect

Plot

Decimation

1

Show datatips

Figure 9.12: The algorithm response from test signal 6, with arc-tangent enable.

61

Skipping ahead to 4 s decimation, the spectrum without arc-tangent demod-ulation can be seen in Figure 9.13.

Frequency [Hz]

0 50 100 150 200 250 300

Ma

gn

itu

de

[V

]

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045Frequency spectrum of vital signs

X: 40

Y: 0.04445

X: 1.25

Y: 0.0102

Serial disconnect

Plot

Decimation

4

Show datatips

Figure 9.13: The algorithm response from test signal 8. Arc-tangent is disabled.

The corresponding spectrum with arc-tangent enabled, does still not have aclear peak at 40 Hz, according to Figure 9.14.

Frequency [Hz]

0 50 100 150 200 250 300

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Frequency spectrum of vital signs

X: 41

Y: 0.2246

X: 0.25

Y: 0.9653

Serial disconnect

Plot

Decimation

4

Show datatips

Figure 9.14: The algorithm response from test signal 8, with arc-tangent enable.

62

The final two spectrum’s with 16 s decimation can be seen in Figure 9.15 with-out arc-tangent demodulation and in Figure 9.16 with.

Frequency [Hz]

0 10 20 30 40 50 60 70

Ma

gn

itu

de

[V

]

0

0.05

0.1

0.15

0.2

0.25Frequency spectrum of vital signs

X: 0.25

Y: 0.2493

X: 1.125

Y: 0.01357

X: 40

Y: 0.04403

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.15: The algorithm response from test signal 10, without arc-tangent demodulation.

Frequency [Hz]

0 10 20 30 40 50 60 70

Ma

gn

itu

de

[V

]

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9Frequency spectrum of vital signs

X: 0

Y: 0.7077

X: 0.25

Y: 0.8643

X: 0.8125

Y: 0.2403

X: 1.312

Y: 0.1762

X: 40.5

Y: 0.2189

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.16: The algorithm response from test signal 10, with arc-tangent enable.

According to Figure 9.15 the spectrum now contains three peaks as expected.The two low peaks are close to the real values of 0.26 Hz and 1.167 Hz. How-

63

ever, the spectrum in Figure 9.16 is very noisy and results in several peaks, whichare hard to relate to the actual real values. And as can be seen, these peaks areconcentrated around the areas where the real peaks are expected.

9.2.1 ADC measures

In order to also test the algorithm together with the ADCs, a signal generator wasconnected to the two ADC inputs. This type of connection required the phase-demodulation to be disabled in order to generate a spectrum at all, because of thedivision in that module. Figure 9.17 shows the GUI with a 10 Hz sinus wave atthe input of the ADCs. This sine wave has an offset and an amplitude of 200 mV.

Frequency [Hz]

0 10 20 30 40 50 60 70

Magnitude [m

V]

0

20

40

60

80

100

120

140

160

180Frequency spectrum of vital signs

X: 10

Y: 176.4X: 0

Y: 174.1

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.17: The algorithm response to a 10 Hz sine wave, with arc-tangent disabled.

64

If the frequency of the same sine wave is slowed down to 1 Hz, the generatedspectrum looks like in Figure 9.18.

Frequency [Hz]

0 10 20 30 40 50 60 70

Magnitude [m

V]

0

20

40

60

80

100

120

140

160

180Frequency spectrum of vital signs

X: 0

Y: 172.2X: 1

Y: 171.4

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.18: The algorithm response to a 1 Hz sine wave, with arc-tangent disabled.

Reducing the frequency of the sine wave even further, down to 100 mHz, thefrequency spectrum becomes as in Figure 9.19.

Frequency [Hz]

0 10 20 30 40 50 60 70

Magnitude [m

V]

0

50

100

150

200

250Frequency spectrum of vital signs

X: 0

Y: 205.4

X: 0.125

Y: 232.3

X: 0.0625

Y: 214.3

Serial disconnect

Plot

Decimation

16

Show datatips

Figure 9.19: The algorithm response to a 100 mHz sine wave, with arc-tangent disable.

65

9.3 Measuring the algorithm

Each individual module that has been implemented was measured in terms of ex-ecution time. This means three different functions has been measured along withthe entire processing loop. For debugging purposes, the UART-transmissions hasalso been measured in order to verify the improvements for the new fputc-versioncompared to the original one.

9.3.1 The processing loop

The processing loop was as mentioned divided into three major processing mod-ules. The Table 9.1 summarizes the measurements on these three modules, whereeach module was measured separately during one minute, to let the program sta-bilize. The Repetition/loop-field refers to how many times the module is executedduring a normal processing loop.

Table 9.1: Time consumed by the three main modules

Description Value

fftProcessTime consumed 4.18 msRepetition/Loop 1

phaseCalcTime consumed 616 µsRepetition/Loop 1

filterAndDecimateTime consumed 892 µsRepetition/Loop 1

Sum. Time consumed 5.688 ms

Apart from the these three modules, there is also the debugging part, whichsends data from the device to a host computer. This communication used thetargeted fputc-function mentioned earlier. The Table 9.2 shows a summary of thetime consumed by the two different types of fputc. The summary is made bysending the two vectors, that contain peak and spectrum data, using the differentfputc-functions.

Table 9.2: Time consumed by the two different fputc-functions

Description Original fputc New fputc

Peak dataTime consumed 115.39 ms 23.04 msRepetition/Loop 1 1

Spectrum dataTime consumed ∼ 11.8 s 368.96 msRepetition/Loop 1 1

Sum. Time consumed ∼ 11.91 s 392 ms

In addition to the time measurements of the new fputc-function, there was alsoan estimation of the time used to send one single byte. The estimation is based onthe time needed to send a single package containing 262 bytes. This time is equal

66

to the time needed to send the peak data, with the new fputc-function in Table9.2, since the size of the peak data vector is known to be less than the size of themaximum payload. Table 9.3 shows the estimated time per byte, which should beequal regarding of which fputc-function is used.

Table 9.3: Time needed per byte sent through the UART

Description Total time Bytes sent Time / byte

Peak data 23.04 ms 262 87.93 µs

Finally the entire processing loop was measured with all debugging enabled.This was done in order to verify the previous measures and to estimate the po-tential overhead from the different buffers used between the modules. Table 9.4contains the summary of this measure and also the estimated overhead. Apartfrom the peak and spectrum data, there is also one other debugging message sentin the form of one 262 byte package.

Table 9.4: Time consumed by the entire processing loop

Description Value

Processing loop Time consumed 421.5 msSum. modules Time consumed 5.688 ms

Sum. debugging Time consumed 415.04 ms

Total overhead Time consumed 772 µs

With an total overhead of 772 µs, this shows the possibility of reducing thetotal processing time down to 6.46 ms if no debugging is allowed.

9.3.2 ADC and data collection

As shown during the Data acquisition-chapter, the sampling rate of the ADCs wasset to 2048 Hz. With the desired update frequency of 2 Hz, this results in 1024new samples every 0.5 s. Before these samples are processed in the main loop,they are moved from the ADC-buffer into the buffer of the processing loop. Table9.5 shows the time needed to copy data from the ADC-buffers to the processingbuffers.

Table 9.5: Time used to copy data into the processing loop

Description Value

copyBuffersTime consumed 148 µsData copied 1024 floats

9.4 Summary

The above described time consumption for the processing loop and the copy fromADC-buffer into the processing buffer can be summarized as in Table 9.6. The ta-

67

ble contains two scenarios, the fastest one without any debugging or presentationof data, and the one with full debugging and both peak and spectrum output.

Table 9.6: Total time needed to process new data

Description Time

No debuggingProcessing loop 6.46 msData copy 148 µsSum. 6.608 ms

Full debuggingProcessing loop 421.5 msData copy 148 µsSum. 421.65 ms

With the desired update frequency of 2 Hz, this leaves the idle time shown inTable 9.7.

Table 9.7: Total idle time with the desired update frequency of 2 Hz

Description Time

New data Updates 500 ms

No debugging Approx. idle time 493.392 msFull debugging Approx. idle time 78.35 ms

The idle time is approximate since there is some extra overhead, hidden be-tween the actual triggering of the interrupt and the copying of data.

68

10Discussion

10.1 Tests of the algorithm

When summarizing the tests performed on the algorithm using the test signalssetup in Test Benches-chapter, there are two results that stand out most. This is thedifference between the algorithm when the arc-tangent calculation is active ornot. All the results with the arc-tangent demodulation enabled, re-assembles thetest results on that particular module from the Processing-chapter. This confirmsthat module is still working as intended. However, the spectrum’s produced bythis demodulation are noisy and seem to contain multiples of the already existingfrequencies within the signal. The results without the arc-tangent demodulationenabled, are however a fair bit cleaner spectrum’s in terms of noise and allowsfor easier spotting of the peaks.

Another interesting difference, that can be observed in almost every compar-ison between the two, is the amplitude difference. By comparing for exampleFigure 9.1 with Figure 9.2, the amplitude value of the 10 Hz peaks and the 40 Hzpeaks differs by more than a factor of two. If the code to generate the test signal 1is examined it will be clear that the most correct spectrum in terms of amplitudeis generated with the arc-tangent enabled. On the other hand, the 50 Hz peak issignificantly larger in the arc-tangent spectrum, while the spectrum in Figure 9.1re-assembles the response of the filter. This is likely due to multiples of both the10 Hz peak adding up to the 50 Hz peak.

10.1.1 Addition of noise

The extra noise that is added in all the spectrum’s generated with the arc-tangentenabled, is likely related to the periodic behavior of the arc-tangent function. Thisperiodic behavior will mean that each frequency will have multiple’s of itselfadded to the signal after the demodulation has been performed. And since thereis no filtering after the demodulation process, the multiples will stay in the signaland be represented in the frequency spectrum as separate frequencies. However,

69

since calculating the phase using arc-tangent is correct, the amplitude shown inthe spectrum for the base frequencies is more close to the actual value used toproduce the signal.

So, if the arc-tangent calculation is correct, why does the spectrum’s of thenon-demodulated signal look less noisy? This is most likely related to a prop-erty of the sin-function stating that sin(x) = x when x ≈ 0. This being true,would simply indicate that there is no need for arc-tangent demodulation whenthe phase is small. In the cases shown in this thesis, the phase can be consideredsmall for all the artificially made signals, and therefore used. However, this thesisdoes not show any results from using real data, which means that to remove thearc-tangent demodulation, the size of the phase has to somehow be monitored.

10.1.2 The use of decimation

As can be seen throughout all the result figures, increased decimation yields ahigher resolution of the frequency spectrum. This is because, increased decima-tion reduces the effective sampling rate of the system, which in turn is related tothe length of the FFT, as described in Eq. 4.1 in the Processing-chapter.

The effective sampling rate can of course also be reduced directly in the ADCsampling process, however with the current setup, problems related to aliasing ofhigher frequency signals into the lower frequency band should be removed, dueto the higher initial sample rate together with the use a digital low-pass filter.

10.1.3 Artificial vital signs

The results from using a test signal containing very low frequencies similar tothat of vital signs, show an increased accuracy as the resolution of the frequencyspectrum increases. However, according to Figure 9.15 and Figure 9.16 where aresolution of 0.0625 Hz per bin was achieved through the use of 16 s decimationfactor, this might need to be even higher in order to achieve a good spectrum.This is because the peaks float together at the very small frequencies of 0.26 Hzand 1.167 Hz and is then impossible to distinguish.

Another solution might be to also add some more post-processing, like sup-pression of non-maximum peaks in close intervals. This could allow the maxi-mum peaks to be more visible in the spectrum, while also allow the software aneasier way to detect peaks.

10.1.4 Usage of the ADCs

The results when collecting data with the ADCs that comes from a signal gener-ator, turned out as expected. Of course, these tests did not have the arc-tangentcalculation enabled since the first operation done there is a division. This divi-sion would simply render the the phase equal to one for every sample, since theADCs was connected to the same input. However, these tests did show that theADCs and the acquisition part of the implementation works and that these sam-ples could be processed and determined in the FFT.

70

It should be noted that, without using both ADCs to collect the sine wave, afairly strong disturbance could be observed. This disturbance was a single peakat 50 Hz and is likely originating from the electrical power grid, which provides230 V AC power at 50 Hz to surrounding equipment in the facility. This observa-tion might mean that the filter needs to be set with a lower cut-off frequency, inorder to remove as much as possible of this disturbance.

10.1.5 The GUI

As can be seen from the figures, each result has been captured using the imple-mented GUI. The GUI allowed for easy configuration of the plot as long as thedecimation used in the MCU, was known. The GUI also allowed the plot win-dow to stop updating the plot with new data, while the collection continued inthe background.

After performing the measures and tests of the algorithm several notes abouthow the GUI could be improved were made. These included bug-fixes such asthe Show datatips-option should not be allowed to crash the update function ofthe plot and the peak data received from the MCU should be translated directlyinto the GUI. They also included the suggestion of adding options to input thesample rate and FFT length directly into the GUI, together with the addition of aslider to allow scaling of the x-axis.

10.2 Time consumption of the algorithm

The second type of tests performed on the implementation regarded the time con-sumed by each module and the overall system. Summarizing these results givesthe conclusion, that with the current implementation, this system is performingwell within the time considerations. This also gives the impression that this im-plementation might be able to handle a lot higher frequencies that can be foundin other household, industrial or medical applications.

10.2.1 The processing

As shown in the Table 9.1, the slowest module is the fftProcess which calculatesthe frequency spectrum and also finds the peaks of this spectrum. This long timeconsumption is likely due to most of the processing being performed on largerarrays, several times, while the other modules only performs its processing onetime on an array. However, this makes the fftProcess-module dominant in thetotal 5.688 ms used, and also the module to need most optimization if the totaltime needs to be reduced.

10.2.2 The communication link

The time consumed by communication link, which uses a Serial-to-USB commu-nication is described in Table 9.2 and in Table 9.3. These two tables refers to data

71

sent from the Nucleo-board towards a computer. In fact, the actual communica-tion link is mostly described in last of these two tables because the value for timeper byte. This time is related to the configured transmission speed of the UART-peripheral, which means that with a higher transmission speed, this time wouldbe lower.

As is seen, the optimization of the original transfer which resulted in the com-munication protocol described in chapter Communication link and the new fputc-function, decrease the time significantly for sending the spectrum data from theNucleo-board to the computer. However, this transfer is still the major bottleneckwhen debugging, and should therefore be optimized or changed into anothertype of communication link.

10.2.3 The data collection

Apart from the desired update frequency of 2 Hz which is controlled by the rela-tion between the sampling speed and the size of the ADC-buffer, there is also theextra time needed to copy the data into the algorithm. This time is not static how-ever, but is instead also related to the size of the ADC-buffer. However, with thecurrent implementation, it might be possible to share the memory of the ADC-buffer and instead make the copy during the filtering and the decimation, dueto the DMA generating an interrupt for each half of the buffer. But this wouldrequire some careful changes to the filterAndDecimate-module in order to use un-signed 16-bit integers instead of floats during the filtering.

72

11Conclusion

11.1 In general

In this thesis, dedicated algorithms for contact-less vital signs detection has beendeveloped and deployed onto a commercial DSP-evaluation platform. However,these algorithms can be used for other types of applications were the desiredinformation is hidden within the phase of the signal. Such applications mightbe angle-of-arrival applications or measures of vibration in remote objects. Theproject resulting in this thesis, is part of an on-going research project at LinkopingUniversity supported by the Norrkoping municipality.

11.1.1 Hardware

As a first step in this project, decisions regarding the system level implementationand hardware specifications were taken. These decisions resulted in the use of theSTM32 Nucleo-F767ZI evaluation platform, as the base hardware upon which thealgorithms has been implemented.

Along with the DSP-core, the evaluation platform also had the desired amountof ADCs, to gather the data before processing, together with a Serial-to-USB com-munication link, to transfer the data to a computer.

11.1.2 The algorithm

The algorithms developed and implemented on the DSP-platform have been di-vided into a set of modules.

• Filtering and decimation

• Arc-tangent demodulation

• FFT calculation and peak detection

73

These modules tied together with the use of buffers, have been implementedbetween the previously mentioned ADCs and the Serial-to-USB communication,to form the entire algorithm.

11.1.3 Test and verification

The used evaluation platform and the developed algorithms have been testedand verified with MATLAB. MATLAB has been used to generate artificial testsignals that have been deployed onto the evaluation platform, along with provid-ing reference diagrams and plots for the tests performed. Furthermore, MATLABhas been used to develop a GUI to receive and present the data from the DSP-platform in a plot, which would allow for easy debugging and further testing ofthe system.

The tests performed with the use of MATLAB, demonstrates that the DSP-platform with its developed algorithms can detect the signals embedded in thephase information.

11.2 Further development

This thesis has got to the point were a working system has been successfully im-plemented on an evaluation platform. This system can successfully sample datasimultaneous from two inputs while also process this data to return the desiredinformation about the phase. However, this implementation forms just the basefunctionality of a complete system. There are many improvements and furtherdevelopment that could be done to further enhance the functionality.

Following is a list in order for where I, the author, see the next set of develop-ment and improvements continue:

1. The processing algorithms has been verified with generated ideal sinusoidalsignals. A more realistic approach should use

• Accurate simulation results from the RF front-end

• Real signals from experiments

2. Better implementation of peak detection, such that the desired peaks aredistinguished from the noise. This implementation could involve

• Non-maximum-suppression algorithms

• Further reduced frequency spectrum

• Probability estimation of peak locations

3. Improvements towards the communication link, such that the speed of thedata transfer is increased, with the use of

• The Ethernet-port on the evaluation platform

• The real USB-port on the evaluation platform

74

References

[1] STMicroelectronics. Nucleo-board decription site. Oct. 21, 2017. URL: http://www.st.com/en/evaluation-tools/nucleo-f767zi.html.

[2] Keysight Technologies. 33120A Function / Arbitrary Waveform Generator, 15MHz. Nov. 3, 2017. URL: http://www.keysight.com/en/pd-1000001289%3Aepsg%3Apro/function-arbitrary-waveform-generator-15-mhz?nid=-

536902324.536881979&cc=US&lc=eng.

[3] Keysight Technologies. DSOX2012A Oscilloscope: 100 MHz, 2 Analog Chan-nels. Nov. 3, 2017. URL: http://www.keysight.com/en/pdx-x201831-pn-DSOX2012A/oscilloscope-100-mhz-2-analog-channels?cc=US&lc=eng.

[4] Adriana Serban. Norrkopings Fond for Forskning och Utbildning (NFFU),Radar/Radio Project Documentation. Oct. 9, 2017.

[5] STMicroelectronics. Arm R© Cortex R©-M7 32b MCU+FPU, 462DMIPS, up to2MB Flash/ 512+16+4KB RAM, USB OTG HS/FS, 28 com IF, LCD, DSI. May 25,2017. URL: http : / / www . st . com / content / ccc / resource / technical /document/datasheet/group3/c5/37/9c/1d/a6/09/4e/1a/DM00273119/

files/DM00273119.pdf/jcr:content/translations/en.DM00273119.pdf.

[6] Adam Dunkels. lwIP - A Lightweight TCP/IP stack. Aug. 10, 2017. URL: https://savannah.nongnu.org/projects/lwip/.

[7] Anders Hernborg. Vad ar normal puls vid vila och vid olika grader av aktivitet?Oct. 16, 2017. URL: https : / / www . 1177 . se / Ostergotland / Stall - en -anonym-fraga/Fragor/Vad-ar-normal-puls-vid-vila-och-vid-olika-

grader-av-aktivitet/.

[8] Gunnel Bjerneroth Lindstrom checked by Lars-Olof Hensjo. Luftvagar ochlungor. Oct. 16, 2017. URL: https://www.1177.se/Ostergotland/Tema/Kroppen/Cirkulation-och-andning/Luftvagar-och-lungor/?ar=True.

[9] STMicroelectronics. RM0410 Reference Manual. May 25, 2017. URL: http://www.st.com/content/ccc/resource/technical/document/reference_

manual / group0 / 96 / 8b / 0d / ec / 16 / 22 / 43 / 71 / DM00224583 / files /

DM00224583.pdf/jcr:content/translations/en.DM00224583.pdf.

75

[10] ARM Ltd. Cortex Microcontroller Software Interface Standard, CMSIS. Version 5.1.0. Aug. 4, 2017. URL: http://www.keil.com/pack/doc/CMSIS/General/html/index.html.

[11] R.J. Beerends, H.G. ter Morsche, J.C. van den Berg, and E.M. van de Vrie.Fourier and Laplace Transforms. Cambridge University Press, 2006. ISBN: 978-0-521-53441-3.

[12] Mark edited by Scott Seidman. Forum post: What is the relation between FFTlength and frequency resolution? Aug. 29, 2017. URL: https://electronics.stackexchange.com/questions/12407/what-is-the-relation-between-

fft-length-and-frequency-resolution.

[13] Goran Forslind and Mats Neymark. Matematisk Analys, En variabel. LiberAB, 2012. ISBN: 978-91-47-10023-1.

[14] Jasper Vijn. Off on a tangent: a look at arctangent implementations. July 12, 2017.URL: http://www.coranac.com/documents/arctangent/.

[15] MathWorks. Hilbert Transform - MATLAB. Version R2017b. Aug. 27, 2017.URL: https://se.mathworks.com/help/signal/ug/hilbert-transform.html?s_tid=gn_loc_drop.

[16] ARM Ltd. Biquad Cascade IIR Filters Using a Direct Form II Transposed Struc-ture. Version 5.1.0. Aug. 27, 2017. URL: http://www.keil.com/pack/doc/CMSIS/DSP/html/group__BiquadCascadeDF2T.html.

76