Vibrationsmätning med mobiltelefon

(1)

2009:113 CIV

E X A M E N S A R B E T E

Vibrationsmätning med mobiltelefon

Patrik Roslund

Luleå tekniska universitet Civilingenjörsprogrammet

Elektroteknik

Institutionen för Systemteknik Avdelningen för EISLAB

(2)

Luleå University of Technology

Department of Computer Science and Electrical Engineering

E x a m e n s a r b e t e i e l e k t r o t e k n i k

V i b r a t i o n s m ä t n i n g m e d m o b i l t e l e f o n .

Patrik Roslund, patros-2@student.ltu.se

(3)

Abstract

Vibration related problems seems to be noticed more and more these days. Not only in the building industry where a lot of power tools are used, but also in the transport service. A driver that under most of his workday, drives on sometimes very bumpy roads is exposed to harmful vibrations that are not always realised. This master thesis will deal with the developement process of a system that can transfer data from a vibration-meter to a cell phone to analyse and present the measured values.

By using this system it’s easy for the driver to keep track on the risks that he is exposed to during a working day. This should lead to a lower vibration exposure, partly by driving more carefully and in the end this will also benefit eventual passengers.

The result of the developement process lead to a wireless solution to be used as the transmission- method and that a cell phone-application was developed to read, present and save measured data. A prototype has been developed and verified in the environment of a busdriver. This product will be marketed by CVK in a near future.

(4)

Sammanfattning

Vibrationsrelaterade problem tenderar att bli mer och mer uppmärksammade, inte bara inom byggin- dustrin där många handverktyg används, utan även inom transportväsendet. En fordonsförare som under större delen av sin arbetsdag kör på ibland väldigt ojämna vägar, utsätts för skadliga nivåer som man inte alltid tänker på. Detta examensarbete kommer att behandla utvecklingsprocessen för ett system som kan överföra data från en vibrationsmätare till en mobiltelefon för analys och presentation av mätvärden. Genom att använda sig av detta system kan fordonsföraren lättare hålla koll på vad han utsätter sig för under en arbetsdag. Detta torde leda till en lägre vibrationsexponering bland annat genom en försiktigare körning, något som i slutändan kommer att gynna även eventuella passagerare.

Resultatet av utvecklingsprocessen ledde till att en trådlös överföringsmetod användes samt att en mobiltelefonapplikation utvecklades för att kunna läsa av, presentera samt spara mätdata. En prototyp har utvecklats och verifierats i en bussförares arbetsmiljö. Denna produkt kommer CVK att marknadsföra inom en snar framtid.

X7002E ii

(5)

Förord

Arbetet här är gjort under hösten 2008 och våren 2009 vid CVK i Luleå. Projektet i sig har varit väldigt roligt samt lärorikt då det har berört flera olika områden, produktframtagning, programmer- ing, hårdvarudesign, arbetsmiljö med mera.

Jag vill även passa på och rikta ett stort tack till Timmy Kristofferson för bilderna till rapporten, samt Peter Jönsson för ett bra jobb som handledare.

(6)

Innehållsförteckning

1 Bakgrund 1

1.1 Syfte . . . 1

1.2 Mål . . . 1

1.3 Avgränsningar . . . 1

2 Teori 2 2.1 Vibrationer . . . 2

2.1.1 Allmänt . . . 2

2.1.2 A(8)-värde . . . 3

2.1.3 Gränsvärde samt insatsvärde . . . 3

2.2 Java Micro Edition . . . 3

2.2.1 Bakgrund . . . 3

2.2.2 Konfigurationer . . . 4

2.2.3 Profiler . . . 4

2.2.4 Stackar . . . 4

3 Metod 5 3.1 Informationsinsamling . . . 5

3.2 Problemklarläggning . . . 5

3.3 Problemundersökning . . . 5

3.3.1 Produktträd . . . 5

3.3.2 Kravspecifikation . . . 6

3.4 Problemlösning . . . 8

3.5 Implementation av valda koncept . . . 9

4 Genomförande 10 4.1 Generering av lösningsvarianter . . . 10

4.1.1 Brainstorming . . . 10

4.1.2 Litteratursökning . . . 10

4.1.3 Analyser av existerande system . . . 11

4.1.4 Introduktion av funna lösningsvarianter . . . 11

4.2 Utvärdering av lösningsvarianter . . . 13

4.2.1 Variant A: Bluetooth . . . 14

4.2.2 Variant B: IrDA . . . 14

4.2.3 Variant C: WLAN . . . 15

4.2.4 Variant D: Kabel . . . 15

4.2.5 Variant E: GPRS . . . 16

4.2.6 Variant F: FM-sändare . . . 17

4.2.7 Variant G: Minneskort . . . 17

4.3 Beslut av slutgiltigt koncept . . . 18

4.4 Val av modul och utvecklingsmiljöer för slutgiltigt koncept . . . 18

4.4.1 Hårdvara . . . 18

4.4.2 Mjukvara . . . 20

4.5 Hårdvaruimplementation av huvudkoncept . . . 21

4.5.1 Information om vald modul . . . 21

4.5.2 Konfigurering och testning av vald modul . . . 21

4.5.3 Montering av modul . . . 22

4.5.4 Interfacekort . . . 22

4.6 Mjukvaruimplementation av huvudkoncept . . . 23

4.6.1 Princip för att upprätta en klient . . . 23

4.6.2 Princip för avläsning av mätdata . . . 25

4.6.3 Princip för tolkning av antalet lagrade bytes . . . 25

4.6.4 Princip för tolkning av mätdata . . . 26

4.6.5 Beräkning av A(8)-värde . . . 27

X7002E iii

(7)

4.6.6 Lagring och distribuering av tolkad mätdata . . . 28

4.7 Mätning och verifiering av huvudkoncept . . . 28

4.8 Förslag till hårdvaruimplementation av andrakoncept . . . 29

4.8.1 Utförande . . . 29

4.9 Förslag till mjukvaruimplementation av andrakoncept . . . 29

4.9.1 Utförande . . . 29

5 Presentation av lösning 30 5.1 Prototypbilder hårdvara . . . 31

5.2 Prototypbilder mobiltelefonapplikation . . . 32

6 Slutsats och diskussion 35

7 Förslag till framtida åtgärder 35

Referenser 36

Bilaga 1: Vibindicatorns UART-protokoll 37

Bilaga 2: Diagram över mätningar 38

(8)

1 Bakgrund

CVK(Center for vibration comfort), är ett företag i Luleå som tillhandahåller metoder och utrust- ning för att mäta och förebygga skador på människor orsakade av vibrationer. Behovet av detta har ökat avsevärt då det börjar att bli mer och mer uppmärksammat inom arbetsmiljöarbetet på grund av hårdare regler och ett EU-direktiv[6] som kom under 2002. Det är arbetsgivaren som har det yttersta ansvaret att direktivet följs. CVK har olika produkter för att mäta och larma om skadliga vibrationer.

En existerande produkt kallad HealthVib, vilken är en enhet för att mäta upp vibrationer och presentera dess data på en inbyggd display. Det finns också en enhet kallad Vibindicator som mottar och lagrar data utsänt ifrån HealthVib-enheten. De har även en kommande produkt kallad Vibindicator- inseat som är en nerskalad version av Vibindicatorn gjord för massproduktion. Den är avsedd att läsa av värden från en Healtvib-inseat som är en mätenhet som kommer färdigintegrerad med stolen.

Det lagrade datat kan senare överföras till en PC med hjälp av USB och data kan sedan presenteras genom en applikation kallad VibView.

1.1 Syfte

CVK ser här ett potentiellt behov på marknaden samt en möjlighet att ligga steget före sina konkur- renter genom att hitta en lösning där datat ifrån Vibindicator-inseat överförs till en mobiltelefon utan att mellanlagras i en dator. Detta då mobiltelefoner idag är ett lättillgängligt verktyg som de flesta bär på sig dagligen. Mobiltelefonen antas ha de funktionaliteter som en modern mobiltelefon har dvs: Internetuppkoppling, Ir, Bluetooth, minneskort samt datakabel.

1.2 Mål

I detta examensarbete skall ett produktsystem utvecklas och anpassas för CVK’s Vibindicator. Detta är de övergripande målen för projektet.

• Att utveckla ett system för överföring och presentering av vibrationmätresultat i en mobiltelefon.

• Systemet ska kunna överföra data från Vibindicator till en mobiltelefon för enkel avläsning.

I denna produkt bestäms det hur data ska överföras, kan Vibindicator modifieras eller behövs det en ny produkt.

• Produkten kan bestå av två delar, en kommunikationsenhet och en mobiltelefon-applikation.

1.3 Avgränsningar

Projektet kommer att behandla överföring av data till mobiltelefon samt ett interface. Projektet kommer ej att behandla större modifikationer på CVK’s hårdvara och mjukvara som exempelvis att modifiera programkod i befintlig produkt.

X7002E 1

(9)

2 Teori

2.1 Vibrationer

2.1.1 Allmänt

