RFID-avläsning med mobiltelefon

TEKNISKA H ¨

OGSKOLAN

H¨

ogskolan i J¨

onk¨

oping

RFID-avl¨

asning med

mobiltelefon

Torbj¨orn Svensson

EXAMENSARBETE 2007

Elektroteknik

TEKNISKA H ¨

OGSKOLAN

H¨

ogskolan i J¨

onk¨

oping

RFID-avl¨

asning med

mobiltelefon

RFID-reading with a mobile phone

Torbj¨orn Svensson

Detta examensarbete ¨ar utf¨ort vid Tekniska H¨ogskolan i J¨onk¨oping inom ¨amnesomr˚adet Elektroteknik. Arbetet ¨ar ett led i den tre˚ariga h¨ogskolein-genj¨orsutbildningen. F¨orfattaren svarar sj¨alv f¨or framf¨orda ˚asikter, slutsatser och resultat.

Handledare: Alf Johansson Omfattning: 10 po¨ang (C-niv˚a) Datum: 31 maj 2007

ABSTRACT

Abstract

MobileReader is a mobile RFID (Radio Frequency Identification) application. The purpose of this application is to create a reader, that can be carried out in the field. This project will concentrate on reading passive RFID-tags on the Lowfrequency band (LF) and will be customized for a newer mobile phone manufactured by Sony Ericsson. This has resulted in a program written for the Atmel ATmega16 microcontroller. The microcontroller receives data from an already existing LF-reader using the Wiegand 44 protocol. The data will be converted into a PDU-packet, Protocol Data Unit, which is the protocol used by mobile phones to send SMS between MS, Mobile System, and BS, Base System.

SAMMANFATTNING

Sammanfattning

MobileReader ¨ar en mobil RFID (Radio Frequency Identification) applika-tion. Syftet med denna applikation ¨ar att skapa en RFID-l¨asare som skall g˚a att b¨ara med sig ute p˚a f¨altet. I f¨orsta hand kommer l¨asaren att kunna l¨a-sa passiva RFID-taggar p˚a L˚agfrekvens-bandet (LF) samt att vara anpassad f¨or nyare mobiltelefoner av tillverkaren Sony Ericsson. Detta examensarbe-te resulexamensarbe-terade i ett program avsett f¨or en Atmel ATmega16 mikroprocessor. Mikroprocessorn tar emot data fr˚an en befintlig LF-l¨asare via ett protokoll vid namn Wiegand 44. Den inl¨asta datan paketeras in i ett PDU-paket, Pro-tocol Data Unit, vilket ¨ar det protokoll som mobiltelefoner anv¨ander f¨or att skicka SMS mellan MS, Mobile System, och BS, Base System.

Nyckelord

• Radio Frequency Identification • Protocol Data Unit

• Sony Ericsson FastPort • Wiegand 44

INNEH˚ALL

Inneh˚

all

1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Syfte och m˚al . . . 1 1.3 Avgr¨ansningar . . . 2 1.4 Disposition . . . 2 2 Teoretisk bakgrund 3 2.1 RFID . . . 3 2.2 Magnetiska RFID-system . . . 3 2.2.1 L˚agfrekvens . . . 3 2.2.2 H¨ogfrekvens . . . 4 2.2.3 Elektromagnetiska RFID-system . . . 4 2.2.4 Ultrah¨ogfrekvens . . . 5 2.2.5 Mikrov˚agsfrekvens . . . 6 2.3 Sony Ericsson . . . 6 2.3.1 FastPort . . . 6 2.3.2 AT-kommandon . . . 6 2.4 Protokoll . . . 7

2.4.1 Protocol Data Unit . . . 7

2.4.2 Wiegand 44 . . . 9

3 Genomf¨orande 10 3.1 H˚ardvara . . . 10

3.1.1 Mikroprocessor, ATmega16 . . . 11

3.1.2 RFID-l¨asare, mikrokontrola TRD-HOT COMBO . . . 11

3.1.3 RS-232 ¨over en pinne . . . 12 3.2 Mjukvara . . . 12 3.2.1 AVR Studio . . . 12 3.2.2 WinAVR . . . 12 3.2.3 ViM . . . 13 3.2.4 AVRTerminal . . . 13

3.2.5 Seriell kommunikation med mobiltelefon . . . 13

3.2.6 Initiering av seriell anslutning . . . 14

3.3 Tillv¨agag˚ang . . . 14

3.3.1 Inl¨asning av ID . . . 16

INNEH˚ALL

4 Resultat 20

5 Slutsats och diskussion 21

6 Referenser 22

7 Sakregister 24

8 Bilagor 25

A HCA-60 25

FIGURER

Figurer

1 RFID med magnetf¨alt . . . 3

2 RFID med radiov˚agor . . . 5

3 Pinnkonfiguration ¨over Sony Ericssons FastPort . . . 6

4 Wiegand 44, t. v¨a. kodning av en 0:a, t. h¨o. kodning av en 1:a 9 5 Wiegand 44, n¨ar data f˚ar skickas . . . 9

6 Schematisk skiss ¨over systemet . . . 10

7 AVR STK500, utvecklingskort . . . 11

8 AVR Dragon, JTAG programmerare . . . 11

9 USART till en pinne (VPPFLASH) . . . 12

10 Fl¨odesschema ¨over initiering av tillbeh¨or . . . 15 11 Fl¨odesschema ¨over sync mellan mobiltelefon och mikroprocessor 17

TABELLER

Tabeller

1 F¨orh˚allande mellan frekvens och antennl¨angd . . . 5

2 N˚agra vanliga AT-kommandon . . . 7

3 Beskrivning och f¨altnamn i PDU . . . 8

1 INLEDNING

1

Inledning

Denna rapport kommer att behandla en till¨ampning p˚a RFID, Radio Fre-quency Identification, d¨ar m˚alet ¨ar att skapa en mobil RFID-l¨asare. Den mobila l¨asaren skall l¨asa in informationen och med hj¨alp av en mobiltelefon skicka vidare informationen in i ett aff¨arssystem.

En stor f¨ordel med denna typ av identifiering ¨ar att ist¨allet f¨or att leta upp en streckkod och scanna av denna eller f¨or hand avl¨asa mottagare/inneh˚all kan personen med den mobila RFID-l¨asaren helt enkelt bara n¨arma sig objektet och tr˚adl¨ost k¨anna av vad som finns inom l¨asavst˚andet. Detta kan ske ¨aven om informationen skulle vara dold f¨or blotta ¨ogat. Eftersom RFID-l¨asaren ¨ar en produkt som ansluts till en mobiltelefon beh¨ovs ingen extra str¨omf¨ors¨orj-ning och personen kan enkelt ha med sig l¨asaren i sitt dagliga arbete ute p˚a f¨altet.

1.1

Bakgrund

P˚a marknaden har det funnits station¨ara RFID-l¨asare ett 10-tal ˚ar men pro-blemet med dessa ¨ar att allt som skall avl¨asas m˚aste f¨orflyttas till l¨asaren. Detta har funnits omst¨andligt och tidskr¨avande samt i m˚anga fall on¨odigt och d¨arf¨or har p˚a senare tid ett allt st¨orre behov av mobila l¨osningar kommit h¨ogre upp p˚a ¨onskelistan. Detta har f¨oretaget CombiPort tagit fasta p˚a och d¨arf¨or har f¨oretaget valt att p˚ab¨orja utvecklingen av en l¨asare som ansluts till en mobiltelefon, vilket g¨or att l¨asaren kan r¨oras fritt ute p˚a f¨altet.

1.2

Syfte och m˚

al

Syftet med projektet ¨ar att ta fram en mobil RFID-l¨asare, vilken ¨ar ansluten till en nyare mobiltelefon av m¨arket Sony Ericsson. Den mobila RFID-l¨asaren skall kunna avl¨asa en tagg (f¨or info om vad en tagg ¨ar, se sektion 2.1) och skicka vidare informationen med hj¨alp av mobiltelefonens vanliga GSM/3G anslutning. P˚a sikt kommer l¨asaren att ing˚a i f¨oretagets sortiment av l¨asare och kommer d˚a att rapportera informationen p˚a samma s¨att som f¨oretagets CombiReader.

M˚alet med examensarbetet ¨ar uppn˚att n¨ar examensarbetaren har lyckats med att l¨asa in informationen fr˚an ett befintligt RFID-chip samt att behandla datan p˚a ett l¨ampligt s¨att s˚a att det g˚ar att ¨overf¨ora informationen i ett SMS med hj¨alp av en mobiltelefon till en mottagare.

1 INLEDNING

1.3

Avgr¨

ansningar

I denna rapport kommer det inte att behandlas hur en RFID l¨asare ¨ar kon-struerad eller vad datan denna l¨amnar ifr˚an sig st˚ar f¨or. Den kommer inte heller att innefatta hur ett aff¨arssystem kan se ut eller fungera.

1.4

Disposition

Kapitel 2 beskriver kortfattat vad RFID st˚ar f¨or och hur det anv¨ands. Det st˚ar ¨aven lite om vad AT-kommando ¨ar och anslutningen p˚a mobiltelefonen. I slutet av kapitel 2 beskrivs hur protokollen som anv¨ands i detta examens-arbete fungerar.

I kapitel 3 finns den mjukvara och h˚ardvara som anv¨ands i detta examensar-bete beskrivet. H¨ar finns det ¨aven med hur arexamensar-betet fortl¨opt.

Under kapitel 4 finns resultatet av det h¨ar examensarbetet. Slutsats och diskussion finns i kapitel 5.

2 TEORETISK BAKGRUND

2

Teoretisk bakgrund

2.1

RFID

