Department of Science and Technology
Institutionen för teknik och naturvetenskap
Linköping University
Linköpings universitet
g
n
i
p
ö
k
r
r
o
N
4
7
1
0
6
n
e
d
e
w
S
,
g
n
i
p
ö
k
r
r
o
N
4
7
1
0
6
-E
S
LiU-ITN-TEK-A--13/022--SE
Filtrering och målföljning av
akustisk signatur på
androidplattformar
Viktor Johansson
Daniel Josefsson
LiU-ITN-TEK-A--13/022--SE
Filtrering och målföljning av
akustisk signatur på
androidplattformar
Examensarbete utfört i Elektroteknik
vid Tekniska högskolan vid
Linköpings universitet
Viktor Johansson
Daniel Josefsson
Handledare Allan Huynh
Examinator Anna Lombardi
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ör
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/
Sammanfattning
Denna rapport omfattar ett arbete kring att förbättra signalbehandling och mål-följning av en förbränningsfrekvens i en androidapplikation för effektberäkning hos accelererande fordon. Den ursprungliga applikationen är utvecklad på i3tex AB och det var även där som arbetet utfördes.
Effektberäkningen görs genom att
• först spela in ljudet i kupén under ett accelerationsförlopp, där inspelning-en signalbehandlas och förbränningsfrekvinspelning-ensinspelning-en målföljs,
• sedan sker transformering från frekvensdomänen till hastighetsdomänen, varpå effekten beräknas via multiplikation av fordonets vikt, hastighet och acceleration.
Problemet med den ursprungliga implementationen av målföljningen var att al-goritmen inte var tillräckligt robust mot lågt signal/brus-förhållande (snr). För att göra systemet mer robust utvecklades lermålsföljning med Kalmanilter, där ett poängsystem bestämmer vilken av målföljarna som mest troligt har följt för-bränningsfrekvensen. Den nya algoritmen presterar betydligt bättre än den ur-sprungliga i avseende på rmse, men är betydligt mer resurskrävande.
Genom optimering av hur signalbehandlingen görs, såsom längd och typ av föns-terfunktioner och andra parametrar för korttidsfouriertransformen (stft), är ex-ekveringstiden för hela analysen marginellt snabbare och betydligt snabbare på en androidenhet med respektive utan stöd för hårdvaruaccelererade lyttalsope-rationer.
Det visade sig även att, trots att inte hårdvaruspeciikationerna för Android, cdd, speciicerar inspelningar av frekvenser under 100 Hz är det möjligt på alla testa-de androidtelefoner och med tillräckligt gott resultat för att genomföra frekvens-följning enligt ovan.
Abstract
This report covers the improvements of an existing Android application, which is used to calculate the power produced by an accelerating vehicle. The improve-ments are in the ield of signal processing and tracking of the combustion fre-quency of the engine. The original Android application, that this work continues from, was developed by i3tex AB and is also where this work was carried out. To calculate the power produced by the car, the application
• records the sound inside the coupé of the car, of which the power is to be calculated, during an acceleration where the recording later is processed and the combustion frequency is tracked and thereafter
• transforms the tracked frequency from frequency to engine speed, where the momentary power can be calculated by multiplying the weight, speed and acceleration of the car.
This work was carried out to improve a prior implementation that proved to be not robust enough with a low signal-to-noise ratio (snr). To make the new sys-tem more robust, a multi-tracking algorithm using Kalmanilter was developed and implemented, where every tracker is appointed a score which is related to how likely it is to have followed the combustion frequency. The trajectory of the tracker with the highest score is used to calculate the produced power. The novel algorithm described in this report performs better than the prior algorithm with respect to rmse, but worse resource wise.
Through optimization of the signal processing, specially the choice of window and other parameters used by the short-time Fourier transform (stft), the full implementation has got a slightly lower execution time than the prior one. If the device running the application does not have hardware accelerated loating point support, which is the case of early Android units, the execution time is improved signiicantly.
Moreover it is also shown that, even though it is not speciied in the Compatibility Deinition Document (cdd) for Android, signals containing frequencies below 100 Hz can be picked good enough to track the combustion frequency of the engine.
Tack
Vi vill tacka vår examintor Anna Lombardi för den vägledning vi fått under ex-amensarbetet. Vi vill även tacka vår handledare Håkan Rolin på i3tex för att ha givit oss möjligheten att utföra detta examensarbete.
Innehåll
Notation 11
I Bakgrund
1 Introduktion 3
1.1 Problembeskrivning . . . 3
1.1.1 Adaptiva ilter för varvtalsbestämning . . . 4
1.1.2 Realtidsanalys . . . 4
1.1.3 Låta applikationen klara av växlingar . . . 4
1.1.4 Veriiering med hjälp av bilars diagnostikuttag . . . 5
1.1.5 Utveckla applikationen till andra plattformar såsom Apple iPhone, Windows Phone eller liknande . . . 5
1.2 Avgränsningar . . . 5 1.3 Metodik . . . 6 1.4 Disposition . . . 6 1.4.1 Rapportens uppbyggnad . . . 7 1.5 i3tex . . . 7 2 Teori 9 2.1 Förbränningsmotor . . . 9 2.1.1 Ottocykeln . . . 9 2.1.2 Akustisk signatur . . . 10 2.1.3 Effekt . . . 11
2.2 Signalteori och signalbehandling . . . 11
2.2.1 Pulskodsmodulering, pcm . . . 11 2.2.2 Frekvensanalys . . . 13 2.2.3 Fönsterfunktioner . . . 14 2.2.4 Brus . . . 16 2.3 Kalmanilter . . . 16 2.3.1 Nomenklatur . . . 17 2.3.2 Algoritm . . . 17 2.3.3 Systemmodell . . . 18 vii
viii INNEHÅLL 3 Mjukvara 19 3.1 Programvara . . . 19 3.1.1 MATLAB . . . 19 3.1.2 Eclipse . . . 19 3.1.3 arecord . . . 20 3.1.4 alsamixer . . . 20 3.1.5 Versionshantering . . . 20 3.2 Ursprunglig implementation . . . 20 3.2.1 Algoritm . . . 20 3.2.2 Sökalgoritm för motorvarvtalet . . . 21 3.2.3 Beräkning framdrivningseffekt . . . 21
3.2.4 Svagheter med denna algoritm . . . 22
4 Android 23 4.1 Applikationsstruktur . . . 23 4.1.1 Resurser . . . 24 4.1.2 Activity . . . 25 4.1.3 Service . . . 26 4.1.4 Manifest . . . 26 4.2 Ljudinspelning . . . 27 4.2.1 Plattformskrav . . . 27 4.2.2 api för ljudinspelning . . . 28
II Experiment och framtagning av ny algoritm
5 Deluppgifter 31 5.1 Karakterisering av androidtelefoners mikrofoner . . . 315.1.1 Inledning . . . 31
5.1.2 Utrustning . . . 32
5.1.3 Metod . . . 33
5.1.4 Resultat . . . 33
5.1.5 Diskussion och slutsatser . . . 35
5.2 Experiment i fält . . . 35
5.2.1 Inledning . . . 36
5.2.2 Utrustning . . . 36
5.2.3 Metod . . . 36
5.2.4 Resultat . . . 38
5.2.5 Diskussion och slutsatser . . . 39
5.3 Ljudilsanalys . . . 40
5.3.1 Inledning . . . 40
5.3.2 Utrustning . . . 40
5.3.3 Metod . . . 40
5.3.4 Resultat . . . 42
5.3.5 Diskussion och slutsatser . . . 43
INNEHÅLL ix
5.4.1 Extrahering av detektioner från frekvensspektrum . . . 44
5.4.2 System- och mätdatamodell . . . 44
5.4.3 Flermålsföljning . . . 46
5.4.4 Algoritmen i korthet . . . 47
5.5 Jämförelse mellan algoritmer . . . 48
5.5.1 Introduktion . . . 48
5.5.2 Utrustning . . . 48
5.5.3 Metod . . . 48
5.5.4 Resultat . . . 49
5.5.5 Diskussion och slutsatser . . . 51
5.6 Effektberäkningar . . . 51
5.6.1 Utrustning . . . 51
5.6.2 Metod . . . 51
5.6.3 Resultat . . . 51
5.6.4 Diskussion och slutsatser . . . 51
III Implementation och resultat
6 Implementation och resultat 55 6.1 Uppbyggnad . . . 55 6.1.1 Bibliotek . . . 56 6.2 Korttidsfouriertransform, stft . . . 56 6.2.1 Inläsningsbuffert . . . 56 6.2.2 Fönsterfunktioner . . . 58 6.2.3 Resultat . . . 596.2.4 Diskussion och slutsatser . . . 59
6.3 Detektionsextrahering . . . 59
6.3.1 Implementation . . . 59
6.3.2 Resultat . . . 59
6.3.3 Diskussion och slutsatser . . . 59
6.4 Kalmanilter . . . 59
6.4.1 Implementation . . . 60
6.4.2 Resultat . . . 60
6.4.3 Diskussion och slutsatser . . . 60
6.5 En jämförelse av mellan den nya applikationen och den ursprung-liga . . . 61
6.5.1 Metod . . . 61
6.5.2 Resultat . . . 61
6.5.3 Diskussion och slutsatser . . . 61
6.6 Testning och veriiering . . . 62
7 Slutsats 63 7.1 Slutsats och diskussion . . . 63
7.2 Framtiden . . . 64
x INNEHÅLL
A.1 Jämförelser mellan telefoner . . . 65
A.2 HTC Desire . . . 81
A.3 HTC Magic . . . 83
A.4 Samsung GT-S5570 . . . 86
A.5 Google Nexus S . . . 89
A.6 HTC One X . . . 92 A.7 HTC Sensation . . . 93 B Tester i fält 97 B.1 Fasta varvtal . . . 97 B.1.1 1500 r/min . . . 97 B.1.2 3000 r/min . . . 101 B.1.3 4500 r/min . . . 103 B.2 Accelerationer . . . 105 C Målföljning 111 C.1 Målföljning, jämförelse . . . 111 D uml-diagram, Android 117 Litteraturförteckning 121
xii Notation
Notation
Variabler
Notation Enhet Betydelse
α - Överlapp vid stft σ - Standardavvikelse Ω Hz Normaliserad frekvens A Variabel Amplitud a m/s2 Acceleration Amin - Gränsvärde för träff b st bitar f Hz Frekvens f0 Hz Grundfrekvens fc Hz Förbränningsfrekvens fmax Hz Nyqvistfrekvensen
fn Hz Frekvens av n-te ordningen
fs Hz Samplingsfrekvens
gn m/s2 Standardgravitationen
m kg Massa
N st Antal i mängd
n - Ordningstal, tid för sampel
ncyl st Antal cylindrar
Nr r/min Motorvarvtal
nr st Vevaxelvarv per förbränningscykel
Nw st Antal sampel i fönsterfunktion
P W Effekt
Pbhp bhp, hk(I) Effekt uttryckt i brake horse power
P(Ω) Hz−1 Spektraltäthet vid frekvensen Ω
Q∆ Variabel/st Nivåupplösning
QEmax - Maximalt kvantiseringsfel
Qn st Kvantiseringsnivåer
R m/r Förhållande mellan
fordonshastig-het och motorvarvtal
∆t s Tid mellan två sampel
v m/s Hastighet
w[n] - Fönsterfunktion vid tid n
x[n] Variabel Kvantisering vid tid n
X(Ω) Variabel Frekvensnivå vid frekvensen Ω
Xmax Variabel Övre gräns på samplingsomfång
Xmin Variabel Lägre gräns på samplingsomfång
Notation xiii Signaler och matriser
Beteckning Förklaring
Γ Modell för hur systembruset verkar på tillstånden
B Modell för hur insignalsvektorn verkar på tillstånden
F Tillståndsövergångsmatris
H Modell för hur mätningar verkar på
tillståndsobserva-tionen
K Kalmanförstärkningen
P Kovariansmatris för felet av estimatet
Q Kovariansmatris för processbrus
R Kovariansmatris för mätbrus
u Styrsignalsvektor
v Bruskälla som verkar på mätsignalen
w Bruskälla som verkar på tillstånden
x Tillståndsvektor
ˆx Mätning av tillstånd
xiv Notation
Förkortningar
Förkortning Betydelse
alsa Advanced Linux Sound Architecture
api Application programming interface
aosp Android Open Source Project
bhp Brake Horse Power
cd-da Compact Disc Digital Audio
cdd Compatibility Deinition Document
dft Discrete Fourier Transform
fft Fast Fourier Transform
fifo First In, First Out
jdt Java Development Tools
ndk Native Development Kit
gps Global Positioning System
mvc Model-View-Controller
ndk Native Development Kit
obd On-board diagnostics
pcm Pulse-code modulation, pulskodsmodulering
pll Phase-locked loop, fastlåst slinga
rmse Root Mean Square Error, kvadratiskt medelvärde för
felet
sdk Software Development Kit
snr Signal-to-noise Ratio, signal-brusförhållande
spl Sound pressure level, ljudtrycksnivå
stft Short time Fourier transform
uml Uniied Modeling Language
Del I
1
Introduktion
Detta kapitel behandlar kortfattat bakgrunden till detta examensarbete. I följan-de avsnitt beskrivs problemet som examensarbetet behandlar, tidigare arbete och vilka avgränsningar som inns och hur arbetet för att nå målen lades upp. Kapit-let beskriver också hur rapportens upplägg ser ut samt vad i3tex, varvid examens-arbetet utfördes, är för företag.
1.1
Problembeskrivning
Genom att spela in motorljud från en förbränningsmotor av kolvtyp sittandes i ett accelerande fordon samt att i förhand veta om hur många cylindrar motorn har, hur mycket fordonet väger och utväxlingen mellan hastighet och motorvarv-tal kan den effekt som driver fordonet framåt beräknas.
i3tex har tagit fram en androidapplikation vars uppgift är att spela in och ana-lysera motorljudet enligt ovan, men implementationen visade sig dock fungera undermåligt. Syftet med examensarbetet är att utreda var bristerna i nuvarande implementering eller beräkningsalgoritm ligger, ta fram förslag, implementera och veriiera lösningar på problemen.
Applikationen är tänkt som en konsumentprodukt där en användare enkelt ska kunna mäta en bils motoreffekt utan ytterligare tillbehör utöver en androidte-lefon. Applikationen ska fungera som reklam för i3tex och därför ge ett roligt, spännande och förtroendeingivande intryck. i3tex har inte, i detta skede, ställt några krav på applikationen ska bli framgångsrik på marknaden.
Kodbasen som tas fram ska även kunna användas för framtida applikationsut-veckling vid i3tex. Därför omfattar även arbetet omstrukturering och
4 1 Introduktion
tationer av funktionalitet som ligger utanför den huvudsakliga problemställning-en. Generella lösningar, som togs fram under arbetets gång, beskrivs även dem i denna rapport.
Då problemet är utav en sådan natur, att tidsåtgången för att karaktärisera och åtgärda bristerna i den beintliga implementationen kan vara kortare än vad spe-ciicerad längd på ett examensarbete för civilingenjörer är1, deinieras även ytter-ligare problem som kan bearbetas i mån av tid. Dessa togs fram av författarna tillsammans med handledarna och presenteras i nedan följande avsnitt2.
1.1.1
Adaptiva filter för varvtalsbestämning
Genom att använda adaptiva ilter bör algoritmen för bestämning av varvtal kun-na göras mindre känslig för störningar. Detta medför i sådakun-na fall högre chans att inspelningen kan användas för analys.
1.1.2
Realtidsanalys
Beroende på hur snabb implementationen av analysalgoritmen är, kan det gå att analysera motorljudet i realtid och därmed få momentan motoreffekt.
Är inte algoritmen tillräckligt snabb ska andra metoder att lösa analysen under-sökas. Detta kan ta lera olika former, bland annat;
• utnyttja andra funktioner ur Androids api,
• utnyttja egen- eller tredjepartsutvecklade javafunktioner för signalanalys • eller att utnyttja Android ndk (2013) för att implementera egen- eller
tred-jepartsutvecklade signalanalysfunktioner skrivna i andra språk, såsom C eller C++.
Även andra förslag på lösningar som uppkommer under arbetets gång bör beak-tas.
1.1.3
Låta applikationen klara av växlingar
Den ursprungliga applikationen är låst till acceleration med fast utväxling, då ap-plikationen kräver att användaren anger en typhastighet för ett varvtal. Med en mer avancerad analys av motorljudet skulle det vara möjligt ta fram när växling-ar sker och därmed när utväxlingen ändras. En typisk växling ger upphov till en varvtalssänkning (släppt gas, koppling, växling och sedan att den högre växeln inte behöver lika högt varvtal för samma hastighet). Använder man sedan andra sensorer som är tillgängliga genom Android api (2013), såsom gps och accelero-meter, för att ta fram den momentana hastigheten bör man kunna få effektkurvor på alla växlar.
1Ett examensarbete på civilingenjörsnivå omfattar 20 veckors heltidsarbete, se TFK (2013). 2Problemen är listade utan inbördes prioritetsordning.
1.2 Avgränsningar 5
1.1.4
Verifiering med hjälp av bilars diagnostikuttag
Många bilar av nyare årsmodell har ett diagnostikuttag, On-board diagnostics obd, där bilverkstäder kan koppla in sig för att mäta olika data. Genom att få tillgång till sådan data skulle en god veriiering av den genom applikationen insamlad data för varvtal och effekt utföras.
1.1.5
Utveckla applikationen till andra plattformar såsom Apple
iPhone, Windows Phone eller liknande
Genom att utveckla applikationen för lera olika operativsystem kan ett lertal jämförelser göras, däribland
• skillnader i api för signalanalys hos de olika operativsystemen, • begränsande hårdvaruskillnader mellan olika plattformar,
• samt olika parametrar som påverkar programvaruutvecklingen, såsom ut-vecklingsmiljö, kostnad och programmeringsspråk.
Då i3tex är ett konsultbolag är det viktigt att ha stor kompetens inom många olika system. Ju bredare kompetens, desto större chans att man täcker in kunders kunskapsbehov.
1.2
Avgränsningar
Rapporten tar inte upp implementationer som enbart är av värde för i3tex. Full-ständig källkod eller fullFull-ständiga klassdiagram redovisas inte, då delar av dessa kan klassas som företagshemligheter enligt (SFS, 1990:409, 1 §).
Vid uträkning av effekt tas inte modeller för luftmotstånd med i beräkningarna. Luftmotståndet beror kraftigt på fordonets utformning och dess hastighet och modellering av detta bör beaktas vid vidareutveckling.
De utvecklade applikationerna är kompatibla från androidversion 2.2 (Froyo, api8) och åtminstone upp till 4.2 (Jelly Bean, api 17). Detta innebär att ca 97 % av alla enheter som använder någon version av Android kan använda applikatio-nerna. En stor uppdatering av Androids api skedde i och med api 11 och vissa uppdateringar bröt bakåtkompabiliteten. Ett funktionsbibliotek, Android Sup-port Library (2013), för att utnyttja den utökade och förändrade funktionaliteten har använts för att nå kraven för funktion på enheter som använder api 8 till api10. Funktionsbiblioteket kan användas ned till api 4, men inga tester av ap-plikationerna på sådana enheter har gjorts.
Då antalet olika hårdvaruplattformar är alldeles för många, för att praktiskt tes-ta applikationerna på alla, har ett urval av dessa genomgått tester. Urvalet gjor-des så att olika hårvaru- och mjukvarukonigurationen kunde kontrolleras, men framförallt grundades det på vilken införskaffningskostnad de olika plattformar-na hade. Det vill säga, de plattformar som författarplattformar-na hade tillgång till och som hade diversiierade konigurationer har testats.
6 1 Introduktion
Det graiska användargränssnitt som innes i applikationen i dagsläget kommer att återanvändas. Då fokuset för detta examensarbete är de tekniska aspekterna för att inna och följa den akustiska signatur som kommer från förbränningsex-plosionerna.
De förbränningsmotorkonigurationer som ska ha täckning av tester är de som har förbränningsfrekvenser som ligger inom spannet 20 - 400 Hz och som har sina förbränningar symmetriskt fasförskjutna kring vevaxelrotationen.
1.3
Metodik
Då en implementation av ursprungsproblematiken fanns implementerad utgick arbetet från denna. Mjukvarubeskrivning och annan tillgänglig dokumentation lästes igenom för att erhålla en första bild av applikationens omfattning. Då dessa dokument är i3tex egendom och för internt bruk ges inga referenser till dessa. Därefter analyserades koden medelst genomläsning och nödvändiga litteraturstu-dier. Android api (2013) konsulterades friskt för att bestämma om den beintliga implementationen var utförd korrekt, men även om andra mer generiska eller optimerade lösningar för olika delar kunde göras. Den litteratur som användes till den teoretiska bakgrunden anges i kapitel 2.
Ljudiler spelades in i studiomiljö och i olika bilars kupéer. Detta för att kon-trollera hur omgivningen påverkar analysalgoritmen och inspelningskvaliteten. Olika androidplattformar och mikrofoner användes för att upptäcka om och hur hårdvaruskillnader påverkade analysalgoritmen och inspelningskvaliteten. Efter ljudinspelningarna var gjorda lästes teori om målföljning och signalbehand-ling på och parallellt implementerades olika delar av teorin i MATLAB för verii-ering. När veriieringen var klar och författarna var nöjda med resultatet imple-menterades samma system i applikationen. Därefter gjordes tester för att säker-ställa implementationen gentemot motsvarigheten i MATLAB.
Dokumentation i form av mjukvaru- och projektbeskrivningar, källkodskommen-teringar samt denna rapport har skrivits löpande under arbetets gång.
Mer utförlig information om den metodik som användes för varje deluppgift inns att läsa i del II.
1.4
Disposition
Rapporten är skriven i typsättningspråket LATEX (Damato m.l. (2013); Latex Pro-ject (2010)) och som stilmall harrtthesis, skriven av Hedenby och Tidefelt (2005),
använts.
Den fullständiga betydelsen av en förkortning anges första gången som förkort-ningen används. Förkortningar särskiljs mot annan text genom att de skrivs med
1.5 i3tex 7 Vid referenser till en speciik klass ur Android api (2013) anges klassnamnet efter årtalet. Ett exempel är en referens till klassen Activity som refereras såsom (Android api, 2013, Activity). Om klassnamnet inte räcker som särskiljare anges klassnamnet med paketnamn som preix. Ett exempel på en sådan referens är (Android api, 2013, android.app.Activity). Om inget annat anges är det api nivå 17 som avses.
1.4.1
Rapportens uppbyggnad
I del I beskrivs problemställningen och annan bakgrund, den teori som har an-vänts för att utföra projektet, den mjukvara som har anan-vänts och hur Android är uppbyggt och hur man programmerar för det.
I del II beskrivs de experiment och utredningar som har gjorts samt framtagandet av den nya målföljningsalgoritmen.
I del III beskrivs hur implementationen av olika delar för Android gjordes och hur resultatet veriierades mot den i MATLAB framtagna nya målföljningsalgo-ritmen.
1.5
i3tex
På i3tex hemsida, i3tex AB (2013), kan man läsa följande företagsbeskrivning: i3tex är ett tekniskt konsultföretag specialiserat på produktutveck-ling och skall vara den självklara partnern för våra kunder. Vi arbe-tar inom branscherna fordon, telekom, verkstad, medicinteknik och energi.
Företaget har kontor i bland annat Göteborg och Norrköping har cirka 230 an-ställda enligt Allabolag (2013).
i3tex har lera kundsegment där användandet av smartphones och läsplattor har och kommer att öka. Exempel på detta är bilindustrin, där man försöker inte-grera användandet av dessa plattformar med funktioner i bilen eller för snabbt prototypskapande. Tekniken kommer mer och mer in i verkstadsindustrin där man väljer att använda dessa färdiga hårdvaruplattformar istället för att utveck-la egna speciallösningar.
2
Teori
Detta kapitel behandlar den teoretiska bakgrunden som ligger till grund för pro-jektet.
Avsnittet Förbränningsmotor behandlar hur en fyrtaktad förbränningsmotor fun-gerar och hur dess akustiska signatur ser ut. Avsnittet Signalteori och signalbe-handling behandlar hur pulskodsmodulering fungerar, hur man kan göra fre-kvensanalyser och kort om fönsterfunktioner samt olika sorters brus. Avsnittet Kalmanilter behandlar hur ett Kalmanilter är uppbyggt och en systemmodell för förlopp med konstant hastighet.
2.1
Förbränningsmotor
Förbränningsmotorer utvinner mekanisk kraft från kemisk energi genom den ke-miska process som uppstår då en luft/bränsle-blandning förbränns. Det inns lera olika typer av förbränningsmotorer men fokuset i denna rapport kommer att ligga på fyrtaktsmotorer, också kända som Ottomotorer, då de är de vanligast förekommande i dagens bilar.
2.1.1
Ottocykeln
En förbränningscykel i Ottocykeln består av fyra steg och har en förbränning per två varv hos vevaxeln. De fyra stegen beskrivs i Heywood (1988) och förklaras enklast tillsammans med en illustration för varje steg. Detta återges nedan i i-gur 2.1.
10 2 Teori
(a) Färskluftsintag: Ny luft sugs in ge-nom luftintaget och blandas med bräns-le som kommer från bränsletillförseln.
Luftintag Avgasrör Luftintag Avgasrör (b) Kompression:
Bå-da ventilerna är stäng-da och blandningen inu-ti cylindern pressas ihop till en liten del av den ursprungliga volymen, förbränningen påbörjas då trycket ökar kraftigt samtidigt som att ett tändstift eller glödstift antänder blandningen. (c) Expansion: Det höga
tryck och den varma gasen pressar cylindern neråt och får vevaxeln att rotera. Mot slutet av detta steg öppnas avga-sventilen för att påbörja avgasutblåsningen.
Luftintag Avgasrör Luftintag Avgasrör (d) Avgasutblås: De resterande avgaserna lämnar cylindern, dels på grund av att trycket i cylindern är högre än det i avgasröret men även för att cykeln av-slutas med att cylindern pressar ut den sista gasen.
Figur 2.1: De fyra stegen i Ottocykeln. Bilden återfinns i originalutförande i Eriksson och Nielsen (2012). Författarna har givit tillåtelse för återgivning här.
2.1.2
Akustisk signatur
Det varvtal som vevaxeln roterar med deinieras som motorns grundfrekvens,
f0 [Hz], och inom fordonsindustrin kallas den (enligt Per Alenius, ljudingenjör, Volvo Personvagnar AB) för en ton av första ordningen. Vid sidan av grundfre-kvensen uppstår även andra toner, fn, av olika slag och dessa benämns som n-te
ordningens toner, där n är den multipel av f0som ger upphov till fn. Detta som
ekvation ger
fn= nf0. (2.1)
En förbränningsmotor kallas också ibland för explosionsmotor då förbränningen sker väldigt snabbt och ger upphov till ett explosionsljud. Explosionsljuden kal-las vardagligen för motorljud och beror på cylinderns mått samt förbränningsfre-kvens. Inom fordonstekniken kallas denna frekvens och dess övertoner för för-bränningsordningar.
Det är vanligt att motorer har ler än en cylinder. För att få en jämn uteffekt på ve-vaxeln är dessa monterade så att expansionsfaserna (igur 2.1c), som ger upphov till vevaxelrotation och därmed uteffekt, sker symmetriskt kring en vevaxelrota-tion.
2.2 Signalteori och signalbehandling 11 Förbränningsfrekvensen, fc, räknas ut som
fc= N60r
ncyl
nr = f0
ncyl
nr , (2.2)
där Nrbetecknar vevaxelns varvtal per minut, ncylantalet cylindrar och nr anta-let vevaxelvarv per förbränningscykel. Den konstanta kvoten 60 omvandlar ve-vaxelvarvtalet per minut till per sekund. Kvoten mellan ncyloch nranger vilken ordning, n, som förbränningsfrekvensen ger upphov till i frekvensspektrumet. Som beskrivet i det första stycket av detta avsnitt är nr= 2 för Ottomotorer. Vid sidan av förbränningsordningarna uppstår även vibrationer som beror på rotationerna hos vevaxeln och kolvarnas rörelser i respektive cylinder. Rotatio-nerna ger upphov till vibrationer och i sin förlängning till ljud. Dessa frekvenser och dessas övertoner samlas under namnet masskrafter inom fordonstekniken. Grundfrekvensen hos masskrafterna beror på vevaxelrotationen och är således av första ordningen.
2.1.3
Effekt
Effekt mäts i SI-enheten Watt, [W], men inom fordonsindustrin används ofta häst-krafter, [hk, hk(M)], eller brake horse power, bhp [bhp, hk(I)], som effektenhet. Enligt EUs direktiv 80/181/EEC (2010) får andra enheter för effekt än W använ-das som komplement och då tillsammans med W. Något blåögt kan man lätt missledas att tro att hk och bhp är ekvivalenta men det är inte fallet. Deinitio-nerna är
1 hk , 75gnkg · m/s ≈ 735, 5 W och (2.3a)
1 bhp , 33000gnlb · ft/min ≈ 745, 7 W, (2.3b)
där gnär standardgravitationen. Skillnaden mellan de två deinitionerna är ca. 1.4%.
2.2
Signalteori och signalbehandling
Detta avsnitt tar upp de tekniker och den teori kring signaler som använts för att lösa problemen som rapporten omfattar.
2.2.1
Pulskodsmodulering,
PCMDet vanligaste sättet att överföra analogt ljud till digitalt sker via pluskodsmodu-lering (pcm), (Rumsey och Watkinson, 2004, kap. 2.5). Det analoga ljudet kvan-tiseras, x[n], vid samplingstid, n, med en viss nivåupplösning, Q∆, via en AD-omvandlare som samplar med en viss samplingsfrekvens, fs, och inom ett samp-lingsomfång, Xlim. Antalet nivåer bestäms av
Qn= 2b, (2.4)
där b anger antalet bitar och Qn är antalet kvantiseringsnivåer. Skalan för den samplade amplituden bestäms av extremvärdena på AD-omvandlarens
samp-12 2 Teori
lingsomfång samt AD-omvandlarens typ. Den vanligast förekommande typen är linjära AD-omvandlare och då bestäms skalan enligt
Q∆=
Xlim
Qn−1, (2.5)
där samplingsomfånget Xlim ges av Xmax− Xmin och ärver enheten av det som
samplas. Det inns även andra typer av AD-omvandlare såsom de av logaritmisk typ.
Vid återskapning av en samplad signal fås sedan amplituden av
A[n] = x[n]Q∆Xmin, x[n] ∈ [0,Qn−1]. (2.6) I igur 2.2 visas hur en pulskodsmodulering med låg nivåupplösning av en sinus-signal ser ut.
Figur 2.2: En sinussignal (röd) med frekvensen f samplas med fs = 32f
och fyra bitars nivåupplösning. Den svarta linjen visar de digitala värdena av pulskodsmoduleringen. Källa: Keenan Tims, http://en.wikipedia.
org/wiki/File:Pcm.svg, hämtad 2013-03-20.
Nivåupplösningen bestämmer hur väl den digitala signalen kan överensstämma med den analoga, detta eftersom att nivåerna är diskreta och inte kontinuerli-ga. Felet som uppstår kallas för kvantiseringsfel, QEmax. Vid en ideal linjär AD-omvandling bestäms det maximala kvantiseringsfelet av
QEmax = 2
−(b+1). (2.7)
En vanligt förekommande nivåupplösning är 16 bitar och det ger att kvantise-ringsfelet högst kan bli 7,6 ppm.
se-2.2 Signalteori och signalbehandling 13 dan återskapas. Detta speciiceras av Nyqvistteoremet,
fmax= f2s, (2.8)
som gör gällande att samplingshastigheten måste vara dubbelt så hög som den frekvens man vill spela in. Vid inspelning av ljud som täcker hela det hörbara spektrumet hos en människa behöver samplingsfrekvensen minst vara 40 kHz, detta då man vanligtvis räknar med att den högsta frekvensen ett mänskligt öra kan uppfatta är 20 kHz. Då Nyqvistteoremet gäller vid ideala fall behöver samp-lingsfrekvensen upp en bit till i praktiken. En vanligt förekommande samplings-frekvens är 44,1 kHz som härstammar från när ljud ofta spelades in på videokas-setter (Watkinson, 2001, kap. 4.5) och är även standardsamplingsfrekvensen på Compact Disc Digital Audio (cd-da, Peek (2010)).
2.2.2
Frekvensanalys
I praktiken är inte signaler opåverkade av brus och det är något man måste ta hänsyn till vid analyser. Signalanalysen kan göras både i tidsdomänen och fre-kvensdomänen. I tidsdomänen kan detta till exempel göras med frekvensföljning via en Phase-locked loop (pll) såsom i Zolzer m.l. (2012). Ett vanligare tillvä-gagångssätt är att man analyserar signalen via diskret fouriertransform (dft) i frekvensdomänen.
2.2.2.1 Diskret fouriertransform (DFT)
Den diskreta fouriertransformen deinieras enligt (Olofsson, 2011, s. 23) som
X(Ω) = F (x[n]){Ω},
n
x[n]e−j2πΩn, (2.9)
där x[n] motsvarar nivån av den samplade signalen vid sampel n och Ω är den kontinuerliga normaliserade frekvensen.
Då resultatet av transformen är komplexvärd analyseras signalen ofta i ett så kallat periodogram, där signalens energispektrum visas. Energispektrumet be-räknas som
P(Ω) = ∥X(Ω)∥2. (2.10)
Komplexiteten hos denna transform är O
n2 enligt Cooley och Tukey (1965). 2.2.2.2 Snabb fouriertransform (FFT)
I Cooley och Tukey (1965) beskrivs en numerisk algoritm som minskar komplexi-teten för en dft till O(n log n). Vidare beskrivs där också fördelarna med att göra analysen på avsnitt med sampellängder som är tvåpotenser.
2.2.2.3 Korttidsfouriertransform (STFT)
Enligt Heisenberg-Gabors osäkerhetsprincip kan man inte fastställa en signal med hög upplösning i både tids- och frekvensdomänen samtidigt. Det ena ex-tremfallet får man om man, i en och samma dft, analyserar hela den samplade
14 2 Teori
signalen. Man får full upplösning i frekvensdomänen men det går ej att bestäm-ma vid vilken tid som en viss frekvens framträdde. Heisenberg-Gabors osäker-hetsprincip deinieras som
∆t∆f ≥ 1
2 (2.11)
i Gabor (1946) och där ∆t motsvarar avståndet i tid mellan två samplingar och ∆f motsvarar avståndet mellan två diskreta frekvenser.
Grundteorin bakom korttidsfouriertransform stft är att för att få tillräckligt god upplösning i både tids- och frekvensled delas sampelmängden upp i mindre de-lar och att analysen görs på varje del för sig. Den tidsdiskreta formen av stft deinieras (omskriven för att passa nomenklaturen) i Allen (1977) såsom
X[m, Ω] = N −Nw ⌈Nw(1−α)⌉ m=0 Nw−1 k=0 w[Nw− k]x[m⌈Nw(1 − α)⌉ + k + 1]e−j2πkΩ/Nw, Nw∈[1,N], α ∈ [0, 1), m⌈Nw(1 − α)⌉ + k + 1 ∈ [1, N], (2.12)
där w motsvarar en fönsterfunktion, Nwär antal sampel där fönstret är relevant,
α är graden av överlapp mellan olika stft-samplingar m. ⌈ · ⌉ och ⌊ · ⌋ står för
avrundning uppåt respektive nedåt till närmsta heltal. I förlängningen är Nw
begränsad av ekvation 2.8 och speciicerad upplösning enligt ekvation 2.11. Korttidstransformen medför vissa nackdelar, bland annat:
• oönskad distortion som uppkommer på grund av uppstyckningen av signa-len, där styckningen gör att signalen inte nödvändigtvis är kontinuerlig i ändpunkterna och att
• bandbredden i praktiken är färre än antalet sampel som ges som insignal. Extremvärdena för antal resultat, Nr, för en signal med N sampel är Nr∈ [1, N]. Nr = 1 fås när hela signalen analyseras på en gång och resultatet ger då ett medelvärde på frekvensinnehållet i signalen. Nr = N ges då ett sampel matas till algoritmen och transformen returnerar då signalen i sitt ursprungsutförande.
Inbyggt i algoritmen inns två sätt att minska påverkan av dessa två brister. Över-lappsparametern α anger hur många av de sampel som återanvänds i nästföljan-de steg i algoritmen och ökar därmed bandbrednästföljan-den genom interpolering. Föns-terfunktionen w används för att minska påverkan av distortionen. Detta genom att multiplicera de sampel som ska analyseras med en funktion av samma längd som samplen och som vanligtvis går mot noll i ändpunkterna. Några av dessa funktioner och dess egenskaper ges i avsnittet nedan.
2.2.3
Fönsterfunktioner
Olika fönsterfunktioner har olika egenskaper och varje fönster har sina fördelar och nackdelar. Harris (1978) har skrivit välförfattad och grundlig artikel om oli-ka fönster och deras egensoli-kaper. Vilket ilter som soli-ka användas i en viss situation
2.2 Signalteori och signalbehandling 15 är en avvägning mellan fönstrens egenskaper och vad man vill uppnå med iltre-ringen. I tabell 2.1 listas några olika fönster och ett urval av deras egenskaper. Bakgrunden till det urval av fönster som presenteras i tabell 2.1 gjordes av följan-de anledningar:
• de tre första fönstren valdes för att de är vanligt förekommande och enkla till sin natur och har diversiierade egenskaper,
• Tukeyfönstret valdes på för att det är en kompromiss mellan ett rektangu-lärt fönster och ett hannfönster och fortfarande har låg spridning över stap-larna och
• det minimerade Blackmann-Harris-fönstret rekommenderas i Harris (1978) och valdes därför även det att tas med.
Tabell 2.1: Fönsterfunktioner och dessas egenskaper, källa: (Harris, 1978, tabell 1). Fönster Högsta sidlobsnivå [dB] Motsvarande brusnivå [staplar] Värsta fallets processförslust [dB] Rektangulärt -13 1,00 3,92 Hann -23 1,23 3,01 Hamming -43 1,36 3,10 Tukey β = 0.25 -14 1,10 3,39 β = 0.50 -15 1,22 3,11 Minimerat Blackman-Harris -92 2,00 3,45
De tre egenskaperna i tabell 2.1 beskriver hur det spektrala läckaget fördelar sig över svaret för transformen. Resultatet av transformen ses ofta som histogram och därför används enheten staplar för spridningen i frekvensled. Ett spektralt läckage uppstår när signaler som samplas inte är periodiska över fönsterfunktio-nens längd. Förklaringar av vad varje egenskap mäter är att
• högsta sidlobsnivå beskriver skillnaden mellan amplituden hos den globala toppen, där den frekvens som samplas återinnes, och den lokala toppen som har näst högst amplitud och kan ses som ett mått på höjningen av brusgolvet,
• motsvarande brusnivå anger vid vilken stapel som amplituden har minskat med 3 dB från den globala toppen och är alltså ett mått på det spektrala läckaget och
• värsta fallets processförlust anger hur många dB som kan förloras från den egentliga amplituden av signalen och representation av signalen via trans-formen.
16 2 Teori
2.2.4
Brus
För att karaktärisera ljudinspelningsutrustning kan referensljud med känt inne-håll spelas upp av en referensanläggning för att samtidigt spelas in med nämnd utrustning. Inspelningen kan sedan analyseras med avseende på hur väl inspel-ningen stämmer överens med uppspelinspel-ningen. Sådana referensljud kan vara allt från senaste slagdängan till mer tekniska referensljud. En form av tekniska refe-rensljud är så kallat brus och nedan förklaras tre olika brustyper.
2.2.4.1 Vitt brus
Vitt brus karaktäriseras av att dess spektraltäthet är konstant, vilket betyder att en signal innehåller samma effekt för alla frekvenser. Detta i ekvationsform ges i (Olofsson, 2011, sida 91) som
Px(f ) = P0. (2.13)
I praktiken får man speciicera en bandbredd inom vilket spektraltätheten skall vara konstant eftersom att det deinitionen av vitt brus inkluderar frekvenser som går mot oändligheten.
2.2.4.2 Rosa brus
Rosa brus karaktäriseras av att dess spektraltäthet är proportionell mot 1 |f | enligt
(Olofsson, 2011, sida 93).
2.2.4.3 Rött brus
Rött brus karaktäriseras av att dess spektraltäthet är proportionell mot f12 enligt (Olofsson, 2011, sida 93).
2.3
Kalmanfilter
Genom att använda sig av ett Kalmanilter kan man minska osäkerheten hos mät-ningar genom att ha en modell för hur systemet beter sig samt för hur den påver-kas av störningar.
Ett Kalmanilter är ett rekursivt ilter som används för att skatta momentana tillstånd hos ett system med en bakomliggande linjär dynamik. Kalmaniltret använder sig av mätningar och data från föregående tillstånd. Kalmaniltret klas-sas som det statistiskt optimala skattningen av tillstånden då iltret minimerar det totala kvadratiska skattningsfelet1, detta gäller om den bakomliggande mo-dellen är linjär samt att de olika störningarna som verkar på systemet har en fördelning enligt N(0, σ2) (Grewal och Andrews (2008)). I denna avdelning pre-senteras de ekvationer som används för att utföra beräkningar med Kalmaniltret, för en teoretisk bakgrund till hur dessa tagits fram hänvisas läsaren till Grewal och Andrews (2008).
2.3 Kalmanilter 17
2.3.1
Nomenklatur
Den systemmodell som Kalmanilteret behöver för att beskriva de tillståndsvari-abler som skall estimeras kan uttryckas såsom
xk = Fxk−1+ Buk+ Γwk, (2.14)
där F är en tillståndsövergångsmodell som verkar på tillståndsvektorn xk−1 , B
är en modell för hur styrsignalssvektorn, uk, påverkar de olika tillstånden, Γ är
en modell för hur systembrus, wk, påverkar de olika tillstånden. wk är av typen
gaussiskt vitt brus och har en fördelning enligt wk ∼ N (0, Qk).
En generell modell för hur mätdata påverkar tillstånden är
zk = H ˆxk+ vk, (2.15)
där zk är observationen av tillstånden xk, H är en modell för hur mätningarna,
ˆxk, påverkar observationen och vk är mätbrus. Mätbruset är av typen gaussiskt
vitt brus och har en fördelning enligt vk ∼ N (0, Rk). Systembruset och mätbruset
är okorrelerade och oberoende av varandra.
2.3.2
Algoritm
Kalmaniltret arbetar i två steg, ett prediktionssteg och ett uppdateringsteg. I prediktionssteget predikteras nästa tillstånd utifrån en given modell och tidigare data. I uppdateringssteget uppdateras prediktionen med mätdata.
2.3.2.1 Prediktion
Nästa tillstånd predikteras enligt ekvation 2.16 samtidigt som nästa kovarians-matris för skattingen, P, predikteras enligt ekvation 2.17. Prediktionerna noteras här med ett subtraktionstecken (-) som exponent på indexet.
xk− = Fxk−1 (2.16)
Pk− = FPk−1FT+ ΓQkΓT (2.17)
2.3.2.2 Uppdatering
Information från en mätning används i detta steg för att korrigera den tidiga-re ptidiga-rediktionen. Kalmanförstärkningen, K, beräknas enligt ekvation 2.18 för att sedan användas till att korrigera prediktionen enligt ekvation 2.19.
Kk = Pk−HT(HPk−HT + Rk)−1 (2.18)
xk = xk−+ Kk(xk−− Hzk) (2.19)
Till sist uppdateras även kovariansmatrisen för skattningen enligt ekvation 2.20.
18 2 Teori
2.3.3
Systemmodell
Till Kalmaniltret behövs en modell som beskriver den bakomliggande dynami-ken för det system som skall skattas. En modell som beskriver ett förlopp som har en konstant hastighet i en dimension ses i ekvation 2.21a - 2.21b.
xk+1= xk+ ˙xk∆t (2.21a)
˙xk+1= ˙xk (2.21b)
där x är position, ˙x är hastighet och ∆t är tidsintervallet mellan samplen k och k+1.
I verkligheten har ett mål väldigt sällan exakt konstant hastighet och därför läg-ges en slumpmässig komponent till som verkar på tillstånden enligt Friedland (1973), den nya systemmodellen ses i ekvation 2.22a - 2.22b.
xk+1= xk+ ˙xk∆t +
1
2Èxk∆t2 (2.22a)
˙xk+1= ˙xk+ Èxk∆t (2.22b)
där Èxkär en slumpmässig acceleration med fördelning enligt Èxk ∼ N (0, σ2Èx). Detta gör att dynamiken för rörelsemodellen kan uttryckas enligt ekvation 2.23 där Èxk
ses som systembrus.
xk+1= Fxk+ Buk+ Γ Èxk (2.23)
Denna ekvation kan förenklas till ekvation 2.24, då insignalsvektorn är okänd och därmed sätts Buk = 0. xk+1 = Fxk+ Γ Èxk, Èxk ∼ N (0, σ2Èx) (2.24) där xk+1 =x˙xk+1 k+1 , F =1 ∆t0 1 och Γ = (∆t)2 2 ∆t
vilket ger att Γ Èxk ∼ N (0, Q) där
Q= Γσ2ÈxΓT = σ2 Èx (∆t)4 4 (∆t) 3 2 (∆t)3 2 (∆t)2 .
3
Mjukvara
Detta kapitel beskriver den programvara av tredje part som har använts under projektet samt den ursprungliga applikationsimplementationen.
3.1
Programvara
Detta avsnitt beskriver den programvara av tredje part som har använts under projektet.
3.1.1
MATLAB
MATLAB är en programvara framtagen av MathWorks som främst används för matematiska beräkningar. MATLAB version 2011b Student Edition har använts vid detta examensarbete och inns gratis att hämta för studenter på LiTH. MATLAB har använts för att veriiera matematiska beräkningar och algoritmer inför implementation i Java.
3.1.2
Eclipse
Eclipse är ett verktyg för mjukvaruutveckling som har stöd för många olika pro-grammeringsspråk. I detta examensarbete har Eclipse använts för att program-mera i LATEXoch Java.
För utveckling av applikationen användes tillägget Android Software Develop-ment Kit, sdk, som inns att hämta på Android Developer Pages (2013).
För test och veriiering av kod användes JUnit 4.0, Beck m.l. (2013) som in-går i Java Development Tools, jdt, och EclEmma 2.2.0, Hoffmann m.l. (2013).
20 3 Mjukvara
JUnitär ett ramverk för att sätta upp tester och EclEmma används för att analy-sera den kodtäckning som testerna har.
3.1.3
arecord
arecordanvänds för ljudinspelning och är en kommandotolksprogramvara för
Linux som använder sig av Advanced Linux Sound Architecture, alsa, ljudkorts-drivrutiner. arecord användes för att spela in referensljud vid frekvenssvarstes-ter.
3.1.4
alsamixer
alsamixer används för att ställa in ljudnivåer och är en
kommandotolkspro-gramvara för Linux som använder sig av alsa ljudkortsdrivrutiner. alsamixer möjliggör equalizing via ett tilläggspaket.
3.1.5
Versionshantering
Både git och svn har använts för versionshantering; svn för central versions-hantering mot i3tex servrar och git för decentraliserad versionsversions-hantering mel-lan projektmedlemmarna.
3.2
Ursprunglig implementation
Detta avsnitt beskriver den ursprungliga implementationen. Först beskrivs algo-ritmen kortfattat och senare behandlas några av stegen djupare.
3.2.1
Algoritm
1. Användaren anger
• antalet cylindrar ncyl, • massa m och
• en förhållande R mellan hastighet v och varvtal Nrför ett varvtal som kommer passeras vid accelerationen
för fordonet som ska testas.
2. En inspelning av motorljudet på det accelererande fordonet görs genom en instans av AudioRecord.
3. Den inspelade sekvensen med längd N skickas vidare för stft-analys. Öv-riga insignaler är samplingsfrekvens fsoch ett hannfönster med längd Nw samt hur stort överlappet mellan tidsstegen i stft-analysen ska vara. Utsig-nalen är ljudsigUtsig-nalens energispektrum.
4. För varje tidssteg letas den frekvens med högst amplitud i ett givet fre-kvensintervall fram och sparas. Innan nästa tidssteg ändras sökgränserna beroende på den funna frekvensen.
3.2 Ursprunglig implementation 21 5. De funna frekvenserna omvandlas till varvtal genom ekvation 2.2 och
map-pas mot det värde som användaren angav för hastighet vid ett visst varvtal. 6. En polynomanpassning på de funna frekvenserna görs för att sedan deri-veras för att få accelerationen över tid. Det linjära sambandet mellan kraft och acceleration i Newtons andra rörelselag multipliceras med hastigheten ger fordonets effekt.
3.2.2
Sökalgoritm för motorvarvtalet
Då det är motorns förbränningsfrekvens fcsom sökes begränsas sökningen starkt till ett rimligt frekvensintervall. Initialt sökområde är ett frekvensintervall som anses vara ett rimligt startområde för en acceleration, till exempel kan motsva-rande frekvenser för motorvarvtal Nrfrån 500 r/min upp till 1500 r/min väljas för den initiala sökningen. I efterföljande steg begränsas sökområdet ytterligare runt den dominanta frekvens som funnits i föregående steg. Förhållandet mellan förbränningsfrekvens och motorvarvtal ges i ekvation 2.2.
• Sökområde steg 1: Nr,min[1] = 500 r/min, Nr,max[1] = 1500 r/min • Sökområde steg n: Nr,min[n] = Nr[n − 1] − 100 r/min, Nr,max[n] = Nr[n − 1] + 200 r/min
Analysen och beräkningen av varvtal utförs för varje steg som stft-algoritmen ger som svar. Resultatet efter att all data har har processerats är en lista med mätpunkter för varvtal givet en tidpunkt.
3.2.3
Beräkning framdrivningseffekt
En polynomanpassning Nr[n] → Nr(t) på listan för varvtal och tidpunkt görs av två anledningar:
• för att kunna rita en ºmjukº hastighetskurva beräknad från polynomet och • för att från en hastighetsfunktion få ut en accelerationsfunktion genom
de-rivering och med hjälp av båda dessa funktioner räkna fram effekten. Om det förutsätts att förhållandet mellan varvtal och hastighet är linjärt; räcker det att skala polynomfunktionen, Nr(t), då den är en ºvarvtal-över-tidº-funktion, genom ekvation 3.1 och ekvation 3.2 för att erhålla en hastighetskurva.
22 3 Mjukvara
Då det är mer intuitivt för användaren att ange hastighet i km/h i stället för m/s skalas även dessa värden om enligt
R = 10
36
v
Nr. (3.2)
Effekten P [W = J/s = N · m/s = kg · m/s · m/s2] beräknas såsom
P(t) = mv(t)a(t) (3.3) där m är fordonets massa i kg som användaren angivit.
Observera att effekten, för användaren, inte presenteras i Watt utan i bhp, vilket kräver en omvandling enligt ekvation 2.3b.
3.2.4
Svagheter med denna algoritm
Då startvillkoren hårdkodats ställer det krav på användaren och hur acceleratio-nen genomförs. Algoritmen är inte heller särskilt robust; om signalen som följes tillfälligt dör ut alternativt om signalen är brusig kan målföljningen snabbt tappa sitt mål och då är det stor risk att den aldrig inner det igen.
4
Android
Källan bakom detta kapitel är Android Developer Pages (2013) och dess undersi-dor om inget annat anges.
Android är ett linuxbaserat operativsystem som ursprungligen utvecklades av Android Inc. och som sedermera köptes upp av Google (Elgin (2005)). Operativ-systemtet är i första hand designat för att användas på mobila enheter såsom mobiltelefoner och surfplattor. Ovanför operativsystemet arbetar Dalvik (aosp, 2013, tech/dalvik). Dalvik är en virtuell maskin som läser in och hanterar pro-gram som körs på applikationsnivå.
Nedan beskrivs det ytligt hur applikationer i Android är uppbyggda samt, mer djupgående, de delar av programmeringsgränssnittet som är av intresse för detta arbete.
4.1
Applikationsstruktur
En androidapplikation är uppbyggd enligt form av designmönstret Model-View-Controller (mvc, (Gamma m.l., 1995, sida 4-6)). I Androids design kan följande översättningar göras:
• Model → Model och Service, • View → Layout och
• Controller → Activity.
Detta är dock en förenkling, då en Activity också agerar som View i vissa fall; men mer om det i avsnitt 4.1.1.1.
24 4 Android MODEL VIEW CONTROLLER USER SEES UPDATES MANIPULATES RESPONDS USES
(a) Generell nomenklatur.
MODEL/SERVICE LAYOUT ACTIVITY USER SEES UPDATES MANIPULATES RESPONDS USES (b) Androids nomenklatur.
Figur 4.1: Flödesschema över hur information färdas i en applikation som implementerar designmönstret mvc.
mvcsärkopplar hur data visualiseras från själva datagenereringen. Detta gör att man kan byta ut det sätt som datan presenteras utan att behöva ändra i hur den tas fram. För att exemplifera detta kan man se en undersökning som en modell och olika diagram (tårt-, stapel- etc.) som visar resultatet för vyer. I igur 4.1 visas hur datalödet sker i mvc.
4.1.1
Resurser
Resurser är ett samlingsnamn för element som kan återanvändas eller föränd-ras beroende på hur applikationen används. Till exempel kan ordlistor för olika språk anges för att applikationen lätt ska kunna lokaliseras. Även bilder av olika storlek och upplösning kan läggas till för att sedan användas beroende av vilken skärmstorlek och upplösning som användarens plattform har. Nedan beskrivs hur en Layout deinieras och vad den måste innehålla.
4.1.1.1 Layout
För att skapa ett graiskt gränssnitt mot användaren deinieras olika element med märkspråket xml. För att inläsningsmotorn av layoutiler ska fungera måste ilen bestå av ett rotelement av typen View (Android api, 2013, View), ViewGroup (Android api, 2013, ViewGroup) eller någon underklass av dessa. ViewGroup är, som namnet antyder, en gruppering av graiska element och i layoutilen kan då ingående element deinieras. View å sin sida är ett enstaka graiskt ele-ment, till exempel ett textavsnitt (TextView). Layoutilerna kompileras och de-inierar därför bara statiska graiska element. För dynamiska element används Activityoch mer om det i avsnitt 4.1.2.1. En enkel deinition av en layout ses i källkod 4.1.1 och det graiska resultatet visas i igur 4.2.
Layoutilerna läses in i två olika steg: först läses javaklasserna in (mörkgröna tag-gar, se rad 20 i källkod 4.1.1) och sedan skickas attribut och dess värden (attribut →ljusgröna element, värden → röda element, se rad 7 i källkod 4.1.1) till klassen
4.1 Applikationsstruktur 25 1 <?xml version="1.0" encoding="UTF-8"?> 2 <RelativeLayout 3 xmlns:android= 4 "http://schemas.android.com/apk/res/android" 5 android:layout_width="fill_parent" 6 android:layout_height="fill_parent"
7 android:orientation="vertical" ><!-- Attribut -->
8 9 <TextView 10 android:id="@+id/splashText1" 11 android:layout_width="wrap_content" 12 android:layout_height="wrap_content" 13 android:layout_alignParentTop="true" 14 android:layout_centerHorizontal="true" 15 android:layout_marginTop="100dp"
16 android:text="Hello World!"
17 android:textAppearance=
18 "?android:attr/textAppearanceLarge" />
19
20 </RelativeLayout><!-- Tagg -->
Källkod 4.1.1: Definition av en layout i xml. En relativ layout specificeras och den innehåller ett textfält med värdet Hello World!.
Figur 4.2: Det grafiska re-sultatet av källkod 4.1.1. Temat (färgsättning) samt den översta delen av re-sultatet definieras i appli-kationens manifest, se av-snitt 4.1.4.
för att behandlas. För att särskilja de attribut som Google har deinierat används namnrymden android och liknande kan göras för egendeinierade attribut. Mer om detta designval förklaras av androidutvecklaren Hackborn (2008).
4.1.2
Activity
En Activity (aktivitet) har till uppgift att behandla om olika händelser som kan påverka vilken samt hur data ska presenteras. Dessa aktiviteter kan initieras av en fysisk användare genom att till exempel trycka på en knapp, men även genom att en aktivitet blir matad med data från automatiska källor såsom sensorer eller datalöden från internet. Att behandla händelser tar sig många former men de kan grovt delas upp i två kategorier:
• händelser som ändrar den data som presenteras för tillfället och • händelser som byter aktivitet.
Vid händelser av det första slaget följer händelseförloppet lödet i igur 4.1b och i andra fallet pausas den aktiva aktiviteten och och läggs på stacken och en ny startas.
En androidapplikation måste ha minst en aktivitet deinierad i sitt manifest, av-snitt 4.1.4. Den aktiviteten som är först deinierad kommer automatiskt köras när applikationen startas.
26 4 Android
En aktivitet är starkt kopplad till en Layout och vanligtvis en eller lera Models.
4.1.2.1 Dynamiska grafikelement
När applikationen kompileras, kompileras även layoutilerna. Detta gör att det inte går att deiniera dynamiska graikelement i dessa iler. Dynamiken i graiken skapas istället genom att man refererar till ett vyelement via dess id och sedan använder sig av gränssnittet för att ändra det.
Ett exempel på när detta används är när antalet element som ska visas inte är känt från början, som vid söktträffar. Då kan man använda ViewGroup och dess gränssnitt för att lägga till underelement.
4.1.3
Service
Serviceär designad för att ta hand om bakgrundsprocesser som inte behöver
hanteras av användaren, men samtidigt är nödvändiga för att applikationen ska fylla sin funktion. Detta kan till exempel vara att upprätthålla en blåtandsupp-koppling eller att ta hand om nedladdningen av en il.
En service är i stort sett samma sak som en aktivitet förutom att den inte har nå-gon layout kopplad till sig. Detta gör att en användare då inte kan kommunicera direkt med en service och det är därför upp till applikationsprogrammeraren att deiniera hur kommunikationen sker.
Android deinierar två typer av livscykler för en service: • Started service (startad service) och
• Bound service (bunden service).
Den första av dessa två kallas av någon (inte nödvändigtvis av sin egen) appli-kation på med startService() och avslutas sedan inte förens en appliappli-kation kallar på servicen med funktionen stopService() eller att servicen själv kallar på stopSelf().
En bunden service startas med funktionen bindService() och avslutas med unbindService(). En sådan service kan bindas samman med lera applikatio-ner samtidigt och avslutas inte förens den sista bindningen upphör.
Det inns klasser (AsyncTask och handlerThread m.l.) som är designade för att hantera bakgrundsprocesser vid androidprogrammering. Det är upp till pro-grammeraren att bedöma vilken av teknikerna som är bäst anpassad för att lösa ett visst problem.
4.1.4
Manifest
Varje applikation måste ha ett manifest. Detta manifest beskriver hur kompila-torn ska agera för just den speciika applikationen. Manifestet kan innehålla in-formation om vilket nivå av api som ska användas, vilket tema som applikatio-nen ska ha och mycket annat.
4.2 Ljudinspelning 27 I källkod 4.1.2 visas hur ett enkelt manifest skrivs. Det går inte att veta exakt vad en applikation gör genom att bara läsa igenom manifestet, men man kan se att applikationen kräver tillåtelse att spela in ljud från ljudkällor. Vanligtvis består en applikation av ett lertal aktiviteter, men denna enkla applikation skulle till exempel kunna vara en diktafon.
Källkod 4.1.2 Ett väldigt kort manifest. Namnet på applikationen inns sparat som en strängresurs och referensen anges på rad 7. Denna applikation begär tillå-telse att spela in ljud från de ljudkällor som inns tillgängliga (rad 4).
1 <?xml version="1.0" encoding="utf-8"?>
2 <!-- . . . visar att fler argument kan definieras. -->
3 <manifest> <!-- . . . -->
4 <uses-permission android:name="android.permission.RECORD_AUDIO" /> <!-- -->
5 <application android:icon="@drawable/app_icon.png" > <!-- . . . -->
6 <activity android:name="com.i3tex.test.ExampleActivity"
7 android:label="@string/application_name" > <!-- . . . -->
8 </activity>
9 <!-- Definition av ytterligare Service eller Activity görs här. -->
10 </application>
11 </manifest>
4.2
Ljudinspelning
Detta avsnitt behandlar både de krav som ställs på en androidplattform samt de delar ur Androids api som är relevanta för ljudinspelning.
4.2.1
Plattformskrav
I Android Compatibility Deinition Document (cdd), (aosp, 2013, Compability), deinieras de krav som ställs på en plattform för att den ska vara kompatibel med Android. Varje större version av Android har sin egen kravspeciikation.
4.2.1.1 Ljudinspelning
För de nivåer på api som behandlas i detta dokument ställs följande krav för ljudinspelning:
When an application has used the android.media.AudioRecord api to start recording an audio stream, device implementations SHOULD sample and record audio with each of these behaviors:
• Noise reduction processing, if present, SHOULD be disabled. • Automatic gain control, if present, SHOULD be disabled. • The device SHOULD exhibit approximately lat amplitude
ver-sus frequency characteristics; speciically, ±3 dB, from 100 Hz to 4000 Hz
• Audio input sensitivity SHOULD be set such that a 90 dB sound power level (spl) source at 1000 Hz yields RMS of 5000 for 16-bit samples.
• pcm amplitude levels SHOULD linearly track input spl changes over at least a 30 dB range from -18 dB to +12 dB re 90 dB spl at the microphone.
28 4 Android
• Total harmonic distortion SHOULD be less than 1% from 100 Hz to 4000 Hz at 90 dB spl input level.
Från och med api 15 lades även följande till:
In addition to the above recording speciications, when an application has started recording an audio stream using the
android.media.MediaRecorder.AudioSource.
VOICE_RECOGNITIONaudio source:
• Noise reduction processing, if present, MUST be disabled. • Automatic gain control, if present, MUST be disabled.
4.2.1.2 Kodning
cddspeciicerar också vilka kodekar som en androidplattform, men
dokumen-tet är något tvetydigt gällande kodning via pcm upp till api 16. Innan dess ges det inte explicit att kodning av inspelat ljud ska kunna ske med pcm, men ett av kraven för ljudinspelning pekar mot det samt att AudioFormat, som är en stödklass till AudioRecord, har en konstant, ENCODING_PCM_16BIT (tillagd i api5), som enligt beskrivningen garanterar att kodning via 16 bitars pcm stöds av alla plattformar.
4.2.2
APIför ljudinspelning
I Androids api deinieras två klasser för inspelning av ljud som båda baseras på lågnivåbiblioteket openSLES 1.0.1 (Khronos Group (2013); Fornwall (2013)):
• MediaRecorder och • AudioRecord.
Dessa två klasser är frikopplade från varandra och delar endast deinitionsklas-sen MediaRecorder.AudioSource som deinierar tillgängliga mikrofonlägen.
4.2.2.1 MediaRecorder
MediaRecorderär en klass som hanterar både ljud- och videoinspelning samt
uppspelning av dessa. Den klarar även av att koda strömmarna i lertalet format i enlighet med cdd.
MediaRecorderär låst till att spela in ljud till en på förhand bestämd il. Detta gör att realtidsanalys av inspelningen omöjliggörs.
4.2.2.2 AudioRecord
AudioRecordskriver data till en buffert och kan även meddela när ett visst antal läsningar från ljudkällan har gjorts. Detta ger en frihet att analysera ljudinspel-ningen medan inspelljudinspel-ningen är i gång. Större krav ställs dock på programmeraren, då det är upp till den att se till att all data hinner hanteras och att inte bufferten lödar över.
Del II
Experiment och framtagning av
ny algoritm
5
Deluppgifter
Då ett antal utredningar kring ursprungsproblemet behövde analyseras innan själva androidimplementationen gjordes kommer dessa presenteras i detta kapi-tel. Efter varje deluppgift drogs ett antal slutsatser och därför kommer de presen-teras med både resultat- och diskussionsdel.
5.1
Karakterisering av androidtelefoners mikrofoner
Då (aosp, 2013, Compability) enbart ställer krav på frekvenssvaret över 100 Hz behövs det utredas om hur detta kunde påverka resten av projektet då förbrän-ningsfrekvensen ligger inom ett intervall av 20 till 400 Hz.
5.1.1
Inledning
För att karaktärisera de mikrofoner som används i dagens androidtelefoner samt för att upptäcka eventuella skillnader mellan de olika inspelningskoniguratio-ner som inns tillgängliga utfördes ett experiment med ett urval av sex olika androidtelefoner. Genom att spela in olika sorters brus på dessa med hjälp av en applikation som spelar in med alla möjliga inspelningskonigurationer som respektive telefon tillåter.
Det frekvensområde som är intressant för denna studie är ca 20 - 400 Hz då en 3-cylindrig motor med ett motorvarvtal på 1000 r/min ger upphov till ett ljud med en förbränningsfrekvens på 25 Hz enligt ekvation 2.2 medan en 8-cylindrig motor med ett motorvarvtal på 6000 r/min ger upphov till en grundfrekvens på 400 Hz.