Vibrationer kan beskrivas som oscillerande rörelser avvikande ifrån ett medelvärde. De kan delas in i två huvuddelar, förutsägbara samt slumpmässiga. Detta illustreras i figur 1. De förutsägbara delas in i periodiska och icke periodiska. Periodiska delas sedan upp i sinusformade och multi-sinusformade.

De icke periodiska delas upp i shock och transient. De slumpmässiga delas upp i stationära och icke stationära. De vibrationsexponeringar som är vanligast att bli utsatt för under arbete, transport och fritid oftast är av den slumpmässiga typen. [9]

Graden av vibrationsexponering är beroende av två faktorer, vibrationsnivå samt exponeringstid, där nivån har större inverkan än tiden enligt ekv(2).

Vibration

Slumpmässig Förutsägbar

Periodisk Icke Stationär

Stationär Icke

Periodisk

Sinus- Formad

Multi- Sinus- formad

Stark Stationär

Svag Stationär Transient Shock

Figur 1: Olika typ av vibrationer

Skador som kan uppstå vid en exponering av helkroppsvibrationer delas upp i övergående besvär samt bestående skador. Bland de övergående besvären kan nämnas fysisk och eller psykisk trötthet.

Detta kan leda till en nedsatt prestationsförmåga vilket kan leda till olycksfall. Bland de bestående skadorna är det främst ryggproblem som är dominerande enligt[15], men även skulder och nack- problem är förekommande [10].

(10)

2.1.2 A(8)-värde

Arbetsmiljöverket specificerar i [1] att exponeringen av helkroppsvibrationer för en arbetsdag ska beräknas som den frekvensvägda accelerationen, Amaxför den dominanta riktningen med avseende på en åttatimmarsperiod. Om den arbetade tiden skiljer sig ifrån åtta timmar kan exponeringen upp- skattas enligt följande:

A(8)= Amax

pT /8 (1)

Om man under en arbetsdag arbetar med olika maskiner så är det möjligt att summera exponerings- bidragen på följande vis:

A(8)= vt

1 8

n

X

i=1

a²_i· Ti (2)

2.1.3 Gränsvärde samt insatsvärde

Om insatsvärdet, tabell 1 överskrids så måste arbetsgivaren utreda orsakerna samt vidta tekniska eller organisatoriska åtgärder så att riskerna minimeras. Gränsvärdet i tabell 2 får ej överskridas, om detta sker så måste arbetsgivaren enligt [1] :

- Vidta omedelbara åtgärder för att minska vibrationsexponeringen så att den ligger under det överskridna gränsvärdet,

- utreda orsakerna till att gränsvärdet överskridits och

- vidta sådana åtgärder att gränsvärdena inte överskrids i fortsättningen.

Tabell 1: Insatsvärden Hand och armvibrationer 2.5m/s² Helkroppsvibrationer 0.5m/s²

Tabell 2: Gränsvärden Hand och armvibrationer 5.0m/s² Helkroppsvibrationer 1.1m/s²

Detta leder till att A(8)-värdet är det relevanta värdet att ta fram. Då detta värde ej lagras i Vibindi- catorn så måste flashminnet på Vibindicatorn läsas ut. A(8)-värdet beräknas sedan baserat på dessa värden.

2.2 Java Micro Edition

2.2.1 Bakgrund

Java ME, förut benämd som J2ME bygger på en optimerad Java Runtime Envirorment gjord för att kunna köras på små batteridrivna enheter med begränsat minne och liten display. Det skapades av

X7002E 3

(11)

Sun microsystems och år 2006 blev källkoden licensierad under GNU General Public Licence. En Java ME-implementation består av en konfiguration, en eller flera profiler samt eventuella tillägs- API’er(Application programming interface).

2.2.2 Konfigurationer

Två olika konfigurationer finns, CLDC(Connected Limited Device Configuration) samt CDC(Connected Device Configuration). CLDC-konfigurationen är den som används i mobiltelefoner medan CDC an- vänds i större apparatur exempelvis PDA’er [14].

2.2.3 Profiler

För att kunna erbjuda en fullständig körmiljö för applikationer så måste en konfiguration komplet- teras med ett antal högnivå-API’er, så kallade profiler som mera ingående specificerar användarinter- face och kommunikationsmöjligheter. MIDP(Mobile Information Device Profile) kallas den profilen som används i mobiltelefoner. API’er som är intressanta för projektet är bland annat JSR-75(åtkomst till telefonens filsystem) och JSR-120(wireless messaging).

2.2.4 Stackar

Kombinationen av konfigurationer, profiler och tilläggs-API’er är ofta kallade för stack.

• MIDP 1.0-stacken, består av MIDP 1.0-profilen samt konfigurationen CLDC 1.0.

• JTWI-stacken, består av MIDP 2.0-profilen, konfigurationen CLDC 1.1 eller 1.0 samt JSR- 120 och JSR-135(multimedia-stöd). JSR-135 är valfri att inkludera medan JSR-120 är nöd- vändig.

• MSA-stacken, innehåller ett stort antal API’er som ej genomgås närmare då det ej är relevant för projektet.

Det som kommer att användas i projektet blir JTWI-stacken med lämpliga tilläggs-API’er, då MIDP 1.0 är alltför begränsad då den endast ger tillgång till CLDC 1.0. CLDC 1.0 stödjer ej flyttals- beräkningar vilket är nödvändigt för projektet. MSA-stacken är åt andra sidan onödigt stor.

(12)

3 Metod

3.1 Informationsinsamling

En stor tyngdvikt läggs i början på projektet för att skapa en förståelse för företagets produkter och deras grundläggande produktkoncept. Deras PC-programvara analyseras för att ta reda på hur den är uppbyggd. Samtal hålls med personer som utvecklat elektroniken och mjukvaran för att utreda grundläggande saker, såsom protokoll för dataöverföring och lagring, samt vad som eventuellt be- höver modiferas för att projektet skall kunna genomföras. Det beslutas att ett prototypkort produceras där åtkomst till UART(Universal Asynchronous Receiver Transmitter) in och ut möjliggörs samt att kortet programmeras så att åtkomst finns till läskommandon för att läsa ut hela dataminnet.

3.2 Problemklarläggning

För att snabbt komma igång med utvecklingsarbetet är det viktigt att i ett tidigt stadium specificera vad uppgiften består av och vilka problem som måste överkommas. Problemet består i att hitta den hårdvarulösning som är mest lämplig utifrån krav och önskemål, för uppgiften i att fungera som kommunikationsenhet samt att designa mjukvara till mobiltelefonen för ett lättanvänt användarinter- face.

3.3 Problemundersökning

Viktiga punkter är exempelvis hur mycket utrymme som står till förfogande för elektroniken, mat- ningsspänning, strömförbrukning. Ett produktträd upprättas för att enklare visualisera produktens uppbyggnad och delar. En kravspecifikation upprättas sedan med önskemål och krav som företaget har på produkten.

3.3.1 Produktträd

Ett produktträd upprättas för att de ingående delarna ska kunna visualiseras på ett överskådligare sätt och för att problemet enklare ska kunna brytas ner i beståndsdelar. Produktträdet kommer att förenkla det senare arbetet med att ta fram kravspecifikationen.

X7002E 5

(13)

Email

Mobiltelefon

SMS Användar-interface Kommunikation

Kommunikationsenhet

Java ME Vibindicator

Figur 2: Produktträd

I figur 2 så ser vi produktträdet med dess ingående delar, där Java ME är navet som knyter ihop användarinterfacet med kommunikationsdelarna.

3.3.2 Kravspecifikation

En kravspecifikation upprättas vilken innehåller krav och önskemål på produkten. Kriterierna för krav och önskemål tas fram genom dialog med företaget.

(14)

Tabell 3: Krav på kommunikationsenhet och mobiltelefonapplikation Kommunikationsenhet Krav

Överföringskapacitet Skall kunna överföra mätdata från Vibindicator - inSeat för 30 dagar.

Räckvidd Minst en meters räckvidd mellan sändare och mottagare.

Mobiltelefonapplikation Krav

Lagring av data Skall kunna lagra: tid + A(8)-värde + period- värde för en dag från Vibindicator -inSeat.

Handhavande Användarvänlig, skall kunna installeras och an- vändas av de flesta mobiltelefon-användare.

Presentation av data Skall kunna presentera lagrad data för en dag från Vibindicator -inSeat.

I tabell 3 så specificeras kraven som ställs på produkten.

X7002E 7

(15)

Tabell 4: Önskemål på kommunikationsenheten och mobiltelefonapplikationen.

Kommunikationsenhet Önskemål

Drifttid Inte påverka drifttiden avsevärt mycket, nu- varande drifttid ligger på cirka 16h.

Montering

• Vara möjlig att byggas in innanför inkap- slingen av Vibindicator -inseat, borrning av entuella hål som behövs är däremot tillåtet.

• Enkel att modifiera, ansluta till befintlig produkt.

Ekonomi

• En låg tillverkningskostnad är att föredra.

Kommunikation

• Att kunna sända data globalt.

• Att kunna överföra 2 × 4 × 3600st värden från Vibindicator standard.