RFID, Radio Frequency Identification, ¨ar en teknik f¨or att l¨asa och spara information i n˚agot som kallas f¨or en tagg. En tagg ¨ar i princip uppbyggd av enbart en radiomottagare, ett minne och en radios¨andare. Det finns tv˚a olika typer av taggar, den ena typen kallas aktiv och den andra passiv. Det som skiljer dessa tv˚a ˚at ¨ar att den aktiva har en egen energik¨alla till skillnad fr˚an den passiva. Den passiva taggen f¨ors¨orjer sig helt och h˚allet p˚a den energi som RFID-l¨asaren skickar ut. D˚a en aktiv tagg inte beh¨over ta emot lika mycket energi f¨or att “svara”, leder detta till att det g˚ar att f˚a mycket l¨angre avst˚and med en aktiv tagg j¨amf¨ort med en passiv.

Vanligtvis brukar RFID delas upp i olika kategorier beroende p˚a vilket fre-kvensband som anv¨ands. De vanligaste kategorierna ¨ar:

• L˚agfrekvens, LF, 125–134,2 KHz och 140-148,5 KHz • H¨ogfrekvens, HF, 13,56 MHz

• Ultrah¨ogfrekvens, UHF, 865–868 MHz och 915 MHz • Mikrov˚agsfrekvens, MV, 2.45 GHz

2.2

Magnetiska RFID-system

Med ett magnetiskt system[1] menas att ¨overf¨oringen av data sker med hj¨alp av magnetiskt f¨alt. N¨astan alla taggar som bygger p˚a ett magnetiskt f¨alt ¨ar passiva. Figur 1 visar schematisk funktionen hos ett magnetf¨alt.

Reader

Transponder/ Tagg

Figur 1: RFID med magnetf¨alt

2.2.1 L˚agfrekvens

LF-bandet anv¨ander ett magnetf¨alt f¨or ¨overf¨oring av energi samt data. P˚a grund av att det ¨ar ett magnetiskt f¨alt blir l¨asavst˚andet kort, oftast i stor-leksordningen ett par centimeter, men detta beror p˚a hur kraftigt f¨alt som

2 TEORETISK BAKGRUND

det idag finns m˚anga tillverkare av magnetiska taggar har det uppkommit ett antal olika kommunikationss¨att. Vanligtvis s¨ands pulsande energi ut p˚a frekvensen 125 kHz och svaret fr˚an taggen skickas tillbaka s˚a fort pulsen g˚ar l˚ag. N˚agra av problemen med LF-bandet ¨ar att frekvensen ¨ar l˚ag, vilket medf¨or att en stor och komplicerad antenn kr¨avs f¨or att f˚anga upp energi. Det ¨ar ¨aven problem med att skapa tillr¨ackligt branta filter f¨or att kunna separera uts¨and och mottagen signal d˚a det energigivande f¨altet ¨ar mycket starkare ¨an det f¨alt som taggen s¨ander tillbaka information med. Ett annat stort problem ¨ar den mycket begr¨ansade m¨ojligheten att lagra energi i tag-gen, vilket medf¨or att ett konstant energif¨alt m˚aste finnas, eller att taggen svarar omedelbart efter det att energif¨altet avl¨agsnats. Den minsta taggen avsedd f¨or LF-bandet ¨ar en glashylsa, 11 mm l˚ang och med en diameter p˚a 1 mm. Som standard saknar LF-bandet antikollision, vilket i praktiken inne-b¨ar att endast en tagg kan befinna sig i l¨asarens energif¨alt. Detta utnyttjas tex i enklare passagesystem d¨ar det ¨ar v¨asentligt att endast en person blir godk¨and ˚at g˚angen. LF ¨ar ¨aven den ¨aldsta frekvensstandarden.

2.2.2 H¨ogfrekvens

HF-bandet anv¨ander precis som LF-bandet ett magnetf¨alt f¨or att ¨overf¨ora energi och data. En stor f¨ordel med HF gentemot LF ¨ar att d˚a HF har mycket h¨ogre frekvens s˚a minskar antennen dramatiskt i storlek, vilket medf¨or att tillverkningen av taggen blir enklare och billigare. Vanligtvis ¨ar HF-taggar i storleksordningen av ett kreditkort, men de kan bli s˚a sm˚a som 1,5 cm g˚anger 1,5 cm. D˚a l¨asaren h˚aller ett konstant energigivande f¨alt, vilket kan moduleras, kan taggen extrahera energi och data fr˚an l¨asaren samt skicka svar till l¨asaren. Dessa mer avancerade taggar har ofta funktionalitet f¨or l¨asning respektive ˚aterskrivning samt antikollision. L¨as- och skriv-avst˚andet ¨ar begr¨ansat av magnetf¨altet till cirka 50 cm. HF-bandet togs fram under 1990–talet av Philips och ¨ar t¨ankt som en ers¨attare till LF-bandet.

2.2.3 Elektromagnetiska RFID-system

Till skillnad fr˚an ett rent magnetiskt system bygger ett elektromagnetiskt system[2] p˚a radiov˚agor, vilket medf¨or m¨ojlighet till betydligt l¨angre avst˚and mellan tagg och l¨asare. I regel s˚a kr¨aver ett elektriskt f¨alt en antenn av halva v˚agl¨angden λ

2 

, vilket skapar en praktisk undre gr¨ans f¨or n¨ar ett elektriskt f¨alt kan anv¨andas. N˚agra typiska f¨orh˚allanden mellan frekvens och antenn-l¨angd finns redovisade i tabell 1. Desto h¨ogre frekvens som anv¨ands, ju dyrare blir komponenterna att tillverka samt att den ¨overf¨orda energin minskar med kvadraten p˚a v˚agl¨angden. Dock sker en f¨ors¨amring av signalstyrkan med ett genom kvadraten p˚a avst˚andet mellan l¨asare och tagg 1_d2



. Aktiva taggar kan kompensera detta genom att offra mer energi f¨or att f¨ors¨akra att datan

2 TEORETISK BAKGRUND

kan ¨overf¨oras, passiva taggar d¨aremot har p˚a grund av detta en praktisk be-gr¨ansning p˚a 10 till 15 meter. P˚a frekvenser upp mot 2.5 GHz ¨ar avst˚andet endast 1 meter. Frekvens (MHz) Antennl¨angd (cm) 100 150 1000 15 2500 5 5800 2,5

Tabell 1: F¨orh˚allande mellan frekvens och antennl¨angd

Tack vare “backscatter”-modulation och skickliga h˚ardvarukonstrukt¨orer har det blivit billigt att producera taggar baserade p˚a elektriska f¨alt. Med“backscat-ter” menas att taggen har m¨ojlighet att ta in den b¨arv˚ag som l¨asaren skickar ut och modulera taggens data p˚a denna f¨or att ˚ater s¨anda ut den modu-lerade signalen. Detta ger m¨ojlighet att anv¨anda taggen p˚a ett stort antal olika frekvenser, g¨ora den passiv samt fram f¨or allt enkel att tillverka d˚a den enbart beh¨over best˚a av en antenn och en liten kiselplatta. Dessa taggar ¨ar dock endast l¨asbara. En nackdel med denna typ av teknik ¨ar att l¨asaren blir komplex d˚a den beh¨over ha stabil frekvens s˚a den modulerade datan kan ex-traheras samt m¨ojlighet att ta emot den svaga modulerade signalen. Idealet f¨or ett s˚adant h¨ar system ¨ar en l¨asare och m˚anga taggar. Figur 2 visar p˚a f¨orh˚allanden som r˚ader f¨or ett elektromagnetiskt RFID f¨alt.

Reader

Transponder/ Tagg

Figur 2:RFID med radiov˚agor

2.2.4 Ultrah¨ogfrekvens

UHF-bandet ¨ar det band som i framtiden kommer anv¨andas mest. Kombi-nationen av antikollision och l˚anga l¨asavst˚and g¨or att detta l¨ampar sig b¨ast i m˚anga sammanhang men tekniken ¨ar ¨annu f¨or dyr f¨or att massproduce-ra. I Europa anv¨ands frekvenserna 865–868 MHz medan i USA anv¨ands 915 MHz. Nyligen har en ¨overenskommelse mellan Europa och USA tr¨affats om att den maximala effekten p˚a mottagaren f˚ar vara 2 Watt, tidigare 4 Watt i USA samt 0,5 Watt i Europa.

2 TEORETISK BAKGRUND

2.2.5 Mikrov˚agsfrekvens

MV-bandet innefattar endast aktiva taggar och har d¨arf¨or l¨angst l¨asavst˚and. Det ¨ar ¨aven det band som klarar av att ha h¨ogst ¨overf¨oringshastighet. Ef-tersom endast aktiva taggar finns i detta band kr¨aver det att varje tagg har en tillf¨orlitlig energik¨alla, vilket g¨or tillverkningen dyr. MV-bandet saknar ¨aven en ordentlig standard. En annan stor nackdel med MV-bandet ¨ar att signalerna vid denna frekvens har en tendens att “hoppa runt” och d¨arf¨or kan det vara sv˚art att f˚a en tillf¨orlitlig ¨overf¨oring.

2.3

Sony Ericsson

2.3.1 FastPort

Anslutningen till en nyare Sony Ericsson mobiltelefon kallas f¨or FastPort. Det finns ingen officiell dokumentation att h¨amta fr˚an Sony Ericsson om hur FastPort ser ut eller hur den kan anv¨andas. Dock finns det en icke officiell sida p˚a Internet[3] som beskriver vad respektive pinne anv¨ands till. Figur 3 visar denna information.

Pin Signal 1 USB +5V in 2 SP REF 3 Mic+/AUXIN L 4 Mic-/AUXIN R 5 DFMS/SP L 6 DTMS/SP R 7 VIDEO/STB 8 VPPFLASH 9 GND 10 CTMS / USB DATA+ 11 CFMS / USB DATA-12 Charge In

Figur 3: Pinnkonfiguration ¨over Sony Ericssons FastPort

2.3.2 AT-kommandon

AT-kommandon har historiskt sett anv¨ants fr¨amst f¨or att styra modem[4] men kan ¨aven anv¨andas f¨or andra till¨ampningar. I Sony Ericssons fall har de lagt till ytterligare kommandon[5] till standarden och med dessa kan en

2 TEORETISK BAKGRUND