• Att kunna använda ihop med en PDA samt olika mobiltelefoner.

Driftspänning Att vara möjlig att använda vid en driftspänning av 3.3V.

Strömbegränsning Att ej behöva mer ström än 260mA.

Mobiltelefonapplikation Önskemål Kommunikation

• Att kunna överföra lagrad data till en annan enhet exempelvis mobiltelefon eller dator med hjälp av SMS eller MMS.

• Att kunna överföra lagrad data till en annan enhet exempelvis mobiltelefon eller dator med hjälp av GPRS.

Handhavande Vara lätt att använda och installera.

Presentering av data

• Presentering av data på ett bra sätt.

• Presentering av lagrad data från Vibindica- tor standard 2 × 4 × 3600.

• Presentering av lagrad data från Vibindica- tor -inseat för 30 dagar.

• Presentering av data i realtid(låg prioritet).

Tabell 4 visar de specificerade önskemålen som ställs på produkten.

3.4 Problemlösning

Lösningar till problemen söks med hjälp idégenerering i form av samtal med experter och upp- dragsgivare, analyser av existerande system, samt litteraturstudier. En brainstormingsession genom- förs även. Ambitionen är att ha så många idéer som möjligt för att sedan kunna gå vidare med de mest lämpade. De olika potentiella lösningarna genomgås, samt att de lösningar som verkar direkt olämpliga utesluts. De kvarvarande lösningarna utvärderas ytterligare en gång och en eller flera lös- ningar väljs ut som slutgiltigt konceptval. En lämplig enhet väljs ut för implementationen av det slutgiltiga konceptvalet. Valet av denna enhet baseras på en undersöknng, de primära urvalskriterier-

(16)

na är lågt pris och liten storlek. Det som behövs i systemet är alltså en fysiskt liten enhet som även är prisvärd samt en passande utvecklingsmiljö. Det är även nödvändigt att hitta en lämplig utveck- lingsmiljö för mobiltelefonapplikationen samt en lämplig mobiltelefon.

3.5 Implementation av valda koncept

Hårdvaru och mjukvaruprototyper implementeras för de valda koncepten. Hårdvaran består av en kommunikationsenhet och mjukvaran av en mobiltelefonapplikation. Kommunikationsenhetenheten integreras med Vibindicatorn. Den underliggande tekniken för kommunikationsenheten är beroende av vilket koncept som väljs i utvärderingarna. Grundläggande tester och mätningar utförs för att fastställa enhetens funktionalitet. Kommunikationsenheten konfigureras sedan så att den blir kompatibel med Vibindicatorns UART-port och ansluts sedan till den. Mjukvaruprototypen kommer att implementeras i Java ME. Stacken som kommer att användas är JTWI-stacken då MIDP 1.0-stacken endast ger tillgång till CLDC 1.0. CLDC 1.0 stödjer ej flyttalsberäkningar vilket är nödvändigt för projektet. Utformningen av denna mjukvaruprototyp kommer att vara beroende på vilket koncept som väljs ut som överföringsenhet. En kommunikationslinje upprättas mellan mobiltelefonapplikationen och kommunikationsenheten. Efter det så används läskommandon från tabell 24 till att läsa ur nödvändig information från Vibindicatorn. Baserat på detta utförs sedan de beräkningar som be- hövs för A(8)-värdet varav sedan detta presenteras för användaren. Mätningar utförs för att verifiera korrektheten i de utförda beräkningarna.

X7002E 9

(17)

4 Genomförande

4.1 Generering av lösningsvarianter

Olika strategier används för att finna potentiella lösningar. Ambitionen är att ha så många ideer som möjligt för att sedan kunna rangordna dem efter dess lämplighet. De olika lösningarna är sedan kom- binerade till olika koncept.

Detta är de strategier som kommer att användas.

• Brainstorming.

• Litteratursökning.

• Analyser av existerande system.

4.1.1 Brainstorming

För att få en större lösningsbredd hölls en brainstorming-session den 20/9 2008. Riktlinjer för detta beskrivs på ett ingående sätt i [2]. Gruppen bestod av ett antal ekonomistudenter. De har normal mobiltelefonvana men är ej så insatta i den underliggande tekniken. Detta anses positivt då de istället för att se problem så kan de se möjligheter. Gruppen introduceras till produkterna och det faktiska problemet. Under cirka 45 minuter så försökte de att ta fram olika lösningsideer, då någon fick en ide så försökte man få denna person att utveckla sin ide ytterligare.

Detta är de förslag som framkom under brainstormingsessionen.

• Bluetooth: Detta var den första spontana iden som uppkom.Troligtvis därför att detta är en teknik som många använder dagligen för till exempel headset, filöverföring med mera.

• IrDA: Någon i gruppen nämde att IR kan man använda för filöverföringar.

• Dockningstation/Kabel: En ide uppstod att man kunde kanske använda sig av mobiltelefonens ordinarie datakabel för att överföra datat. Det optimala vore här att datat överföres automatiskt då mobiltelefonen kopplas till dockningsstationen eller kabeln.

• GPRS/GSM: Diskussioner angående att använda sig av det ordinarie mobiltelefonnätet såsom GSM eller GPRS.

• WI-FI: Möjligheten diskuterades att använda sig av WI-FI(WLAN) för dataöverföringen.

Deltagarna ansåg själva att en lösning med antingen en dockningsstation eller via Bluetooth vore att föredra då detta är metoder som de själva har användarvana av.

4.1.2 Litteratursökning

Ett antal gamla examensarbeten, böcker samt internetpublikationer inom liknande områden genomgås för att hitta inspiration till flera lösningar samt för att samla fakta till de redan funna lösningarna.

(18)

4.1.3 Analyser av existerande system

Lösningsmetoden som används i ett examensarbete som består i att överföra data från en RFID-läsare till en mobiltelefon [21] genomgås, då den verkar riktigt intressant. Några simuleringar utförs i P- spice i syfte att undersöka kretsens beteende samt att personen som skrivit examensarbetet kontaktas via email för diverse frågor.

4.1.4 Introduktion av funna lösningsvarianter

Här visas en summering av de framtagna lösningsvarianterna.

• A) Bluetooth

• B) IrDA

• C) WLAN

• D) Kabel

• E) GPRS

• F) FM-sändare

• G) Minneskort

Variant A: Bluetooth

Användningsområde

Bluetooth’s grundläggande ide är att kunna ersätta kablar mellan olika utrustningar. De flesta tillverkare idag bygger in detta i sina mobiltelefoner. Detta är en teknik som fokuserar på låg kostnad, kort räck- vidd och låg effekt.

Teknik

Bluetooth är en standard för kommunikation mellan enheter. Bakom denna standard finns företagen IBM, Toshiba, Intel, Nokia och Ericsson, men den har sin grund i Ericsson Mobile Communications där utvecklingsarbetet av Bluetooth startade under 90-talet [5]. Bluetooth använder sig av radiosig- naler inom 2.4GHz-bandet för kommunikation [3]. En bluetoothenhet innehåller en sändare och en mottagare som har möjlighet att söka efter andra enheter i området och sedan ansluta sig mot dessa.

Olika bluetoothenheter stödjer olika profiler berende vad de ska användas till. Det som är viktigt att tänka på är att båda enheterna måste ha stöd för profilen som ska användas. Alla enheter måste däremot ha stöd för två profiler: Generic Access Profile samt Service Discovery Application Profile [4]. Den mest intressanta profilen för projektets syfte är Serial Port Profile som emulerar en virtuell serieport över bluetoothuppkopplingen.

X7002E 11

(19)

• Klass 1= 100mW, 20dBm

• Klass 2= 2.5mW, 4dBm

• Klass 3= 1mW, 0dBm

Det finns tre olika effektklasser[5], den klass som är vanligast använd i mobiltelefoner är klass 2 som ger ungefär 10m räckvidd.

Variant B: IrDA

Användningsområde

IrDA används till att skicka information mellan enheter över korta avstånd, vanligtvis någon meter.

Detta är en prisvärd teknik, men andra tekniker börjar numera att ta över mer och mer på marknaden.

Teknik

IrDA[22] är en teknik som bygger på att information skickas via infrarött ljus. Sändaren använder sig av en IR-diod som slås av och på för att modulera data. Mottagaren använder sig av en fotodiod för att omvandla ir-signalen till en strömsignal. Filter används för att kunna filtrera bort omodulerat ir-ljus så att störningar från lysrör och annat kan förebyggas. Det krävs att det är fri sikt emellan enheterna, regn eller damm i luften kan störa överföringen.

Variant C: WLAN

Användningsområde

WLAN används främst för att via en dator ansluta sig mot en accesspunkt för att få en internetuppkoppling. Det har på senare tid blivit allt vanligare att integrera WLAN även i mobiltelefoner. Det som är intressant för projektets syfte är att kunna upprätta en uppkoppling utan en accesspunkt, en så kallad AD-HOC-uppkoppling, där en dator kan kopplas mot en dator, en mobiltelefon mot en annan mobiltelefon eller en mobiltelefon mot en Vibindicator med integrerad WLAN-modul.

Teknik

WLAN är en radiobaserad teknik som definieras genom olika standarder. Standardiseringsorgansi- sationen IEEE har tagit fram ett antal standarder för WLAN under namnet IEEE 802.11 [12].

• IEEE802.11a-5.725GHz till 5.850GHz, maximal hastighet 54Mbps.

• IEEE802.11b-2.4GHz till 2.4835GHz, maximal hastighet 11Mbps.

• IEEE802.11g-2.4GHzbandet maximal hastighet 54Mbps, bakåtkompatibel med 802.11.b.

Variant D: Kabel

Användningsområde

Denna variant bygger på kabeln som brukar skickas med då man köper en ny mobiltelefon. Den kan

(20)

sedan användas för att överföra exempelvis bilder eller kontakter mellan mobiltelefonen och datorn.

Teknik

Olika mobiltelefontillverkare använder sig av olika standarder för överföringen. Förut användes ofta standarden RS232 för överföringen, men numera använder sig de flesta av någon slags USB-baserad lösning då detta möjliggör högre överföringshastigheter. Detta innebär dock problem för projektet då USB baseras på att man har en host som flera olika tillbehör kan ansluta sig emot. Problemet blir då här att i projektet vill vi rationalisera bort datorn(som fungerar som host). Mobiltelefonen själv klassas som ett tillbehör.

Variant E: GPRS

Användningsområde

GPRS används exempelvis för att ansluta sig till Internet för att kunna tex läsa email i mobiltelefonen.

Teknik

Stöd för GPRS var möjligt i Sverige under 2002. Den stora fördelen med GPRS är att man kan vara ständigt uppkopplad mot Internet. Datat skickas i paket och man betalar endast då ett utbyte av data skes till skillnad mot ren GSM som arbetar med kretskoppling där betalning sker för uppkopplad tid [8].

Variant F: FM-sändare

Användningsområde

Tekniken har under lång tid används för utsändning av rundradio men har på senare tid blivit populär att använda för att överföra musik från exempelvis en MP3-spelare till en bilstereo.

Teknik

Ett radiobaserat system där informationen läggs in genom att bärvågen på signalen frekvensmoduleras[7].

Variant G: Minneskort

Användningsområde

En kortläsare används som ett interface för att kunna kommunicera mot ett minneskort. På minneskortet kan sedan bilder och annan media lagras. Behovet av minneskort i mobiltelefoner uppstod då det blev populärt att börja integrera digitalkameror och dylikt.

Teknik

Olika mobiltelefontillverkare använder sig av olika slags minneskort. Exempelvis använder sig Sony Ericsson av kort kallade Memory Stick, Nokia använder olika typer av SD-kort samt MMC-kort.

4.2 Utvärdering av lösningsvarianter

Lösningsvarianterna är först utvärderade så att olämpliga metoder kan uteslutas i ett tidigt skede.

De viktigaste kriterierna är A-D, ett minus på något av dessa kriterier leder till att lösningsvarianten

X7002E 13

(21)

elimineras.

4.2.1 Variant A: Bluetooth Kompabilitet

Ja, denna lösning är kompatibel med de övergripande målen.

Uppfyllande av kravspecifikationen

Det enda kriterium som ej uppfylls helt är att kunna skicka data globalt. Detta går dock att lösa då telefonens funktioner för detta kan nyttjas. Då alla krav är uppfyllda samt de flesta önskemålen så beslutar vi att förslaget uppfyller kravspecifikationen.

Möjlig att implementera

Ja, en bluetoothenhet integreras till Vibindicatorn.

Rimlig kostnad

Ja, för att implementera denna lösning krävs det att man investerar i ett uvecklings-kit samt en bluetooth-enhet. Sedan kanske även en billig mikrokontroller som får agera som brygga mellan Vibindicatorns processor och bluetooth-enheten beroende på vilken bluetooth-enhet som används.

Tabell 5: Sammanställning variant A

A B C D E

Kompabilitet Krav-spec Implementering Rimlig kostnad Erforderlig info Beslut

+ + + (+) + +

Beslut: Ja detta är en lösning som uppfyller kraven och är möjlig att realiseras inom en rimlig kostnad.

Anmärkning:Telefonen måste stödja JSR82-API.

4.2.2 Variant B: IrDA Kompabilitet

Uppfyllande av kravspecifikationen:

Räckviddskravet på minst 1m uppnås precis på gränsen i denna lösning. Önskemålet att enheten ska kunna användas till flera olika telefoner begränsas i och med att tillverkarna börjar föredra att stoppa in bluetooth i sina telefoner i stället för Ir. SonyEricsson listar exempelvis på sin hemsida den 30/9 2008 [18] sina sex populäraste telefoner, av de sex så har endast två stycken inbyggdt stöd för IR.

Har försökt att finna liknande information från nokia.

Tabell 6: SonyEricsson med IR

Modell W980 C902 C702 W760i G900 W890i

Stöd för IR Ja Ja Nej Nej Nej Nej

Ja, en UART till IrDA-konverterare används tillsammans med en kombinerad sändare mottagare för

(22)

IR. Dessa finns att köpa i modulform.

Rimlig kostnad

Ja, detta är en prisvärd lösning.

Tabell 7: Sammanställning variant B

A B C D E

(+) (+) + + + +

Beslut: En klen lösning då räckvidden är så pass begränsad samt att lösningen ej är tillräcklig generell då många mobiltelefoner numera saknar inbyggd IrDA. Frågan är om detta kan vägas upp mot prisvärdheten hos IrDA. Lösningen får vara kvar för vidare utvärdering.

4.2.3 Variant C: WLAN Kompabilitet

Uppfyllande av kravspecifikationen:

Drar mycket ström, går ej använda till de flesta telefoner.

Ja, en WLAN-modul integreras med Vibindicatorn.

Rimlig kostnad Ja.

Tabell 8: Sammanställning variant C

A B C D E

+ (+) + (+) ? +

Beslut: Denna lösning kräver ca 250mA under drift, så Vibindicatorn ligger precis på gränsen för att kunna strömförsörja en WLAN-enhet. Den måste troligtvis modiferas med kraftigare spänningregu- latorer vilket innebär en viss omkostnad. De flesta telefoner stödjer i nuläget inte WLAN så den är heller ej särskilt generell. Den får vara kvar för ytterligare utvärdering.

4.2.4 Variant D: Kabel Kompabilitet

Det enda kriterium som ej uppfylls helt är att kunna skicka data globalt. Detta går dock att lösa då telefonens funktioner för detta kan nyttjas. Då alla krav är uppfyllda samt de flesta önskemålen så beslutar vi att förslaget uppfyller kravspecifikationen.

X7002E 15

(23)

Ja, ett interface måste konstrueras för att konvertera från telefon till UART. Sedan måste de korrekta handskakningarna enligt [21] mjukvaruimplementeras i en mikrokontroller. Sedan så kan man up- prätta en Vibindicator till telefon uppkoppling via kabel. Om detta fungerar tillfredsställande så kan lösningen expanderas till trådlöst genom att kabeln ersätts med valfri prisvärd trådlös teknik.

Rimlig kostnad Ja.

Tabell 9: Sammanställning variant D

A B C D E

(+) + + + - +

Beslut: En billig lösning som ändå är relativt generell samtidigt som den möter de flesta önskemålen.

Den får vara kvar för ytterligare utvärdering.

Anmärkning:Måste ha tillgång till protokollen och handskakningarna som är använda av mobiltele- fontillverkarna för att sätta upp en kommunikationslinje. Oftast så använder de sig av slutna protokoll för detta.

4.2.5 Variant E: GPRS Kompabilitet

Strömförbrukningen blir relativt hög, Vibindicatorn kanske måste modifieras för att klara av detta.

Kapslingen på Vibindicatorn måste eventellt modifieras med anslutning för antenn

Ja, en GPRS-modul integreras inuti Vibindcatorn.

Rimlig kostnad Ja

Tabell 10: Sammanställning variant E

A B C D E

+ + + (+) ? +

Beslut: En nackdel är att all information som skickas via GPRS-enheten kommer att kosta oavsett om man befinner sig på en meters avstånd eller på 1 mils avstånd. GPRS har däremot den stora förde- len av att kunna kommunicera globalt utan behovet av att bli vidarelänkad av en telefon i närheten.

GPRS får vara kvar för ytterligare utvärdering men den känns som en lite overkill-lösning.

(24)

4.2.6 Variant F: FM-sändare Kompabilitet:

Uppfyller kravspecifikationen Ja.

En fmsändare integreras i Vibindicatorn, sänder signal till telefonens inbyggda fm-mottagare. Det största problemet är mjukvaruimplementeringen i telefonen där det krävs att java ska ha hårdvarustöd för att få access till telefonens fm-mottagre.

Rimlig kostnad Ja.

Tabell 11: Sammanställning variant F

A B C D E

(+) + - ? ? -

Beslut: Detta beslut elimineras då väldigt få telefoner i nuläget har stöd för att implementera denna typ av lösning.