Sony Ericsson mobiltelefon styras. Till exempel kommer mobiltelefonen att ringa upp ett nummer d˚a det har kommandot ATD som prefix. F¨or att ringa H¨ogskolans v¨axel skulle s˚aledes kommandot ATD036101000 skickas. Tabell 2 visar ett utdrag av AT-kommandon som Sony Ericsson har.

Kommando Funktion

AT Telefonen svarar med “OK” om f¨orbindelsen fungerar

ATD Ring upp

AT*SEACID Identifiera anslutet tillbeh¨or AT+CMGS Skicka SMS

Tabell 2: N˚agra vanliga AT-kommandon

2.4

Protokoll

2.4.1 Protocol Data Unit

Protocol Data Unit[6], PDU, ¨ar namnet p˚a det paket som skickas mellan mobiltelefon och basstation i ett GSM-n¨at (Global System for Mobile Com-munications) n¨ar anv¨andaren vill skicka ett SMS. Tabell 3 beskriver de olika f¨alten som en PDU innefattar. Om inget annat anges skall v¨ardena anges i hexadecimal form.

Exempel: Service nummer +46123, mottagare 098765, meddelande “Hej!” i 8-bitars kodning i klass 0 ger PDU till

04 91 6421F3 11 00 04 81 907856 00 F4 FF 04 48656A21 d¨ar,

04h st˚ar f¨or “Length of Service Center Address”, 91h st˚ar f¨or “Type of Service Center Address” osv.

2 TEORETISK BAKGRUND

F¨altnamn Beskrivning

Length of Service Center Address Antalet tecken i f¨alten, typ och Service Center.

Type of Service Center Address Riks- eller nationellt Service Center nummer.

Address Field Service Center nummer angivet i decimal form med parvis v¨axlade siffror. ¨Ar antalet tecken udda l¨agges ett F in som n¨ast sista tecken.

First Octet Ar satt till 11¨ h vid SMS-SUBMIT. Message Reference Ett referensnummer i intervallet

0-FF. 0 inneb¨ar att mottagarens telefon genererar ett nummer. Length of Originating Address Antalet tecken i f¨alten, typ och

mottagarnummer.

Type of Originating Address Riks- eller internationell mottagare. Address Field Mottagarens telefonnummer angivet

i decimal form med parvis v¨axlade siffror. ¨Ar antalet tecken udda l¨agges ett F in som n¨ast sista tecken.

Protocol Identifier Anger typ av SMS (0 ¨ar “Standard Text SMS”).

Data Coding Scheme V¨aljer teckenkodning samt typ av meddelande. 7bit ger upp till 160 tecken per SMS, 8bit ger upp till 140 tecken per SMS.

Validity Period Anger hur l¨ange basstationen skall f¨ors¨oka leverera SMS:et till

mottagaren.

User Data Length Antalet tecken i SMS:et.

User Data Sj¨alva meddelandet, hexkodad ASCII

f¨or tecknet i fr˚aga.

2 TEORETISK BAKGRUND

2.4.2 Wiegand 44

Protokollet Wiegand 44 bygger p˚a tv˚a dataledningar. Data0 i figur 4 ¨ar den ledare i vilken en puls kommer om biten som skickas ¨over ¨ar en etta. Data1 i figur 4 ¨ar den ledare i vilken en puls kommer om biten som skickas ¨over ¨ar en nolla. I vilol¨age ¨ar b˚ada ledarna h¨oga, vilket medf¨or att pulserna som kommer p˚a de b˚ada ledarna ¨ar inverterade. Enligt figur 4 tar det 2 ms att ¨overf¨ora en bit, eller 88 ms f¨or att ¨overf¨ora ett ID. Efter att ett ID ¨overf¨orts skall det finnas en lucka d˚a ledarna h˚alls h¨oga i minst 100 ms, vilket figur 5 visar. Detta i teorin leder till en teoretisk maximal hastighet p˚a 5,3 ID:n per sekund. Protokollet saknar verifikation p˚a att paketet ¨ar korrekt motta-get eller att det ¨over huvud tamotta-get kom fram, vilket g¨or att protokollet b¨or undvikas i s¨akerhetssystem. En stor f¨ordel med protokollet ¨ar att det ¨ar en-kelt att implementera. Wiegand 44 kan anv¨andas f¨or enklare kommunikation mellan tv˚a enheter, till exempel anv¨ander TRD-HOT COMBO fr˚an f¨oretaget mikrokontrola detta f¨or att ¨overf¨ora ett inl¨ast ID fr˚an en RFID-tagg.

Figur 4: Wiegand 44, t. v¨a. kodning av en 0:a, t. h¨o. kodning av en 1:a

3 GENOMF ¨ORANDE

3

Genomf¨

orande

Systemet fungerar som s˚a att ett ID inl¨ases fr˚an RFID-l¨asaren (TRD-HOT COMBO, se sektion 3.1.2) och skickas med prokollet Wiegand 44 (se sek-tion 2.4.2) till en Atmel ATmega16. Mikroprocessorn skickar sedan vidare informationen via en konverterare, vilken ¨overs¨atter den tv˚a-ledade kommu-nikationsl¨anken till en enkel-ledad, till en mobiltelefon av tillverkaren Sony Ericsson. JTAG anv¨ands f¨or att programmera och fels¨oka programkoden med hj¨alp av en dator och AVR Studio. En schematisk skiss ¨over systemet och dess olika delar finns att se i figur 6.

Atmel ATmega16

JTAG

TRD−HOT COMBO Data0 Data1

Sony Ericsson

Konverterare

RX TX VPPFLASH 1 2 3 4 5 6 7 8 9 0

*

#

SMS

Figur 6: Schematisk skiss ¨over systemet

3.1

H˚

ardvara

Vid framtagning av den mobila RFID-l¨asaren anv¨ands en processor av typ Atmel ATmega16 p˚a ett AVR STK500 (se figur 7). F¨or att programmera processorn anv¨ands en AVR Dragon (se figur 8) vilken har ett JTAG, Joint Test Action Group, gr¨anssnitt mot processorn.

3 GENOMF ¨ORANDE

Figur 7:AVR STK500, utvecklingskort

Figur 8: AVR Dragon, JTAG programmerare

3.1.1 Mikroprocessor, ATmega16

I detta projektet anv¨ands en ATmega16. Det ¨ar en 8 bitars RISC processor med 16 kB flash minne. Som oscillator anv¨ands en extern kristall p˚a 8 MHz. N˚agra av egenskaperna som processorn har[7]:

• 3 timers, tv˚a 8 bitars och en 16 bitars • 1kB internt RAM

• 512 byte EEPROM

• JTAG, IEEE standard 1149.1 kompatibelt gr¨anssnitt • En USART

• Mestadels encykels instruktioner

3.1.2 RFID-l¨asare, mikrokontrola TRD-HOT COMBO

RFID-l¨asaren som anv¨ands i detta projektet ¨ar en TRD-HOT COMBO fr˚an f¨oretaget mikrokontrola. TRD-HOT COMBO ¨ar en LF-l¨asare och saknar antikollision.

N˚agra av egenskaperna som l¨asaren besitter[8]:

• L¨aser RFID p˚a LF-bandet

• Hanterar sp¨annings niv˚aer i intervallet 7-15 V

3 GENOMF ¨ORANDE

3.1.3 RS-232 ¨over en pinne

Eftersom kommunikationen med mobiltelefonen skall ske seriellt och Sony Ericsson valt att inte anv¨anda tv˚a pinnar i anslutningen FastPort finns det bara ett alternativ, n¨amligen att k¨ora seriell kommunikation ¨over pinne 8 (VPPFLASH). VPPFLASH ¨ar inte en ren RS-232 utan det ligger inb¨addat i ett annat hemligt protokoll. F¨or att m¨ojligg¨ora kommunikation p˚a endast en pinne beh¨ovs en extern konstruktion (se figur 9).

Figur 9: USART till en pinne (VPPFLASH)

3.2

Mjukvara

3.2.1 AVR Studio

AVR Studio[9] ¨ar en komplett IDE, Integrated Development Environment, men saknar en C kompilator. F¨or att f¨ora in st¨od f¨or C i AVR Studio kan till exempel WinAVR[10] eller IAR[11] anv¨andas. AVR Studio kommer att anv¨andas f¨or att programmera mikroprocessorn via AVR Dragon. AVR Stu-dio har ¨aven viktiga funktioner som att kunna stega ett program som ligger i mikroprocessorn, den har s˚aledes h˚ardvarusimulering. Detta l¨ampar sig bra d˚a det enkelt g˚ar att modifiera register under drift utan att beh¨ova program-mera om mikroprocessorn.

3.2.2 WinAVR

WinAVR[10] ¨ar ett komplett paket av verktyg f¨or mjukvaru-utveckling till Atmel AVR RISC mikroprocessorer avsedd f¨or plattformen Microsoft

Win-3 GENOMF ¨ORANDE

dows. WinAVR ¨ar ett “¨oppen k¨allkod”-projekt. Det h¨arstammar fr˚an GNU GCC[12] och har st¨od f¨or b˚ade C och C++. En stor f¨ordel med WinAVR j¨amf¨ort med andra varianter av utvecklings verktyg som till exempel IAR[11] ¨ar att det ¨ar helt fritt och gratis att anv¨anda. WinAVR skickar ¨aven med en b¨attre editor ¨an den som ing˚ar i AVR Studio vid namn “Programmers Notepad”. Denna editor har bland annat funktioner som syntax markering och st¨od f¨or projekt. I detta projektet anv¨ands dock ViM d˚a den faller b¨attre i smaken.

3.2.3 ViM