Anmärkning:Telefonen måste stödja JSR135. Även om en telefon har stöd för detta API så innebär ej detta att telefonen måste ha stöd för hela API’t i detta fall det för streamad radio.

4.2.7 Variant G: Minneskort Kompabilitet

Kapslingen på Vibindicatorn måste modifieras med en öppning för kortläsaren.

Ja, en kortläsare byggs in i Vibindicatorn samt en mikrokontroller som sköter om läsning och skrivning till minneskortet.

Rimlig kostnad Ja.

Tabell 12: Sammanställning variant G

A B C D E

(+) + + + - +

Beslut: Olika telefontilllverkare har olika minneskort i sina produkter vilket ger vissa kompabilitet- sproblem. Vi har även ett liknande problem med slutna protokoll som i variant D för skrivning

X7002E 17

(25)

och läsning av minneskorten. Det krävs ganska mycket samverkan ifrån användaren. Lite av en lo- techlösning. Denna lösningsvariant får vara kvar för ytterligare utvärdering.

Anmärkning:Om denna lösning ej används för själva dataöverföringen så finns det en stor potential i att använda detta system för att distribuera telefonapplikationen. Det enda som kunden behöver göra är i princip att stoppa in minneskortet i sin telefon och välja "Vill du installera detta program eller inte?"

4.3 Beslut av slutgiltigt koncept

De lösningsvarianter som nu finns kvar måste utvärderas ytterligare. Det som måste göras först är att identifiera urvalskriterierna. Kriterierna baseras i första hand på kravspecifikationen. Lösningsvari- anterna ges betyget 1-4 där 4 är mycket bra och 1 är mycket dåligt, beroende på hur bra de uppfyller det aktuella kriteriet.

Tabell 13: Slutgiltig utvärdering

A B C D E G

Nr Kriterium: Vikt BT IR WLAN DS GPRS KORT

Funktion (1) Lämplighet för syftet

1 4 3 2 2 4 2

(2) Uppfyller olika länders krav

1 4 4 3 4 4 4

(3) Låg komplexitet 1 2 4 2 4 2 4

Arbetsprincip (4) Driftsäker 1 3 3 3 4 3 4

(5) Frånvaro av Ad- hoclösning

1 4 4 4 1 4 1

Embody (6) Påverkan av

produktens utseende

1 4 3 4 3 2(a) 3

Produktion (7) Inga extra mo- ment mhp kapsling

1 4 2 4 2 2 1

(8) Inga extra mo- ment mhp elek- tronik

1 3 3 2 3 2 3

Assemblering (9) Enhetens ihop- sättning

1 4 3 4 4 2 3

Summering 32 29 28 27 25 25

Beslut Utvärderingen resulterade i att sätta fokus på koncept A som ett första alternativ då det fick bäst värden, men att ändå försöka att hinna med en utvärdering av koncept E då det trots utvärderingen är ett intressant koncept.

(a) En yttre antenn måste kopplas till vibindicatorn.

4.4 Val av modul och utvecklingsmiljöer för slutgiltigt koncept

4.4.1 Hårdvara Alternativ A

En tillverkare vars moduler finns tillgängliga hos en svensk återförsäljare. De har en ytmonterad

(26)

modul som verkar intressant. Den har en inbyggd Bluetoothstack som stödjer SPP(Serial Port Pro- file) och har den fysiska storleken 45.0 × 20.0 × 2.0 mm. Den är lite lång men den går in i kapslingen.

Fördelar

Lätt att löda manuellt.

Nackdelar Ej så prisvärd.

Alternativ B

En tillverkare vars produkter finns tillgängliga hos en svensk återförsäljare. De har en modul som verkar intressant. Den har en inbyggd Bluetoothstack som stödjer SPP och har den fysiska storleken 18.0 × 20.0 × 11.7 mm. Problemet här är höjden.

Fördelar

Lätt att löda manuellt.

Nackdelar

Ryms ej omodifierad i kapsel pga dess stiftlist.

Ej så prisvärd.

Alternativ C

En tillverkare av bluetooth-moduler som finns tillgänglig hos en svensk återförsäljare har en modul som verkar intressant. Den har en inbyggd Bluetoothstack som stödjer SPP och har den fysiska storleken: 28.5 × 15.2 × 2.1 mm och väger 1.2g. Den verkar väldigt lovande pga dess låga pris samt den fysiska storleken.

Fördelar Liten Prisvärd

Har både kompakta moduler samt OEM(Original Equipment Manufacturer)-moduler med stiftlist.

Avsedd för maskinlödning.

Nackdelar

Svår att löda manuellt.

Alternativ D

En tillverkare av bluetooth-moduler som finns tillgängligt hos en svensk återförsäljare har en modul som verkar intressant. Den har en inbyggd Bluetoothstack som stödjer SPP och har den fysiska storleken: 24.0 × 13.0 × 2.1 mm och väger 1.2g. Den verkar väldigt lovande pga dess låga pris samt den fysiska storleken.

Fördelar Liten Prisvärd

Avsedd för maskinlödning.

Nackdelar

Svår att löda manuellt

Finns ej tillgänglig som OEM-modul.

X7002E 19

(27)

Finns ej tillgänglig i produktionsvolym.

Ny produkt vilket kan innebära diverse buggar.

Tabell 14: Sammanställning av moduler

Alternativ Fysisk storlek Montering Prisbild

A 45.0 × 20.0 × 2.0 mm avsedd för ytmontering 2X

B 18.0 × 20.0 × 11.7 mm stiftlist redan monterad 2X C 28.5 × 15.2 × 2.1 mm avsedd för maskinlödning X D 24.0 × 13.0 × 2.1 mm avsedd för maskinlödning X

Beslut: Då alternativ C är prisvärt, storleken blir väldigt liten samt att det är en modul som funnits på marknaden ett tag så väljs detta ut som det starkaste alternativet.

Alternativa utvecklingsverktyg för den valda modulen.

• A) Tillverkarens egna utvecklingskit.

• B) Implementering av ett mera avskalat interface.

• C) Implementering av ett avskalat interface genom att utöka en simpel modul.

Tabell 15: Sammanställning av utvecklingsverktyg Alternativ Tidsåtgång Prisbild

A Liten 2X

B Stor X

C Mellan X

Beslut: Alternativ A väljs där utvecklingsverktygen beställs från den valda modul-tillverkaren. Detta ger en kortare tid att komma igång med själva produkt-utvecklingen. Om tid finns så kommer även alternativ B att användas.

4.4.2 Mjukvara

Det finns lite olika alternativ att välja för utvecklingsmiljön. Det går exempelvis att använda en kom- plett IDE(Integrated Developement Envirorment) såsom Netbeans Mobility, eller en kompilator med separat editor. Här valdes det senare alternativet då det tar mindre resurser utav utvecklingsdatorn.

Valet av kompilator föll på Wireless Toolkit 2.5.2[19], vilken är fritt tillgänglig från Sun. Som editor valdes SuperEdi version 4.1.3.U[20] vilken är en freeware programvara som har det som behövs, dvs den visar reserverade ord samt radnummer, vilket underlättar felsökning vid enentuella kompi- leringsfel. Mobiltelefonen som väljs ut är en SonyEricsson W660. Orsaken till detta är att det är en telefon som prismässigt ligger i mellanklassen, det viktiga är att den stödjer Bluetoothprotokollet JSR-82. En USB-dongel för bluetooth används vid överföringen av den kompilerade Javakoden till mobiltelefonen. Andra alternativ vore att föra över den med en datakabel, ett minneskort eller att programmet helt enkelt läggs upp på en websida för nerladdning.

(28)

4.5 Hårdvaruimplementation av huvudkoncept

4.5.1 Information om vald modul

Modulen använder sig av en programvara kallad Wireless UART som fungerar likadant som SPP, dvs att en kommunikationslinje upprättas i form utav en emulerad seriekabel över bluetooth-uppkopplingen.

Den är konfigurerbar mellan alla tre effektklasserna. Den är konfigurerad med en default sändeffekt på 4dBm och en max sändeffekt på 8 dBm så effektmässigt så ligger den väl mer som klass 1 än klass 2. Detta är en rimlig effekt att använda då man trots allt är begränsad av telefonens räckvidd som brukar vara på cirka 10 meter.

4.5.2 Konfigurering och testning av vald modul

Modulen testas först och främst emot det medföljande utvecklingskortet för att man ska kunna få en uppfattning om hur den fungerar och beter sig i olika lägen. Så länge som ingen bluetoothuppkoppling är upprättad så är det möjligt att konfigurera modulen via dess serieinterface. Följande inställningar används för konfigurationsläget och går ej att ändra på.

Tabell 16: Värden för konfigurationsläget Parameter Default värde Baudrate 38400

Parity None

Databits 8 Stopbits 1 Flowcontrol On

Det som först och främst testas är att ansluta sig med en dator mot modulen. Sedan testas även att konfigurera modulen att automatiskt ansluta sig mot en mobiltelefon vid spänningssättning vilket fungerar bra. Modulen förbereds sedan för montering genom att konfigureras med inställningar kom- patibla med Vibindicatorns UART-port.