ViM[13], Vi iMproved, ¨ar en kraftfull texteditor skapad av Bram Moolenaar. ViM ¨ar, som namnet antyder, t¨ankt som en ers¨attare till Vi. Vi har sitt ur-sprung i Unix system. D˚a det fanns en grupp m¨anniskor p˚a Internet som ans˚ag att viktiga funktioner saknades i Vi p˚ab¨orjades arbetet att l¨agga till dessa funktioner och till sist v¨axte ViM fram som en helt skild editor fr˚an Vi. ViM har bland annat funktioner som syntax markering, automatisk in-tendering och m¨ojlighet att anv¨anda regular expression f¨or att enkelt ¨andra inneh˚all genom en hel fil. ViM g˚ar under licensen “charityware” och ¨ar fri att anv¨anda.

3.2.4 AVRTerminal

AVRTerminal[14] ¨ar en avancerad seriell terminal. Den har bland annat st¨od f¨or att skicka str¨angar kodade i det hexadecimala talsystemet samt att logga till fil. Det senare har funnits mycket anv¨andbart vid fels¨okning av det bin¨ara protokoll som anv¨ands f¨or kommunikation p˚a VPPFLASH.

3.2.5 Seriell kommunikation med mobiltelefon

Protokollet som anv¨ands mellan mobiltelefon och tillbeh¨or har Sony Erics-son valt att h˚alla hemligt. Enligt dokumentation fr˚an f¨oretaget Firma Jens Fr¨obom (se A), bygger protokollet p˚a att telefonen skickar ut en fr˚aga och till-beh¨oret svarar. Det ¨ar s˚aledes kritiskt att tillbeh¨oret inte sporadiskt skickar data till telefonen d˚a kollision ¨ar oundvikligt.

Varje paket som skickas mellan telefon och processorn m˚aste b¨orja med ko-den AAh som anv¨ands f¨or att synkronisera baudrate. D¨arefter kommer tv˚a byte som anger avs¨andare och vilken typ av data som skickas. Den tredje byten inneh˚aller l¨angden (i byte) som data-blocket inneh˚aller, CR och LF inr¨aknade. Data blocket kan max inneh˚alla 15 byte och d¨arf¨or m˚aste l¨angre meddelanden delas upp i flera segment.

3 GENOMF ¨ORANDE

Id Beskrivning

2000-2999 Input enhet 5000-5999 Bil handsfree 6000-6999 Portabel handsfree Tabell 4: Lista ¨over vanliga tillbeh¨orsklasser

3.2.6 Initiering av seriell anslutning

Innan tillbeh¨oret identifieras skickar telefonen ut ett par snabba pulser f¨oljt av en l¨angre sync-puls p˚a ca 12ms (se bilaga A, sektion 3.1.1, bild 1 och 2). F¨orloppet att initiera kommunikationen finns ¨aven beskrivet med hj¨alp av fl¨odesschemat i figur 10. F¨or att p˚ab¨orja identifieringen skall tillbeh¨oret, direkt efter att telefonen avslutat sin puls, l¨agga TX h¨og i 50 ms. D¨arefter kan initieringen b¨orja p˚a en hastighet av 2400 baud. N¨ar USART:en ¨ar p˚ asla-gen skall ytterligare en f¨ordr¨ojning ske p˚a 50 ms varefter f¨orsta initierings-str¨angen skickas till telefonen. Telefonen kommer att svara, varefter den and-ra initierings-str¨angen skickas. N¨ar telefonen ˚aterigen svarar justeras hastig-heten upp p˚a f¨orbindelsen till 38400 baud, vilken f¨oljs av en ny f¨ordr¨ojning p˚a 100 ms. Vid detta laget sker den sista verifieringen av att l¨anken mellan telefon och tillbeh¨or fortfarande fungerar genom att den tredje och sista ini-teringsstr¨angen skickas och telefonen svarar. Om telefonen skulle missa att svara p˚a n˚agon av de tre initeringsstr¨angarna inom 100 ms skall initieringen avbrytas och tillbeh¨oret skall ˚ater s¨allas i l¨aget att leta efter synkroniserings-pulsen och d¨arefter b¨orja om initieringen. N¨ar initieringen fallit igenom utan fel ¨ar det dags att ber¨atta vad det ¨ar f¨or tillbeh¨or som ¨ar anslutet till mobil-telefonen. Detta g¨ors genom att AT-kommandot AT*SEACID=<acc id> skickas med l¨ampligt ID. Tabell 4 nedan visar n˚agra vanliga exempel p˚a olika ID:n. N¨ar AT*SEACID kommandot ¨ar skickat till telefonen och telefonen svarat med “OK” ¨ar identifieringen slutf¨ord. Eventuellt kan andra typer av tillbeh¨or kr¨ava ytterligare identifieringskommandon f¨or att exempelvis s¨atta telefonen i handsfree l¨age, men i fallet med RFID-l¨asaren beh¨ovs inte detta. Eftersom protokollet bygger p˚a att telefonen skickar ut sm˚a paket, vilka an-v¨ands f¨or att skicka data till telefonen, m˚aste tillbeh¨oret alltid vara berett p˚a att svara n¨ar tillf¨alle ges. Om ingen data skall skickas vid denna f¨orfr˚agan m˚aste ett “handskaknings”-svar skickas.

3.3

Tillv¨

agag˚

ang

N¨ar projektet att ta fram en mobil RFID-l¨asare med hj¨alp av en Sony Er-icsson p˚ab¨orjades var det inte k¨ant huruvida mobiltelefonen hade ett seriellt gr¨anssnitt eller om den var ren USB. Efter att ha gjort lite unders¨okningar, bland annat genom en dialog med f¨oretaget Firma Jens Fr¨obom och en del Internets¨okningar stod det klart att Sony Ericsson helt tagit bort den seriella

3 GENOMF ¨ORANDE

3 GENOMF ¨ORANDE

kommunikationsl¨anken och ersatt den med en USB-bus ist¨allet. Direkt upp-stod problem med hur kommunikationen skulle ske mellan processorn och mobiltelefonen. Efter ytterligare en diskussion med Firma Jens Fr¨obom stod det klart att den enda seriella kommunikationsv¨agen som finns tillg¨anglig var ¨over pinnen VPPFLASH i FastPort. VPPFLASH har ett bin¨art protokoll i vilket AT-kommandon kan kapslas in f¨or att styra mobiltelefonen. Eftersom det ¨ar en pinne f¨or b˚ade RX och TX till processorn beh¨ovs en extern kon-struktion g¨oras som beskrivet i sektion 3.1.3.

3.3.1 Inl¨asning av ID

RFID-l¨asaren TRD-HOT COMBO fr˚an f¨oretaget mikrokontrola har st¨od f¨or en mindre uppsj¨o av protokoll. D˚a ATmega16 enbart har en USART fanns bara ABA Track II samt Wiegand 44 kvar p˚a listan ¨over m¨ojliga protokoll. Protokollet Wiegand 44 ¨ar n¨armare beskrivet under sektion 2.4.2. F¨or att implementera Wiegand 44 i mikroprocessorn ¨ar det l¨ampligt att ansluta Da-ta0 respektive Data1 till INT0 och INT1. D˚a det ¨ar skilda avbrott f¨or en 0:a respektive en 1:a kan r¨att bit av den mottagna koden enkelt sparas i ett minnesutrymme.

F¨or att kontrollera att den mottagna koden ¨ar korrekt anv¨ands en TRD-DESK USB fr˚an f¨oretaget mikrokontrola, vilken rapporterar det avl¨asta ID:t i hexkod via ett seriellt gr¨anssnitt. AVRTerminal[14] anv¨ands f¨or att visa koden p˚a datorn. ID:t avl¨ast med TRD-HOT COMBO skickas ¨aven via USART till datorn f¨or verifiering. Denna procedur ¨ar enbart skapad f¨or fels¨okning och finns inte med i slutgiltig produkt. D˚a korrektheten hos ID:t verifierats kan denna fas av programmeringen anses vara avslutad.

3.3.2 Mobiltelefon

Vid f¨ors¨ok med mobiltelefon har det visat sig att n¨ar USART:en ¨ar avst¨angd ¨ar det viktigt att se till att TX ¨ar l˚ag d˚a i annat fall VPPFLASH effektivt styrs till h¨og, vilket resulterar i att mobiltelefonen l˚aser sig. Om TX ¨ar l˚ag en kort sekund, startas bara mobiltelefonen om men i annat fall l˚aser den sig “h˚art”. Det enda som upph¨aver denna h˚arda l˚asning ¨ar att avl¨agsna batteriet. Vid v¨antan p˚a synkroniserings-puls fr˚an telefonen befinner sig programmet i ett tillst˚and kallat SYNC. Det som sker i detta tillst˚and ¨ar att s˚a fort pin-nen som delas med RX g˚ar l˚ag kommer en mjukvarutimer, som g˚ar med frekvensen 1 kHz, att startas och r¨akna ned ifr˚an 10. Om RX pinnen skulle g˚a h¨og n˚agon g˚ang under den tid det tar f¨or timern att r¨akna ut kommer timern att startas om och ˚ater b¨orja r¨akna ned fr˚an 10. Talet 10 kommer fr˚an det att pulsen skall vara 10 ms l˚ang. Om timern skulle r¨akna ut g˚ar pro-grammet vidare till tillst˚and INIT i vilket initieringen av kommunikationen sker. Fl¨odesschemat i figur 11 beskriver synkroniserings-f¨orloppet grafiskt. Initieringsrutinen ¨ar beskriven i detalj i sektion 3.2.6.

3 GENOMF ¨ORANDE

3 GENOMF ¨ORANDE

N¨ar initieringen och identifieringen av tillbeh¨oret ¨ar utf¨ort g˚ar programmet vidare in i tillst˚andet IDLE. I detta tillst˚and ligger mikroprocessorn och v¨an-tar p˚a de sm˚a “handskaknings”-paketen som telefonen skickar med ca 5 ms intervall. Mikroprocessorn kommer att besvara majoriteten av dessa med ett “handskaknings”-svar. Om ett ID mottagits fr˚an RFID-l¨asaren kommer ist¨al-let denna data att skickas i ett SMS. ID:t blir d˚a representerat i hexadecimal form.

F¨ors¨ok med ett par olika AT-kommandon har utf¨orts, bland annat med AT*EAPP samt AT+CMGS. AT-kommandot AT*EAPP skall, enligt datablad[5], bland annat kunna skicka SMS och skriva notiser, men vid f¨or-s¨ok visade det sig att inga SMS kom fram skickade med detta kommando. Det g˚ar dock att anv¨anda kommandot f¨or att skapa notiser i mobiltelefonen s˚a som databladet beskriver. Det verkar s˚aledes troligt att det ¨ar en begr¨ansning i den mobiltelefon som anv¨ands vid dessa f¨ors¨ok.

Ytterligare Internets¨okningar p˚avisade att AT+CMGS ¨ar r¨att v¨ag att g˚a. Det finns bland annat ett exempel p˚a hur en person anv¨ander kommandot i Visual Basic f¨or att skicka SMS. Det visade sig dock att denna syntax inte ¨ar giltig i den mobiltelefon som anv¨ands, utan att denna anv¨ander en n˚agot annorlunda syntax. R¨att syntax, enligt databladet, ¨ar

AT+CMGS=<length><CR><pdu><ESC>

med f¨orklaringen att “length” avser antalet oktetter i PDU efter “Service Center Address” f¨alten. Vid s¨okningen fanns ¨aven ett dokument (se bilaga B), vilket beskriver hur ett SMS skickas med PDU fr˚an Siemens samt en Java-klass vid namn smslib. Studie av smslib samt exemplet p˚a sidan 31 i Siemens datablad visar hur ett PDU block skall skapas. F¨or ytterligare infor-mation om PDU, se sektion 2.4.1. F¨or att underl¨atta implementering har en fast str¨ang med plats f¨or 10 SMS-tecken valts samt 8-bitars teckenkodning. D˚a str¨angl¨angden h˚alls konstant inneb¨ar detta att enbart “User Data”-delen i PDU-str¨angen beh¨over bytas ut. S˚aledes ¨ar implementeringen i mikroproces-sorn t¨amligen enkel. Eftersom hela PDU-str¨angen sparas i RAM underl¨attar detta f¨or fels¨okning d˚a det enkelt g˚ar att s¨atta en brytpunkt i AVR Studio direkt efter att str¨angen skapats vilket medf¨or att verifiering av giltigheten host PDU:n l¨att kan g¨oras.

F¨or att skicka PDU-str¨angen till mobiltelefonen beh¨over PDU-str¨angen delas upp i ett flertal segment. Detta beror p˚a att varje paket som telefonen kan ta emot via den seriella l¨anken, enbart kan innefatta maximalt 15 tecken s˚a som beskrivet i sektion 3.2.5. Detta medf¨or att det kommer att ta ett antal “handskakningar” f¨or att ¨overf¨ora informationen till mobiltelefonen.

3.3.3 Sammanfogning av mobiltelefon och RFID-l¨asare

D˚a b˚ade generering av PDU-str¨ang f¨or SMS samt inl¨asningen av RFID-informationen sker helt separerat torde det vara relativt enkelt att sammafoga

3 GENOMF ¨ORANDE

dessa tv˚a funktionaliteter. Rent praktiskt kopieras de tv˚a kodblocken till ett och samma projekt. D˚a Wiegand 44 anv¨ander tv˚a egna avbrottsrutiner ¨ar det enklast att flytta ¨over dessa till mobiltelefon-koden. N¨ar sammanslagningen ¨ar utf¨ord ¨ar det bara att initiera avbrottsrutinerna samt st¨alla in- respektive ut-g˚angar. D¨arefter ¨ar produkten f¨ardig f¨or testning.

4 RESULTAT

4

Resultat

Arbetet med den mobila RFID-l¨asaren resulterade i ett program skrivet f¨or en mikroprocessor av typ Atmel ATmega16. Programmet hanterar protokol-let Wiegand 44, vilket finns beskrivet i sektion 2.4.2, f¨or inh¨amtning av ID:t fr˚an mikrokontrola’s RFID-l¨asare TRD-HOT COMBO. Processorn anv¨an-der ¨aven USART f¨or kommunikation med mobiltelefonen av m¨arket Sony Ericsson. Kommunikationen med telefonen sker genom att AT-kommandon skickas inkapslade i ett bin¨art protokoll, vilket Sony Ericsson valt att h˚alla hemligt.

Programmet uppfyller de krav som f¨oretaget hade, d˚a det klarar av att l¨asa av en tagg och rapportera ID:t, fr˚an taggen, till en mobiltelefon med hj¨alp av ett SMS.

5 SLUTSATS OCH DISKUSSION

5

Slutsats och diskussion

Som slutsats kan dras att arbetet i vissa avseenden varit sv˚arare ¨an f¨orv¨antat, medan i andra avseenden har det varit enklare. Till exempel var jag inte beredd p˚a att ett SMS skulle vara s˚a sv˚art att skicka och kr¨ava s˚a mycket tid som det gjorde. Jag hade ¨aven r¨aknat med att det skulle g˚a att f˚a ut lite data om hur kommunikationen med mobiltelefonen skulle ske fr˚an Sony Ericsson, men eftersom s˚a inte var fallet har arbetet blivit i vissa fall sv˚ararbetat. Om arbetet skulle ha p˚ab¨orjats idag, och jag hade haft den erfarenhet som jag idag besitter, hade jag nog valt att vi skulle ha varit tv˚a examensarbetare om projektet. Detta d˚a det vid ett flertal tillf¨allen uppst˚att problem som hade varit l¨attare att tackla om det funnits n˚agon, som man kunde diskutera f¨or-respektive nackdelar med. Det kan till exempel r¨ora huruvida mikroproces-sorn skall h˚alla uppe kommunikaionen med mobiltelefonen ¨aven om det inte finns n˚agon data att hantera. Kanske vore det b¨attre om kommunikationsl¨an-ken enbart togs upp n¨ar det fanns ett ID att skicka. Om s˚a vore fallet skulle det g˚a att minska energif¨orbrukningen genom att s¨atta mikroprocessorn i sleep-l¨age st¨orre delen av tiden.

6 REFERENSER

6

Referenser

[1] Magnetic coupled transponder systems.

http://rapidttp.com/transponder/magnetic.html (Acc. 2007–05–06).

[2] Electric coupled transponder systems.

http://rapidttp.com/transponder/electric.html (Acc. 2007–05–06).

[3] Pinouts.ru FastPort.

http://pinouts.ru/CellularPhones-P-W/se k750i pinout.shtml (Acc. 2007–03–13).

[4] Historik om AT-kommandon.

http://en.wikipedia.org/wiki/AT Commands (Acc. 2007–03–26).

[5] Sony Ericsson, AT-kommandon.

http://developer.sonyericsson.com/getDocument.do?docId=65054 (Acc. 2007–03–13).

[6] SMS with the M20.

http://www.etm.se/gsmstuff/files/M20 sms.zip (Acc. 2007–03–26).

[7] ATmega16(L) (357 pages, revision O, updated 03/07).

http://www.atmel.com/dyn/resources/prod documents/doc2466.pdf (Acc. 2007–03–13).

[8] mikrokontrola Unique TRD-HOT COMBO. http://www.mikrokontrola.pl/plikiproduktow/ TRD-HOT%20COMBO%20ver%201 1%20EN.pdf (Acc. 2007–03–26).

[9] AVR Studio.

http://www.atmel.com/dyn/products/tools card.asp?tool id=2725 (Acc. 2007–04–02). [10] WinAVR. http://winavr.sourceforge.net/ (Acc. 2007–04–02). [11] IAR. http://www.iar.com/ (Acc. 2007–04–26). [12] GNU GCC. http://gcc.gnu.org/ (Acc. 2007–04–26).

6 REFERENSER [13] Vi iMproved. http://www.vim.org/ (Acc. 2007–04–26). [14] AVRTerminal. http://www.avrfreaks.net/index.php?module=Freaks%20Tools&func= viewItem&item id=293 (Acc. 2007–03–14).

7 SAKREGISTER

7

Sakregister

A

Aktiv tagg, 3 AT-kommando, 6 AT*EAPP, 18 AT*SEACID, 6, 14 AT+CMGS, 6 ATD, 6 ATmega16, 11 AVR Studio, 12

D

Data Coding Scheme, 8 Dragon, 10

F

FastPort, 6

G

GSM, 7

H

H¨ogfrekvens, 4

L

L˚agfrekvens, 3

M

Mikrov˚agsfrekvens, 6

O

Originating Address, 8

P

Passiv tagg, 3 PDU, 7

Protocol Data Unit, 7

R

Radio Frequency Identification, 3 RS-232, 11, 13

S

Service Center Address, 8 SMS, 7 STK500, 10

T

TRD-HOT COMBO, 11

U

Ultrah¨ogfrekvens, 5

V

VPPFLASH, 6, 12

W

Wiegand 44, 9, 11, 16 WinAVR, 12

8 BILAGOR

8

Bilagor

A

HCA-60

Sony Ericsson

Advanced Car Handsfree HCA-60

Author: Jens Fröbom Email: jens.frobom@gmail.com Website:

Phone: +46 36 16 21 20 Mobile: +46 70 46 14 851

Company Firma Jens Fröbom Date: 2007-03-13

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

1. Contents

1. CONTENTS ... 2 2. CONNECTORS... 3

2.1. 4 WAY DOUBLE ROW MICRO FIT (POWER) ... 3 2.2. 4 WAY SINGLE ROW MICRO FIT (SPEAKER) ... 3 2.3. 8 WAY DOUBLE ROW MICRO FIT (STEREO SPEAKERS)... 3 2.4. 3 WAY SINGLE ROW MICRO FIT (MICROPHONE)... 3 2.5. 12 WAY DOUBLE ROW MICRO FIT (PHONE INTERFACE)... 3

3. DATA COMMUNICATION EXPERIMENT... 4