Tabell 17: Värden för Vibindicatorns UART-port Parameter Valt värde

Baudrate 38400

Parity None

Databits 8(ej konfigurerbar) Stopbits 2

Flowcontrol On(ej konfigurerbar)

Olika alternativ finns hur enheterna ska anslutas till varandra.

• 1: 1 - Telefon ska alltid ansluta till en modul.

• 1: 1 - Modul ska alltid ansluta till en telefon.

• 1:N - Modul är öppen för anslutningar från andra enheter.

• 1:N - Modul letar efter enheter att ansluta sig till.

X7002E 21

(29)

Det tredje alternativet är mest passande för situationen, då all användar-interaktion där läggs på tele- fonsidan så detta kommer att bli alternativet som modulen konfigureras med. Valet av denna metod leder till att en bluetooth-klient måste implementeras i mobiltelefonen som kan leta efter Bluetooth- enheter i området och ansluta sig mot valfri enhet.

4.5.3 Montering av modul

Då modulen är av typ DFN(Dual Flat No Lead )-kapsling avsedd för maskinlödning så uppstod ett litet problem med hur den skulle kunna monteras och lödas manuellt. Lösningen för det första prototypkortet blev att löda kablar från modulen till en liten bit av ett experimentkort. Lösningen för det andra prototypkortet blev att löda in tunna kablar direkt på bluetooth-modulen. Denna lösning är den som är minst utrymmeskrävande. Nackdelen med den är att vid längre drift kan kablarna vi- brera loss. Detta skulle kunna förebyggas med att kablarna limmas fast och fixeras vid kretskortet med tex snabblim. Bluetooth-modulen bygger 2.1 mm på höjden samt att kabeln som används har en diameter på ca 0.6 mm så den bygger ej så mycket på höjden. Alternativt så etsas ett kretskort med tjockleken 0.5-0.8 mm.

Figur 3: 3D-rendering av modulkort

I figur 3 visas ett exempel på hur ett modulkort skulle kunna se ut. Bluetoothmodulen kan maskinlö- das på modulkortet och lödpaddar är utdragna med GND, VCC, TX, RX och RESET för lödanslut- ning via kabel till Vibindicatorn.

4.5.4 Interfacekort

Ett litet prototyp-interfacekort konstrueras som är tänkt att ersätta utvecklingskortet. Kopplingss- chemat visas i figur 4. Designen bygger på en spänningsomvandlingskrets MAX232 som konverterar spännningsnivåerna i datorns serieport(-12V till 12V) till TTL-nivåer(0-5V). Kortet spänningsmatas via 5V, denna spänning tas lämpligen från en USB-kabel. Då USB leverar 5V och modulen arbetar på 3.3V så läggs 3 stycken dioder i serie med matningsspänningen. Spänningsfallet över dioderna gör så att vi kommer ner till cirka 3.4V vilket är acceptabelt.

(30)

Figur 4: Schema över interfacekortet

Kortet går sedan att använda som ett interface mellan Bluetoothtmodul och dator för konfigureringsän- damål. En kretskortsdesign utförs även, se figur 5.

Figur 5: Kretskortslayout till interfacekortet

För att man ska kunna få sig en uppfattning av hur ett färdigmonterat kort kommer att se ut så utförs en 3D-rendering av kretskortslayouten, se figur 6.

Figur 6: 3D-rendering av interfacekortet

4.6 Mjukvaruimplementation av huvudkoncept

4.6.1 Princip för att upprätta en klient

Att upprätta en bluetoothanslutning till en given enhet från en mobiltelefon görs i flera olika steg, vilket beskrivs i [11, 14, 16] på ett utförligt sätt.

X7002E 23

(31)

• Initiering av bluetooth

• Device discovery

• Parning

• Service discovery

• Anslutning till enhet

Initiering av bluetooth

Det första som måste göras är att skapa en instans av LocalDevice.

LocalDevice bt = LocalDevice.getLocalDevice();

LocalDevice har sedan metoder för att ta reda på om bluetooth är påslaget, enhetens namn och adress. Det mest användbara men kan göra med den är att använda den för att skapa en DiscoveryAgent, som går att använda för att hitta andra enheter och tjänster som de erbjuder [14].

Device discovery

Enheten som ska anslutas till måste vara i sökbart läge. Det som man får ut av en Device discovery är en lista på adresser till de funna enheterna. Det är även möjligt att läsa ut enhetens namn. An- vändaren väljer sedan i listan den enhet som han vill kunna kommunicera med.

För att leta efter enheter i närheten så anropas startInquiry() i instansen till DiscoveryAgent.

DiscoveryAgent discovery_agent = bt.getDiscoveryAgent();

boolean success = discovery_agent.startInquiry(DiscoveryAgent.GIAC,dl);

Sedan så finns det ett interface kallat DiscoveryListener. Detta interface implementerar fyra metoder, två stycken för device discovery och två stycken för service discovery. Varje gång som en enhet(RemoteDevice) är funnen så anropas DeviceDiscovered() som lägger de funna enheterna i en vektor. När sökningen är färdig så anropas metoden inquiryCompleted() som tar reda på en- heternas namn och skapar en lista av vektorn med de funna enheterna. Användaren kan sedan välja en av enheterna i listan.

Parning

Om enheterna ej är parade sedan förut så måste en PIN-kod anges i detta läge.

Service discovery

Då användaren har valt en enhet att kommunicera med så måste han/hon ta reda på om enheten stöd- jer den önskade tjänsten. Detta görs med hjälp av en Service discovery. Här så söker vi efter tjänsten Serial Port Profilevilken enligt [13] har identiteten 0x1101.

UUID[] uuid = new UUID[1];

uuid[0] = new UUID(0x1101);

vector = new java.util.Vector();

discovery_agent.searchServices(null, uuid, selected_unit, this);

Varje gång en matchande tjänst hittas anropas funktionen DeviceDiscovered() i interfacet DiscoveryListener där den sparas i en vektor bestående av ServiceRecord-objekt. När sökningen

(32)

efter tjänster är klar anropas serviceSearchCompleted().

Anslutning till enhet

Här så skapas en anslutning till den första förekomsten av den specifika tjänsten som man vill an- vända sig av, ut och inputstreamar kopplas till denna anslutning. I detta fall så ansluter vi oss mot tjänsten: Serial Port Profile.

url = ((ServiceRecord)(vector.elementAt(0))).getConnectionURL(0, false);

stream_connector = (StreamConnection)Connector.open(url);

output_stream = stream_connector.openOutputStream();

output_stream_writer = new OutputStreamWriter(output_stream, "US-ASCII");

input_stream = stream_connector.openInputStream();

input_stream_reader = new InputStreamReader(input_stream, "US-ASCII");

Nu så kan dessa streamar användas för att kommunicera med den uppkopplade enheten.

Exempel

output_stream_writer.write(’t’); // för att skicka bokstaven t int_i = input_stream.read(); // för att läsa in en siffra

4.6.2 Princip för avläsning av mätdata

Då Vibindicatorn slås av och på indikerar detta en nystart, det kommer då att läggas in serienummer, tidsstämpel och en indikation för nystart. Läsning av minnet sker via att skicka kommandot ’F’ till Vibindicatorn. Den kommer då att returnera ett ’F’ samt fyra bytes som anger hur många bytes som finns lagrade i minnet.

Tabell 18: Format på returnerad data Byte1 Byte2 Byte3 Byte4 Byte5

’F’ D3 D2 D1 D0

Dessa bytes måste tolkas genom bitshiftning och konvertering för att man ska kunna veta det totala antalet bytes som är lagrade i minnet.

4.6.3 Princip för tolkning av antalet lagrade bytes

Tabell 19 visar principen för att bitshifta fram de enskilda bitarna som är av intresse.

X7002E 25

(33)

Tabell 19: Uträkning av antal lagrade bytes int_i = input_stream.read();

byte_eight = (int_i & 0xf0)>>4; // 10 00 00 00 byte_seven = int_i & 0x0f; // 01 00 00 00 int_i = input_stream.read();

byte_six = (int_i & 0xf0)>>4; // 00 10 00 00 byte_five = int_i & 0x0f; // 00 01 00 00 int_i = input_stream.read();

byte_four = (int_i & 0xf0)>>4; // 00 00 10 00 byte_three = int_i & 0x0f; // 00 00 01 00 int_i = input_stream.read();

byte_two = (int_i & 0xf0)>>4; // 00 00 00 10 byte_one= int_i & 0x0f; // 00 00 00 01 // konverterar från hex till int

byte_one = byte_one*1; // 16^0

byte_two = byte_two*16; // 16^1

byte_three = byte_three*256; // 16^2 byte_four = byte_four*4096; // 16^3 byte_five = byte_five*65536; // 16^4 byte_six = byte_six*1048576; // 16^5 byte_seven = byte_seven*16777216; // 16^6 byte_eight = byte_eight*268435456; // 16^7