3.1. OSCILLOSCOPE GRAPHS... 4 3.1.1. Initiation ... 4 3.1.2. Idle... 7 3.1.3. Button Press (‘1’) ... 9 3.1.4. Outgoing call... 10 3.1.5. MP3 audio playback... 14 3.2. RESULT... 17 3.2.1. Protocol ... 17 3.2.2. Frames... 17 4. DATA COMMUNICATION... 18 4.1. FRAME FORMAT... 18 4.2. RESULT CODES... 18 4.2.1. Listing... 18 4.2.2. +CKEV (Keypad event)... 18 4.2.3. *SEAULSI (Audio Line Status) ... 18

4.3. MESSAGES... 18

4.4. SCENARIOS... 19

4.4.1. Placing a call ... 19 4.4.2. Incoming call... 19 4.4.3. Playing MP3 audio... 19 4.4.4. Incoming call during MP3 audio playback... 19 4.4.5. Answering call during MP3 audio playback... 19 4.4.6. Disconnected call ... 19 4.4.7. Disconnected call during MP3 audio playback ... 19

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

2. Connectors

The connectors are all made by AMP but they’re compatible with Molex Micro Fit.

2.1. 4 way double row Micro fit (Power)

1. Unknown 2. Unknown 3. Unknown 4. Unknown

2.2. 4 way single row Micro fit (Speaker)

1. Unknown 2. Unknown 3. Unknown 4. Unknown

2.3. 8 way double row Micro fit (Stereo speakers)

1. Unknown 2. Unknown 3. Unknown 4. Unknown 5. Unknown 6. Unknown 7. Unknown 8. Unknown

2.4. 3 way single row Micro fit (Microphone)

1. Unknown 2. Unknown 3. Unknown

2.5. 12 way double row Micro fit (Phone interface)

Pin1 on the micro fit connector is connected to pin1 on the phone interface connector and so on. 1. Vbus Not connected

2. SP_REF Speaker- 3. MIC+/AUXIN_L Microphone+ 4. MIC-/AUXIN_R Microphone- 5. DFMS/SP_L Speaker left 6. DTMS/SP_R Speaker right 7. VIDEO/STB Not connected 8. VPPFLASH Debug 9. GND Ground 10. CTMS/D+ Not connected 11. CFMS/D- Not connected 12. DCIO Power

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

3. Data

communication

experiment

On pin 8 (VPPFLASH) there’s data communication between HCA-60 and K750i.

3.1. Oscilloscope graphs

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

3.2. Result

An initiation sequence is sent when a phone is inserted. After that the normal communication begins. It consists of a status question from the hands-free and a status response from the phone.

3.2.1. Protocol

The data line is low when it’s idle. A data frame consists of one start bit (high), one stop bit (low) and 8 data bits at the data rate 38kbaud. It’s assumed that the least significant bit (lsb) is sent first. The initiation sequence is sent with 2400baud. Data line low is considered ‘1’ and high is considered ‘0’.

3.2.2. Frames

Init1 request (2400baud) 0xAA 0xE0 0x45 0x01 0x76 Init1 response (2400baud) 0xAA 0x0E 0x45 0x02 0x75 0x01 Init2 request (2400baud) 0xAA 0x1F 0x45 0x02 0x74 0x04 Init2 response (2400baud) 0xAA 0x0F 0x45 0x02 0x73 0x04

Init3 request (38kbaud) 0xAA 0x10 0x45 0x02 0x7F 0x03 might be carkit enable Init3 response (38kbaud) 0xAA 0x01 0x45 0x02 0x7F 0x33 might be ACK HS from hands-free 0xAA 0x1F 0x45 0x01 0x7E

HS from phone 0xAA 0x0F 0x45 0x01 0x7E

Status response (Button ‘1’ 1) 0xAA 0x01 0x05 0x0E 0x0D 0x0A 0x2B 0x43 0x4B 0x45 0x56 0x3A 0x20 0x31 0x2C 0x31 0x0D 0x0A

Status response (Button ‘1’ 2) 0xAA 0x01 0x05 0x0E 0x0D 0x0A 0x2B 0x43 0x4B 0x45 0x56 0x3A 0x20 0x31 0x2C 0x30 0x0D 0x0A

Status response (Outgoing call 1) 0xAA 0x01 0x05 0x0E 0x0D 0x0A 0x2B 0x43 0x4B 0x45 0x56 0x3A 0x20 0x5B 0x2C 0x31 0x0D 0x0A

Status response (Outgoing call 2) 0xAA 0x01 0x05 0x10 0x0D 0x0A 0x2A 0x53 0x45 0x41 0x55 0x4C 0x53 0x49 0x3A 0x20 0x31 0x2C 0x31 0x0D Status response (Outgoing call 3) 0xAA 0x01 0x05 0x0E 0x0D 0x0A 0x2B 0x43 0x4B 0x45

0x56 0x3A 0x20 0x5B 0x2C 0x30 0x0D 0x0A

Status response (MP3 audio 1) 0xAA 0x01 0x05 0x0F 0x0D 0x0A 0x2B 0x43 0x4B 0x45 0x56 0x3A 0x20 0x3A 0x4A 0x2C 0x31 0x0D 0x0A Status response (MP3 audio 2) 0xAA 0x01 0x05 0x10 0x0D 0x0A 0x2A 0x53 0x45 0x41

0x55 0x4C 0x53 0x49 0x3A 0x20 0x31 0x2C 0x32 0x0D Status response (MP3 audio 3) 0xAA 0x01 0x05 0x0F 0x0D 0x0A 0x2B 0x43 0x4B 0x45

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

4. Data

communication

4.1. Frame format

{Sync, Source, Type, Block Length, Block}

Sync 0xAA Used to sync the baud rate Source 0x01 Phone 0x0E Phone init 0x0F Phone handshake 0xE0 Hands-free init 0x1F Hands-free handshake 0x10 Hands-free

Type 0x45 No ascii 0x05 Result code

Block Length Number of bytes in block (CR and LF included) Block CR LF Result code CR LF ASCII

Message No ASCII

4.2. Result codes

4.2.1. Listing

+CKEV: 1,1 Button press ‘1’ +CKEV: 1,0 Button release ‘1’