total_byte = byte_eight + byte_seven + byte_six +byte_five + byte_four+byte_three+byte_two+byte_one;

Nu så finns i variabeln total_byte lagrat i decimalformat, det totala antalet bytes som finns i Vibindi- catorns minne. Efter det så returneras 0xFE, sedan kommer mätvärdena för x, y, z. De är förpackade i 32bits integers där de första två bitarna anger vilken typ av data som är lagrad. 00 indikerar vanlig data, 01 indikerar en nystart samt innehåller data, 10 indikerar en tidsstämpel, den räknas dock ej som ett mätvärde, 11 indikerar sändarens serienummer.

Tabell 20: Format på returnerad data

Byte1 Byte2 Byte3 Byte4 Byte5

0xFE iixxxxxx xxxxyyyy yyyyyyzz zzzzzzzz

4.6.4 Princip för tolkning av mätdata

Dessa returnerade mätvärden tolkas sedan till giltiga tids och vibrationsvärden. Vi kommer här att råka ut för fyra olika fall som måste behandlas separat.

• Vanlig data

• Nystart

• Tidsstämpel

• Serienummer

Vanlig data

En-sekundersvärden för X, Y och Z-axlarna bitshiftas fram, sedan kvadreras värdena och adderas

(34)

till den förra mätningen.

Tabell 21: X, Y, och Z-värden kvadreras och adderas new_x = new_x + ((x_1*256 + x_2*16 + x_3*1)*0.00790569)*

((x_1*256 + x_2*16 + x_3*1)*0.00790569); // ok

new_y = new_y + ((y_1*256 + y_2*16 + y_3*1)*0.00790569)*

((y_1*256 + y_2*16 + y_3*1)*0.00790569); // ok

new_z = new_z + ((z1*256 + z2*16 + z3*1)*0.00790569)*

((z1*256 + z2*16 + z3*1)*0.00790569); // ok

Efter det så ökas sekundvärdet med ett.

Nystart

Samma rutin utförs som i Vanlig data, samt att tidsvärdet som finns här kommer att lagras som en indikering på när mätperioden startades.

Tidsstämpel

Tiden ligger lagrad i en 32 bits integer.De två första bitarna är testbitar.

Tabell 22: Format på tidsdatat

Byte1H Byte1L Byte2H Byte2L Byte3H Byte3L Byte4H Byte4L

ttyy yymm mmdd dddh hhhh mmmm mmss ssss

Värdena för år, månad, dag, timme, minut och sekund bitshiftas fram, sedan konverteras årtalet enligt tabell 24.

Serienummer

Tidsvärdet som finns här kommer att lagras som en indikering på när mätperioden stoppades.

4.6.5 Beräkning av A(8)-värde

Då vi i kap4.6.4 sparat undan de kvadrerade X, Y och Z-värdena samt respektive start och stopptid för dessa så kan vi nu räkna ut separata A(8)-värden för alla mätperioder eller en kombination av olika perioder. Det som först måste göras är att beräkna RMS-värden för alla perioder som vi vill använda.

RMSmp= vt

1 n

n

X

i=1

a²_i (3)

Nu är det möjligt att beräkna A(8)-värdet.

A(8)= s

Pn

mp=1RMS²_mp· Tmp

8· 3600 (4)

X7002E 27

(35)

Om det är så att mätdatat som finns ej är baserat på en hel arbetsdag så finns möjligheten att vikta resultatet ovan med ekvationen nedan.

A(8)E stimerad = A(8)·

rU ppskattad_T id

8 (5)

4.6.6 Lagring och distribuering av tolkad mätdata

Det som måste lagras i telefonen är den aktuella tiden, den effektiva mättiden, start och stopptider för mätperioderna samt A(8)-värdet. Detta lagras i en recordstore med möjlighet att radera lagrad mätning då den ej längre är användbar. Det kommer att ges möjlighet för användaren att spara informationen i en textfil på telefonens minneskort. Användaren har då möjlighet att överföra denna textfil till en PC med hjälp av datakabel, Bluetooth, IrDA eller genom att minneskortet flyttas över till en PC med minneskortsläsare. Användaren ges även möjligheten att skicka vidare de uppmätta värdena via ett SMS-meddelande. Det som skickas i meddelandet är den effektiva mättiden samt motsvarande A(8)-värde. Det som även skickas med är start och stopptiderna för de mätningar som A(8)-värdet baseras på, samt respektive RMS-värden.

4.7 Mätning och verifiering av huvudkoncept

För att samla in realistiska mätdata så utfördes två mätningar, en den 20 februari, samt en den 23 februari i form av två bussresor mellan Aurorum och Älsby busstation, en resa som tar ungefär en timme enkel väg. Resultaten visas i figur 27. Det vi kan utläsa utifrån diagrammen är att den ena mätningen har betydligt högre nivåer. Detta kan eventuellt förklaras med att den ena mätningen ut- fördes på kvällen och den andra på morgonen. Morgonbussen har fler passagerare vilket leder till en ökning av antalet start och stopp vid busshållplatserna. Detta ger att busschauffören förlorar mer tid som han då måste köra igen, vilket leder till en offensivare körteknik och högre vibrationsnivåer. De höga nivåerna i början av varje mätning härrör ifrån då vibrationsmätaren placerades på bussätet. En beräkning utfördes sedan i Excel av A(8)-värdet, detta värde jämfördes mot det beräknade värdet i mobiltelefonapplikationen för att verifiera hur stor felmarginal som uppstår. Resultatet av detta visas i tabell23.

Tabell 23: Referensmätning mobiltelefon gentemot Excel Mätning nr A(8) i Excel A(8) i mobiltelefon Sträcka

1 0,108086m/s² 0,108089m/s² Luleå Aurorum-Älvsby busstation 2 0,145756m/s² 0,145754m/s² Älvsby Busstation-Luleå Aurorum 3 0,161551m/s² 0,161551m/s² Kombination mätning 1 och mätning 2

Vi kan se att det blir en liten skillnad mellan uträkningarna i Excel och de som utförs i mobiltelefonapplikationen, detta beror med största sannolikhet på att Java ME saknar en ordentlig avrundnings- funktion.

Ett test gjordes för att uppskatta överföringstiden för mätvärden. Mätvärden baserade på 2.73 timmar lästes ut med mobiltelefonen. Detta tog 18.03 sekunder. En uppskattning blir då att det kommer att ta ungefär 52.83 sekunder att överföra mätdata för 8.0 timmar.

En mätning gjordes även för att uppskatta strömförbrukningen i enheten. Strömförbrukningen hamnar med god marginal under maxnivån som är specificerad i kravspecifikationen.

(36)

4.8 Förslag till hårdvaruimplementation av andrakoncept

4.8.1 Utförande

En GPRS-modul med UART-interface införskaffas och kopplas in på Vibindicatorns UART-port.

Svårigheter med detta är främst strömförbrukningen, sedan antennen. Frågan är hur liten en antenn till en modul kan vara utan att räckvidden blir avsevärt försämrad. En lämplig modul finns tillgänglig hos en återförsäljare för ett rimligt pris. Den är lite mindre än batteriet så den går in i kapslingen.

4.9 Förslag till mjukvaruimplementation av andrakoncept

4.9.1 Utförande

En socketconnection upprättas mellan GPRS-modulen och mobiltelefonen. Över denna kommunikationslinje kan mobiltelefonen läsa av och tolka datat från Vibindicatorn.

X7002E 29

(37)

5 Presentation av lösning

Utvecklingsarbetet i projektet resulterade i att en hårdvaruprotoyp konstruerades i form av en Blue- toothmodul som kopplades ihop med en Vibindicator, samt en mjukvaruprototyp i form av en mobiltelefonapplikation programmerad i Java ME. Genom att koppla upp sig via bluetooth från mobiltelefonapplikationen var det möjligt att läsa av de mätdata som var lagrat i Vibindicatorn. Sedan kunde man välja vilka mätningar som skulle användas och beräkna ett A(8)-värde baserat på dessa.

Informationen presenteras sedan för användaren i form av när mätningen startades, stoppades, den totala mättiden, A(8)-värdet samt den axel som hade den dominerande riktningen. Användaren ges möjlighet att inuti mobiltelefonanapplikationen skicka vidare de sparade A(8)-värdena i ett SMS.

Tester har gjorts även med en emailfunktion, i mjukvaruprototypen så är dock denna funktion ej inkluderad. Ett tänkbart scenario vore att efter arbetsdagens slut så skickar man dagens uppmätta värden till sin närmaste chef. Mätvärden sparas även i en textfil på minneskortet, denna fil kan sedan överföras till en PC med valfri teknik, Bluetooth, IR, datakabel eller att minneskortet flyttas från mobiltelefon till en PC med minneskortsläsare. Figur 7 visar ett flödesdiagram över mobiltelefonapplikationen, detta visualiserar hur programmet är uppbyggt samt vilka valmöjligheter som finns.

Sök Enheter Avslutar

Visa

Välj

Välj Enhet

Radera

Anslut Till Vald Enhet

Välj

Skicka SMS

Läs Flash