+CKEV: [,1 Button press ‘Call’ (Outgoing call 1) +CKEV: [,0 Button release ‘Call’ (Outgoing call 3)

*SEAULSI: 1,1 Outgoing call (No line feed after this)(Outgoing call 2)

4.2.2. +CKEV (Keypad event)

+CKEV: <keys>,<press>]

<keys> 0..9 = Number keys [ = Soft key 1

:J = Joystick button pressed <press> 1 = Key pressed

0 = Key released

4.2.3. *SEAULSI (Audio Line Status)

*SEAULSI: <audio_line>,<audio_type>

<audio_line> 0 = Audio line inactive 1 = Audio line active <audio_type> 0 = No audio

1 = Speech 2 = Media

…X = Any other type

4.3. Messages

0x7F 0x03 Carkit enable 0x7F 0x33 Carkit enable ACK

Sony Ericsson Advanced Car Handsfree HCA-60 Updated 2007-03-13

4.4. Scenarios

4.4.1. Placing a call

x +CKEV: [,1 Soft key 1 is pressed

x *SEAULSI: 1,1 Audio line is active (speech)

x +CKEV: [,0 Soft key 1 is released

4.4.2. Incoming call x RING

x SEAULSI: 1,1 Audio line is active (speech)

4.4.3. Playing MP3 audio

x +CKEV: :J,1 Joystick button is pressed

x *SEAULSI: 1,2 Audio line is active (media)

x +CKEV: :J,0 Joystick button is released

4.4.4. Incoming call during MP3 audio playback x RING

x RING

4.4.5. Answering call during MP3 audio playback

x +CKEV: [,1 Soft key 1 is pressed

x +CKEV:[,0 Soft key 1 is released

x *SEAULSI: 1,1 Audio line is active (speech)

4.4.6. Disconnected call

x SEAULSI: 1,0 Audio line is active (no audio)

4.4.7. Disconnected call during MP3 audio playback

SMS with the M20

'HYHORSHU¶V*XLGH

SMS with the M20 'DWH )LOHVPVBJXLGBYBGRF SDJHRI  ,1752'8&7,21   6HUYLFH&HQWHU1XPEHU&6&$   6HOHFW0HVVDJH6HUYLFH&606   6HOHFW0HVVDJH)RUPDW&0*)   606,17(;702'(   7H[W0RGH3DUDPHWHU&603  2.1.1 Text-Mode-Parameter First-Octet )2! 7 2.1.2 Text-Mode-Parameter Validity-Period 93! 8

2.1.3 Text-Mode-Parameter Protocoll Identifier 3,'! 8

2.1.4 Text-Mode-Parameter Data-Coding-Scheme '&6! 8

 6066XEPLW0RELOH2ULJLQDWHG 

2.2.1 Write SMS to SIM-Card-Memory (+CMGW) 9

2.2.2 Send SMS from SIM-Card-Storage (+CMSS) 10

2.2.3 Send SMS direct from Terminal (+CMGS) 10

 606'(/,9(50RELOH7HUPLQDWHG 

2.3.1 Indication about new SMS-DELIVER 11

2.3.2 Direct routing of new SMS-DELIVER 13

 606,135272&2/'$7$81,702'(3'802'( 

 6066XEPLW0RELOH2ULJLQDWHG 

3.1.1 Write SMS to SIM-Card-Storage (+CMGW) 15

3.1.2 Send SMS from SIM-Card-Storage (+CMSS) 16

3.1.3 Send SMS direct from Terminal (+CMGS) 16

 606'(/,9(50RELOH7HUPLQDWHG 

3.2.1 Indication about new SMS-DELIVER 17

3.2.2 Direct routing of new SMS-DELIVER 18

 7KH%DVLFHOHPHQWVRIWKH6063'8 

3.3.1 The Basic elements of the SMS-DELIVER-PDU (Mobile Terminated) 20 3.3.2 The Basic elements of the SMS-SUBMIT-PDU (Mobile Originated) 20

3.3.3 Service-Center-Address (SCA) 20 3.3.4 First Octet 22 3.3.4.1 Message-Type-Indicator (MTI) 22 3.3.4.2 More-Messages-to-Send (MMS) 23 3.3.4.3 Validity-Period-Format (VPF) 23 3.3.4.4 Status-Report-Indication (SRI) 23 3.3.4.5 Status-Report-Request (SRR) 23 3.3.4.6 User-Data-Header-Indicator (UDHI) 23 3.3.4.7 Reply-Path (RP) 23

SMS with the M20

3.3.4.8 Reject-Duplicates (RD) 24

3.3.5 Protocol-Identifier (PID) 24

3.3.6 Data-Coding-Scheme (DCS) 24

3.3.7 Originator Address (OA) 25

3.3.8 Destination-Address (DA) 26

3.3.9 Message-Reference (MR) 26

3.3.10 Validity-Period (VP) 26

3.3.11 User Data Length (UDL) 27

3.3.12 User Data (UD) 28

 3'8(;$03/(6   60668%0,73'8   606'(/,9(53'8   $33(1',;   'HIDXOWDOSKDEHW   $EEUHYLDWLRQV   3DFNLQJRIELWFKDUDFWHUV   606VSHFLILFHUURUFRGHV 

SMS with the M20

'DWH )LOHVPVBJXLGBYBGRF SDJHRI

 ,QWURGXFWLRQ

The SMS provides a means to transfer short messages between a GSM Mobil-Staion (MS) and an Short-Message-Entity (SME) via an Service-Center (SC). The SC serves as an interworking and relaying function of the message transfer between the MS and the SME. The short message point-to-point services comprise two basic services:

⇒ SM MT (Short Message Mobile Terminated Point-to-Point);

⇒ SM MO (Short Message Mobile Originated Point-to-Point).

The text messages to be transferred by means of the SM MT or SM MO contain up to 140 octets (max 160 Characters).

1.1



Service Center Number (

&6&$

)

6HUYLFH&HQWUH6&Function responsible for the relaying and store-and-forwarding of a short message between an SME and an MS. The SC is not a part of the GSM PLMN, however MSC and SC may be integrated.

To use the SMS you have to declare the number of the SMSC (Short Message Service Center, SCA) in the MS (Mobile Station), provided that the MS support SMS-MO (Short Message Service-Mobile Orginated).

6,0&DUG 606&QXPEHU

A1-Mobilkom +436640501

A3-Max.Mobil +43676021

D1-Telekom +491710760000 D2-Privat +491722270333

With the command „$7&6&$"“ the M20 shows the current Service-Center-Address stored

on the SIM-Card.

With the AT-Command „$7&6&$ 6&$!>726&$!@´the SMSC-Number is enterd. 6\QWD[

,QSXW ([HFXWLRQ &RPPHQW

$7&6&$" <CR> Query current Service-Center-Address

(SCA) setting (read from SIM-Card) Response:

&6&$´6&$!´ 2.

$7&6&$ ´6&$!´ _<CR> Defines the Service-Center-Address (SCA) (stores on SIM-Card)

3DUDPHWHU

6&$! Service-Center-Address (String-Type)

726&$! Type-Of-Service-Center-Address (numbering plan) optional

([DPSOHV

$7&6&$ ´´ _<CR> Defines the Service-Center-Address (SCA) in international number format.

$7&6&$ ´´ _<CR> Defines the Service-Center-Address (SCA) in national number format.

SMS with the M20

127,&(

⇒ 6WRULQJ HYHU\ DGGUHVV LQ LQWHUQDWLRQDO QXPEHULQJ IRUPDW EHJLQQLQJ ZLWK ij

FRQWLQXHG ZLWK WKH FRXQWU\FRGH LV UHFRPPHQGHG WR DYRLG SUREOHPV ZKLOH URDPLQJ

⇒ $VN\RXUORFDOQHWZRUNSURYLGHUIRUWKHULJKW606&QXPEHU

⇒ 7KH6&$GGUHVVLVDSDUWRIWKH606

7KH6&$GGUHVVLVVWRUHGWRJHWKHUZLWKHDFK606RQWKH6,0FDUGDWWKHWLPHWKH 606LVWVWRUHG

1.2



Select Message Service

&606

)

This command selects messaging service . It returns the types of messages supported by the M20 and can be changed with the AT-Command Ä$7&606 6(59,&(!´.

6\QWD[

$7&606 6(59,&(! <CR> Select Message Service Response:

&6066(59,&(!07!02!%0! 2.

3DUDPHWHUV

6(59,&(! indicates the messaging service

07! service for mobile terminated messages

02! service for mobile originated messages and

%0! service for broadcast type messages.

Examples: Read-Command:

$7&606" <CR> Read command returns supported message types along the current service setting.

Response:

&606

2. Command returns the current messaging service and alist of all services supported by the M20.

6HW&RPPDQG

$7&606  <CR> Set command defines supported

message type.

Response: &606

SMS with the M20

'DWH )LOHVPVBJXLGBYBGRF SDJHRI

'HILQHG9DOXHV

3DUDPHWHU YDOXH GHVFULSWLRQ

0 The syntax of SMS AT commands is compatible with GSM Phase 2

Phase 2+ features which do not require new command syntax may be supported (e.g. correct routing of messages with new Phase 2+ data coding schemes) 1 The syntax of SMS AT commands is compatible with

GSM Phase 2+ version (active acknowledgment of class 0 SMS-DELIVER-Messages)

2...127 reserved

6(59,&(!

128 Sets the SIEMENS M20 in a Mode compatible to the SIEMENS M1 (no Service-Center-Address added at the beginning of a PDU-SMS)

0 type not supported

07!02!%0! 1 type supported 127,&( ⇒ :KHQ&606 DFODVV606'(/,9(5KDVWREHDFNQROHGJHGDFWLYHZLWKWKH FRPPDQGÄ$7&10$´ZLWKLQDGHILQHGWLPH ⇒ )RUWKHVWUDLJWKIRUZDUGFDVHVHWWKLVSDUDPHWHUWR$7&606  ⇒ _{7REHFRPSDWLEOHZLWKWKH6,(0(160VHWWKLVSDUDPHWHUWR}$7&606 ) !



Select Message Format

&0*)

The AT-Command Ä$7&0*) 02'(!´ sets up the M20, which input and output format of messages to use. The Parameter indicates the format of messages used with send, list, read and write commands and unsolicited result codes resulting from received messages. Mode can be either Text mode or PDU mode (headers and body of the messages given as separate parameters).

6\QWD[

$7&0*) 02'(! <CR> Select SMS-Format

Response:

2.

SupportedValues:

PRGH! PHDQLQJ

0 PDU mode (default when)

1 Text mode

Examples: Read-Command:

$7&0*)" <CR> Read command returns current SMS-Mode.

Response:

&0*)

2. Command returns the current mode.

6HW&RPPDQG

$7&0*)  <CR> Set-Command defines SMS-Mode.

Test command returns supported modes as a compound value. See M20 Technical Description for further details on Character-Set.

NOTICE: Text mode uses the value of parameter &+6(7! specified by AT-Command Ä$7&6&6 &+6(7!´ - Select Terminal Character Set - to inform the character set to be used in the message body in the TA-TE interface.

SMS with the M20

 606LQ7H[W0RGH

With the AT-Command „AT+CMGF=1“ the M20 has to be set in desired SMS-Text-Mode.

From then every SMS-Input or Output is treated in Text-Mode. To switch back to PDU-Mode use the same command with the value 02'(!=0.

2.1



Text-Mode Parameter (+CSMP)

Setting the Parameter for SMS-Submit could be changed within the comand Ä$7&603 )2!93!3,'!'&6!´.

6\QWD[

$7&603 )2!93!3,'!'&6! <CR> Sets Tex-Mode-SMS-Parameters Response:

2.

3DUDPHWHUV

)2! First Octet of the delivered / submitted SMS

93! Validity-Period

3,'! Protocol-Identifier

'&6! Data-Coding-Scheme

For query of the current status use the read command Ä$7&603"´

([DPSOHV 5HDG&RPPDQG

$7&603" <CR> Query of the current status. Response:

&603 Shows the current settings.

6HW&RPPDQG

$7&603  <CR> Sets Tex-Mode-SMS-Parameters Response:

&603 Shows the current settings.

The Test-Command „$7&603 "“ gives as response only a „2.“.

 7H[W0RGH3DUDPHWHU)LUVW2FWHW)2!

This value describes the first octet of SMS-DELIVER, SMS-SUBMIT (default 17), in integer format.

Use 17 for the standard case of a SMS-SUBMIT. )2! = 17&d = 11&h = 00010001&b...means:

• VP field present and integer represented (relative).

• SMS-SUBMIT (in the direction MS to SC)

SMS with the M20

'DWH )LOHVPVBJXLGBYBGRF SDJHRI

 7H[W0RGH3DUDPHWHU9DOLGLW\3HULRG93!

The Validity-Period is the information element which gives an MS submitting an

SMS-SUBMIT to the SC the possibility to include a specific time period value in the short message (Validity-Period field). The TP-Validity-Period parameter value indicates the time period for which the short message is valid, i.e. for how long the SC shall guarantee its existence in the SC memory before delivery to the recipient has been carried out.

This value describes Validity-Period in integer format (default 167&d).

93!YDOXH

> G@ 9DOLGLW\SHULRGYDOXH

0 to 143 (VP + 1) x 5 minutes (i.e. 5 minutes intervals up to 12 hours) 144 to 167 12 hours + ((VP -143) x 30 minutes)

168 to 196 (VP - 166) x 1 day 197 to 255 (VP - 192) x 1 week

The Validity-Period is counted from when the SMS-SUBMIT is received by the SC. When the first deliver attempt failed (maybe because destination ME is not in service) and the validity-periods expires the SMS will be rejected by the SC.

 7H[W0RGH3DUDPHWHU3URWRFROO,GHQWLILHU3,'!

The PID is the information element by which the Transport Layer either refers to the higher layer protocol being used, or indicates interworking with a certain type of telematic device. Some examples of PID codings:

3,'!YDOXH

> G@ 3URWRFROO

0 The SMS has to be treat as a short message 1 The SMS has to be treat as a telex

2 The SMS has to be treat as group3 telefax 3 The SMS has to be treat as group4 telefax

For further information see GSM 03.40 chapter 9.2.3.9 127,&()RUWKHVWDQGDUGFDVHXVH3,'  127,&(,WLVQRWJXDUDQWHHGWKDWWKH606&VXSSRUWVHYHU\3,'FRGLQJ



606ZLWKQRWVXSSUWHG3,'FRGLQJVPD\EHUHMHFWHG $VN\RXUORFDO*60SURYLGHUKRZWRJHQHUDWHD6060HVVDJHWRD)$;RUHPDLO DGGUHVV  7H[W0RGH3DUDPHWHU'DWD&RGLQJ6FKHPH'&6!

The DCS field indicates the data coding scheme of the UD (User Data) field, and may indicate a message class.

'&6!YDOXH

> G@ FKDUDFWHUFRGLQJ 0HVVDJH&ODVV

0 default (7-bit) no class

240 default (7-bit) class 0 (immediate display)

241 default (7-bit) class 1 (Mobile Equipment- specific) 242 default (7-bit) class 2 (SIM specific message)

243 default (7-bit) class 3 (Class3 Terminate Equipment- specific)

244 8-bit class 0 (immediate display)

245 8-bit class 1 (Mobile Equipment- specific) 246 8-bit class 2 (SIM specific message)

247 8-bit class 3 (Class3 Terminate Equipment- specific)

For further information see GSM 03.38 chapter 4.

Default alphabet indicates that the UD (User Data) is coded from the 7-bit alphabet given in the appendix. When this alphabet is used, eight characters of the message are packed in

SMS with the M20

seven octets, and the message can consist of up to 160 characters (instead of 140 characters in 8-bit data coding)

In 8-bit data coding, you can relate to the INTEL ASCII-HEX table.

In Class 0 (immediate display) the short message is written directly in the display, as the M20T has no display the Class 0 SMS is routed direct to the Terminal.

In Class 1 to Class 3 the short message is stored on the SIM-card and TE.

In Class 2 the SMS has to be stored on the SIM-card, ditrect routing to Terminal is prohibited.

127,&(

⇒ ,Q&DVHRIELWFRGLQJD606FDQFRQVLVWRQXSWRFKDUFWHUVLQFDVHRIELW

FRGLQJRQO\FKDUDFWHUVDUHSRVVLEOH

⇒ )RUWKHVWDQGDUGFDVHRQ7H[W606XVH'&6! 

2.2



SMS-Submit (Mobile Originated)

SMS-SUBMIT means that the GSM-Mobile sends a SMS to the Service-Center.  :ULWH606WR6,0&DUG0HPRU\&0*:

The execution command „$7&0*:´stores message (either DELIVER or SMS-SUBMIT) to SIM-Card memory storage.

6\QWD[ $7&0*: '$!>72'$!>67$7!@@ <CR> !7(;7 <CTRL-Z / ESC> Response: &0*:,1'(;! 2.

If command is executed correct the SMS-Storage-index-number is presented.

3DUDPHWHU

'$! Destination-Address (String-Type)

72'$! Type-Of- Destination-Address (numbering plan) optional

67$7! allows other status values to be given than ’stored unsent’.

,1'(;! Memory location

([DPSOHV

$7&0*: ´´ <CR> Switches to SMS-Input-Mode, the SMS will be stored as „unsent“ with the destiantion address: „+12345“.

!7+(%,*%52:1)2; *) <CTRL-Z / ESC> **)

Input of the SMS-Message upto 160/140***) Characters. Stores a SMS onto the SIM-card.

Response:

&0*:

2. The SMS has been stored on the SIM-Card in index 1.

*) The promp sign „!“ is generated by the M20.

**) The key <CTRL> +<Z> executes the command, <ESC> -key quits execution without

storing/sending

***) Depends on Data-Coding-Scheme: 160 Character on 7 bit coding, 140 Character on

SMS with the M20

'DWH )LOHVPVBJXLGBYBGRF SDJHRI

 6HQG606IURP6,0&DUG6WRUDJH&066

The AT-Command „$7 &066 ,1'(;!>'$!>72'$!@@´ sends message with location

value ,1'(;! from SIM-Card message storage to the network (SMS-SUBMIT). If new

recipient address '$! is given given for SMS-SUBMIT, it shall be used instead of the one

stored with the message.

Reference value 05! is returned to the TE on successful message delivery. Optionally

(when &6066(59,&(! value is 1 and network supports) 6&76! is returned.

6\QWD[

$7&066 ,1'(;! <CR>

Response:

&06605!>6&76!@ The SMS has been sent from the SIM-storage

successfully. Reference value 05! is returned to the Terminal on successful message delivery. Optionally (when &6066(59,&(! value is 1 and network supports) 6&76! is returned..

3DUDPHWHU

,1'(;! SIM-Card-Memory location

05! Message Reference

6&76! Srvice-Center-Time-Stamp

([DPSOHV

$7&066  <CR> The SMS stored on the SIM-Card in

,1'(;! will be sent to the Service-Center.

Response:

&066

2. The Message Reference number is returned.

 6HQG606GLUHFWIURP7HUPLQDO&0*6

This execution command sends message from a Terminal to the network (SMS-SUBMIT), without storing the SMS-Message onto the SIM-Card.

Reference value 05! is returned to the TE on successful message delivery. Optionally

(when &6066(59,&(! value is 1 and network supports) 6&76! is returned.

6\QWD[ $7&0*6 '$!>72'$!@ <CR> !7(;72)606 <CTRL-Z> / <ESC> Response: &0*605!>6&76!@ 2.

The Message Reference number is returned when sending was

successful.

3DUDPHWHU

,1'(;! SIM-Card-Memory location

'$! Destination-Address (String-Type)

72'$! Type-Of- Destination-Address (numbering plan), optional.

05! Message Reference

SMS with the M20

([DPSOHV

$7&0*6 ´´ <CR> Switches to SMS-Input-Mode, the SMS will be send to the destinantion address: „+991234567“.

!7+(%,*%52:1)2; *) <CTRL-Z / ESC> **)

Input of the SMS-Message upto 160/140***) Characters. Stores a SMS onto the SIM-card.

Response:

&0*6

2. The SMS has been send to the SC with MessageRefernence 255.

*) The promp sign „>“ is generated by the M20.

**) The key <CTRL> +<Z> executes the command, <ESC> -key quits execution without

sending

***) Depends on Data-Coding-Scheme: 160 Character on 7 bit coding, 140 Character on

8 bit coding.

127,&(7KHUHLVQRSRVVLELOLW\WRUHVHQGWKLV6060HVVDJHDJDLQ

2.3



SMS-DELIVER (Mobile Terminated)

SMS-DELIVER means that the M20 receives a SMS-Message from the Service-Center. There are two principle ways to show the SMS.

⇒ If SMS-DELIVER is stored into SIM-Card, indication of the memory location is routed to

the Terminal using unsolicited result code: „&07,0(0!,1'(;!´

⇒ SMS-DELIVERs (except class 2 messages (store message)) are routed directly to the

Terminal using unsolicited result code: Ä&07 2$! >$/3+$!@6&76!

>722$!)2!3,'!'&6!6&$!726&$!/(1*7+!@&5!/)!'$7$!´ 127,&( ⇒ $ERXWDPRXQWRISDUDPHWHUVSUHVHQWHGUHIHUFRPPDQG6KRZ7H[W0RGH 3DUDPHWHUV&6'+ ⇒ $ERXWFRQGLWLRQVRQGLVSOD\LQJHLWKHU606'(/,9(5VWRUHGRQ6,0&DUGRUURXWHG GLUHFWO\WRWKH7HUPLQDOUHIHUFRPPDQGÄDWFQPL³LQ07HFKQLFDOGHVFULEWLRQ  ,QGLFDWLRQDERXWQHZ606'(/,9(5

An information is send to the Terminal that a new SMS-Mesage has arrived and it is stored on the SIM-Card.

6\QWD[

&07,0(0!,1'(;! indication of the memory location is routed to the Terminal using unsolicited result code

3DUDPHWHU

0(0! preferred message storage („SM“)

SMS with the M20 'DWH )LOHVPVBJXLGBYBGRF SDJHRI 6\QWD[IRUUHDGQHZ606 $7&0*5 ,1'(;! <CR> Response: &0*567$7!2$!>$/3+$!@6&76! >722$!)2!3,'!'&6! 6&$!726&$!/(1*7+!@ '$7$! 2.

SIM-Card index 1 contains this SMS.

3DUDPHWHU

integer type in PDU mode (default 0), or string type in text mode (default 5(&

815($');indicates the status of message in memory; defined values:

0 5(&815($' received unread message (i.e. new message) 1 5(&5($' received read message

2 672816(17 stored unsent message

67$7!

3 6726(17 stored sent message

2$! Originating-Address Address-Value field in string format

722$! 7ype of Origiantor-Address

$/3+$! 6tring type alphanumeric representation of <OA> corresponding to the entry found in SIM-phonebook

6&76! Service-Centre-Time-Stamp in time-string format.

)2! *) First octet of SMS-DELIVER, SMS-SUBMIT (default 17), in integer format.

3,'! *) Protocol-Identifier in integer format (default 0).

'&6! *) SMS Data Coding Scheme (default 0), or Cell Broadcast Data Coding Scheme in integer format

6&$! *) SC Address-Value field in string format.

726&$! *) SC address Type-of-Address octet in integer format.

/(1*7+! Integer type value indicating in the text mode (+CMGF=1) the length of the message body '$7$! in characters.

'$7$! Content of Message

*) header values not shown when +CSDH=0

'HOHWHQHZ606

$7&0*' ,1'(;! <CR> Deletes the SMS on SIM-Card index <index>

Response:

2.

([DPSOH

&07,60 A SMS has been delivered and stored on the SIM-Card in index 1