Välj Mätningar Mätt Hel Dag?

Nej

Start

Visa Rec

SMS Bakåt

Visa Funna Enheter

Ange Arbetad Tid

Skicka 'F'

Visa Mätningar Ja

Koppla ner anslutning Radera

Visa

Spara Rec

Skicka Email Email

Beräkna och spara A(8)

Figur 7: Flödesdiagram över mobiltelefonapplikationen

Systemet som sådant är lättanvänt och borde gå bra att använda sig av för arbetsgrupper såsom buss- chaufförer eller lastbilsförare. De kan därmed snabbt få information om de risker som de dagligen utsätter sig för.

(38)

5.1 Prototypbilder hårdvara

Figur 9 visar en bild på det färdiga prototypkortet med den inlödda bluetoothmodulen, samt figur 8 som visar konfigurationsenheten.

Figur 8: Bild av prototypkortet för konfigureringsenheten

Till vänster i figur 8 så ser vi konfigurationsenheten med RS232-uttag för inkoppling till dator samt USB-kabel för strömförsörjning. Till höger ser vi den första prototypen för bluetoothmodulen där modulen löddes fast med tunna kablar vi en liten bit av ett experimentkort.

Figur 9: Bild på det slutgiltiga prototypkortet

Här ser vi en bild på den andra prototypen där tunna kablar löddes in direkt på bluetoothmodulen för

X7002E 31

(39)

att sedan lödas in på Vibindicator prototypkortet.

5.2 Prototypbilder mobiltelefonapplikation

Figur 10: Startbild Figur 11: Valmöjligheter

Då programmet startas finns två val, antingen att visa gamla sparade mätningar alternativt att ansluta sig mot en Vibindicator för att hämta in nya värden.

Figur 12: Sökning av enheter Figur 13: Funna enheter

I figur 12 så söks omgivningen av efter bluetoothenheter. I figur 13 så ser vi att mobiltelefonen har hittat två stycken bluetoothenheter varav den övre är Vibindicatorn. Vi kan nu välja att ansluta oss till Vibindicatorn.

Figur 14: Förfrågan till användaren Figur 15: Ansluten

(40)

Nu har telefonen upprättat en bluetoothuppkoppling med Vibindicatorn. Vi kan nu välja att läsa av värden från Vibindicatorn vilket figur 15 visar.

Figur 16: Avläsning av värden Figur 17: Visning av mätperioder

Figur 18: Val av mätperioder Figur 19: Arbetat hel dag

Nu har alla mätvärden lästs in och användaren kan specificera vilka mätperioder som ska väljas. Det vi även kan notera är att bluetoothuppkopplingen nu är nerkopplad, det ser vi på bluetoothsymbolen.

Detta är gjort för att spara värdefull batteritid både i mobiltelefonen och i Vibindicatorn.

Figur 20: Ange arbetad tid Figur 21: Recfil vald

Om man exempelvis har arbetat halvdag och således i figur 19, väljer att man ej arbetat en hel dag så ges möjligheten att ange hur många timmar man jobbat enligt figur 20. Piltangenterna på mobiltelefonen används för inmatningen av tiden. Annars hamnar man direkt på figur 21.

X7002E 33

(41)

Figur 22: Recfil visad Figur 23: Ange mottagare

I figur 22 så visas informationen som är lagrad i den valda recfilen. Nu kan man välja att skicka detta via ett SMS.

Figur 24: SMS skickas Figur 25: Mottaget SMS

Telefonnumret till mottagaren anges i formuläret samt att en förfrågan ges ut innan SMS-et skickas iväg.

Figur 26: Mottaget SMS

I figur 25 och figur 26 visas hur det mottagna SMS-et ser ut.

(42)

6 Slutsats och diskussion

Projektet visar på att en mobiltelefon är lämplig att använda för hantering av vibrationsmätdata, dels för dess kompakthet och dels för dess kommunikationsmöjligheter. Dock finns det begränsningar i mobiltelefonen, då främst skärmstorleken. Detta innebär att ibland så måste en dator användas.

Det som alltid måste hållas i åtanke vid arbete med program avsedda för mobiltelefoner är främst att bildskärmen som finns till förfogande är väldigt begränsad i sin storlek. Tankar fanns i början av projektet att kunna presentera datat via en graf men insikten kom snabbt att det skulle bli svårt att genomföra på ett bra sätt på grund av den begränsade skärmytan. En annan viktig detalj har varit att hela tiden försöka att hålla nere storleken på programmet så att det även skulle vara möjligt att använda det i en äldre mobiltelefon.

7 Förslag till framtida åtgärder

Här ges ett antal punkter som skulle kunna förbättra systemet.

• Det som går att göra för att få en snabbare överföringstid är att porthastigheten på Blue- toothenheten konfigureras till ett högre värde. Då måste givetvis Vibindicatorn flashas om med matchande portinställningar för UART’en.

• Att implementera exempelvis en FTP-klient eller liknande i mobiltelefonapplikationen som möjliggör att mätningar kan skickas till en serverdator för lätt åtkomlighet.

• Att göra så att mobiltelefonapplikationen sparar adresserna till tidigare anslutna Bluetoothen- heter.

• Att modifiera/porta mobiltelefonapplikationen så att den går att använda i en PDA.

X7002E 35

(43)

Referenser

[1] Arbetsmiljöverket. AFS 2005:15 - Vibrationer. Solna: Arbetsmiljöverket, 2005.

[2] Beitz, Wolfgang, and Gerhard Pahl. Engineering Design: A Systematic Approach. New York:

Springer, 1999.

[3] Bluetooth. Bluetooth SIG, 2009.

http://www.bluetooth.com/Bluetooth/Technology/Works/ (2009-05-20) [4] Bluetooth.Wikipedia, 2009.

http://sv.wikipedia.org/wiki/Bluetooth (2009-05-20)

[5] Bray, Jennifer, and Charles F. Sturman. Bluetooth 1.1: Connect Without Cables (2nd Edition).

Upper Saddle River: Prentice Hall PTR, 2001.

[6] European Directive. On the minimum health and safety requirements regarding the exposure of workers to the risks arising from physical agents(vibration)(sixteenth individual directive within the meaning of article 16(1) of Directive 89/391/EEC), 2002.

[7] Frequency Modulation.

http://www.fas.org/man/dod-101/navy/docs/es310/FM.htm (2009-05-20)

[8] GPRS (General Packet Radio Service), HSCSD& EDGE. Landmark Internet Ltd, 2001-2009.

http://www.mobile-phones-uk.org.uk/gprs.htm (2009-05-20)

[9] Griffin, M.J. Handbook of Human Vibration. Toronto: Academic Press, 1996.

[10] Hellberg, Annika. Vibrationer i arbetet -hur du minskar risken för skador. Solna: Ar- betsmiljöverket, 2005.

[11] JSR-000082 JavaTM APIs for Bluetooth. Sun Microsystems, 1995-2004.

http://jcp.org/aboutJava/communityprocess/final/jsr082/index.html (2009-05-20)

[12] IEEE 802.11TM WIRELESS LOCAL AREA NETWORKS. the Institute of Electrical and Elec- tronics Engineers, Inc. (IEEE), 2001.

http://www.ieee802.org/11/ (2009-05-20) [13] javax.bluetooth Class UUID

http://www.forum.nokia.com/document/Java_Developers_Library_v2/GUID-9F75713D- 5642-4C39-9A33-C20928F37BF7/javax/bluetooth/UUID.html (2009-05-20)

[14] Knudsen, Jonathan. Kicking Butt with MIDP and MSA: Creating Great Mobile Applications (The Java Series).Upper Saddle River: Prentice Hall PTR, 2008.

[15] Mansfield, Neil J. Human Response to Vibration. Boca Raton: CRC, 2004.

[16] Ortiz, C.E. Using the Java APIs for Bluetooth, Part 2 - Putting the Core APIs to Work. Sun Microsystems, 2005.

http://developers.sun.com/mobility/apis/articles/bluetoothcore/ (2009-05-20)

[17] Padron-McCarthy, T. Mobiltelefonapplikationer med Java ME. Örebro universitet, 2008.

http://basen.oru.se/kurser/j2me/2008-2009-p12/ (2009-05-20) [18] Sony Ericsson. Sony Ericsson Mobile Communications AB, 2008.

http://www.sonyericsson.com/cws/home?cc=se&lc=sv (2008-09-30)

[19] Sun Java Wireless Toolkit 2.5.2_01 for CLDC Download. Sun Microsystems, 1994-2009.

http://java.sun.com/products/sjwtoolkit/download.html (2009-05-20) [20] SuperEdi 4.2.2. WoLoSoft International, 2009

http://www.wolosoft.com/en/superedi/ (2009-05-20)

[21] Svensson, T. RFID-avläsning med mobiltelefon. Jönköping, 2007.

http://www.uppsatser.se/uppsats/120ac399d1/ (2009-05-20) [22] What is infrared and Where is it used?. Infrared Data Assosiation,

http://www.irda.org/displaycommon.cfm?an=1&subarticlenbr=14 (2009-05-20)