Optisk dataoverførsel til en microcontroller - Danmarks Tekniske ...

“Optisk dataoverførsel til en microcontroller” Eksamensprojekt, Diplom-IT
I samarbejde med og IMM-B.Eng-2007-76
Danmarks Tekniske Universitet. 2008-03-14
Optisk dataoverførsel til en microcontroller
Optical Data Transmission to a Micro Controller
STUDERENDE Hasse Bylov Høll (s051155)
VEJLEDER (EKSTERN) Bjarne Madsen, Prevas A/S
VEJLEDER Edward Alexandru Todirica, DTU

Forord
Projektet omhandler optisk overførsel af data fra almindelige desktop-computere til
microcontrollere. Vha. en Java-applet vil data blive præsenteret på en almindelig
computerskærm, hvorfra de opsamles af en fotosensor forbundet til microcontrolleren.
Rapporten vil give en overordnet analyse af problemstillingen og belyse overvejelser i
forbindelse med udviklingen af den bagvedliggende teknik. Der gives et overblik over
arkitekturen samt nogle af de problematikker, der gør sig gældende vedrørende fysiske
forhold. Derudfra vil der blive foretaget en vurdering af systemets robusthed ved fejlbetjening.
Opgaven består af to dele, hvor første del bl.a. beskæftiger sig med overførselsprotokol, data-
modtagelse samt dekodnings-processen på microcontrolleren. Anden del vil omhandle
udviklingen af en Java-applet med fokus på enkodning og transmittering af data.
Yderligere vil der blive udviklet en prototype til demonstration af hardwaren.

Indhold
Forord.............................................................................................................................................................................................3
1 Indledning....................................................................................................................................................................................6
2 Forundersøgelse......................................................................................................................................................................8
2.1 Baggrund..................................................................................................................................................................................8
2.2 Sammenhæng.......................................................................................................................................................................8
2.3 Formål........................................................................................................................................................................................9
2.4 Interessenter............................................................................................................................................................................9
2.5 Kravspecifikation.................................................................................................................................................................10
2.6 Afgrænsning..........................................................................................................................................................................11
2.7 Løsningsmuligheder.............................................................................................................................................................11
2.8 Tidsplan...................................................................................................................................................................................12
2.9 Risikomomenter...................................................................................................................................................................12
3 Overblik.....................................................................................................................................................................................13
3.1 Udviklingsmiljøet....................................................................................................................................................................13
3.1.1 Webnet-modul.............................................................................................................................................................13
3.1.2 Microchip MPLAB ICD2..........................................................................................................................................14
3.1.3 Hardware-prototype................................................................................................................................................15
3.1.4 Forsøgsopstilling.........................................................................................................................................................16
3.2 Opgaven.................................................................................................................................................................................17
4 Test-applikation......................................................................................................................................................................18
4.1 Analyse....................................................................................................................................................................................18
4.1.1 Skærmteknologier.....................................................................................................................................................19
4.1.2 Lysforhold....................................................................................................................................................................20
4.2 Design......................................................................................................................................................................................21
4.2.1 Programstruktur.........................................................................................................................................................21
4.2.2 Klassediagram...........................................................................................................................................................21
4.2.3 Dataoverførsel............................................................................................................................................................21
4.2.4 Gentegning.................................................................................................................................................................22
4.3 Implementering.....................................................................................................................................................................23
4.3.1 Filer..................................................................................................................................................................................23
4.3.2 Data-panel..................................................................................................................................................................23
4.3.3 Test-applikation.........................................................................................................................................................24
4.3.4 Hjemmeside................................................................................................................................................................26
4.3.5 Placering......................................................................................................................................................................26
4.3.6 Systemafvikling.........................................................................................................................................................27
4.4 Test..........................................................................................................................................................................................27
5 Modtager.................................................................................................................................................................................30
5.1 Analyse....................................................................................................................................................................................30
5.1.1 Systemanvendelse....................................................................................................................................................31
5.1.2 Dataoverførsel............................................................................................................................................................32
5.1.2.1 Analog og digital signalbehandling...........................................................................................................32
5.1.2.2 Kodning..............................................................................................................................................................35
5.1.2.3 Visualisering......................................................................................................................................................36

5.2 Design.....................................................................................................................................................................................37
5.2.1 Aflæsning af signal..................................................................................................................................................37
5.2.2 Overførselsprotokol.................................................................................................................................................38
5.2.3 Tilstandsmaskine......................................................................................................................................................39
5.2.4 Kommandoer............................................................................................................................................................40
5.3 Implementering.....................................................................................................................................................................40
5.3.1 Filer..................................................................................................................................................................................40
5.3.2 Opsætning..................................................................................................................................................................41
5.3.3 Interrupts.......................................................................................................................................................................41
5.3.4 Opbygning...................................................................................................................................................................41
5.3.5 Datamodtagelse........................................................................................................................................................41
5.3.5.1 Tjeksum..............................................................................................................................................................42
5.3.5.2 Lagring...............................................................................................................................................................42
5.4 Test..........................................................................................................................................................................................42
6 Sender......................................................................................................................................................................................48
6.1 Analyse...................................................................................................................................................................................48
6.2 Design.....................................................................................................................................................................................49
6.3 Implementering.....................................................................................................................................................................50
6.3.1 Filer..................................................................................................................................................................................50
6.3.2 Data-panel (version 2)...........................................................................................................................................50
6.3.3 Dynamisk hjemmeside..........................................................................................................................................52
6.3.4 Systemafvikling.........................................................................................................................................................52
6.4 Test..........................................................................................................................................................................................52
7 Udvidelser................................................................................................................................................................................56
8 Konklusion...............................................................................................................................................................................58
8.1 Systemet................................................................................................................................................................................58
8.2 Processen.............................................................................................................................................................................59
Bilag A - Tidsplan....................................................................................................................................................................60
Bilag B - Logbog.....................................................................................................................................................................62
B.1 Oversigt.................................................................................................................................................................................62
B.2 Detaljer..................................................................................................................................................................................63
Bilag C - Tekniske begreber...............................................................................................................................................65
Bilag D - Kildekode...............................................................................................................................................................67
D.1 Test-applikation..................................................................................................................................................................67
D.1.1 TestApplication.java..............................................................................................................................................67
D.1.2 DataPanel.java (version 1).................................................................................................................................70
D.1.3 index.html..................................................................................................................................................................73
D.1.4 template.css............................................................................................................................................................74
D.2 Modtager.............................................................................................................................................................................74
D.2.1 main.c........................................................................................................................................................................74
D.2.2 picutil.h......................................................................................................................................................................79
D.2.3 picutil.c......................................................................................................................................................................80
D.2.4 Init.h............................................................................................................................................................................80
D.2.4 init.c............................................................................................................................................................................80
D.2.5 isr.c.............................................................................................................................................................................81
D.3 Sender..................................................................................................................................................................................83
D.3.1 Transmitter.java.....................................................................................................................................................83
8.2.1 D.3.2 DataPanel.java (version 2)......................................................................................................................88
D.3.3 index.php.................................................................................................................................................................92
D.3.4 template.css (replikeret).....................................................................................................................................93

1 Indledning
Der er, specielt i USA, en kæmpe industri inden for gave- og lykønskningskort, som de
pågældende producenter forsøger at skabe opmærksomhed omkring ved at gøre dem så
specielle som muligt. Her i Danmark er gavekort typisk almindelige check-lignende papirlapper,
dekorative kort, og den mere luksuriøse slags kommer enten i klodsede indpakninger eller som
plastikkort i stil med personlige kreditkort. Lykønskningskort fås også med elektronik, der bl.a.
kan frembringe metallisk klingende lyde, som de fleste vel nok er stødt på ved lejligheder som
fødselsdage og jul – men over there (i USA) er der en hel industri, hvad sådan noget angår.
Man kan eksempelvis få plastikkort med blinkende juletræer og talende tegneseriefigure – blot
for at nævne nogle få. Firmaet Cardlab har i samarbejde med Prevas udviklet et såkaldt
wavecard 1 (altså et kort man ryster eller vinker med), der vha. blot syv lysdioder viser en tekst
frit i luften – og så er kortet endda kun på størrelse med et almindeligt kreditkort, hvor de
amerikanske oftest er ret tykke (ca. 3-4 mm). Wavecards er, i modsætning til de tykke kort,
lige så fleksible som plastikkort, og de kan derfor opbevares sammen med ens stadigt
voksende samling.
Går man skridtet videre og gør wavecards mere personlige, så brugeren selv kan bestemme
hvilken tekst, der frit skal svæve i luften, vil produktet kunne anvendes i flere sammenhænge
og dermed være mere interessant for kunden. Det vil være sjovere for brugeren, hvis
produktet gøres mere gadget-agtig, så det skaber omtale, og venner og bekendte inspireres til
at få fingre i et wavecard. Det kan eksempelvis opnås, ved at man selv nemt og hurtigt kan
omprogrammere kortet med personlige hilsner eller tekster til forskellige lejligheder.
Mulighederne er mange – eksempelvis foreslår Cardlab på deres hjemmeside, at man til
koncerter vil kunne mindske risikoen for ildspåsættelse ved at bruge kortene i stedet for
lightere til at udtrykke sig med.
Det vil dog være forholdsvist ressourcekrævende og besværligt at installere
programmeringsudstyr hos hver enkelt bruger eller forhandler af kortene. Den ideelle løsning vil
være at overføre tekster med udstyr, som er tilgængelig for alle og enhver – nemlig vha. en
helt almindelig computer med skærm.
Opgaven udføres i samarbejde med Prevas A/S, der er blandt de førende i norden inden for
embedded (indlejret) systemudvikling. Rapporten udgør den skriftlige del af det afsluttende
eksamensprojekt for IT-diplomingeniører ved Danmarks Tekniske Universitet (DTU). Dette
dokument belyser problemstillinger og overvejelser, der ligger til grund for udviklingen af den
bagvedliggende teknik for overførsel af forholdsvis små datamængder fra en computerskærm.
1 Wavecard: http://www.cardlab.com/Wavecard.htm
6 Indledning

Der vil blive givet en analyse af den anvendte metode til optisk dataoverførsel til en
microcontroller med en skærm som interface, og derudfra vil der blive foretaget en vurdering
af systemets robusthed ved fejlbetjening. Ligeledes skabes et overblik over nogle af de
problematikker, der gør sig gældende vedrørende fysiske forhold for denne form for
kommunikation.
Rapporten afspejler projektets arbejdsproces, hvor hver delkomponent udvikles hver for sig. En
forundersøgelse beskriver projektets kontekst og opstiller en kravspecifikation for funktionelle
og fysiske krav til den samlede løsning, hvorefter overvejelser ang. systemets anvendelse
belyses. I et afsnit for sig skabes der overblik over forsøgsopstillingen og arbejdsopgaverne. Jf.
forordet vil opgaven være delt i to. Der er dog i virkeligheden tale om tre – hhv. en test-
applikations-del samt en modtager- og en sender-del. Hver del er struktureret i fire
udviklingsfaser: En analyse afgrænser løsningen, og der træffes overordnede beslutninger for
funktionaliteten. Løsningen konkretiseres og detaljer fastlægges i designfasen. Dokumentation
for implementeringen består af fremhævede tekniske detaljer i forbindelse med selve
udviklingen, der kræver yderligere kommentarer. I hvert testafsnit undersøges, hvorvidt den
implementerede løsningen lever op til de stillede krav. Sidst i rapporten undersøges
mulighederne for fremtidige udvidelser, og der konkluderes på baggrund af de opnåede
testresultater. Rapportens bilag indeholder en tidsplan for projektet, en logbog over
arbejdsprocessens faktiske forløb, en mindre ordbog over tekniske betegnelser og den
samlede kildekode. På den vedlagte DVD findes nærværende rapport inklusiv bilag samt
kildekoden. Alle henvisninger forekommer som fodnoter i rapporten.
Outputtet fra skærmen (senderen) laves som en Java-applet vha. Eclipse 2 samt den seneste
Java-compiler fra SUN Microsystems. Microcontrollerens firmware (modtageren) er
implementeret i ANSI C i udviklingsmiljøet MPLAB 3 fra Microchip sammen med den officielle
PIC-compiller, PICC fra Hi-Tech Software. Dokumentationen udarbejdes i OpenOffice.org, og
illustrationer behandles i programmerne Dia, Inkscape og The GIMP.
2 Eclipse Platform: http://www.eclipse.org/
3 MPLAB Integrated Development Environment: http://www.microchip.com
Indledning 7

2 Forundersøgelse
Følgende afsnit vil forsøge at skabe overblik over projektet og placere det i den rette kontekst.
Der gives en beskrivelse af baggrunden for projektet og sammenhængen med andre
projekter, hvorudfra formålet beskrives. Derudover indkredses projektets interessenter – altså
de involverede parter – og målgruppen fastlægges. Krav til systemet konkretiseres og
afgrænses, og der kigges nærmere på forskellige løsningsmuligheder. En foreløbig tidsplan
udarbejdes, og eventuelle risikomomenter forsøges afklaret.
2.1 Baggrund
Prevas har udviklet et wavecard for Cardlab. Ved første øjekast ligner wavecardet et helt
almindeligt plastikkort, ligesom kreditkort, benzinkort og tilsvarende. Wavecardets elektronik er
opbygget på et yderst tyndt lag film, der udgør dets PCB (printplade), hvorpå der er monteret
et tyndt aflangt batteri, en meget lille MCU (microcontroller), syv små LEDs (lysdioder) samt en
piezo. Den sidstnævnte består af en flad piezo-krystal
monteret på en tynd metalplade og anvendes typisk
som højttaler i digitalure, alarmsystemer mv. Den
udsender lyd ved at påvirke krystallet med en
spænding, hvilket får krystallet, og dermed også
metalpladen, til at trække sig sammen og udvide sig
med høj hastighed. Den sætter altså luften i
svingninger, hvilket er opskriften på lydbølger, hvorfor
der fremkommer et lydsignal. I wavecardet fungerer
piezo'en dog lige omvendt. Den sender
udefrakommende bevægelser til en ADC (analog-til-digital-converter) på MCU'en, der så kan
registrere hurtige bevægelser over nul-punktet (udgangspunktet) på X-aksen (set i forhold til et
kort der vender på højkant). Microcontrolleren skal sørge for at tænde og slukke lysdioderne i
forhold til kortets position, så den forventede tekst fremstår rigtigt i luften (se illustration 1 der er
hentet fra Cardlabs website 4 ).
2.2 Sammenhæng
I øjeblikket udvikles der på sideløbende plastickort-projekter. Disse er for øjeblikket
hemmeligstemplede, hvorfor der desværre ikke kan refereres til dem i denne rapport.
4 Wavecard på Cardlabs website: http://www.cardlab.com/Wavecard.htm
Illustration 1: Et wavecard rystes i luften.
8 Forundersøgelse

2.3 Formål
Der skal udvikles en prototype af wavecardet, der kan programmeres, så enhver med
adgang til internettet, vil kunne gøre deres wavecards personlige. En forhandler eller bruger
indtaster en personlig tekst, som derpå overføres til kortet. Betjeningen skal være så simpel
som mulig, da man ikke på forhånd kan sige noget om de personer, der i sidste ende
anvender produktet. Ligeledes skal der være mulighed for, at enhver er i stand til at
omprogrammere kortene vha. alment tilgængeligt udstyr. Man kan hverken forvente, at
brugeren har mere eller mindre avancerede programmeringsenheder til sin rådighed – end
heller at brugeren på nogen måde er teknisk kyndig.
På længere sigt vil resultatet af projektet kunne benyttes i mere seriøse sammenhænge som
eksempelvis til en videreudvikling af det ovenfor beskrevne kort til aflæsning af fingeraftryk.
2.4 Interessenter
Projektet (se de involverede i figur 2) er led i undertegnedes afsluttende opgave ved DTU med
Edward Todirica som vejleder og Bjarne Madsen som ekstern vejleder. Opgaven afvikles hos
Prevas, der har udviklet wavecardet for Cardlab med Finn Nielsen som projektleder. Bo Neis
er studiemedhjælper hos Prevas og arbejder bl.a. med udviklingen af hardware-prototyper af
wavecardet. Det er ham, der kommer til at udvikle den hardware, der skal modtage signaler
fra skærmen.
Forhandlerne af wavecardet og deres kunder
(brugerne) udgør de primære målgrupper for det
program, der skal udvikles til at overføre tekster fra
computerskærmen til wavecardet. Disse to
brugergrupper omfatter ukendte personer, der skal
være i stand til at håndtere programmeringen af
kortene. Derudover udvikles en test-applikation til
brug for nuværende og fremtidige hard- og
softwareudviklere til projekter, hvor der arbejdes
med optisk datatransmission.
Bo Neis udvikler et simpelt stykke hardware, der
skal benyttes til at simulere modtager-delen ved at
omdanne billedesignaler til et elektrisk signal. Denne
prototype består af et hulprint på størrelse med et kreditkort, hvorpå der sidder forskellige
elektriske komponenter – bl.a. nogle solceller der skal opfange skærmens lyssignaler. Læs
mere om prototypen, udviklingsmiljøet og forsøgsopstillingen i afsnit 3.
Illustration 2: Projektets omgivelser.
Forundersøgelse 9

2.5 Kravspecifikation
I tabel 1 herunder opstilles nogle krav til det samlede system jf. opgaveformuleringen. Hvert af
disse krav har et identifikationsnummer samt et tilhørende unikt navn, der udgør en titel for
beskrivelsen af det pågældende krav. Kravene er prioriterede, så primære krav har værdien 1,
og krav, der bør vente, har værdien 5. De kan kort beskrives på følgende måde:
● 1. prioritet (must have): Fundamentale krav til systemet der skal opfyldes.
● 2. prioritet (should have): Vigtige krav der bør opfyldes, hvis det er muligt.
● 3. prioritet (could have): Krav af mindre betydning.
● 4. prioritet (nice to have): Krav der godt kan vente.
● 5. prioritet (would like to have): Forslag til senere versioner.
Desuden kan kravene inddeles i forskellige typer, der i dette tilfælde begrænser sig til
funktionelle (F) og fysiske (I for ikke-funktionelle) krav.
Det tilstræbes i denne opgave, at alle krav med de to højeste prioriteter bliver realiseret.
# Navn Beskrivelse Pri. Type
01 Applikation En Java-applet skal overføre data til en microcontroller. 1 F
02 Medie Data overføres via en skærm. 1 I
03 Hjemmeside Appletten skal køres fra en hjemmeside. 1 F
04 Placering Appletten skal vises nederst på hjemmesiden. 1 I
05 Multi-transfer Flere områder på appletten skal overføre data. 5 F
06 Tekst Appletten modtager data via et tekstfelt. 1 F
07 Kodning Data skal kodes. 1 F
08 Modtager Microcontrolleren skal modtage data via optisk overførsel. 1 F
09 Sensor, solo Overførslen sker til en lysfølsom sensor. 1 I
10 Sensor, multi Flere lysfølsomme sensorer skal modtage data individuelt. 5 I
11 Dekodning Modtagne data skal tjekkes for fejl og dekodes. 1 F
12 Visualisering Data skal visualiseres. 1 F
13 Prototype En simpel model skal udgøre en prototype for systemet. 1 I
14 Størrelse Prototypen skal være på størrelse med et plastickort/smartcard. 2 I
Tabel 1: De opstillede krav jf. opgavebeskrivelsen.
10 Forundersøgelse

2.6 Afgrænsning
Metoden til hvorledes wavecardet sættes i programmerings-tilstand undersøges, og der skal
foretages en vurdering af de forhold, hvorunder kortet fungere optimalt – herunder lysforhold
og skærmtyper. Programmet til overførsel af tekster skal kunne benyttes af så mange brugere
som muligt – både hvad angår et intuitivt brugerinterface og kompatibilitet med diverse
browsere. Emner som konvertering mellem analoge og digitale signaler, seriel kommunikation,
kodning samt systemets forskellige tilstande vil blive berørt i rapporten.
Der foretages en vurdering af den udleverede prototypes stabilitet, og der kigges nærmere på
muligheden for overførsel af flere bits ad gangen vha. gråtoner VS. s/h-signaler.
For yderligere informationer vedrørende afgrænsningen henvises til rapportens forord.
2.7 Løsningsmuligheder
I forbindelse med opstarten af projektet er der blevet talt om at anvende wavecardets
lysdioder til at modtage data fra skærmen, hvilket ville betyde, at der ikke skulle tilføjes
yderligere komponenter til selve kortet. Der er dog to væsentlige årsager til, at prototypen ikke
er implementeret på denne måde. For det første skal der arbejdes målrettet på at udvikle et
specielt forstærkerkredsløb til at give nogle tydelige signaler – og for det andet vil wavecardet
ikke samtidig kunne kommunikere informationer til
brugeren.
Der blev også talt om at bruge en lysfølsom modstand,
men det endelige valg faldt på solceller, da de ikke
bruger strøm og fås i udgaver med forskellige fysiske
egenskaber mht. stige-/faldetider, spænding mv.
Desuden findes der udgaver, der er så fleksible, at de vil
kunne benyttes til plastikkort. Udover solcellerne benyttes
et forstærkerkredsløb og muligvis en form for filter til at
filtrere forskellige lyskilder fra.
Det er før lykkedes at lave produkter, der kan modtage
data fra en skærm. I midten af 1990'erne introducerede
Timex 5 et ur (se illustration der er hentet fra Wikipedia),
som kunne modtage data via skærme med billedrør
igennem en linse placeret over dens display.
5 Timex Datalink: http://en.wikipedia.org/wiki/Timex_Datalink
Illustration 3: Timex-uret kan modtage
data fra en computerskærm.
Forundersøgelse 11

2.8 Tidsplan
Der er for projektet udarbejdet en tidsplan, som illustrerer de enkelte delområders
afhængighed. Eksempelvis skal test-appletten udvikles før modtageren, så denne kan
kalibreres. Test af senderen er afhængig af modtageren osv. Tidsplanen findes i bilag A
bagerst i rapporten.
2.9 Risikomomenter
Projektet rummer nogle usikkerhed, hvilke kan hindre et optimalt projektforløb og komme i
vejen for et positivt udfald af det endelige system.
● Hardware-prototypen er under stadig udvikling. Der har desværre været nogle
uregelmæssigheder i de signaler den genererer efter monteringen af et par simple
komponenter til at filtrere høje frekvenser fra (et såkaldt low-pass filter – læs mere
herom i afsnit 3.1.3). Filtret har nogle lange ledninger, som kan påvirkes af støj, blot en
person nærmer sig. Bliver der ikke rettet op på dette, vil signalerne kunne have
indvirkning på udviklingsprocessen i forbindelse med implementering og test af
systemet. Der skal med andre ord foretages mere nøjagtige målinger af hardwarens
output.
● Programmeringsenheden (se afsnit 3.1.1), hvorpå microcontrolleren er fastmonteret,
opfører sig til tider uheldigt. Man har desværre ikke fuld kontrol over opsætningen af
microcontrolleren, hvorfor det bør overvejes at skifte til en anden måde at flashe
(programmere) chippen på. Den fastmonterede chip er i familie med den, der anvendes
på wavecardet, men det er ikke nøjagtigt den samme type. Det bør derfor medtages i
overvejelserne at skifte chip-type og udviklingsmiljø, da dette vil kunne gavne
udviklingsprocessen på længere sigt. Der er dog et trade-off forbundet hermed, da
udviklingen vil være længere tid om at kunne påbegyndes.
12 Forundersøgelse

3.1 Udviklingsmiljøet
3 Overblik
Her gives et indblik i den hardware, der benyttes til udviklingen af den optiske dataoverførsel til
wavecardet. Forholdsvist tidligt i udviklingsprocessen blev der skiftet udviklingsmiljø. I
begyndelsen anvendtes et af Prevas' egne produkter kaldet Webnet til at kommunikere med
en microcontroller på et tilhørende udviklingskort. Dette modul er egentlig beregnet til at
kommunikere med forskellige former for maskiner via et netværk. Tidligere nævntes en række
risikomomenter (afsnit 2.9), hvor netop problemer med udviklingsmiljøet blev nævnt. Problemet
skyldtes flere ting – bl.a. overtager Webnet'en en del af kontrollen over microcontrolleren, så
der eksempelvis kan være besvær med at styre interrupts og andre ting. Desuden er der
ingen mulighed for debugging – og sidst men absolut ikke mindst tager det ret lang tid at
reprogrammere chippen. I stedet blev der bestilt en microcontroller af samme type som
wavecarets samt en programmeringsenhed, der virker med Microchips MPLAB IDE – altså et
helt udviklingsmiljø.
3.1.1 Webnet-modul
Det første udviklingsmiljø var ikke noget rigtigt udviklingsmiljø. De anvendte komponenter ses i
figur 4, som viser et udviklingskort med et såkaldt Webnet-modul monteret i en sokkel på dets
underside. Webnetten er hjernen i systemet og har en masse funktionalitet – bl.a. en
webserver, hvortil ens programmer uploades efter at være blevet compilet. Denne proces
tager imidlertid rigtig lang tid (fra 30 sekunder og op – alt afhængig af HEX-filens størrelse) at
udføre gang på gang, og da
der ikke er nogen debugger
tilknyttet, og man på ingen
måde kan overvåge
systemet, ser det lidt sort ud.
Som vist på oversiden af
udviklingskortet (til højre i
figuren) er der dog en
terminal-port tilknyttet; men
her skal man selv opsætte
Illustration 4: Det første udviklingsmiljø.
en seriel forbindelse i microcontrolleren og evt. skrive til et terminalprogram, hvilket også lod sig
gøre dog uden at have samme kontrol og indsigt som ved brug af en debugger. For at
Overblik 13

komme i kontakt med de enkelte ben på microcontrolleren, blev der lavet et kabel med nogle
stik, som for eksempel ville passe i et breadboard.
Endnu en årsag til at skifte udviklingsmiljø ligger i det autentiske – ved at arbejde med netop
den chip-type som wavecardet besidder.
3.1.2 Microchip MPLAB ICD2
Programmeringsenheden (den runde boks på
illustration 5) er Microchips egen ICD2, der
kan programmere stort set alle PIC-chips på
markedet. Den forbindes til en PC via et
USB-kabel (af typen A-B), hvorfra den også
får strøm til at programmere microcontrolleren
og dens status vises via nogle kontrollamper.
Ønsker man at tildele strøm til det system,
man udvikler, kan det gøres via en ekstern
strømforsyning. Microcontrolleren forbindes til
ICD2'en via et fladkabel (med RJ25-stik i programmerens ende og IDC-stik i chippens ende)
som vist i detaljer på illustration 6. Der benyttes fem ben til kommunikation mellem PIC-chippen
og ICD2'en. PIC'en kræver en høj spænding (12V) på VPP-benet for at programmere den.
Illustration 6: Detaljer for fladkabel.
Illustration 7: Programmerings-interface.
Illustration 5: Microchip ICD2 (In-Circuit Debugger).
Datasignalerne ryger ind og ud via PGD og styres
med et clock-signal via PGC. VDD (i andre
sammenhænge også kaldet VCC, V+ eller VS+) er
positivspændingen, og VSS er stel (eller ground). Da
der ikke er noget development board til at forbinde
enden af fladkablet med microcontrolleren, har
undertegnede selv måtte lave et vha. et så kaldt
breadboard (fumlebræt), hvilket beskrives yderligere
nogle afsnit herunder (se afsnit 3.1.4).
For at kunne tilslutte enden af programmeringkablet
er der blevet lavet et lille print (se illustration 7) med
nogle stik, som skaber de rigtige forbindelser mellem
ICD2-enheden og microcontrolleren på breadboardet.
Den venstre del af figuren viser benene på
undersiden af stikket, der går ned i breadboardet,
hvor de tre pins, der sidder på række, hhv. går
direkte ind på microcontrollerens plus-, data- og clock-ben. VPP og Ground føres manuelt rundt
om chippen og går ind på de respektive ben. De to plus-ben er shunted (parallelkoblet) og
tilfører samtidig hele systemet en positiv spænding – ligesom ground udgør stel for hele
systemet. Den højre del af figuren viser IDC-stikkets tilslutning på oversiden af det
14 Overblik

hjemmelavede stik.
Ved brug af Webnet'en (beskrevet tidligere) var der ikke
tilknyttet noget IDE (software udviklingsmiljø), for at knytte
en avanceret teksteditor sammen med compiler og
debugger. Dette er heldigvis tilfældet med denne løsning,
hvor Microchip har sørget for, at det hele smelter
sammen. Programmet MPLAB IDE (se illustration 8)
integrerer netop disse dele med hinanden. Projektfiler
hånteres via en velkendt træstruktur og ændres med
editoren, der selvfølgelig viser kildekoden i farver. Den
officielle compiler (PICC fra Hi-Tech Software) giver et
hurtigt overblik over ressourceforbruget af programmet
samt eventuelle syntax-fejl (errors) i koden og advarsler om mulige semantiske misforståelser
(warnings). Der er hurtig adgang til at flashe (programmere) microcontrolleren og styre
afviklingen af programmet, der giver mulighed for debugging og øjebliksbilleder af ønskede
variabler. Ligeledes kan indholdet af EEPROM'en vises efter at have stoppet programmet.
3.1.3 Hardware-prototype
Der er udarbejdet en prototype (vist i
illustration 9) bestående af et simpelt
veroboard (hulprint/printplade), hvorpå der er
monteret en række serieforbundne solceller og
i første omgang en op.amp. (operations-
forstærker/forstærkerkredsløb). Senere er der
tilføjet et low-pass filter mellem solcellerne og
forstærkeren.
Forstærkeren blev implementeret, da der ikke
kunne genereres nok spænding på udgangen
af solcellerne til at detektere signalerne med
microcontrolleren.
Solcellerne kan aktiveres individuelt – og antallet af aktive solceller afgør hvor meget spænding
der leveres på forstærkerens udgang. For at give en idé om størrelsesforholdet er her et
eksempel på outputtet ved forskellige input fra skærmen:
Illustration 8: Microchip MPLAB IDE.
Illustration 9: Hardware-prototypens bestanddele.
Når farven på skærmen er sort, giver det et logisk 0 (ca. 531mV ved 3V forsyning til op-amp),
og strøm forbruget for hele kredsløbet er ca. 26 µA. Ved et hvidt signal på skærmen får man
et logisk 1 (ca. 2,28V ved 3V forsyning til op-amp), og strømforbruget for hele kredsløbet er
ca. 11 µA. Med en 5V forsyning til op-amp giver en sort skærm ligeledes et logisk 0 (ca.
531mV) og et strøm forbrug for hele kredsløbet på 32µA. Hvid skræm giver igen et logisk 1
Overblik 15

(ca. 4 V) og et strømforbrug for hele kredsløbet på 34µV. Ud fra printet går en ledning, hvor
den grønne er VCC (positiv-spændingen), brun er ground – og endelig den hvide der er
outputtet fra op-amp. Der er monteret et stik som passer ned i breadboardet.
Low-pass filtrets knækfrekvens (ωc) er sat til
30Hz, så alt over denne frekvens dæmpes
fra. Selve filtret består blot af en kondensator
(33nF) i serie med en modstand (1M Ω).
Bag på boardet sidder i alt fem solceller i serie
(vist i illustration 10). Disse solceller kan kobles
til og fra via jumpers. Ved op-amp'en bruges
den ene af de to modstande til at sætte gain,
- og den er monteret så den kan udskiftes og
hvormed gain ændres. Modstandene ved op-amp, R1 og R2, har hhv. værdierne 15k Ω og
330k Ω,
hvilket giver et gain på 23.
3.1.4 Forsøgsopstilling
Figuren (illustration 11) viser et hjemmelavet development board konstrueret på et så kaldt
breadboard, hvor forbindelserne løber som vist med markeringerne i cirklen – altså på langs
ude i kanten og på tværs de andre steder. Ledningerne længst til højre forbinder de to
langsider med hinanden, hvor VDD
(plus) og VSS (stel) løber.
Microcontrolleren (angivet som MCU
på billedet) er forbundet via det
hjemmelavede interface med VDD,
PGD og PGC (som omtalt i afsnit
3.1.2). Ligeledes er hele systemet
forsynet med strøm via det
hjemmelavede interface øverst i
billedet. VPP føres rundt om MCU'en
og ind på samme ben som MCLR
(der holdes høj med en pull-up modstand), og stel tilsluttes på benet ved siden af.
Microcontrolleren kan nulstilles ved kortvarigt at trække MCLR lav (altså til stel). Det er muligt at
slutte strøm til systemet via et batteri, hvis man vil undgå afhængighed af en ekstern
strømforsyning (tilsluttet programmeringsenheden). En lysdiode indikerer, om der er strøm på.
Det ovenfor beskrevne er minimum-kravet til systemet for at kunne arbejde med PIC'en.
Dataoverførsel fra en computerskærm gøres muligt via en ADC-pin tilsluttet solcellerne – eller
rettere udgangen af forstærkerkredsløbet (beskrevet i afsnit 3.1.3). Desuden er der monteret
nogle lysdioder for at kunne simulere wavecardets output. De er trukket høje, hvorfor de er
aktivet lave.
Illustration 10: Prototypen set fra skærmen.
Illustration 11: Hjemmelavet development board.
16 Overblik

Selve microcontrolleren er af typen PIC-16F819 6 , der er spækket med funktionalitet – bl.a. en
intern oscilator fra 31 kHz til 8MHz, 3584 bytes programhukommelse, 256 bytes SRAM, en
EEPROM på 256 bytes, 16 I/O-porte, en 16-bit timer, to 8-bit timere, en 10-bit 5-kanals ADC,
16-bit capture og compare, 10-bit puls-bredde-modulator, SPI og I 2 C (slave). Med al den
funktionalitet kan man godt tvivle på om Prevas bliver ved med at benytte netop denne chip til
deres wavecards, da det burde være muligt at finde en MCU med et par ADC'er (til piezo og
solceller) og en enkelt 8-bit port (til LEDs) noget billigere end denne temmeligt kraftige
microcontroller.
3.2 Opgaven
Overordnet set består den samlede opgave i at udvikle flere programmer, hvilke består af
yderligere delopgaver. Samlet er der tale om tre programmer, som løses hver for sig i deres
egne dele af rapporten, hvor der fortages en analyse og et design af den givne problemstilling
hvorefter programmet implementeres og testes:
● Test-applikation (Java-applet)
○ Analyse
○ Design
○ Implementering
○ Test
● Modtager (Firmware til wavecardets microcontroller)
○ Analyse
○ Design
○ Implementering
○ Test
● Sender (Java-applet)
○ Analyse
○ Design
○ Implementering
○ Test
Hvert enkelt program ligger op til løsningen af de følgende, så disse kan testes vha. hinanden.
Test-applikationen er en Java-applet (hvorfor den også omtales test-applet), der udvikles for at
kunne implementere og teste modtageren. Den kan blinke med skærmen i forskellige nuancer
og med variabel frekvens og duty-cycle. Desuden laves der en hjemmeside, som kan vise
appletten, så den fremtidige udvikling af modtageren kan testes blot vha. en internetforbindelse.
Modtageren er selve wavecardet, der overordnet set består af en microcontroller med
forskellige I/O-enheder. Den testes ved at benytte test-applikationen. Senderen er en
videreudvikling af test-applikationen, som kan transmittere data til modtageren via en
hjemmeside. Modtageren benyttes til at teste senderens funktionalitet og stabilitet.
6 PIC-16F819 datablad: http://ww1.microchip.com/downloads/en/DeviceDoc/39598e.pdf
Overblik 17

4 Test-applikation
Der skal udarbejdes et testprogram, som er en mini-udgave af den endelige sender-
applikation, til at understøtte både soft- og hardwareudviklingen af modtageren. Programmets
formål er at generere pålidelige datasignaler fra skærmen. For at kunne bruge outputtet til
noget fornuftigt er det nødvendigt at kende de forhold, som wavecardet skal operere under.
Man er bl.a. nødt til at kende til forskellige typer af skærme, og vide hvordan de opfører sig.
Det vil også være nyttigt at vide, om et lokales lysforhold kan påvirker wavecardets sensorer
mv. Yderligere strukturers og implementeres en hjemmesideløsning, hvorfra appletten kører fra.
Til sidst undersøges systemets anvendelighed ud fra udførte tests.
4.1 Analyse
Test-applikationen henvender sig til systemudviklere, og den skal bruges til at teste hardwaren
vha. systematiske input. Programmet implementeres som en Java-applet, så den kan
anvendes fra en hvilken som helst computer med en internetopkobling og grafisk
brugerinterface. Dens opgave består i at udsende blinke-signaler i en, af brugeren, defineret
rytme, hvorfor det skal være muligt at variere
både frekvensen, hvormed der blinkes, samt
on-/off-tiden for det enkelte blink. On-tiden går
under betegnelsen duty-cycle. Derudover skal
det være muligt at ændre kontrasten mellem
blinkets høje og lave del for at gøre det muligt
at undersøge og justere hardwarens
lysfølsomhed.
Illustration 12 viser et udkast til applettens
opbygning. De to kasser med runde hjørner
repræsenterer hver sin del af programmet,
hvoraf den store er selve appletten og den lille
udgør et data-panel med det blinkende område
(markeret med grå). De ovenfor beskrevne
funktionaliteter, for styring af frekvens, duty-
cycle og kontrast, er repræsenteret vha. de lodrette scroll-bars. Der er ligeledes placeret en
knap, mærket ”Test” til at tænde og slukke for signalerne.
Illustration 12: Prototype af test-applet.
18 Test-applikation

4.1.1 Skærmteknologier
Normalt benyttes skærme som en form for vindue, der omdanner elektriske signaler til
information til brug for levende mennesker – hvad end der er tale om TV-billeder eller
statusmeddelelser for maskiner. Det nye, ved den måde hvorpå skærmen anvendes i dette
projekt, ligger i modtager-delen, da det nu er en maskine, der skal kunne forstå billederne.
Senderen genererer billeder i stedet for elektriske signaler, og det er modtagerens opgave at
regenerere de elektriske signaler ud fra billederne. Da der er forskel på skærme, er det
nødvendigt at kigge nærmere på de forskellige typer. Her omtales kun traditionelle
computerskærme med katoderør og displays, da de udgør den aller største del på markedet
– hvorfor plasma- og laserskærme ikke vil blive berørt yderligere.
Ældre skærme (se illustration 13, der er hentet
fra Wikipedia 7 ), af typen CRT, benytter en
elektronkanon (1) – kaldet et katoderør – til at
sende elektronstråler (2) mod et positivt ladet
område (5). Undervejs samles (3)
elektronstrålerne og rettes (4) mod et bestemt
punkt på et fint-maske net (6), der sorterer de
tre ”grundfarver”. Derefter rammer strålerne
forskellige fluorescerende fosforlag (7 og 8) på
indersiden af en glasplade, hvilket får den til at
udsende lys, i det korte øjeblik pladen rammes
af elektroner. Elektronkanonen starter i
skærmens øverste venstre hjørne (set fra seerens synsvinkel) og bevæger sig så i læse
retning mod nederste højre hjørne.
Skærmens opdateringsfrekvens (eng. refresh rate måles i hertz) er et udtryk for, hvor mange
gange i sekundet billedet på skærmen gentegnes. Bliver opdateringsfrekvensen for lav, vil øjet
registrere gentegnigerne som irriterende blink.
Skærmen opdateres i samme takt som den strøm, der kommer ud af en stikkontakt. I Europa
er denne frekvens 50Hz, hvorfor hele skærmbilledet vil være opdateret 50 gange i sekundet.
Det sker ved hhv. at opdatere de lige og ulige linjer med hver 25Hz.
CRT-skærme har det, man kalder efterglød ligesom elektriske pærer, der skal bruge nogle
millisekunder på at lyse helt op og slukke helt. Grunden, til at man ikke blot vil se en masse
små blinkende punkter, skyldes en kombination af eftergløden og den, i forhold til øjet, høje
opdateringsfrekvens.
Nyere CRT-skærme opdateres ved højere frekvenser end 50 Hz, da man gradvist har været
nødt til at mindsket eftergløden. Sætter man eksempelvis sin computer til sit halv-gamle TV, vil
billedet fremstå gnidret og tåget, og musen vil eksempelvis ikke kunne følge med – der opstår
7 CRT: http://en.wikipedia.org/wiki/Cathode_ray_tube
Illustration 13: Skærm med CRT-teknologi.
Test-applikation 19

”haler” efter musen, som det kaldes. For at computerskærme kan leve op til de gradvist højere
krav til hurtig grafik, der ofte kræves af computerspil, 3D-programmer og lignende, er
eftergløden blevet mindsket. Dette har dog resulteret i øgede krav til opdateringsfrekvensen af
billedet, for at øjet ikke skal nå at opfatte at skærmen i virkeligheden blinker.
De mere moderne fladskærme benytter et dot-matrix AMLCD (LCD-display) – se illustration 14,
der også er hentet fra Wikipedia 8 . Hver pixel består af tre TFT'er til at belyse de enkelte
punkter på skærmen med hhv. rød, grøn og blå. Der anvendes altså ikke elektronstråler, og
dermed opdateres billedet ikke på samme måde som ved CRT-skærme, men i stedet vises et
fast billede.
Illustration 14: Fladskærm med
TFT-teknologi.
En TFT-skærm vil oftest have en opdateringsfrekvens på
60Hz, hvilket svarer til skærmens vertikale opdatering 9 .
Ved at ændre spændingen (målt i volt) til skærmens
baggrundslys, f.eks. vha. PWM (puls-bredde modulation), kan
man styre skærmens lysintensitet. Dette kan dog imidlertid
resultere i højfrekvente blinke-signaler, som en lysfølsom
sensor vil kunne registrere.
TFT-skærmens responstid (for tiden målt i millisekunder) er et
udtryk for, hvor lang tid det tager at gentegne skærmen –
altså den tid et enkelt punkt skal bruge for at kunne nå at
skifte fra en farve til en anden og tilbage igen. Des lavere
responstid des mere flydende vil bevægelser i billedet opfattes.
Ofte vil responstiden være målet for en gråtone-overgang
(grey-to-grey eller G2G) og ikke efter den oprindelige sort/hvid-overgang jf. ISO-standarden –
hvor en skærm målt efter den første metode vil give et tilsyneladende ”flottere resultat”. Der
kan dog argumenteres for at forhandlerne benytter sig af resultaterne af G2G-målinger, da
skift mellem helt sort og helt hvid forekommer sjældent ved alment brug.
4.1.2 Lysforhold
Det kan ikke antages, at modtageren på forhånd er kalibreret til en bestemt mængde lys, da
brugeren kan befinde sig i alt fra et oplyst kontor til en mørk kælder. På forhånd kan der heller
ikke siges noget om brugerens behov for lys på skærmen – eller mangel på samme. Ideelle
signaler er derfor udelukket fra starten, hvilket kommer til at gøre designet af modtageren
mere besværligt. Disse forhold kan simuleres vha. ændringen af kontrasten i appletten, så
man nøjagtigt kan definere bestemte gråtone-værdier for højt og lavt signal.
8 TFT-LCD: http://en.wikipedia.org/wiki/Thin_film_transistor_liquid_crystal_display
9 TFT refresh rate: http://www.tftcentral.co.uk/specs.htm
20 Test-applikation

4.2 Design
Efter at have analyseret de fysiske forhold, for miljøet hvori dataoverførslen skal foregå, står
det nu forholdsvist klart, hvilke former for signaler der sendes til modtageren. Rent faktisk
resulterede analysen i en lettere modificering af selve hardwaren, der fik tilføjet et low-pass filter
mellem udgangen på solcellerne og indgangen på forstærkerkredsløbet for at undgå de
forstyrrende PWM-signaler ved dæmpning af skærmbelysningen. Dermed undgår man også
andre højfrekvente lyssignaler fra eksempelvis lysstofrør.
I det følgende foretages en gennemgang af test-applikationens programstruktur, hvor de
enkelte elementer til visning og afvikling af programmets funktionalitet kort ridses op. Et
klassediagram viser rammerne for applettens overordnede opbygning, og der udarbejdes en
teknik til at tegne på skærmen.
4.2.1 Programstruktur
Der vil blive oprettet en fil med HTML-struktur til at vise appletten på en hjemmeside, og
layoutet styres vha. et stylesheet, som placerer indholdet nederst i browser-vinduet i henhold til
kravspecifikationen. Gældende standarder inden for webdesign bør følges, og layoutet skal
kunne vises i så mange browsere som muligt. Der vil ikke gøres noget særligt ud af
brugerinformationer på hjemmesiden, da det i sidste ende vil være op til Cardlab at
underbygge deres nuværende layout og chargon.
4.2.2 Klassediagram
Programmet inddeles i to Java-klasser, hvor TestApplication udgør selve appletten og
indeholder diverse komponenter – bl.a. DataPanel der er det specielle område på skærmen,
som oversætter tekst til data i form af
billedesignaler. Det fremgår af
illustration 15 at DataPanel skal
implementere Runnable. Dette skyldes,
at panelet skal køre i en tråd for ikke
at bruge alle applettens ressourcer på
udelukkende at stå og blinke.
4.2.3 Dataoverførsel
Illustration 15: Overordnet klassediagram for test-appletten.
I princippet vil man kunne overføre data med hastigheder relativt til antallet af farvenuancer på
skærmen og mængden af sensorer på wavecardet. Teknologien er dog på nuværende
tidspunkt begrænset af, hardware-prototypen af wavecardet der blot har en enkelt sensor,
som kun kan detektere gråtoner. De analoge signaler er præget af en del støj, og sænkes
lysstyrken på nyere LCD-skærme, bliver signalet naturligvis endnu dårligere, da kontrasten
bliver lavere, og dermed bliver billedet forholdsvist mørkt. Denne rapport vil først og fremmest
Test-applikation 21

fokusere på binær datatransmission, da hardwarens genkendelse af gråtoner endnu ikke er
tilstrækkeligt udviklet. Dette bevirker imidlertid at dataoverførslen begrænses grundet de
omtalte skift mellem helt sort og helt hvid, som blev omtalt i analysen. Det forventes dog ikke,
at teknologien når at blive så raffineret i løbet af udarbejdelsen af denne opgave, at der opnås
hastigheder, hvor dette bliver et problem. Man bør dog i videreudviklingen af systemet sørge
for at hardwaren implementeres med mere fintfølende modtagere end de nuværende solceller,
så lysniveauerne bedre kan skelnes fra hinanden. Hvis der kan måles en forskel på to
forholdsvist tætliggende gråtoner, vil overførselshastigheden kunne forøges betragteligt.
For at undgå de høje frekvenser er der indsat et filter i hardware-prototypen mellem solcellerne
og forstærkeren. Fladskærme opdaterer som bekendt skærme med 60Hz, så filteret sættes
til halvdelen af max-frekvensen, for at undgå så meget støj som muligt. Dette vil dog let kunne
ændres senere, når man engang har fået systemet til at blive mere stabilt. Med en frekvens
på 30Hz giver det en maksimal overførselshastighed på 30bit/s, hvilket ikke virker særligt
hurtigt, men sammenlignes med datamængden på nogle bytes vil det være ganske fornuftigt.
Ideelt set vil 15 karakterer kunne overføres på fire sekunder. Dertil skal muligvis ligges et par
ekstra bytes for at styre kommunikationen samt et par bits per byte til fejltjek; hvorfor den
endelige overførsel mere sandsynligt vil tage et sted mellem seks til otte sekunder.
Test-applikationen konfigureres til at kunne blinke med skærmen 1-100 gange i sekundet. De
yderligere 30-100 gange er simpelthen grundet fremtidssikring – og signalets duty-cycle kan
varieres mellem 0-100%. Indstillingen af kontrasten, for repræsentationen af 0 og 1, varierer
skærmens gråtoner med værdier mellem 0-255.
4.2.4 Gentegning
Datapanelet skal stå og blinke med
forskellige nuancer, og dermed
foretages en gentegning af
datapanelets område en hel del
gange i sekundet. Gentegnes
panelet kan der imidlertid opstå
væsentlige problemer med
visningen af billedet på skærmen,
da det tegnes punkt for punkt, linje
for linje. I stedet anvendes en teknik
kaldet double-buffering 10 (se
illustration 16), hvor billedet forberedes uden for skærmen. Her skabes billedet i en buffer (1), så
selve tegne-processen ikke vises i datapanelet. Når billedet er tegnet færdigt bag facaden,
smækkes det op på skærmen (2).
10 DoubleBuffering: http://java.sun.com/docs/books/tutorial/extra/fullscreen/doublebuf.html
Illustration 16: Gentegning af datapanel.
22 Test-applikation

4.3 Implementering
Herunder beskrives programmets overordnede struktur, samt mindre detaljer for specielle
program-metoder. Selvforklarende kode beskrives ikke i det følgende, men der henvises til den
samlede kildekode bagerst i rapporten eller på vedlagte CD, hvor kildekoden for test-
applikationen er forsøgt beskrevet så tydeligt som muligt. Ligeledes er der gjort meget ud af
brugen af sigenede variabler og konstanter for at gøre koden letlæselig.
Først gennemgås genereringen af blinkesignaler for datapanelt og derefter opsætningen af
applettens grafiske brugergrænseflade.
4.3.1 Filer
Applettens brugergrænseflade er implementeret i TestApplication.java, og DataPanel.java kan
blinke med skærmen. Det hele vises på en statisk hjemmeside med index.html, og
template.css placerer appletten det ønskede sted.
Fil Beskrivelse
TestApplication.java Appletten der indeholder selve brugergrænsefladen og dens funktionalitet.
DataPanel.java Det blinkende område på skærmen.
index.html Hjemmesiden som viser Java-appletten.
favicon.ico Ikon med Prevas' logo vises ved browserens URL og som bogmærke.
template.css Et stylesheet som håndterer placeringen af appletten på hjemmesiden.
4.3.2 Data-panel
For bedst muligt at styre signalets høje og lave periode er det nødvendigt hele tiden at tjekke,
hvor længe tråden har ventet. Sættes systemet til blot at vente i en bestemt periode, løber
tråden let over tiden, og signalet bliver meget upræcist. Metoden herunder minimere dette
problem betragteligt.
private void dynamicDelay(int time) {
long bitPeriod = System.currentTimeMillis();
while((System.currentTimeMillis()-bitPeriod) < time) {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Tabel 2: Perioden mellem de enkelte blink håndteres af dynamicDelay, der sætter tråden til at vente.
Der forekommer dog alligevel mindre forsinkelser, hvilket kan have stor betydning for
stabiliteten af datamodtagelsen senerehen, og kalibreringen af systemet bliver ligeledes berørt
af dette fænomen.
Panelet blinker i debugmode – ellers står tråden blot og venter. Hvis ikke denne ventetid
Test-applikation 23

håndteres vil system-ressurcerne for den givne proces gå helt op i det røde felt. NB: Dette må
siges at være noget af en sikkerhedsbrist ved Java-appletter, da den vil kunne få en browser
til at bruge 99% af CPU'en. Vha. et simpelt delay undgås dette som vist herunder.
public void run() {
while(true) { // forever...
if(getMode() == "debugmode") { // test-application
screenBinary();
} else { // to avoid CPU overload, system needs idle time
dynamicDelay(50);
}
}
}
Tabel 3: Tråden skal vente i idlemode for ikke at belaste CPU'en.
Hver gang bit-værdien ændres, gentegnes appletten. Værdien fastsættes, og repaint kalder
paint, hvor data-panelets baggrundsfarve ændres til den givne værdi. Offscreen-buffer
funktionen håndteres af paint. Metoden update ændres, så paint kaldes direkte uden først at
gentegne baggrunden, som den normalt vil gøre inden noget nyt tegnes på skærmen.
public void invalidate() { super.invalidate(); offscreen = null; }
public void update(Graphics g) { paint(g); }
public void paint(Graphics g) {
Color highColor = new Color(getHighContrast(), getHighContrast(), getHighContrast());
Color lowColor = new Color(getLowContrast(), getLowContrast(), getLowContrast());
}
if(offscreen == null) {
offscreen = createImage(getSize().width, getSize().height);
}
Graphics offscreenGraphics = offscreen.getGraphics();
offscreenGraphics.setClip(0, 0, getSize().width, getSize().height);
super.paint(offscreenGraphics);
if(getBit()) {
offscreenGraphics.setColor(highColor);
offscreenGraphics.fillRect(0, 0, getSize().width, getSize().height);
} else {
offscreenGraphics.setColor(lowColor);
offscreenGraphics.fillRect(0, 0, getSize().width, getSize().height);
}
g.drawImage(offscreen, 0, 0, null);
offscreenGraphics.dispose();
4.3.3 Test-applikation
Tabel 4: Håndteringen af offscreen-bufferen sker i paint(), der kaldes når en bit-værdi ændres.
Appletten begynder med at afvikle init, hvor selve opsætningen af brugergrænsefladen finder
sted. Det hele ordnes i en tråd, så appletten ikke fryser fast imens.
public void init() {
try { // Set up the user interface
javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
createGUI();
}
});
} catch (Exception e) { // an unknown error occurred
System.err.println("createGUI() didn't successfully complete");
}
}
Tabel 5: init() håndterer opsætningen af applettens paneler, knapper mv.
24 Test-applikation

Appletten er inddelt således, at nogle overordnede
paneler indeholder andre paneler. Dette hjælper med til
at organisere knapper i blokke og blokke i sektioner,
så det er forholdsvist let at rykke rund på grupper af
knapper – eller slå dem til og fra som man ønsker.
Appletten har en Container, hvor i panelerne er placeret
(se illustration 17). Inden i containeren er placeret to
paneler – én til at blinke med data (outputPanel) og én til
at tage imod input (controlPanel). Den første udgøres af
et objekt af DataPanel-klassen, og den anden indeholder
paneler til at styre blinke-signalerne. Senere vil der blive
oprettet et userPanel, hvor brugeren kan kommunikere
data til wavecardet via et tekstfelt og nogle knapper;
men indtil videre er der blot et debugPanel i controlPanel.
debugPanel indeholder yderligere paneler med Swing-komponenter a la knapper, slidere, tekst-
labels mm. Disse simple komponenter er placeret i paneler udelukkende for at adskille dem i
grupper. For en mere detaljeret gennemgang af brugerinterfacets paneler henvises til
kildekoden for metoden createGUI, hvor opsætningen af de enkelte paneler er inddelt i blokke
af kode for at gør det mere overskueligt.
Brugerens handlinger registreres vha. Action- og ChangeListeners. Her gennemgås den
overordnede idé med et eksempel på en Listener i debugPanel, der er føjet til en komponent
som i eksemplet med dutycycleSlider herunder.
periodSlider.addChangeListener ( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setDutycycle(dutycycleSlider.getValue());
dutycycleValueLabel.setText("ON-time:" + outputPanel.getDutyHigh() +
"ms OFF-time:" + outputPanel.getDutyLow() + "ms");
}
} );
Tabel 6: Handlinger ved ændring af dutycycleSlider.
Til at lytte og reagere på komponenters hændelser benyttes konstruktioner af anonyme indre
klasser, hvorved implementering af de krævede metoder jf. den pågældende Listeners
interface undgås. Man bør dog være opmærksom på at de indre klasser ikke ligger inde i
selve den ydre klasse (TestApplication.java), men indlæses hver for sig. Det tager længere tid,
des flere klasser der skal indlæses, hvorfor eksempalvis større brugergrænseflader ikke bør
benytte sig af denne metode. I stedet kan man lade den ydre klasse implementere
ChangeListener, så kun en klasse indlæses, og derfor vises appletten hurtigere.
De resterende Listeners ligner den forgående og vil ikke blive beskrevet yderligere her. Der
henvises til kildekoden bagerst i rapporten (bilag D.1.1) eller den vedlagte DVD.
Illustration 17: Panelers placering.
Applettens såkaldte look-and-feel ændres til udseendet for det operativsystem, som brugeren
anvender, for at give brugeren en fornemmelse af at kunne genkende brugerinterfacet.
Knapper, sliders, tekstfelter mv. vil fremstå som de, der som standard benyttes af systemet.
Test-applikation 25

private void createGUI() {
...
looks = UIManager.getInstalledLookAndFeels();
changeLookAndFeel(SYSTEM_LAYOUT);
}
private void changeLookAndFeel(int value) {
try {
UIManager.setLookAndFeel(looks[value].getClassName());
SwingUtilities.updateComponentTreeUI(this);
} catch (Exception e) {
e.printStackTrace();
}
}
4.3.4 Hjemmeside
Tabel 7: Brugerinterfacet får samme udseende som brugeren er vant til.
Hjemmeside-dokumentet 11 har den obligatoriske DOCTYPE, der fortæller browseren, hvilken
dokumentstandard HTML-filen lever op til – i dette tilfælde er der tale om XHTML 1.0 Strict.
Derudover har dokumentet den sædvanlige struktur med en head- og body-sektion. I head er
karaktersættet valgt til iso-8859-1 for vestlige bogstaver – og der linkes til stylesheet'et
template.css (hvilket omtales i det efterfølgende afsnit). Man ville muligvis let forfalde til blot at
indsætte et enkelt applet-tag for at kalde Java-appletten. Dette er dog ikke hensigtsmæssigt,
da tag'et er under afvikling jf. W3C-standarden 12 og derfor ikke understøttes af den valgte
DOCTYPE. I stedet bør object-tags anvendes, og for at understøtte flere browser-typer må der
lidt omdirigering til vha.

4.3.6 Systemafvikling
Det endelige resultat af programmet ses i
figuren til højre (illustration 18), hvor appletten er
zoomet i forhold til selve browser-vinduet.
Browseren er i full-screen, og appletten vises
nederst til højre. I forhold til prototypen
(beskrevet under analysen) vises sliders
vandret og ikke lodret. Desuden kan
kontrasten justeres med enkelte klik eller ved at
indtaste tallet direkte. I stedet for frekvensen er
det periodetiden, der ændres, da det giver
større præcision i selve programmet. Derudover
vises en statusmeddelelse med oplysninger om
frekvens, periodetid samt on- og off-tider for
signalet. Det hvide område nederst i appletten
repræsenterer datapanelet.
4.4 Test
Inden testen af appletten analyseres signalets karakteristika (se figur 19) vha. lys fra en
blinkende lysdiode. Der måles med et oscilloskop – først på outputtet af solcellernen, hvilket
giver et pænt firkant-signal (A), som dog er ret lavt, men trodst alt ligner inputtet. Efter at have
haft signalet igennem et low-pass filter ses tydelige forandringer (B), der er et resultat af dets
RC-led. Modstandens størrelse og kondensatorens tidskonstant afspejler hhv. stige- og
faldetiderne. Efter en forstærkning af signalet bringes det op på et niveau, der er til at måle for
microcontrolleren (C).
Vha. test-appletten er der udført en række tests af hardware-prototypen for at finde ud af,
hvordan hardwaren opfører sig. Der foretages målinger på forskellige led i systemet, hvor der
startes med det rå output fra solcellerne, hvorefter low-pass filteret monteres og til slut måles
på det endelige signal fra forstærkerens udgang (det direkte input til microcontrollerens ADC-
indgang). Derudover undersøges signalernes grænseværdier.
Illustration 18: En browser i full-screen viser
appletten.
Illustration 19: Outputtet fra hhv. solcellerne, filtret og forstærkeren ved belysning af en lysdiode.
Test-applikation 27

Testen har til formål at verificere de pulser, som appletten udsender via skærmen og samtidig
teste de signaler, som hardwaren generer derudfra.
Testscenarie Forventet resultat Faktisk resultat
Test-appletten sættes
til at blinke med
en frekvens på
2Hz@50% (altså to
gange i sekundet
med en duty-cycle
på 50%). Hardwareprototypen
placeres
på en LCD-skærm
og, der foretages
målinger direkte på
solcellerne.
Signalet føres gennemforstærkerkredsløbet,
men
ellers foretages ingen
ændringer.
Der fremkommer et
pulssignal, som minder
om et firkantsignal.
Herudfra vil signalets
opførsel i forhold til
skærmen kunne
analyseres.
En højere spænding
kan forventes som
output.
Der fremkommer
et
signal med
en frekvens
på 2Hz,
hvor de høje
og lave perioder
er ca.
lige store. Ved første øjekast ser signalet
næsten perfekt ud. Stigetiden ligger på
omkring 18ms (aflæst øverst til højre i billedet)
og faldetiden 29ms, hvilket skyldes skærmens
responstid. Spændingen mellem højt og lavt
niveau (Pk-Pk) er på ca. 190mV.
Et signal
med en
peak-topeak
på ca.
3V
genereres,
og der er
sket en
halvering af
stigetiden, hvilket imidlertid ikke er positivt.
Signalets amplitude vil blive større des mere
lys, der er til stede, og på et tidspunkt vil
forstærkeren gå i mætning og simpelthen
klippe af signalet og give en konstant høj
spænding, hvis solcellerne leverer et for kraftigt
signal (ved for højt gain), hvilket er tilfældet for
signalet på figuren. Dette kan løses ved at
ændre på antallet af solceller, skrue ned for
forstærkningen eller dæmpe for lysstyrken på
skærmen. Den mest optimale løsning vil være
en kombination af de to første, da ansvaret for
hardwaren ikke bør ligge i brugerens hænder.
Der vises et tydeligere eksempel på dette
under udviklingen af modtageren.
28 Test-applikation

Lysstyrken dæmpes
– ellers holdes systemet
uændret.
Lysstyrken holdes
uændret jf. testscenariet
ovenfor.
Low-pass filtret er
sat på efter solcellerne
og skulle
dermed dæmpe de
høje frekvenser over
30 Hz.
Et par af solcellerne
frakobles for at give
pænere signaler.
Nu placeres
hardware-prototypen
på en CRT-skærm,
og der måles direkte
på solcellerne. Testappletten
slukkes,
hvorfor den kun
udsender et hvidt
lyssignal.
Test-appletten sættes
til at blinke med
en fast frekvens.
Signalet viser højfrekvent
støj.
Signalets karakteristik
burde være uændret i
forhold til signalet fra
første testscenarie.
Skærmens
karakteristika
visualiseres.
CRT-skærmens fortolkning
af et pulssignal
vises på skopet.
Der ses tydeligesignalforstyrrelser
som skyldes
baggrundslysets
højfrekvente
PWM-signal.
Der vil altså ikke kunne måles på skærme
med dæmpet lysstyrke med sådanne signaler,
hvorfor der må sættes et filter på før
forstærkningen.
Signalet minder
om outputtet
fra forstærkeren
inden dæmpningen
af lysstyrken.
Systemet er
ikke længere følsomt overfor den højfrekvente
støj fra skærmen, lysstofrør mv. Samtidig er
microcontrolleren i stand til at måle signalets
niveau.
Der fremkommer
et
trekant-signal
som vist i
figuren. Man
ser tydeligt
hvordan signalet
peaker i
det øjeblik en elektron rammer det
flouriserende lag på glaspladen og efterglødens
langsomme aftagen – indtil endnu en elektron
rammer. Ved sort signal fremkommer blot en
vandret linje.
Man ser tydeligtforskellen
mellem
høje og lave
signal. Antallet
af peaks
afhænger af
den frekvens,
hvormed der blinkes – des lavere hastighed
des flere toppe på signalet. Det er dog svært
at vurdere præcist hvornår, signalet går lavt.
Test-applikation 29

5 Modtager
Der er i det foregående udarbejdet et program til at generere systematiske blinkesignaler til
gavn for udviklingen af selve modtageren. Indtil videre er programmets generelle funktionalitet
blevet beskrevet, og det hele har været set fra oven. I dette afsnit inddeles systemet i
delproblemer for bedre at kunne overskue diverse problemstillinger. Ligeledes beskrives den
måde, hvorpå wavecardets microcontroller modtager informationer fra en LCD-skærm. De
fysiske udfordringer vil blive analyseret, og der kigges nærmere på udviklingen af en
overførselsprotokol – herunder datamodtagelsen, dekodningsprocessen og fejlkontrol.
5.1 Analyse
Her præsenteres systemets enkelte delområder med udgangspunkt i skitsen (illustration 21)
herunder. Den viser det originale wavecard øverst til højre i figuren – og dens nye anvendelse
som modtager nederst til højre. Oprindeligt bestod wavecardet blot af en MCU, en piezo, nogle
LEDs og et batteri. For at muliggøre datamodtagelse er der i den nye version yderligere
monteret et par
solceller (bag på
kortet) samt et
filter og en
forstærker til at
optimere de
signaler, der
sendes til MCU'en.
En Java-applet
udgør senderen
(på samme måde
som i test-
applikationen), der
for eksempel vises
i en browser på en computerskærm. Data overføres, ved at senderen lyser med skærmen på
en bestemt måde, og modtageren opfanger lyset via solcellerne og sender det til en ADC-
indgang på microcontrolleren.
Illustration 20: Skitse af systemets overordnede funktionalitet.
Wavecardet vendes, så dens LEDs peger ud mod brugeren og placeres foran appletten oven
på computerskærmens nederst kant (hvis det er muligt for den pågældende skærmtype).
Dette vil dog typisk ikke kunne lade sig gøre på de ældre CRT-skærme, hvor brugeren selv
30 Modtager

må holde kortet eller midlertidigt sætte det fast med tape. Dermed er solcellerne placeret lige
over appletten, så data kan opfanges, og wavecardet kan kommunikere status-informationer
til brugeren via lysdioderne.
5.1.1 Systemanvendelse
Der er udtænkt en bestemt procedure (se illustration 21), som brugeren skal følge for at
programmere kortet fra senderen på skærmen. De mørke bobler indikerer brugerens
interaktivitet med sender-appletten, og de hvide er brugerens handlinger med selv wavecardet.
Hele processen begynder med, at brugeren indtaster den tekst, der ønskes overført til
wavecardet. Dernæst trykkes på en knap mærket for at udsende gentagne signaler
om, at senderen er klar til at programmere kortet. For at kortet kan opfatte senderens
signaler, skal det på en eller anden måde aktiveres, hvilket kun kan ske vha. de signaler, som
piezoen genererer ud fra rystelser. Dernæst placeres kortet på skærmen over de blinkende
signaler. Når kortet opdager
den blinkende sekvens,
finder den automatisk baud-
raten for dataoverførslen,
hvilken indikeres ved at vise
periodetiden for de blinkende
sekvenser med kortets
lysdioder. Brugeren behøver
ikke specifikt at vide, at dette
netop er periodetiden, men
skal blot sammenligne
lysdioderne med senderens
illustration af perioden, for at
kontrollerer om der er overensstemmelse. Opdages signalet ikke – eller er der ikke
overensstemmelse – må der være sket en fejl, så kortet rystes og placeres gentagne gange,
indtil signalet opfanges korrekt. Brugeren trykker på knappen , og senderen
overfører dermed data til modtageren, der indikerer modtagelse ved at blinke med lysdioderne.
Ved fejl i overførslen vises periodetiden på ny, og der kan blot trykkes endnu engang på
for at forsøge igen. Når modtagelsen er færdig, indikeres dette overfor brugeren
med en bestemt sekvens på lysdioderne – eksempelvis lyser de alle op, viser et løbelys eller
lignende. Brugeren fjerner kortet fra skærmen og tester det på sædvanligvis ved at ryste det i
luften og tjekker, om den ønskede tekst vises. Er dette ikke tilfældet begyndes forfra dog uden
at indtaste teksten på ny. Ellers er wavecardet nu færdig-programmeret.
Systemet holdes så brugervenligt som muligt, ved at holde programmerings-proceduren på et
absolut minimum og give interfacet et fåtal af knapper.
Illustration 21: Aktivitetsdiagram for systemets anvendelse.
Modtager 31

Ønskes en endnu mere brugervenlig tilgang (se illustration 22), kan auto-baud funktionaliteten
erstattes med en på forhånd defineret baud-rate, som både sender og modtager er enige om,
hvilket vil være den sædvanlige procedure ved traditionelle serielle forbindelser. Man vil derved
spare en del interaktivitet og dyrebar ventetid
væk, som ofte vil få brugeren til at blive
utålmodig og dermed træt af systemet.
knappen vil kunne fjernes – så
brugen nu blot skal indtaste den ønskede
tekst, aktivere kortet (ved at ryste det), placere
det foran skærmen og trykke på .
Wavecardet vil selv opdage, at en sender
forsøger at programmere det. Fejler processen
trykkes blot på endnu engang.
Auto-baud funktionaliteten vil dog alligevel blive implementeret – for det første for eksemplets
skyld og for det andet er det en rar feature, der i fremtiden kan eksperimenteres yderligere
med. Eksempelvis vil det på sigt være nyttigt af hensyn til bagud-kompatibilitet med ældre
korttyper. Der kan evt. udvikles en metode til at gemme en detekteret baud-rate, der så
bruges som standard, indtil man beslutter sig for at ændre den igen. Dette er blot en idé til
videreudvikling og ligger uden for formålet med denne opgave.
5.1.2 Dataoverførsel
Efter at brugeren har trykket på eller (som vist ovenfor), sender
skærmen en masse analoge signaler afsted. Figur 23 viser de stadier i dataoverførslen, der
Illustration 23: Indkapsling af data.
skal arbejdes med fra aflæsning af
skærmen til visning af den overførte tekst.
For at modtageren kan forstå signalerne,
må de analyseres og digitaliseres. Det er
derefter modtagerens opgave et få noget
fornuftigt ud af de digitaliserede signaler
ved at undersøge niveauerne og timingen. Derefter skal data dekodes og tjekkes for fejl – for
til sidst at blive gemt og kunne visualiseres.
5.1.2.1 Analog og digital signalbehandling
Illustration 22: Simplificeret anvendelse.
Skærmen udsender data i form af lyssignaler, der opfanges af en lysfølsom sensor, hvorefter
de sendes til MCU'en for yderligere behandling, hvilket er illustreret i figuren (illustration 24).
32 Modtager

Solcellerne modtager ikke kun lyset fra skærmen, men forstyrres af andre lyskilder – som
nævnt tidligere kommer selv skærmens eget PWM-signal i vejen. Disse uønskede, højfrekvente
signaler sorteres fra med et low-pass filter og sendes til indgangen på en forstærker, for at
booste max-spændingen fra omkring 100-200mV til 2-6V. Derefter ankommer signalerne til en
ADC på wavecardets MCU, hvor de analoge signaler digitaliseres og bearbejdes yderligere i
det program, der tager hånd om datamodtagelsen. Og det er netop, hvad der beskrives i de
følgende afsnit; men først kigges der lidt nærmere på en karakteristik af det indkomne signal.
Illustration 25: Detaljeret signal fra solcellerne.
Illustration 26: Detaljeret signal efter filtrering.
Illustration 24: Lyssignalet fra skærmen filtreres, forstærkes, digitaliseres og behandles.
Vha. af et osscilloskop måles et analogt pulssignal
fra solcellerne (se illustration 25), og det har en
karakteristik, der minder om et digitalt signal. I
forhold til faldtiden har signalet en hurtig stigning på
omkring 17ms (aflæst til højre i billedet) ved
optimale lysforhold, hvor computerskærmens
baggrundslys ikke er dæmpet, og der ikke er
kraftigt lys i rummet. Efter stigningen afrundes
signalet roligt og viser en konstant vandret linje. Når
signalet går lavt falder det hurtigt i starten og
afrundes jf. skærmens responstid. For de
pågældende forhold tager det signalet ca. 26ms
at falde til ro. Amplituden er på ca. 160mV (jf.
50mV pr. tern som vist nederst til venstre i figuren).
Low-pass filtret sorterer de høje frekvenser fra
lyset, som påvirker solcellerne og lader de lave
frekvenser slippe igennem. Her kan som sagt
være tale om højfrekvent lys fra lysstofrør og
andre lyskilder, men specielt fladskærme har det
med at puls-bredde-modulere baggrundslyset, når
brugeren sænker lysstyrken. Illustration 26 viser et
pulssignal fra en computerskærm, hvor baggrundslyset er dæmpet en del. Det ses tydeligt at
filtrets RC-led (modstanden og kondensatoren) ikke påvirker signalets karakteristik
nævneværdigt. Dog resulterer dæmpningen af baggrundslyset i en noget lavere amplitude, der
Modtager 33

for dette signal når ned på omkring 80mV (jf. 20mV pr. tern), hvilket dog ikke i sig selv er et
problem, da signalet forstærkes. Sammenlignes signalet med figuren for det optimale signal
opdages en del støj (der er et resultat af et zoom på signalet), som naturligvis også vil blive
forstærket og vil fylde en del i forhold til selve signalet. Dvs., at signalet kan blive svært at
analysere, hvis skærmens lysstyrke sænkes for meget, da MCU'en vil have svært ved at
beregne signalets niveau. Ud fra analysen af outputtet fra solcellerne, ser det ud til at blive
udfordrende nok at detektere forskellen mellem signalets, i forvejen skæve, høje og lave
niveauer. Overførslen til wavecardet skal kunne foregå under forskellige forhold, og det vil blive
svært at detektere flere niveauer med de nuværende solceller, så der vil arbejdes videre med
idéen om at omdanne de analoge niveauer til digitale signaler. Dermed må overvejelser
omkring overførsel af data parallelt (altså som gråtoner), se sig slået af simple skift mellem sort
og hvid – hhv. højt og lavt niveau, for bedre at kunne detektere signalet. Dermed går man på
sigt også på kompromis med overførselshastigheden, da skift mellem sort og hvid, som nævnt
tidligere, tager længere tid for en fladskærm end skift mellem gråtoner.
Illustration 27: Analog til digital med level-trigger.
For at detektere et skift mellem de to
nuancer vil den oplagte løsning være at
analysere signalets værdier og give et bud
på, hvornår det er over eller under en given
grænse (ofte 50%) af hhv. dets minimum-
og maximum-niveau (se illustration 27).
Figurens stiplede linje er niveauet, hvor
omkring det digitale signal skifter i enten den
ene eller anden retning jf. det analog signal.
Der er nødt til at være en margen (de prikkede linjer), som det analoge signale skal nå over,
før der skiftes til højt niveau – eller nå under for et lavt niveau. Dette gøres for at undgå glitches
(se illustration 28), hvor signalt vil hoppe op og ned nogle gange inden et endeligt skift.
De langsomme stige-/faldetider kommer dog til at volde en
del problemer for den pågældende metode til at
konvertere signalet. Eksempelvis vil et pulssignals høje og
lave niveauer variere med nogle millisekunder i forhold til
hinanden alt afhængig af frekvensen, hvormed der blinkes
på skærmen. Ved høje frekvenser når signalet ikke at
falde helt ved skift fra højt til lavt og til højt niveau igen (se
illustration 29). Signalet skifter mellem MIN og MAX, men
ved for høje frekvenser når det simpelthen ikke helt ned
på MIN (grundet filtrets tidskonstant og skærmens
responstid), inden det igen begynder at stige.
Illustration 28: Eksempel på en glitch
ved niveauskift.
34 Modtager

I testafsnittet for sektionen om
test-appletten viste det sig at
forstærkerens nuværende
opsætning desværre havde en
tendens til at gå i mætning, når
solcellerne blev påvirket af for
meget lys. Det fremgår af det
øverste signal i illustration 30, hvordan forstærkeren klipper toppen af signalet, hvilket resulterer
i for høj on-tid og dermed for lav off-tid i forhold til det oprindelige signal. Stigningen har ikke
den sædvanlige bløde overgang til det høje niveau. Max-spændingen er med forstærkningen
Illustration 30: Forstærkeren går i mætning.
nu oppe på 4V (jf. 2V pr. tern) og svinger med en
peak-to-peak på ca. 3½V. Dette er illustreret med
outputtet (se figurens nederste signal) fra et lille
hjemmelavet program til en microcontroller, som
giver et digital signal ud fra et analogt (i dette tilfælde
figurens øverste signal). Microcontrollerens inbyggede
A/D-converter er på 10 bit, hvilket giver 1024
niveauer (værdier fra 0-1023). Der trigges på et fald
eller en stigning på 10% i stedet for den ovenfor
beskrevne metode.
Som nævnt i forbindelse med analysen af systemanvendelsen (afsnit 5.1.1) skal der defineres
en periodetid, så systemet ved, hvornår det skal læse den pågældende digitale værdi.
Signalet aflæses evt. midt i perioden som vist i
illustration 31, så man er nogenlunde sikker på, at det
har nået at skifte til den aktuelle værdi. Da der ikke er
noget kloksignal peger det i retning af asynkron seriel
kommunikation 13 , hvor der må udvikles en overførsels
protokol, som synkroniserer signalet løbende. Hvis der
blot synkroniseres på første bit, kan man eksempelvis
ikke regne med at bit 100 netop aflæses som denne. Der kan være sket indtil flere
forskydninger undervejs, så det i stedet er for eksempel bit 99 eller 103, der aflæses.
5.1.2.2 Kodning
De datablokke, som senderen overfører, er kodet på en speciel måde for at sikre en eller flere
aspekter – så som hurtig transmission, sikker transmission, fejlkontrol og lignende. Da der ikke
findes en gængs måde at kode data på til transmission via en skærm, vil der i designfasen
blive udviklet en hybrid mellem flere kendte kodningsformer. Koden skal tilpasses, så der kan
overføres så mange forskellige tegn som muligt, for at sikre den fremtidige udvikling for andre
kortprojekter, som desværre ikke kan omtales yderligere her (jf. afsnit 2.2).
13 Asynkron kommunikation: http://en.wikipedia.org/wiki/Asynchronous_communication
Illustration 29: Ved høje frekvenser når signalet ikke at falde helt.
Illustration 31: Aflæsning af digitalt signal.
Modtager 35

Inden for emnet datakommunikation benyttes begreberne kodning og dekodning – typisk
anvendes deres engelske varianter – hhv. encoding og decoding. En kode er ikke hemmelig i
denne sammenhæng. Det er blot en måde at udtrykke data på, som var der tale om et andet
sprog. Informationer omdannes simpelthen til en anden form – enten fysisk eller repræsentativt.
Ved kodning omdannes data til symboler, der kan kommunikeres, og ved dekodning sker det
modsatte. I modtagerens tilfælde er det altså dekodningsprocessen, der er interessant. Den
sørger for, at de modtagne data omdannes til den form, der passer til visningen af symboler
på wavecardet.
Karakterer repræsenteres vha. et skema som for eksempel en ASCII-tabel 14 , en Morse-kode 15 ,
stregkoder á la Code128B 16 etc. Fordelen ved at den første er den, at de fleste
computersystemer allerede har ASCII ”indbygget”. Implementeres andre koder, vil man, typisk i
programkoden, skulle oprette et skema som en oversigt over kodningen for hvert enkelt tegn,
hvilket vil kræve væsentlig plads på en microsontroller. De fleste embeddede systemer
forsøges holdt så billige som muligt, og de har dermed begrænset lagerplads, da der ofte skal
produceres et stort antal, hvorfor en besparelse på få cents vil have stor indflydelse. Der er
derfor ikke råd til at spilde plads på lagerområder, megen funktionalitet og I/O-ben på chippen.
Morse-koden vil kunne overføre data hurtigere, da den er direkte optimeret til dataoverførsel –
og stregkoder vil typisk være udstyret med en effektiv fejlkontol. Der er dog også trade-offs
ved brug af disse alternativer til ASCII. Morse har udover tal og store bogstaver også visse
specielle tegn repræsenteret, men man vil selv skulle opfinde koder for små bogstaver og
yderligere specialtegn.
Ved anvendelse af en af de anerkendte stregkode-type, Code128, fylder hver karakter
forholdsvist meget – 11 bit i forhold til de sædvanlige 8 bit. Den har dog en interessant
beregning af checksum, hvor hver enkelt karakter vægtes i forhold til de andre og giver
dermed større sikkerhed end den simpleste form for tjeksum-beregning 17 . Samtidig er den ikke
så beregningstung, som ved brug af CRC (eng. Cyclic Redundancy Check) 18 .
5.1.2.3 Visualisering
Wavecardet bruger kun syv LEDs til at vise en tekst i luften. En karakter
består af et kvadrat på 7x7 punkter, der enten er tændt eller slukket (se
illustration 32). For hver karakter vises en lodret linje af gangen (indikeret
med den grå ramme) – og når kortet rystes skiftes hurtigt mellem de
lodrette kolonner, så øjet vil opfatte teksten, som om den står i luften.
Det kan blive vanskeligt at vise den overførte tekst frit i luften, da den
14 ASCII-tabel: http://www.asciitable.com/
15 Morse-kode: http://en.wikipedia.org/wiki/Morse_code
16 Code128: http://www.barcodeisland.com/code128.phtml
17 Simpel checksum: http://en.wikipedia.org/wiki/Checksum
18 CRC: http://en.wikipedia.org/wiki/Cyclic_redundancy_check
Illustration 32:
Visning af tegn.
36 Modtager

nuværende implementation af wavecardet ikke har en fast karaktertabel, der fortæller,
hvordan hvert enkelt bogstav ser ud. I stedet er bogstaverne hard coded, hvilket på ingen
måde er særligt fleksibelt. Desuden er der ikke mere plads på wavecardet i sin nuværende
form til at implementere en sådan tabel, hvilket vil kræve en del oprydning i koden – og så kan
man endda ikke være sikker på, at der samtidig vil være plads til både koden for
dataoverførsel og visning af bogstaver.
En nødløsning vil være at vise ASCII-koden på lysdioderne for hver karakter, der er blevet
overført via skærmen. Som test vil man kunne overføre bestemte karakterer og observere at
de rigtige ASCII-værdier fremkommer på lysdioderne. Eksempelvis vil en overførelse af teksten
”QqQqQq” vise hhv. ”01010001”, ”01110001” osv. på lysdioderne (jf. ASCII-tabellen), og dermed
blinker kun bit 5 (startende med bit 0 bagfra), hvilket vil være let at overskue. Ligeledes vil en
udskrift af den variabel eller det område i hukommelsen, hvor den overførte tekst ligger, kunne
dokumentere påstanden om, at en given tekst blev overført korrekt.
5.2 Design
Den overordnede forståelse for de indkomne signaler er nu på plads. Der er ligeledes blevet
lavet en grov skitse af de teknikker, der skal benyttes til at kode data med, og der er blevet
kigget lidt på visningen af det endelige resultat. Denne del danner grundlag for
implementationen af modtageren, hvor de enkelte delelementer af programmet bygges op.
Først omdannes det analoge signal til en digital værdi, og der kigges nærmere på udviklingen
af en protokol til datatransmission via en skærm. For at styre begivenhederne i
overførselsprocessen udarbejdes tilstande, som systemet kan befinde sig i undervejs.
5.2.1 Aflæsning af signal
MCU'en modtager som bekendt datasignalet via en ADC-ingang, som ved et skift fra sort til
hvid på skærmen giver et
signal, der ligner det på
illustration 33. I
baggrunden ses det rå
signal, og oven på det er
vist, hvordan det skal
fortolkes af programmet.
Først midles signalet og
derudfra foretages en
række målinger med
faste mellemrum,
hvorefter en ny værdi
sammenholdes med en
tidligere aflæst værdi. Ved
Illustration 33: Signalet midles og aflæses med faste mellemrum. Der
foretages en vurdering af om niveauet er skiftet inden for en margen.
Modtager 37

at indsætte et mellemrum mellem målingerne, omsættes værdierne til vinkler, så en stigning
eller et fald let kan registreres. Der indsættes en definition for et stabilt signal, der udgør en
margen, som signalet kan bevæge sig inden for uden at skifte den digitale værdi. Kun hvis en
ny måling når at afvige meget fra en tidligere måling, registreres enten en stigning eller et fald i
signalet – og det virtuelle digitale signal skifter tilstand.
5.2.2 Overførselsprotokol
I forbindelse med computernetværk har OSI-
modellen 19 vist sig som en effektiv måde at
analysere og arbejde med datakommunikation
på, hvorfor der er forsøgt skabt overblik over
dataoverførslen til wavecardet med inspiration
fra netop denne model. Illustration 34 viser en
protokol for, hvordan data er repræsenteret
undervejs i transmissions-processen. Pilene
viser kommunikationsvejen, hvor der er tale
om envejskommunikation fra sender til
modtager med hhv. en skærm og solceller
som interface.
Brugeren indtaster en tekst i senderens
applikationslag (kaldet ”Tekst” i figuren), hvorefter den kodes i laget nedenunder. Data-blokke,
der på modtager-siden kan være både
karakterer og kommandoer, repræsenteres
vha. blinkende sekvenser på skærmen.
Solcellerne opfanger de blinkende sekvenser,
der læses som asynkron seriel-data (se
illustration 35), da der som bekendt ikke er noget kloksignal tilrådighed. For hver data-byte
synkroniseres signalet ved hver start-bit (logisk 1), og systemet gør sig klar til endnu en
transaktion ved modtagelse af en stop-bit (logisk 0). Imellem de to kontrol-bits sendes 8 bit
data – typisk med LSB (altså bit
0) først. Denne konfiguration
kaldes 8N1 (otte databits, ingen
paritet og en enkelt stop-bit) og
er den mest almindelige inden for asynkron seriel-kommunikation. Overførselshastigheden
beregnes ved at dividere bit-raten med ti – jf. den 10-bit lange data-byte – så med en bit-rate
på eksempelvis 30bits/s vil der kunne overføres 3 bytes i sekundet.
Efter modtagelse af en data-byte smides start- og stop-bits væk, og systemet skal bruge en
start-kommando for at kunne påbegynde datamodtagelsen. Når den opfanges gemmes de
19 OSI-modellen: http://en.wikipedia.org/wiki/OSI_model
Illustration 36: Data-bytes sendt.
Illustration 34: Lagdelt protokol.
Illustration 35: Seriel-datas repræsentation.
38 Modtager

følgende karakterer, som vist i illustration 36, indtil en stop-kommando detekteres. Første
modtagne byte er en tjeksum-karakter (eng. checksum), der skal verificere, om data mellem
en start- og stop-kommando overføres korrekt.
5.2.3 Tilstandsmaskine
Der opbygges en tilstandsmaskine som vist i figur 37. Cirklerne udgør de forskellige tilstande
(kaldet operationer), som systemet kan befinde sig i. Pilene mellem cirklerne kaldes transitioner,
og de viser, hvad der skal til for at skifte fra en operation til en anden.
Ved aktivering af kortet nulstilles microcontrolleren i Reset og går direkte videre (”true” eller ”1”
betyder uden betingelse) til Normal. Denne tilstand repræsenterer wavecardets almindelige
funktionalitet, hvor tekst vises i luften, når kortet rystes. Wavecardet holdes ligeledes vågen ved
at ryste det og går automatisk i dvale
ved længere tids inaktivitet. Opdages
et blinke-signal via kortets solceller
skiftes til Signal, hvor kortet forsøger
at detektere frekvensen af det
modtagne signal. Periodetiden for hhv.
det høje og lave signal af hvert enkelt
blink sammenlignes med hinanden,
men bliver disse på intet tidspunkt
ens inden en given time out, nulstilles
systemet i Reset. Hvis de tilgengæld
bliver ens, accepteres periodetiden,
hvilket resulterer i et skift til Init, hvor
systemet gøres klar til
datamodtagelse og går direkte til
Ready. Modtages en start-bit inden
for en given periode, gøres systemet
klar til at modtage en databyte i Data
– ellers hoppes tilbage til Reset. Når
Illustration 37: Systemets tilstande.
der er modtaget en databyte og en efterfølgende stop-bit, synkroniseres datamodtagelsen, og
systemet går i Mode. Modtages ikke en hel byte data eller en stop-bit inden for en given
periode, sendes systemet tilbage i Ready og venter på en ny start-bit eller time out.
Modtager 39

5.2.4 Kommandoer
I tilstandsmaskinen ovenfor er Mode en form for virtuel
operation. I første omgang er den synonym med No-mode,
(se illustration 38) der venter på at modtage en kommando. I
tilfælde af en start-kommando (start-byte) skiftes til Receive.
Programmet kan udvides til at modtage flere kommandoer
og derved skifte mellem forskellige modes. Når en
kommando er modtaget, vender systemet automatisk tilbage
til Ready fra Mode (som vist tidligere), hvor der gøres klar til
modtagelse af flere data.
I Receive ventes på modtagelse af en stop-byte (synonymt
med en stop-kommando). Efter en undersøgelse af
tjeksummen vurderes om datamodtagelsen er foregået uden
fejl. Er dette ikke tilfældet sættes mode tilbage til No-mode,
og systemet går i Ready for at vente på en ny kommando. Accepteres tjeksummen derimod,
afsluttes datatransmissionen, og systemet går i Finish for at indikere korrekt datamodtagelse
overfor brugeren. Derefter nulstilles systemet for at gøre klar til at vise den overførte tekst.
5.3 Implementering
Kildekoden på vedlagte DVD er løbende beskrevet undervejs i implementeringsprocessen, og
der er naturligvis anvendt sigende variabler for at øge læsevenligheden. Der indledes med en
oversigt over de anvendte filer, og efterfølgende beskrives bearbejdelsen af selve modtagerens
funktionalitet.
5.3.1 Filer
Systemet er splittet op i flere filer for at gøre programmet mere overskueligt. Der anvendes
header-filer på sædvanligvis for at gøre programfunktioner, #defines mv. tilgængelige.
Fil Beskrivelse
main.c Hovedprogrammet som indeholder den grundlæggende funktionalitet.
init.c Microcontrollerens grundlæggende opsætning.
init.h En simpel header-fil som gør init.c tilgængelig.
isr.c Håndtering af interrupts.
picutil.c Samling af program-funktioner til udvikling af embeddede projekter.
picutil.h Typiske systemindstillinger for embeddede projekter.
Illustration 38: Kommandoer.
40 Modtager

5.3.2 Opsætning
Fundamentet for afviklingen af programmet på microcontrolleren ligger i dens opsætning.
Systemet kører med en intern 8MHz clock og interrupts for Timer1, ADC og EEPROM
aktiveres. Port A har flere analoge indgange, hvor port AN0 anvendes som indgang for
hardware-prototypen, og wavecardets syv lysdioder er tilknyttet port B (bit 7 til 1). Der
anvendes en 16-bit timer (Timer1), som programmet kan benytte til at tælle og vente i en
bestemt periode uden at fryse systemet ved polling 20 . Der arbejdes med en frekvens på
999,50Hz og dermed en bekvem periodetid på 0,001001 sekund (altså ligeomkring 1 ms). Se
evt. flere detaljer i den kommenterede kildekode for init.c (afsnit D) eller på vedlagte DVD.
5.3.3 Interrupts
Ved et hvert interrupt kaldes funktionen my_isr i filen isr.c, hvor den pågældende interrupt
identificeres, og der reageres kun på en interrupt, hvis den er aktiveret i filen init.c. I interrupt-
funktionen aflæses og analyseres de digitaliserede signaler fra ADC'en. Signalerne gemmes i
en ring-buffer, der har længden RAW_SIGNAL_BUFFER_LENGTH, og med mellemrum midles bufferens
indhold jf. SIGNAL_MEASURE_MS for bedre at kunne detektere siganlets niveau og dermed udglatte
eventuelle fejl i ADC'ens målinger.
De digitale signalers periodetid bearbejdes også i interrupt-funktionen under timer-interrupts. Her
styres aflæsningen af de digitale værdier vha. virtual_clock, der beregnes ud fra den fundne
periodetid.
5.3.4 Opbygning
Programmet udføres i en forever-løkke (altså en uendelige løkke), som for hvert gennemløb
analyserer signalerne fra skærmen via hardware-prototypen. Ligeledes styres programmets
tilstand med en almindelig tilstandsmaskine som beskrevet tidligere (i afsnit 5.2.3 og 5.2.4) og
brugeren informeres om systemets tilstand via de syv lysdioder.
5.3.5 Datamodtagelse
Beregningen af en tjeksum for de overførte data gøres forholdsvist ukompliceret, da der ikke
er tale om kritiske data. Ved senere implementering af dataoverførsel til brug for andre
kortprojekter bør der evt. kigges nærmere på beregning af en CRC, for at datamodtagelsen
bliver mere pålidelig. I første omgang er der dog ikke behov for en så grundig og beregnings-
tung algoritme.
Microcontrolleren har en ubenyttet EEPROM, som kan rumme en hel del data (256 bytes),
hvortil overførslen kan foregå. Dermed kan teksterne variere i længde uden brug af dynamiske
variabler, så man ikke risikerer at løbe ind i problemer med den begrænsede hukommelse.
20 Polling: http://en.wikipedia.org/wiki/Polling_(computer_science)
Modtager 41

5.3.5.1 Tjeksum
Data-blokkene består som bekendt af karakterer eller kommandoer. De er kodet jf. samme
kodning som Code 128B, der svarer til ASCII, men hvor de første 32 kontroltegn er fjernet.
Dvs., at første tegn (på plads nul) er Space, hvilket giver i alt 96 karakterer med mulighed for
kommandoer og egne tegn så som smilies og hjemmelavede symboler fra og med plads 96.
Grunden til at tabellens indhold flyttes, skyldes den modulo-operation, som Code 128 anvender
til beregning af tjeksum, hvorved multiplikation med store tale undgås. Med en start-kommando
(for nuværende ASCII-kode 96) gøres wavecardet klar til modtagelse af data. Tjeksummen
beregnes ved at tage værdien af start-kommandoen, hvortil der lægges den vægtede sum af
hver enkelt karakter for til sidst at tage en modulo 96 af resultatet – hvor tallet svarer til start-
kommandoen eller rettere den første karakter uden for tabellen:
I et eksempel på udregning af tjeksummen for ordet ”Hej” vil man først tage start-kommandoen
og lægge værdien af føste karakter til, dernæst 2 gange værdien af den anden karakter og til
sidst 3 ganget med værdien af tredje karkter. Stop-kommandoen (i dette tilfælde 97)
medregnes ikke. Dette giver tallet 496, hvoraf man udfører en modulus-operation (altså finder
resten ved division) med tallet 96, hvilket giver, tjeksum-værdien, 16. Udregningen ser altså
således ud: Tjeksum =961⋅402⋅69 3⋅74mod 96=16
En data-byte med tallet 16 er derfor indeholdt på ”Check”-pladsen jf. figur 36 på side 38,
hvorfor værdierne af de overførte bytes vil være: 96, 16, 40, 69, 74 og 97 for ordet ”Hej”.
5.3.5.2 Lagring
I microcontrolleren gemmes data i dens
interne EEPROM, der virtuelt er delt op i to
blokke (kaldet banker – se illustration 39).
Formålet med bankerne er at bevare gamle
data ved modtagelse af nye, for at undgå
at en eventuel fejl i dataoverførslen resulterer i et ikke-funktionelt wavecard. Med en EEPROM-
størrelse på 256 bytes (for PIC16F819) er der 128 bytes tilrådighed per bank. De to første
bytes i hver bank bruges dog til hhv. den pågældende teksts længde samt tjeksum-byten.
Illustrationen viser, at længden af indholdet i bank 0 er på tre bytes efter check-byten (aflæst
på første plads i bank 0), hvilket betyder, at alt andet derefter ikke læses. Bank 1 er inaktiv,
da dennes første byte har værdien 255 (FFh).
5.4 Test
Tjeksum =Kommando start ∑ i =1
n
i⋅Karakter i mod Kommando start
Illustration 39: EEPROM-banker hvor Bank 0 er aktiv.
Test af modtageren udføres med hjælp fra test-appletten, der følger et fast mønster, når den
blinker med skiftevis højt (sort) og lavt (hvidt) signal, hvilket modtageren fortolker som hhv. 1 og
42 Modtager

0. Første data-bit modtages efter en start-bit (et logisk 1-tal), hvorfor de følgende bits modtages
som 01010101B, hvilket læses bagfra, da LSB modtages først, så resultatet ved aflæsning af
EEPROM'en bliver i virkeligheden 10101010B eller (AAH). Overførslen afsluttes med en stop-bit
(repræsenteret ved et logisk 0), og en ny transaktion påbegyndes med endnu en start-bit osv.
osv. Dette scenarie benyttes til at undersøge fejlraten for modtageren ved at fylde EEPROM'en
med en masse 1'er og 0'er, hvorfor succeskriteriet er så mange AH-nibbles (1010B) i
EEPROM'en som muligt. Efterfølgende undersøges grænserne for automatisk detektering af
signalets periodetid.
Hvert af de følgende testscenarier afhænger af de forudgående, så de givne forhold og
indstillinger er gældende, indtil andet beskrives.
Testscenarie Forventet resultat Faktisk resultat
Modtageren modificeres
til at kunne modtage
data med en fast
periodetid på 100ms.
Yderligere sættes modtageren
til skrive de
modtagne bits direkte i
EEPROM'en.
Test-appletten sættes til
at blinke med en
frekvens på 5Hz@50%
(en periode på 200ms),
hvilket giver hhv. en on-
og off-tid på 100ms,
hvilket svarer til
periodetiden for hver bit.
Efter nogle minutter
standses forsøget.
Det meste af
EEPROM'en vil være
fyldt med HEX-værdien
A (1010B). Der vil
muligvis være nogle fejl
i modtagelsen, der kan
skyldes at appletten
”falder ud”, som
skyldes manglende
kalibrering.
Modtageren opdager et blinkesignal og
forsøger at detektere periodetiden.
Tydelige fejl i blinkesignalet opdages med
det blotte øje – og efter nærmere
undersøgelse af styresystemets processer
står det klart, at nogle programmer
optager store mængder CPU-tid.
Figuren viser styresystemets jobliste
sorteret efter CPU-tid, og det fremgår
tydeligt, hvad problemet skyldes – nemlig
programmet Miro, der sluger store
mængder ressourcer.
Modtager 43

Efter at have afsluttet de
krævende processer
foretages endnu et
forsøg som beskrevet
ovenfor.
Systemet sættes til at
køre med periodetid på
200ms.
EEPROM'en fyldes
med AH'er som
beskrevet ovenfor.
Forekomsten af fejl
reduceres i forhold til
den tidligere test.
Billedet viser EEPROM'ens 256 bytes
(2048 bits) fyldt op med 1'er og 0'er
repræsenteret som HEX-værdier. Fejlraten
er illustreret med de grå felter:
Tæller man efter, er der fejl i 13 af de 256
bytes, hvilket giver en fejlrate på 1 hver
157-158 bits.
Der optræder kun en enkelt fejl, men
tilgengæld tager det lang tid at fylde
EEPROM'en op. En beregning viser, at
dette vil tage mere end 8½ minut (10 bits x
200 ms x 256 bytes). Selvom det ikke er
nødvendigt at fylde hele lageret under
normalt brug, giver det alligevel en idé om,
hvor langsomt det går. En overførsel af 15
karakterer er måske et mere håndgribeligt
eksempel; hvilket vil tage et halvt minut (10
bits x 200 ms x 15 karakterer).
Noget kan tyde på at Java-appletter ikke
er beregnet til at stå og blinke mange
gange i sekundet. Double-bufferen har en
betydelig virkning på opdateringen af
datapanelet, men den er dog ikke i stand
til at udrette mirakler. For at udvikle en
mere stabil sender er man nødsaget til at
gå på kompromis med den dynamik, der
ligger i brugen af Java-appletter for at
opnå dybere adgang til grafikkortet.
Desuden kan et real-time system
anbefales, hvilket Java bestemt ikke er i
stand til at levere, da programmerne kører
i en virtuel maskine med en masse
sideløbende processer så som garbage
collection.
Styresystemets processer får hver 10 ms
CPU-tid af gangen, hvilket gør, at
systemet i hvert fald ikke i fremtiden kan
køre hurtigere end denne hastighed.
44 Modtager

Modificeringen af
kildekoden ændres
tilbage til sin oprindelige
form, for at kunne teste
den automatiske
detektering af
periodetiden.
Test-appletten startes
med en on/off-tid på
50ms. Modtagerens
lysdioder aflæses, når
periodetiden er fundet,
hvorefter samme test
udføres nogle gange.
Test-appletten sættes
gentagende gange til en
on/off-tid på 40 ms, og
modtagerens lysdioder
aflæses.
Test-appletten sættes
gentagende gange til en
on/off-tid på 30 ms, og
modtagerens lysdioder
aflæses.
Test-appletten sættes
gentagende gange til en
on/off-tid på 20 ms, og
modtagerens lysdioder
aflæses.
Test-applikationen
sættes til at blinke med
en periodetid på 30ms.
Der måles på outputtet
fra hardware-prototypen
(den analoge indgang)
samt på en port (RA7),
hvor værdien af
variablen digital_value
(microcontrollerens
fortolkning af det
analoge signal) tilskrives.
Modtagerens lysdioder
viser periodetiden.
Modtagerens lysdioder
viser periodetiden.
Modtagerens lysdioder
viser periodetiden.
Modtagerens lysdioder
viser periodetiden.
Forholdet mellem de
analoge og digitale
signaler kan
sammenlignes for den
givne periodetid. Der
forventes en fin
sammanhæng mellem
det analoge og digitale
signal.
Lysdioderne viser gentagne gange
0110010B (50D), hvilket svarer til den
ønskede periodetid.
Lysdioderne viser gentagne gange
0101000B (40D), hvilket svarer til den
ønskede periodetid.
Lysdioderne viser gentagne gange
0011110B (30D), hvilket svarer til den
ønskede periodetid.
Modtageren har besvær med at detektere
periodetiden, hvilket vil sige, at grænsen
for aflæsning med den nuværende
konfiguration ligger omkring en periodetid
på 30 ms. Dette betyder ikke
nødvendigvis, at systemet kan overføre
data jf. denne hastighed, men viser blot
grænsen for aflæsningen af skærmen
med den nuværende hardware og
opsætning.
Det lykkedes
langt hen ad
vejen at
aflæse et
korrekt signal.
Dog
fremgår det
tydeligt, at
signalet har svært ved at nå helt op på
MAX og helt ned på MIN (som forklaret i
afsnit 5.1.2.1) ved hvert skift i niveau på
skærmen.
Modtager 45

Modtageren sættes til at
modtage data med en
fast periodetid på 40ms,
og test-appletten
indstilles tilsvarende. Igen
måles på outputtet fra
hardware-prototypen
samt debug-porten
(RA7).
Test-applet og modtager
ændres igen – nu til at
overføre data med en
50ms periodetid og
samme målinger
foretages.
Periodetiden på 50ms
bibeholdes og igen
sættes modtageren til at
skrive de modtagne bits
direkte i EEPROM'en.
Der vil muligvis ikke
forekomme voldsomme
problemer mht.
aflæsning af det
genererede digitale
signal. Dog forventes
stadig inkonsistente
perioder for det digitale
signals.
Der forekommer flere
fejl end ved forsøg med
en periodetid på 100
ms.
Modtageren
kan bedre
analysere
de lidt
længere
perioder, og
den kan
derfor generere
et pænere digitalt signal. Der er dog
stadig uregelmæssigheder, som gør, at
det analoge signal ikke når helt i top eller
bund for hver periode.
Testappletten
udsender
et analogt
signal hvorudframodtageren
genererer
en velpro-portioneret digital udgave. Kigger
man på billedet, ses det, hvor på det
analoge signal der trigges. Når der vises
en hvid farve i test-applikationen, giver det
et logisk 0 – og tilsvarende giver en sort
farve et logisk 1-tal.
Resultatet viser ret tydeligt at en halvering
af periodetiden resulterer i en fordobling af
antallet af fejl:
Dette kan sandsynligvis forhindres med en
kalibrering af systemet ved at justere de
enkelte parametre (#defines) øverst i
kildekoden.
46 Modtager

Periodetiden forbliver
uændret, og modtageren
kalibreres ved at
justere følgende parametre
i hhv. main.c og
isr.c:
MEAN_SIGNAL_OFFSET_VALUE,
SIGNAL_TRIGGER_LEVEL_PCT,
PERIOD_READ_DIVIDER,
RAW_SIGNAL_BUFFER_LENGTH,
samt SIGNAL_MEASURE_MS.
Efterfølgende afvikles
programmet på microcontrolleren,
og efter et
par minutter aflæses
EEPROM'en. Alt dette
gøres nogle gange indtil,
der er opnået et
tilfredsstillende resultat.
Antallet af AH'er i
EEPROM'en varierer fra
gang til gang. Slutresultatet
bliver bedre
end ved forrige test.
Det lykkedes at reducere fejlraten
betydeligt efter kalibrering af modtageren.
Tests viser, at den kan komme ned i
omegnen af otte fejl, som vist i figuren,
hvilket cirka giver en fejl i 1:256 gange.
Denne konfiguration ser således ud – med
to solceller aktiveret:
MEAN_SIGNAL_OFFSET_VALUE = 15
SIGNAL_TRIGGER_LEVEL_PCT = 5
PERIOD_READ_DIVIDER = 2
RAW_SIGNAL_BUFFER_LENGTH = 3
SIGNAL_MEASURE_MS = 10
Systemet kan muligvis kalibreres en
anelse bedre, men flimren fra skærmen
gør proceduren besværlig og
usystematisk. Desuden lever de
nuværende indstillingerne op til at kunne
besvise muligheden for dataoverførsel via
en computerskærm med en nogenlunde
hastighed.
Modtager 47

6 Sender
Test-applikationen viste sig nyttig i forbindelse med udarbejdelse af modtageren, og den vil i
det følgende blive modificeret, så der kan indtastes og overføres en tekst til wavecardet.
6.1 Analyse
Brugerinterfacet kommer til at ligne test-
applikationens (se illustration 40), og den
placeres samme sted på hjemmesiden (nederst
i højre hjørne) som vist tidligere. Der er ikke
behov for at implementere meget andet end
brugerens mulighed for at kommunikere en
given tekst videre til modtageren, hvorfor der
skal være et enkelt tekstfelt samt nogle
knapper til at påbegynde transaktionen.
Teksten skal blot kodes jf. datamodtagelsen på
modtageren (se afsnit 5.3.5) og transmittere
resultatet via skærmen – på stort set samme
måde som test-appleten (afsnit 4) blinkede med
skærmen.
Selve programmet er på samme måde som tidligere bygget op omkring en applet (figurens
største kasse med runde hjørner) med et datapanel (den lidt mindre kasse med runde hjørner).
Herover, i et panel for sig selv, placeres et tekstfelt samt de tidligere omtalte knapper
og jf. afsnittet om systemets anvendelse (afsnit 5.1.1). Test-applikationens
resterende funktionalitet er gemt af vejen for at forvirre brugeren mindst muligt; og man kan
overveje muligheden for hurtigt at hente dem frem igen med en parameter i URL'en
(browserens adressefelt) til brug for videreudvikling af systemet.
Illustration 40: Prototype for senderen.
48 Sender

6.2 Design
Der ændres ikke voldsomt på programmets struktur i forhold til test-applikationen. Dog
erstattes HTML-filen af en PHP-fil blot for at kunne frembringe test-applikationens funktionalitet
uden at skulle have to forskellige udgaver af programmet liggende. Ud over en mindre
tilpasning af appleten er det kun kodningen af data og selve overførselsprocessen, der
bearbejdes yderligere.
Cirklerne i illustration 41 viser de data-blokke,
der omsættes til blinkende sekvenser på
skærmen, når der trykkes på . Som
bekendt sendes først en start-byte efterfulgt af
den beregnede tjeksum og alt afhængig af
antallet af karakterer sendes en databyte af
gangen, og der afsluttes med en stop-byte
(nøjagtigt som beskrevet i afsnit 5.2.2 på side
38).
Farvenuancerne i figuren er et eksempel på de
sekvenser, som datapanelet blinker med. De repræsenterer hver enkelt bit i overførslen af en
start-byte. Imellem hvert skift ventes i en periode, så den pågældende farve vises på
skærmen i et fast tidsrum. Der vises enten sort (logisk 1) eller hvid (logisk 0) på skærmen i en
periode svarende til periodetiden. En start-bit repræsenteres med en sort sekvens, hvorpå der
følger 8 bit data og afslutningsvis vises en hvid sekvens som stop-bit. Det samme gør sig
gældende for de resterende bytes, hvor nuancerne for repræsentationen af data dog varierer.
Knappen viser blot skiftende sekvenser af sort og hvid med en fast ventetid mellem
hvert skift. I testfasen (afsnit 6.4) vurderes den maksimale overførselshastighed ved at finde
den korteste periodetid for en stabil overførsel.
Illustration 41: Kodning og dataoverførsel.
Sender 49

6.3 Implementering
Som vist i designet er der tale om en meget fast sekventiel struktur af, måden data overføres
på. Der er ikke nogen dynamik i form af tilbagemelding fra modtageren, da der som bekendt
er tale om envejskommunikation. Det gælder simpelthen om, at sender og modtager skal
være enige om strukturen for overførslen samt opsætningen af kodningen. De følgende
underafsnit beskriver og viser de vigtigste kodestumper i forbindelse med udviklingen af
senderen. For yderligere detaljer henvises til den samlede kildekode bagerst i rapporten (afsnit
D) eller på vedlagte DVD.
6.3.1 Filer
Sammenlignet med test-applikationen er filen TestApplication.java skiftet ud med
Transmitter.java og index.html er erstattet af index.php. Desuden er DataPanel.java blevet
opdateret, og debug.html sørger for, at hele applikationen kan afvikles fra den vedlagte DVD.
Fil Beskrivelse
Transmitter.java Appletten der indeholder hele brugergrænsefladen og dennes funktionalitet.
DataPanel.java Det blinkende dataområde på skærmen.
index.php
debug.html
favicon.ico
Dynamisk hjemmeside som enten viser sender-appletten eller hele
programmet på en gang. Hertil kræves en server med PHP installeret.
Viser både test- og sender-applet som en statisk hjemmeside, så hele
programmet kan afvikles uden brug af en webserver med PHP.
Et ikon med Prevas' logo der vises ved siden af URL'en og gemmes som
bogmærke.
template.css Et stylesheet som håndterer placeringen af appletten på hjemmesiden.
6.3.2 Data-panel (version 2)
Start-bits repræsenteres som logisk 1 og en stop-bits som det modsatte – logisk 0. ASCII-
tabellen flyttes 32 tegn ned, hvilket svare til karakteren for Space (' '), der også benyttes til at
”skifte” mellem de logiske blokke for små og store bogstaver i ASCII-tabellen. Start- og stop-
bytes sættes til hhv. første og anden karakter efter tabellen, så de svarer til modtagerens
konfiguration (afsnit 5.3.5 på side 41).
Appletten kan gå i forskellige modes, hvor debugmode udfører test-applikationens funktionalitet; et
tryk på knappen sætter programmet i detectmode, ligesom knappen
sætter programmet i programmode. Ved den sidste låses systemet dog først, så påvirkninger
ved tryk på andre knapper ikke registreres og dermed ødelægger transaktionen. Derefter
bliver data-panelet clearet i en periode svarende til en byte data, for at modtageren kan
detekterer start-byten. Når transaktionen er færdig låses systemet op igen og vender tilbage til
50 Sender

udgangspunktet (idlemode).
Detect-signalet blinker med højt og lavt niveau, der begge holdes i en fastlagt periode. Det
fungerer stortset på samme måde som ved test-appletten.
Ved programmering overføres data-signalerne som illustreret i designet (afsnit 6.2). Først
beregnes tjeksummen, hvorefter de enkelte bytes vises på skærmen en karakter af gangen.
Figuren herunder viser den sekventielle struktur i koden.
private void programMode() {
char checksum = calculateChecksum(getText()); // calculate checksum
transmit(START_BYTE); // send start byte
transmit(checksum); // send checksum byte
for(int i=0; i < getText().length(); i++) // loop characters
transmit((char)((getText().charAt(i)) – ASCII_OFFSET)); // - and send data
transmit(STOP_BYTE); // send stop byte
} // programMode
Tabel 8: Strukturen for dataoverførslen.
Tjeksummen, for den tekst der skal overføres, beregnes på sædvanlig vis (jf. afsnit 5.3.5.1,
side 42).
private char calculateChecksum(String text) {
int sum = START_BYTE;
for(int i=1; i = 0; i--) {
if(binary.charAt(i) == '0')
setBit(false);
else
setBit(true);
}
dynamicDelay(getPeriod());
// send stop bit
setBit(STOP_BIT);
dynamicDelay(getPeriod());
} // transmit
Tabel 10: Repræsentation af data på skærmen.
Sender 51

6.3.3 Dynamisk hjemmeside
Senderen 21 implementeres på en dynamisk hjemmeside, så det er muligt hurtigt at slå test-
funktionaliteterne til og fra. I en fremtidig udgave kan man evt. justere appletten automatisk i
forhold til skærmopløsningen ved brug af et par linjer JavaScript, så datapanelet opnår samme
størrelse som wavecardet.
6.3.4 Systemafvikling
Illustration 42 viser to browser-vinduer med
hver sin udgave af sender-applikationen.
Bagerste vindue viser udgaven med test-
miljøet, der giver mulighed for både at
anvende test-funktionaliteterne til udvikling af
nye hard- og software prototyper samt den
ordinære sender med tekstfeltet og de
tilhørende knapper.
Det forreste vindue viser den stilrene
sender-applikation tilegnet slutbrugeren. Den
fremstår enkel, og der skulle ikke være så
meget at tage fejl af. På selve hjemmesiden
kan brugen evt. informeres om systemets
anvendelse – så som hvilke knapper der
skal trykkes på, og hvordan browseren
sættes i full-screen mv.
6.4 Test
Formålet med dette afsnit er at teste det samlede system og udforske grænserne for de
forhold, modageren bedst fungerer under i samspil med senderen. Først gennemgås
brugerens interaktion med både sender og modtager – og derefter undersøges modtagerens
stabilitet og performance. Som ved tidligere tests afhænger de enkelte testscenarie af
hinanden, hvilket betyder, at testen er et samlet forløb, hvor et givet testscenarie afhænger af
de forudgående.
21 Sender med simpelt brugerinterface: http://micromedia.dk/wavecard/ eller http://micromedia.dk/wavecard/index.php og
med test-funktioner: http://micromedia.dk/wavecard/index.php?debug
Illustration 42: Sender – hhv. med og uden debugger.
52 Sender

Testscenarie Forventet resultat Faktisk resultat
Modtageren aktiveres.
Der anvendes
en LCD-skærm.
Der indtastes en
tekst (”Greetings”) i
senderns tekstfelt,
og der trykkes på
knappen .
Senderens
datapanel begynder
at blinke med hhv.
højt og lavt signal.
knappen
trykkes igen, og
senderen holder op
med at blinke.
Endnu engang
trykkes på .
Efter at have fundet
periodetiden ventes
en rum tid mens
senderen stadig
blinker.
Mens datapanelet
stadig blinker (hvilket
dog ikke er et krav)
trykkes nu på
.
Modtageren går i
normal-tilstand. Den
lyser med alle sine
lysdioder og indikerer
dermed, at den ikke
indeholder data.
Modtageren indikerer,
at den forsøger at
finde periodetiden ved
at blinke med hhv. en
af to lysdioder. Når
periodetiden er fundet
vises 110010B (50D ms)
på lysdioderne, hvilket
svarer til den
periodetid senderen er
indstillet til.
Efter en rum tid (jf.
modtagerens variabel
TIMEOUT) går
modtageren tilbage i
normal-tilstand.
Modtageren forsøger
endnu engang at finde
periodetiden, og
indikerer dette på
lysdioderne.
Modtageren forbliver i
samme tilstand og
venter på at modtage
en start-kommando.
Lysdioderne begynder
at blinke med
periodetiden. Bagefter
indikeres om
modtagelsen lykkedes.
Lysdioden viser konstant 1111111B.
Modtageren blinker med hhv. 0000001B og
0000010B. Der går nogle sekunder, inden
modtageren finder en mulig periodetid angivet
ved 0101000B (40D ms), hvilken desværre er
forkert.
Lysdioderne viser 1111111B, og indikerer
dermed, at den er tilbage i normal-tilstand.
Lysdioderne indikerer igen, at den forsøger at
finde periodetiden ved at blinke med hhv.
0000001B og 0000010B. Af og til går
modtageren kortvarigt tilbage i normal-tilstand
(jf. variablen TIMEOUT), men søgningen efter
periodetiden genoptages hurtigt.
Lysdioderne viser den ønskede periodetid –
0110010B (50D ms ).
Lysdioderne viser uændret 0110010B (50D).
Modtagerens lysdioder blinker med hhv.
0110010 (periodetiden) og 1001101 (den
inverterede periodetid).
Efter nogle sekunder vises periodetiden igen,
og modtageren indikerer dermed, at
datamodtagelsen ikke var vellykket.
Sender 53

Mens modtageren
stadig viser
periodetiden trykkes
endnu engang på
.
Modtageren er
tilbage i normaltilstand.
Der indtastes en ny
tekst (”Happy
Valentine's”) og
trykkes på .
Når den rigtige
periodetid er fundet
trykkes på
.
Igen blinker
lysdioderne med
periodetiden og viser
derefter om data blev
modtaget korrekt.
Lysdioderne blinker
med indholdet af det
dataområde, som
netop er blevet
tilskrevet den overførte
tekst.
Modtageren viser, at
den forsøger at finde
periodetiden som
beskrevet tidligere.
Den fundne periodetid
vises og blinkes under
dataoverførslen.
Ved korrekt
modtagelse vises et
løbelys og
efterfølgende vises den
nye tekst på
lysdioderne.
Under datamodtagelsen blinker lysdioderne
atter med hhv. periodetiden og den inverterede
periodetid.
Efterfølgende viser modtageren et hurtigt
løbelys, der bekræfter korrekt datamodtagelse.
Kigger man nøje efter, viser lysdioderne igen
og igen de enkelte karakters ASCII-værdi for
den overførte tekst: G (1000111B = 47H), r
(1110010B = 72H), e (1100101B = 65H), e
(1100101B = 65H), t (1110100B = 74H), i
(1101001B = 69H), n (1101110B = 6EH), g
(1100111B = 67H) og s (1110011B = 73H). De
binære tal angiver, hvad lysdioderne viser – og
de hexadecimale kan ses i EEPROM'en:
Første byte i EEPTOM'en er som bekendt
længden af teksten – altså tallet 9.
Andet tal er den overførte tjeksum-karakter, M
(4DH).
Modtageren er nogle sekunder om at
registrere periodetiden. Efter at have fundet
den forsøges data overført nogle gange, før
det lykkedes. Der skal muligvis en del
kalibrering mere til for at undgår disse
ventetider.
Kigger man efter i EEPROM'en, har
modtageren registreret den nye tekst og gjort
den aktiv ved at angive dens længde (11H =
17D karakterer). Den gamle teksts længde er
sat til FFH, hvilket gør den inaktiv:
54 Sender

Baggrundslyset på
skærmen sænkes
så meget som
muligt, og dermed
mindskes amplituden
for det signal
microcontrolleren
skal behandle.
Modtageren ændres
igen, så der skrives
A'er (1010B) overalt i
EEPROM'en.
Der trykkes på
-knappen,
så appletten blinker
med en periode på
50ms.
Der skrues nu op på
halv kontrast og
endnu et forsøg
foretages som det
ovenfor.
Skærmbilledet bliver
gråligt. Muligvis vil
systemet skulle
justeres for at kunne
registrere de svage
signaler.
Resultatet burde blive
en hel del bedre end
tidligere.
Allerede inden der trykkes på ,
begynder microcontrolleren at søge efter
periodetiden. Variablen PROGRAMMER_MODE_TICKS
(antallet af blink inden der søges efter
periodetiden) ændres fra værdien 3 til 4.
Efter endnu et forsøg venter microcontrolleren
med at søge efter periodetiden indtil der
trykkes på . Dog ser indholdet af
EEPROM'en katastrofalt ud.
Hardware-prototypen er så følsom, at den kan
påvirkes blot ved at bevæge en hånd 8-10 cm
hen i nærheden af den.
Der opstår i omegnen af 17 fejl, hvilket må
betragtes som et udmærket resultat taget den
noget ustabile hardware i betragtning.
Sender 55

7 Udvidelser
Udviklingsafdelingen bag de forskellige plastickort-projekter så som wavecardet åbner nye
muligheder for måden at sammensætte forskellige teknologier på. Dette afsnit stiller skarpt på
nogle idéer til videreudvikling, som er opstået undervejs i projektforløbet. Der er tale om rene
tankeeksperimenter, hvor fantasien får frit spil.
For det første kan der kigges nærmere på implementering af de lavt prioriterede krav fra
kravspecifikationen (jf. afsnit 2.5), hvor datamodtagelsen kan forbedres betydeligt, ved
implementering af flere sensorer. Dette stiller imidlertid krav til antallet af ADC-indgange på
microcontrolleren og kan gå hen at blive dyrt i længden. Ved implementering af en mere
lysfølsom og stabil sensor vil der kunne aflæses nuancer af grå fra skærmen. Endvidere vil en
farvesensor, á la en CCD-chip, muliggøre aflæsning af endnu flere nuancer fra skærmen,
hvilket vil øge dataoverførslen betydeligt. Man må dog påregne en del tab, hvis der skal være
en vis sikkerhed i overførslen og ved mulighed for dæmpning af lysstyrken på skærmen.
Desuden vil man gå glip af strømbesparelsen ved implementering af en farvesensor.
Der er indlysende fordele ved at bruge solceller (og piezoer), da de ikke bruger strøm, men i
stedet generer den. Denne type komponenter er defor geniale til små embeddede systemer,
hvor strøm besparelse vægtes højt.
Antallet af CRT-skærme er nedadgående, og inden for nogle få år vil de være et yderst
sjældent syn i de teknologiske dele af verden. Godt kan de gengive flottere billeder end LCD-
typen, men tilgengæld afgiver de en masse varme, bruger en del mere strøm og æstetisk set
er de klodsede, besværlige og fylder meget. Folk vælger dem typisk fra, hvorfor udvidelser af
dataoverførselen til CRT-skærme nok ikke vil blive aktuel, så fokus kan lægges på
forbedringer af understøttelsen af LCD-skærme.
Implementeres et digitalt filter i stedet for det nuværende RC-kredsløb mellem solcellerne og
forstærkeren på prototypen, vil man undgå en del af de langsomme stige-/faldetider på
signalet som vist under test af hardware-prototypen (afsnit 4.4) og analysen af modtageren
(afsnit 5.1.2.1). Dette vil dog kræve mere plads på microcontrolleren, men tilgengæld vil
signalerne blive meget mere tydelige, så der vil kunne opnås en højere overførselshastighed.
Hvad angår udviddelse af selve kortets funktionalitet, er det kun fantasien, der sætter
grænser. Her nævnes i flæng: visning af firmalogo, scrolling-tekst, logoer der drejer rundt og
andre gadget-agtige funktioner. Aflæsning fra skærmen kan også kombineres på forskellige
måder, så der kan udvikles mere raffinerede teknologier. Prevas har nogle forskellige idéer på
tegnebrættet, som desværre ikke kan nævnes yderligere her.
56 Udvidelser

Kunne man helt undgå operationsforstærkeren mellem solcellerne, og ADC'en vil der kunne
spares på produktionsomkostningerne. Signalet vil dog komme til at ligge ret lavt, hvorfor man
vil gå på kompromis med opløsningen og dermed overførselshastigheden, medmindre hele den
ene side af kortet fyldes med solceller. Systemet vil tilgengæld være ret simpelt, da solcellerne
forbindes direkte til ADC-indgangen uden fordyrende mellemled.
En af de større problemer bliver på sigt at holde liv i kortets batteri, hvofor der må en form for
genopladning til. Af de muligheder, der umiddelbart er tilrådighed, kan nævnes opladning via
piezoen, når kortet rystes. Ved montering af solceller til dataoverførsel vil disse også kunne
anvendes som energiforsyning. Der vil endda være rigeligt med plads på kortet til solceller,
selvom man eventuelt beslutter sig for en anden form for sensor til datamodtagelse. Muligvis
kan der udvikles en anordning til opladning vha. en magnet, eller der kan monteres et minimalt
stik til opladning via en transformator til stikkontakten, som det kendes fra mobiltelefoner,
GPS'er og lignende. Yderligere vil man muligvis i fremtiden se batterier med solceller
premonteret, eller batterier der oplades vha. varme, når kortet ligger i ens baglomme. Den
fremadstormende nanoteknologi bidrager konstant med nye muligheder.
Udvidelser 57

8 Konklusion
På baggrund af de udførte tests vurderes det samlede resultat af systemet. Der foretages en
kort gennemgang af kravspecifikationen for at undersøge, om løsningen lever op til
forventningerne. Projektets arbejdsproces kommenteres og sammenholdes med dele af
forundersøgelsen.
8.1 Systemet
Det er vigtigt at understrege, at der ikke er tale om et færdigt produkt – i stedet handler det
om proof-of-concept med fokus på optisk dataoverførsel fra en computerskærm til et indlejret
system. Med dette udgangspunkt kan udfaldet betragtes som en succes, hvor stillede krav
(afsnit 2.5, side 10) med de to højeste prioriteter er opfyldt. Jf. visualiseringen (krav 12) vises
data kort på modtagerens lysdioder – eller de kan aflæses i et af dens interne lagerområder
vha. et udviklingsmiljø. Den overførte tekst vises altså ikke i luften, hvilket skyldes den
nuværende implementering af wavecardet, hvor tekster er hard-kodet på kortet og ikke
benytter en systematisk metode til at omdanne karakterer til lys. Krav med lavere prioriteter
(krav 5 og 10) har ikke vist sig aktuelle af den simple årsag, at de vil kræve flere tilgængelige
porte på microcontrolleren. Wavecardets microcontroller står overfor en udskiftning til en anden
type med færre funktionaliteter, da denne type embeddede systemer produceres i større
mængder, og der kan spares mange penge ved at mindske hardwareomkostningerne.
De udførte tests afhænger meget af modtagerens konfiguration mht. behandlingen af det
analoge signal. Ligeledes betyder de forhold systemet fungere under en hel del for succesen
af overførslen – her spiller forskellige faktorer ind så som forstyrrelser i hardware-prototypen,
løse forbindelser i testmiljøet, kalibrering af modtageren, for svagt lys fra skærmen, for kraftige
lysforhold i rummet og applettens stabilitet. I bund og grund vil det kun være bearbejdningen af
det analoge signal fra skærmen, som kan volde problemer, fordi mange af forhindringerne vil
forsvinde ved den endelige implementering af hardwaren. Lysforholdene er ikke blevet testet
særligt grundigt af den simple årsag, at solcellerne på den endelige udgave vil være placeret
klods op og ned ad skærmen, og selve kortet vil skygge for det udefrakommende lys. Den
nuværende hadware-prototype vil dog være følsom overfor direkte lys. Man bør kraftigt
genoverveje brugen af Java-appletter til at overføre data med, hvis de ikke tildeles tilstrækkeligt
med systemressourcer. Systemudviklere vil sandsynligvis have styr på dette (i forbindelse med
tests), hvilket ikke kan forventes af slutbrugeren. Desuden har Java ikke en dyb nok tilgang til
systemet, så der opstår flimren på skærmen, hvilket skyldes manglende synkronisering mellem
skærm og grafikkort. Dog er det smart, at senderen kan tilgås blot vha. en internetforbindelse.
58 Konklusion

Bredden af selve bølgerne, fra de lyssignaler som skærmen udsender, varierer en del, alt efter
hastigheden hvormed der blinkes, hvilket gør bestemmelse af periodetiden en anelse
besværlig.
Ønskes detektering af gråtoner fra skærmen, for at øge dataoverførslen, får man imidlertid
problemer med modtagelsen, hvis baggrundslyset er dæmpet, hvilket vil få den uønskede
effekt, at brugeren aktivt skal forberede transaktionen.
8.2 Processen
Der kan puttes mange tillægsord på arbejdsmiljøet hos Prevas, hvor der konstant kommer nye
folk til, og nogle få falder fra. Medarbejderne er imødekommende, interesserede i hinandens
projekter og venlige til at hjælpe. Specielt i forbindelse med udviklingen af hardware-prototypen
har det været rigtigt spændende at være med i samarbejdet på tværs af forskellige
fagområder og opleve grænselandet mellem hard- og softwareudvikling.
For det meste har det daglig arbejde foregået i virksomheden – og i mere privat regi under
intensiv rapport-skrivning grundet støj fra det åbne kontorlandskab. Arbejdsdisciplinen har
været høj under hele projektforløbet med en gennemsnitlig arbejdsdag på omkring 8-9 timer
5-6 dage om ugen – i runde tal en arbejdsuge på lidt over 41 timer – og dertil kommer
yderligere tid til frokost og networking. (se evt. detaljerne i bilag B). Fordelingen af
arbejdsindsatsen fremgår af
illustration 43, som viser det
procentvise tidsforbrug for hver
udviklingsfase samt rapportering.
Der er blevet brugt en del
ressourcer på bestilling af udstyr og
fremstilling af testmiljøet, hvorfor
implementeringen fylder forholdsvist
meget.
Projektet har i overraskende høj
grad fulgt tidsplanen (se bilag A)
med ganske få afvigelser. Der er
overordnet set blevet arbejdet efter
vandfaldsmodellen gennem hele
forløbet; men samtidig har opgavens art forudsættet en tilbagevenden til tidligere udførte
opgaver. Her tænkes på arbejdet med test-applikationen, der gradvist blev udvidet til at have
flere af senderens egenskaber. Desuden har de enkelte tests været vigtige for at kunne
udføre de efterfølgende opgaver, hvorfor vandfaldsmodellen i dette tilfælde viste sig effektiv.
Med hensyn til kontakt til vejlederen har al kommunikation foregået via CampusNet (DTUs
intranet), og der har fundet to møder sted i virksomheden samt tre på DTU.
Analyse
Design
Impl.
Test
Rapport
Illustration 43: Fordeling af tidsforbruget for projektets faser.
Konklusion 59

Bilag A - Tidsplan
Der afsættes en uge til halvanden til selve opstarten af projektet for at danne overblik over
problemstillingerne. Inden juleferien (i uge 51, 2007 og uge 1, 2008) udvikles en test-applikation
for at kunne tilpasse hardwaren og analysere de signaler, der sendes til modtageren. Der
afsættes ca. 10 dage til dette.
Illustration 44: Det indledende forløb samt udvikling af test-applikationen.
Til udviklingen af modtageren er der afsat ca. 3-4 uger – så med en uges vinterferie sidst i
perioden burde de resterende programfunktioner komme på plads.
Illustration 45: Udvikling af modtageren.
60 Bilag A - Tidsplan

I den afsluttende del af projektet skal alle komponenterne kædes sammen. Senderen udvikles
ud fra test-applikationen og testes med modtageren. Sidst men ikke mindst skal rapporten
skrives færdig.
Illustration 46: Udvikling af senderen og det afsluttende forløb.
Bilag A - Tidsplan 61

Bilag B - Logbog
Her følger en oversigt over det faktiske tidsforbrug, som indledes med en opsummering af
timetallet for de enkelte områder samt en illustrattion, der grafisk viser de indbyrdes forhold
mellem udviklingsfaserne. Ligeledes følger en detaljeret oversigt over de enkelte dages
aktiviteter i løbet af projektperioden.
B.1 Oversigt
Fordeling af arbejdstid
Analyse
Design
Impl.
Test
Rapport
Beskrivelse Analyse Design Im pl. Test Rapport Total Pr. uge
Antal timer i alt 95 72 138 70 121 496 41,33
Fordeling 19% 15% 28% 14% 24% 100%
62 Bilag B - Logbog

B.2 Detaljer
Uge Dato Beskrivelse af aktivitet Analyse Design Im pl. Test Rapport Pr. uge
1 man. 3. dec. Research 8
tir. 4. dec. Research, Tidsplan 8
ons. 5. dec. Research, Kravspecifikation 8
tor. 6. dec. Analysediagram, Aktivitetsdiagram 8
fre. 7. dec. Aktivitetsdiagram 8
lør. 8. dec.
søn. 9. dec. Research 5 45
2 man. 10. dec. Struktur, Rapport-setup 8
tir. 11. dec. Struktur, Forord, Indledning, 8
ons. 12. dec. Introduktion til prototype, Test-program 3 5
tor. 13. dec. Test-program, Aktivitetsdiagram 6 2
fre. 14. dec. Analysediagram for test-applet 5
lør. 15. dec.
søn. 16. dec. 37
3 man. 17. dec. Designdiagram, transmitter-/test-applet 3
tir. 18. dec. Transmitter-applet 9
ons. 19. dec. HTML og stylesheet til applet 8
tor. 20. dec. Datapanel (område der blinker med data) 8
fre. 21. dec. Observationstest af test-applikation 4 4
lør. 22. dec.
søn. 23. dec. 36
4 man. 24. dec. Juleferie
tir. 25. dec.
ons. 26. dec.
tor. 27. dec.
fre. 28. dec.
lør. 29. dec.
søn. 30. dec.
5 man. 31. dec.
tir. 1. jan.
ons. 2. jan.
tor. 3. jan.
fre. 4. jan.
lør. 5. jan.
søn. 6. jan.
6 man. 7. jan. Forberedelse 4 4
tir. 8. jan. Målinger med prototype 5 3
ons. 9. jan. Install af HI-TIDE, opsætning af MCU 4 2
tor. 10. jan. Skærmteknologier 6 3
fre. 11. jan. Designdiagrammer for modtager 3 5
lør. 12. jan.
søn. 13. jan. 39
7 man. 14. jan. Justering af double-buffer i applet 8
tir. 15. jan. Undersøg overførselsprotokol. 4 4
ons. 16. jan. Forsøg på udvikling af protokol. 3 4
tor. 17. jan. Diagrammer for protokol. Indkøb ICD2. 5 3
fre. 18. jan. Møde med Bjarne. Stik til udviklingsmiljø 3 4 1
lør. 19. jan.
søn. 20. jan. 39
8 man. 21. jan. MPLAB-opsætning. Struktur af rapport 4 3
tir. 22. jan. Indsamling af måledata. Diagrammer 3 3 2
ons. 23. jan. Møde med Edw ard på DTU 4
Bilag B - Logbog 63

tor. 24. jan. Opsætning af microcontroller 6
fre. 25. jan. Pulse detection 8
lør. 26. jan. Analyse af signaler 8
søn. 27. jan. 41
9 man. 28. jan. Vinterferie
tir. 29. jan.
ons. 30. jan.
tor. 31. jan.
fre. 1. feb.
lør. 2. feb.
søn. 3. feb.
10 man. 4. feb. Digital modtagelse 1 2 6
tir. 5. feb. Sender applikation 1 2 6
ons. 6. feb. Modtager decoding 1 2 6
tor. 7. feb. Datamodtagelse tuning 6
fre. 8. feb. Datamodtagelse tuning 8
lør. 9. feb.
søn. 10. feb. 41
11 man. 11. feb. Datamodtagelse 3 5
tir. 12. feb. Test-applikation dokumentation 5 5 5
ons. 13. feb. Enkodning af datasignaler på sender 2 4 6
tor. 14. feb. Fremvisning af dataoverførsel 3
fre. 15. feb. Modtager analyse 2 7
lør. 16. feb.
søn. 17. feb. 47
12 man. 18. feb. Signalbehandling for modtager 6 2 3
tir. 19. feb. Dataoverførsel 6 2 3
ons. 20. feb. Design illustrationer 6 4
tor. 21. feb. Design illustrationer 8
fre. 22. feb. Design illustrationer 4 3
lør. 23. feb.
søn. 24. feb. 47
13 man. 25. feb. Design illustrationer 8
tir. 26. feb. Illustrationer, implementering og testmiljø 4 4
ons. 27. feb. Illustrationer implementering og testmiljø 4 4
tor. 28. feb. Illustrationer, implementering og testmiljø 4 4
fre. 29. feb. Test 8
lør. 1. mar.
søn. 2. mar. 40
14 man. 3. mar. Test og kalibrering 6
tir. 4. mar. Test og kalibrering 6
ons. 5. mar. Test og kalibrering 6
tor. 6. mar. Rettelser og opsætning af rapport 6
fre. 7. mar. Målinger, Møde med Edw ard på DTU 6 3
lør. 8. mar. Test af signaler 5
søn. 9. mar. Rettelser 8 46
15 man. 10. mar. Konklusion 8
tir. 11. mar. Møde med Bjarne i Prevas 2 6
ons. 12. mar. De sidste rettelser 9
tor. 13. mar. De sidste rettelser 8
fre. 14. mar. Udskrivning og kopiering af CD'ere 5 38
64 Bilag B - Logbog

Bilag C - Tekniske begreber
I rapporten forekommer ord og vendinger af teknisk karakter, som kan være svære at forstå
betydningen af, hvis man ikke er stødt på dem før eller i det daglige arbejder med denne form
for systemer. Listen herunder viser så vidt som muligt både den tekniske betegnelse i hele ord
og dennes forkortelse samt dennes betydning.
Teknisk betegnelse Betydning
ADC
(Analog-to-Digital Converter)
AMLCD
Active Matrix Liquid Crystal Display
Omsætter analoge signaler fra den fysiske verden til digitale signaler,
som en computer kan forstå.
Se under LCD.
Bit-rate Også kaldet data-rate angiver antallet af bits der overføres i en
dataforbindelse – typisk angivet i bits per sekund med enheden bps
eller bit/s.
CSS
Cascading Style Sheet
Adskiller en hjemmesides layout fra den struktur (HTML eller XHTML),
så designet kan bearbejdes separat fra indholdet.
Duty-cycle Den del af tiden (målt i procent) et digitalt signal er højt.
EEPROM
Electrically Erasable Programmable
Read-Only Memory
IDE
Integrated Development Environment
Et lagerområde på en chip der bevares, selv om den ikke tilføres
strøm.
Udviklingsmiljø der integrerer en avanceret teksteditor med
projektstyring, compiller og debugger.
Interrupt Giver en microcontroller besked når forskellige forhold gør sig
gældende. F.eks. hvis en ADC-måling er klar, en timer nulstilles mv.
LCD
Liquid Crystal Display
LED
(Light-Emitting Diode)
En type avanceret display der ofte forekommer i fladskærme.
Også kaldet en lysdiode – udsender lys når den påvirkes med en
svag elektrisk spænding.
Low-pass filter Et elektrisk kredsløb der filtrerer høje frekvenser fra et signal og kun
videresender frekvenser under en fastsat grænse. Se RC-led.
LSB
Least Significant Bit
MCU
(Micro Controller Unit)
MSB
Most Significant Bit
Den mindst betydende bit i et binært tal er den, der er længst til
højre.
En meget lille computer der er yderst specialiseret, så den kun
anvendes til bestemte formål.
Den mest betydende bit i et binært tal er den, der er længst til
venstre.
Nibble En halv byte eller 4 bits (24) repræsenterer 16 forskellige værdier.
Op-amp
Operational amplifier
PCB
Printed Circuit Board
Et forstærkerkredsløb der eksempelvis kan hæve en given svag
spænding et hel del gang.
Teknisk betegnelse for en printplade.
Bilag C - Tekniske begreber 65

PIC
Programmable Interface
Controller/Programmable Intelligent
Computer
PWM
Pulse Width Modulation
RC-led
Resistor/Capacitor
SRAM
Static Random Access Memory
TFT
Thin Film Transistor
En microcontroller udviklet af producenten Microchip der fås i mange
forskellige udgaver.
En måde at sænke en elektrisk spænding på ved skiftevis at tænde
og slukke for den med høj hastighed.
Oplader en kondensator igennem en modstand for at bestemme
den tid, hvormed kondensatoren oplades. Se evt. under Low-pass
filter.
Er en type hurtig hukommelse vis indhold forsvinder, når strøm ikke
tilføres.
En teknik anvendt i bl.a. LCD-skærme til at kunne vise hver pixel.
Timer Benyttes af en microcontroller til at holde styr på hvor lang tid der
går mellem forskellige hændelser. En timer anvendes evt. sammen
med interrupts.
XHTML
eXtended HyperText Markup
Language
Den måde en hjemmeside beskrives på. XHTML er en
videreudvikling af HTML for at komme tættere på XML.
66 Bilag C - Tekniske begreber

D.1 Test-applikation
D.1.1 TestApplication.java
package testapp;
// Core packages
import java.awt.*;
import java.awt.event.*;
// Extension packages
import javax.swing.*;
import javax.swing.event.ChangeEvent;
import javax.swing.event.ChangeListener;
/**
* 'Transmitter' is a web application for transferring
* data from the screen to an electronic device. It has
* debugging facilities to control the duty cycle and
* period of the digital signals.
*
* @author Hasse Bylov - hasse@bylov.com
* @see http://www.micromedia.dk/wavecard/index.html
*
*/
public class TestApplication extends JApplet {
private static final long serialVersionUID = 5811536125471100063L;
private static final int PERIOD_MIN = 10;
private static final int PERIOD_MAX = 1000;
private static final int PERIOD_INIT = 50;
private static final int DUTY_MIN = 0;
private static final int DUTY_MAX = 100;
private static final int DUTY_INIT = 50;
private static final int HIGH_CONTRAST = 0;
private static final int LOW_CONTRAST = 255;
private static final int COLOR_DEPTH_MAX = 255;
private static final int COLOR_DEPTH_MIN = 0;
private static final int COLOR_DEPTH_STEP = 1;
private static final int NUMBER_OF_ROWS = 4;
private static final int NUMBER_OF_COLUMNS = 4;
private static final int SYSTEM_LAYOUT = 2;
// System
private UIManager.LookAndFeelInfo looks[];
// Panels
private JPanel periodPanel;
private JPanel dutycyclePanel;
private JPanel contrastPanel;
private JPanel statusPanel;
private JPanel debugPanel;
private JPanel controlPanel;
private DataPanel outputPanel;
Bilag D - Kildekode
Bilag D - Kildekode 67

Debugging
private JLabel periodLabel;
private JSlider periodSlider;
private JLabel periodValueLabel;
private JLabel periodUnitLabel;
private JLabel dutycycleLabel;
private JSlider dutycycleSlider;
private JLabel dutycycleValueLabel;
private JLabel dutycycleUnitLabel;
private JLabel lowContrastLabel;
private SpinnerNumberModel lowContrast;
private JSpinner lowContrastSpinner;
private JLabel highContrastLabel;
private JSpinner highContrastSpinner;
private SpinnerNumberModel highContrast;
private JToggleButton operateButton;
/**
* init() is the applet's main method where things are setup once
*/
public void init() {
try { // Set up the user interface
javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
createGUI();
}
});
} catch (Exception e) { // an unknown error occurred
System.err.println("createGUI() didn't successfully complete");
}
} // init
/**
* changeLookAndFeel() makes the user interface look
* like the user's operating system
* @param int look number
*/
private void changeLookAndFeel(int value) {
try {
UIManager.setLookAndFeel(looks[value].getClassName());
SwingUtilities.updateComponentTreeUI(this);
} catch (Exception e) {
e.printStackTrace();
}
} // changeLookAndFeel
/**
* getFrequency() calculates the frequency
* from the data panel's period and hacks
* it to return a decimal value
* @return double frequency in Hz
*/
private double getFrequency() {
double frequency = 1000.0 / (double)(outputPanel.getPeriod());
return Math.round(frequency * 100.0) / 100.0;
} // getFrequency
/**
* createGUI() sets up the panels, sliders and buttons
*/
private void createGUI() {
// Debug panel
periodLabel = new JLabel("Period:");
periodLabel.setLabelFor(periodSlider);
periodSlider = new JSlider(SwingConstants.HORIZONTAL, PERIOD_MIN, PERIOD_MAX,
PERIOD_INIT);
periodSlider.setMajorTickSpacing(PERIOD_MAX-PERIOD_MIN);
periodSlider.setPaintTicks(true);
periodSlider.setPaintLabels(true);
periodValueLabel = new JLabel("");
periodUnitLabel = new JLabel("ms");
DUTY_INIT);
dutycycleLabel = new JLabel("Duty cycle:");
dutycycleLabel.setLabelFor(dutycycleSlider);
dutycycleSlider = new JSlider(SwingConstants.HORIZONTAL, DUTY_MIN, DUTY_MAX,
68 Bilag D - Kildekode

dutycycleSlider.setMajorTickSpacing(25);
dutycycleSlider.setPaintTicks(true);
dutycycleSlider.setPaintLabels(true);
dutycycleValueLabel = new JLabel("");
dutycycleUnitLabel = new JLabel("%");
lowContrastLabel = new JLabel("Low:");
lowContrastLabel.setLabelFor(lowContrastSpinner);
lowContrast = new SpinnerNumberModel(LOW_CONTRAST, COLOR_DEPTH_MIN,
COLOR_DEPTH_MAX, COLOR_DEPTH_STEP);
lowContrastSpinner = new JSpinner(lowContrast);
highContrastLabel = new JLabel("High:");
highContrastLabel.setLabelFor(lowContrastSpinner);
highContrast = new SpinnerNumberModel(HIGH_CONTRAST, COLOR_DEPTH_MIN,
COLOR_DEPTH_MAX, COLOR_DEPTH_STEP);
highContrastSpinner = new JSpinner(highContrast);
operateButton = new JToggleButton(" Turn On ");
operateButton.setMnemonic(KeyEvent.VK_T);
periodPanel = new JPanel();
periodPanel.setLayout(new FlowLayout());
periodPanel.add(periodLabel);
periodPanel.add(periodSlider);
periodPanel.add(periodUnitLabel);
dutycyclePanel = new JPanel();
dutycyclePanel.setLayout(new FlowLayout());
dutycyclePanel.add(dutycycleLabel);
dutycyclePanel.add(dutycycleSlider);
dutycyclePanel.add(dutycycleUnitLabel);
contrastPanel = new JPanel();
contrastPanel.setLayout(new FlowLayout());
contrastPanel.add(lowContrastLabel);
contrastPanel.add(lowContrastSpinner);
contrastPanel.add(highContrastLabel);
contrastPanel.add(highContrastSpinner);
contrastPanel.add(operateButton);
statusPanel = new JPanel();
statusPanel.setLayout(new FlowLayout());
statusPanel.add(periodValueLabel);
statusPanel.add(dutycycleValueLabel);
debugPanel = new JPanel();
debugPanel.setLayout(new GridLayout(NUMBER_OF_ROWS, NUMBER_OF_COLUMNS, 0, 0));
debugPanel.setBackground(Color.LIGHT_GRAY);
periodSlider.addChangeListener ( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setPeriod(periodSlider.getValue());
periodValueLabel.setText("Frequency:" + getFrequency() + "Hz ("
+ outputPanel.getPeriod() + "ms)" );
dutycycleSlider.setValueIsAdjusting(true);
dutycycleSlider.setValueIsAdjusting(false);
}
} );
dutycycleSlider.addChangeListener ( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setDutycycle(dutycycleSlider.getValue());
dutycycleValueLabel.setText("ON-time:" +
outputPanel.getDutyHigh() + "ms OFF-time:" + outputPanel.getDutyLow() + "ms");
}
} );
lowContrast.addChangeListener( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setLowContrast( ((Integer)lowContrast.getValue()).intValue() );
}
} );
highContrast.addChangeListener( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
Bilag D - Kildekode 69

outputPanel.setHighContrast( ((Integer)highContrast.getValue()).intValue() );
}
} );
operateButton.addChangeListener( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
if(operateButton.isSelected()) {
operateButton.setText(" Turn Off");
outputPanel.setMode("debugmode");
} else if(outputPanel.getMode() == "debugmode") {
operateButton.setText(" Turn On ");
outputPanel.setMode("idlemode");
}
}
} );
debugPanel.add(periodPanel);
debugPanel.add(dutycyclePanel);
debugPanel.add(contrastPanel);
debugPanel.add(statusPanel);
// Output panel
outputPanel = new DataPanel(periodSlider.getValue(), dutycycleSlider.getValue(),
((Integer)highContrast.getValue()).intValue(), ((Integer)lowContrast.getValue()).intValue());
outputPanel.setBackground(Color.ORANGE);
// Control panel
controlPanel = new JPanel();
controlPanel.setLayout(new BorderLayout());
controlPanel.setBackground(Color.WHITE);
if(getParameter("debug") != null)
controlPanel.add(debugPanel, BorderLayout.NORTH);
//controlPanel.add(userPanel, BorderLayout.CENTER);
// Setup panels
Container container = getContentPane();
container.add(controlPanel, BorderLayout.NORTH);
container.add(outputPanel, BorderLayout.CENTER);
// Show default values
periodSlider.setValueIsAdjusting(true);
periodSlider.setValueIsAdjusting(false);
dutycycleSlider.setValueIsAdjusting(true);
dutycycleSlider.setValueIsAdjusting(false);
looks = UIManager.getInstalledLookAndFeels();
changeLookAndFeel(SYSTEM_LAYOUT);
} // createGUI
} // TestApplication
D.1.2 DataPanel.java (version 1)
package testapp;
// Core packages
import java.awt.*;
// Extension packages
import javax.swing.JPanel;
/**
* 'DataPanel' is a JPanel used for transferring binary data
* (and in the future also multiple color values) from a normal
* computer screen on to an electronic device. The panel is
* used with the 'TestApplication' program.
*
* @author Hasse Bylov - hasse@bylov.com
* @see http://www.micromedia.dk/wavecard/index.html
70 Bilag D - Kildekode

*
*/
public class DataPanel extends JPanel implements Runnable {
private static final long serialVersionUID = -2997949170529730708L;
// off-screen buffer
private Image offscreen;
// visual control
private boolean bit;
private int period;
private int dutycycle;
private int highContrast;
private int lowContrast;
// mode select
private String mode;
// panel constructor
public DataPanel(int period, int dutycycle, int contrastHigh, int contrastLow) {
super();
}
this.period = period;
this.dutycycle = dutycycle;
this.highContrast = contrastHigh;
this.lowContrast = contrastLow;
new Thread(this).start();
/*
* trivial getter/setter methods
*/
private boolean getBit() {
return bit;
}
public void setBit(boolean value) {
this.bit = value;
repaint();
}
public int getPeriod() {
return period;
}
public void setPeriod(int period) {
this.period = period;
}
private int getDutycycle() {
return dutycycle;
}
public void setDutycycle(int dutycycle) {
this.dutycycle = dutycycle;
}
public int getDutyHigh() { // ON-Time = D*T
return (getDutycycle() * getPeriod()) / 100;
}
public int getDutyLow() { // OFF-Time = (1-D)*T
return ((100-getDutycycle()) * getPeriod()) / 100;
}
public int getHighContrast() {
return highContrast;
}
public void setHighContrast(int high) {
this.highContrast = high;
}
public int getLowContrast() {
return lowContrast;
Bilag D - Kildekode 71

}
public void setLowContrast(int low) {
this.lowContrast = low;
}
public String getMode() {
return mode;
}
public void setMode(String mode) {
this.mode = mode;
}
/**
* dynamicDelay() holds the square wave signal
* for a given time
* @param int time
*/
private void dynamicDelay(int time) {
long bitPeriod = System.currentTimeMillis();
while((System.currentTimeMillis()-bitPeriod) < time) {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} // dynamicDelay
/**
* screenBinary() blinks the data panel according
* to the debug controls. Besides the trivial methods
* this is enough to control the test-application
*/
private void screenBinary() {
if(getDutyHigh() > 0) {
setBit(true);
dynamicDelay(getDutyHigh());
}
if(getDutyLow() > 0) {
setBit(false);
dynamicDelay(getDutyLow());
}
} // screenBinary
/**
* run() is the default Thread loop, from where
* the program mode is controlled
*/
public void run() {
while(true) { // forever...
if(getMode() == "debugmode") { // test-application
screenBinary();
} else { // to avoid CPU overload, system needs idle time
dynamicDelay(50);
}
}
} // run
/**
* invalidate() removes the off-screen buffer
*/
public void invalidate() {
super.invalidate();
offscreen = null;
} // invalidate
/**
* update() overrides the default update()
* to NOT erase the background before painting
* @param Graphics g
*/
public void update(Graphics g) {
paint(g);
} // update
72 Bilag D - Kildekode

image
/**
* paint() puts everything in place in an off-screen buffer and then shows entire
* on screen at once.
* @param Graphics g
*/
public void paint(Graphics g) {
Color highColor = new Color(getHighContrast(), getHighContrast(),
getHighContrast());
Color lowColor = new Color(getLowContrast(), getLowContrast(),
getLowContrast());
if(offscreen == null) {
offscreen = createImage(getSize().width, getSize().height);
}
Graphics offscreenGraphics = offscreen.getGraphics();
offscreenGraphics.setClip(0, 0, getSize().width, getSize().height);
super.paint(offscreenGraphics);
if(getBit()) {
offscreenGraphics.setColor(highColor);
offscreenGraphics.fillRect(0, 0, getSize().width, getSize().height);
} else {
offscreenGraphics.setColor(lowColor);
offscreenGraphics.fillRect(0, 0, getSize().width, getSize().height);
}
g.drawImage(offscreen, 0, 0, null);
offscreenGraphics.dispose();
} // paint
} // DataPanel
D.1.3 index.html
/>
Prevas &mdash; Screen Transfer
Bilag D - Kildekode 73

This browser does not have a Java Plug-in.
Get the latest Java Plug-in here.
D.1.4 template.css
* {
}
body {
}
margin: 0;
padding: 0;
font: 76%/1.3em "Trebuchet MS", Helvetica, Verdana, Arial, sans-serif;
#content {
color: #333333;
font-size: 1.1em;
}
#transmitter {
border-top: 1px dashed #CCDDEE;
border-left: 1px dashed #CCDDEE;
position: absolute;
bottom: 0;
right: 0;
}
D.2 Modtager
D.2.1 main.c
#include
#include "init.h"
#include "picutil.h"
// signal // defaults
#define MEAN_SIGNAL_OFFSET_VALUE 15 // 15
#define SIGNAL_TRIGGER_LEVEL_PCT 5 // 5
#define PERIOD_READ_DIVIDER 2 // 2
#define PROGRAMMER_MODE_TICKS 2
// user interface
#define NUMBER_OF_PERIODS 20
#define TIMEOUT 3000
#define NUMBER_OF_LEDS 7
#define LED_SPEED 2
// serial communication - 8N1
#define START_BIT 1
#define STOP_BIT !START_BIT
#define DATA_BITS 8
74 Bilag D - Kildekode

decode
#define ASCII_OFFSET 32
#define START_BYTE (128-ASCII_OFFSET)
#define STOP_BYTE (129-ASCII_OFFSET)
#define MODULO START_BYTE
// eeprom
#define DATA_BANK0 0x00
#define DATA_BANK1 0x80
#define DATA_BANK_EMPTY 0xFF
#define CHECK_BYTE_ADR 1
// statemachines
enum operation{ OP_RESET, OP_NORMAL, OP_SIGNAL, OP_INIT,
OP_READY, OP_DATA, OP_MODE, OP_FINISH };
unsigned char operation = OP_RESET;
enum mode{ MODE_NONE, MODE_RECEIVE };
unsigned char mode = MODE_NONE;
// normal
unsigned char pulse_count = 0;
// analog signal
signed int mean_signal = 0;
signed int mean_signal_old = 0;
unsigned char edge_detected = false;
// digital values
enum digital_value{ LOW, HIGH };
unsigned char digital_value;
// digital controls
unsigned char digital_value_ready = false;
unsigned int period_detected = 0;
unsigned int period_time = 0;
unsigned char virtual_clock = false;
unsigned int idle_time = 0;
// data banks
unsigned char bank_active;
unsigned char bank_temp;
// display & debugging
unsigned char led_refresh = false;
// function prototypes
void square_wave(void);
void bank_select(void);
void display(unsigned char value);
void main(void){
unsigned char text_length;
unsigned char data_buffer_next;
unsigned char data_buffer;
unsigned int checksum;
unsigned char data_byte;
unsigned char read_char;
unsigned char led_value;
unsigned char led_unit;
unsigned int period_prev;
init(); // device setup
for(;;){ // forever...
square_wave();
// square_wave2(mean_signal, mean_signal_old, &edge_detected, &digital_value);
// generate square wave
// program control
switch(operation){
case(OP_RESET): // system reset
bank_select(); // choose data storage
Bilag D - Kildekode 75

mode
+read_char);
// ** testing ** //
// period_detected = 40;
// operation = OP_INIT;
// length of text to display
text_length = eeprom_read(bank_active);
virtual_clock = false;
period_detected = 0;
period_prev = !period_detected;
data_buffer = 0;
data_buffer_next = 0;
data_byte = 0;
led_refresh = true;
led_value = 0;
led_unit = 0;
read_char = 0;
operation = OP_NORMAL;
break; // end of OP_RESET
case(OP_NORMAL): // programming mode NOT detected
if(mean_signal_old && edge_detected){ // search for signal
edge_detected = false;
}
if(++pulse_count == PROGRAMMER_MODE_TICKS){ // switch
}
idle_time = 0;
operation = OP_SIGNAL;
// simulate wavecard output
if(led_refresh){
led_refresh = false;
if(read_char >= text_length)
read_char = 0;
}
led_value = eeprom_read(bank_active + CHECK_BYTE_ADR + +
break; // end of OP_NORMAL
case(OP_SIGNAL): // measure signal's pulse period
if(mean_signal_old && edge_detected){ // first edge detected
edge_detected = false;
}
// find signal periods
if(digital_value == LOW){ // falling edge
if(period_time){ // digital high period available
period_detected = period_time;
period_time = 0;
}
} else if(digital_value == HIGH){ // rising edge
if(period_time){ // digital low period available
period_prev = period_time;
period_time = 0;
}
}
if(idle_time > TIMEOUT)
operation = OP_RESET;
// compare the low and high periods
if(period_detected == period_prev) // signal period detected
operation = OP_INIT;
// indicate measuring
led_value = led_refresh? 0b0000001 : 0b0000010;
break; // end of OP_SIGNAL
76 Bilag D - Kildekode

full
+;
case(OP_INIT): // signal detected
virtual_clock = period_detected/PERIOD_READ_DIVIDER;
operation = OP_READY;
idle_time = 0;
break; // end of OP_INIT
case(OP_READY): // ready to receive data
if(digital_value == START_BIT){
digital_value_ready = false;
period_time = virtual_clock; // synchronize period
idle_time = 0;
}
operation = OP_DATA;
if(idle_time > TIMEOUT)
operation = OP_RESET;
if(!mode)
led_value = period_detected; // display period
break; // end of OP_READY
case(OP_DATA): // serial data reception
if(digital_value_ready){ // read and store data bit
digital_value_ready = false;
if(data_buffer_next != DATA_BITS){ // data buffer NOT
idle_time = 0;
// ** testing ** //
eeprom_write(++data_byte, data_buffer);
synchronize period
reception
initialize checksum
number of data bytes received
}
// store bit value from LSB to MSB, ex. --101010
data_buffer |= digital_value (int)(period_detected*NUMBER_OF_PERIODS)){
idle_time = 0;
mode = MODE_NONE;
operation = OP_READY;
}
if(mode == MODE_RECEIVE)
led_value = led_refresh? 0b0000001 : 0b0000010;
else
led_value = period_detected; // display period
break; // end of OP_DATA
case(OP_MODE): // select program mode
switch(mode){
case(MODE_NONE): // no mode defined
if(data_buffer == START_BYTE){ // start data
}
checksum = START_BYTE;//
data_byte = 0; //
mode = MODE_RECEIVE;
Bilag D - Kildekode 77

eceived
checksum byte
with check byte in cell 1
data_buffer + ASCII_OFFSET);
eeprom_read(CHECK_BYTE_ADR + bank_temp)){
data_byte-1); // activate temporary bank
DATA_BANK_EMPTY); // inactivate other bank
TIMEOUT/NUMBER_OF_LEDS*LED_SPEED;
} // main
} // operation
operation = OP_READY;
break; // end of false mode
case(MODE_RECEIVE): // receiving data
if(data_buffer != STOP_BYTE){ // more text
// calculate weighted sum - ignore
checksum += data_byte * data_buffer;
// store data in temporary bank starting
eeprom_write(++data_byte + bank_temp,
// wait for next byte
operation = OP_READY;
} else { // stop byte detected
// calculate checksum from weighted sum
checksum %= MODULO;
}
} // mode control
// reset data buffer
data_buffer_next = 0;
data_buffer = 0;
break; // end of OP_MODE
// check to see if checksum is valid
if(checksum + ASCII_OFFSET ==
// store data length
eeprom_write(bank_temp,
eeprom_write(bank_active,
// change bank
bank_select();
idle_time = 0;
led_unit =
operation = OP_FINISH;
} else { // checksum not valid
idle_time = 0;
operation = OP_READY;
}
mode = MODE_NONE;
break; // end of MODE_RECEIVE
case(OP_FINISH): // data successfully received
if(idle_time >= TIMEOUT/2)
operation = OP_RESET;
led_value = (1 > 1;
break; // end of OP_FINISH
// LED control
display(led_value); // display status on wavecard
// signal debugging - scope on port RA7
RA7 = digital_value;
} // forever...
78 Bilag D - Kildekode

it-manipulated square wave generation
void square_wave(void){
value
trigger value
signed int signal_low_margin = 0;
signed int signal_high_margin = 0;
unsigned int trigger_low = 0;
unsigned int trigger_high = 0;
// define signal margins according to last measure
signal_high_margin = mean_signal_old + MEAN_SIGNAL_OFFSET_VALUE;
signal_low_margin = mean_signal_old - MEAN_SIGNAL_OFFSET_VALUE;
// define when signal triggers the edge
trigger_high = (signal_high_margin * SIGNAL_TRIGGER_LEVEL_PCT) / 100;
trigger_low = (signal_low_margin * SIGNAL_TRIGGER_LEVEL_PCT) / 100;
if(mean_signal >= (signal_high_margin+trigger_high)){ // signal above trigger
if(digital_value != LOW){ // signal has changed
edge_detected = true;
digital_value = LOW;
}
} else if(mean_signal

BIT_CLR clears in 'obj', the bits that are specified by 'mask'.
#define BIT_CLR(obj, mask) ((obj) &= ~(mask))
// BIT_TGL toggles in 'obj', the bits that are specified by 'mask'.
#define BIT_TGL(obj, mask) ((obj) ^= (mask))
// BIT_CPY copies into 'obj', the bits in 'val' that are specified by 'mask'.
#define BIT_CPY(obj, mask, val) ((obj) ^= (((obj) ^ (val)) & (mask)))
typedef char* String;
extern void delay(unsigned long delay_time);
#endif /*PICUTIL_H_*/
D.2.3 picutil.c
// Utilities for Microchip PIC
#include
// *** Pulling delay ***
void delay(unsigned long delay_time)
{
delay_time *= 150;
while (--delay_time) continue;
}
D.2.4 Init.h
// Peripheral initialization function
extern void init(void);
D.2.4 init.c
#include
/* Program device configuration word
* Oscillator = INTRC-RA6 is Port I/O
* Watchdog Timer = Off
* Power Up Timer = On
* MCLR Select Bit = RA5 is MCLR
* Brown Out Detect = Off
* Low Voltage Program = Disabled
* Data EE Read Protect = Disabled
* Flash Program Write = Write Protection Disabled
* Background Debug = Disabled
* CCP1 Mux = RB2
* Code Protect = Disabled
*/
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLREN & BORDIS & LVPDIS & UNPROTECT & WRTEN & DEBUGDIS &
CCPRB2 & UNPROTECT);
// Peripheral initialization function
void init(void){
/***** Common Code ****
* Timer 1 interrupt enabled.
* A2D interrupt enabled
*/
PIE1 = 0b01000001;
/*
* Portbit7:4 interrupt-on-change disabled
* Peripheral interrupts enabled
* Global interrupt disabled during initialization
*/
80 Bilag D - Kildekode

INTCON = 0b01000000;
/*
* Weak pullup on PORT disabled
*/
OPTION = 0b10000000;
/*
* Port directions: 1=input, 0=output
* A2D Converter input (AN0) on RA0
*/
TRISA = 0b00000001; // set AN0 as input to solar cells
PORTA = 0b00000000; // reset port A
/***** 16F819 Code ****
* Internal oscillator set to 8MHz
*/
OSCCON = 0b01110000;
/***** A2D Converter Code ****
* A2D module powered up
* Channel selected is AN3
* conversion clock derived from internal A2D RC Oscillator
*/ //port:___
ADCON0 = 0b11000001; // NB: ADC not startet
ADCON0 |= 0b00000100; // start ADC conversion
/*
* Analog/Digital ports using configuration 4
* Format is right justified
*/
ADCON1 = 0b10000100;
/***** EEPROM Code ****
* EEPROM interrupt enabled.
*/
PIE2 = 0b00010000;
/***** PortB Code ****
* Port directions: 1=input, 0=output
*/
TRISB = 0b00000001; // digital out on bit 0
// TRISB = 0b00000001; // LEDs on bits 7-1
PORTB = 0b11111111; // reset LEDs
}
D.2.5 isr.c
/***** Timer 1 Code ****
* Timer is active and running
* Timer derived from system clock
* External clock input is not synchronized
* T1 oscillator circuit (for external input) is inactive
* Timer prescaler is 1:1
*/
T1CON = 0b00000101;
// TMR1 Preset = 45541 - Freq = 999.50 Hz - Period = 0.001001 seconds
TMR1H = 248; // preset for timer1 MSB register
TMR1L = 47; // preset for timer1 LSB register
ei(); // Global interrupts enabled
// Interrupt service routines
#include
#include "picutil.h"
#define RAW_SIGNAL_BUFFER_LENGTH 3 // 3
#define SIGNAL_MEASURE_MS 10 // 10
#define PROGRAMMER_TIMEOUT_MS 100
#define LED_REFRESH_MS 250
Bilag D - Kildekode 81

normal operation
extern unsigned char pulse_count;
// ADC manipulation
extern signed int mean_signal;
extern signed int mean_signal_old;
// square wave detection
extern unsigned int period_time;
extern unsigned int period_detected;
extern unsigned char virtual_clock;
// digital values
extern unsigned char digital_value_ready;
extern unsigned int idle_time;
// debugging
extern unsigned char led_refresh;
void interrupt my_isr(void){
// ADC
static unsigned int raw_signal;
static unsigned int raw_signal_buffer[RAW_SIGNAL_BUFFER_LENGTH];
static unsigned char raw_signal_buffer_next = 0;
// Timer 1
static unsigned char pulse_count_time = 0;
static unsigned int led_delay = 0;
static unsigned int signal_measure_time = 0;
static unsigned char signal_measure_ready = false;
unsigned int i,sum;
if((ADIE)&&(ADIF)){ // ADC interrupted
// read A/D-signal from screen
raw_signal = (ADRESH

} // my_isr
// detect programming mode
if(++pulse_count_time == PROGRAMMER_TIMEOUT_MS){
pulse_count_time = 0;
pulse_count = 0;
}
period_time++;
if(virtual_clock){ // period time detected
if(period_time == period_detected) // define signal's period time
period_time = 0;
}
} // Timer1
idle_time++;
if(period_time == virtual_clock) // read bit value
digital_value_ready = true;
// TMR1 Preset = 45541 - Freq = 999.50 Hz - Period = 0.001001 seconds
TMR1H = 248; // preset for timer1 MSB register
TMR1L = 47; // preset for timer1 LSB register
// restart timer
TMR1IF = 0; // clear event flag
TMR1IE = 1; // enable interrupt
if((EEIE)&&(EEIF)){ // EEPROM interrupted
WREN = 0; // disable EEPROM write
EEIF = 0; // clear event flag
} // EEPROM
D.3 Sender
D.3.1 Transmitter.java
package transmit;
// Core packages
import java.awt.*;
import java.awt.event.*;
if(WRERR){ // errors occured
WRERR = 0; // clear the flag
// TODO...
}
// Extension packages
import javax.swing.*;
import javax.swing.event.ChangeEvent;
import javax.swing.event.ChangeListener;
/**
* 'Transmitter' is a web application for transferring
* data from the screen to an electronic device. It has
* debugging facilities to control the duty cycle and
* period of the digital signals.
*
* @author Hasse Bylov - hasse@bylov.com
* @see http://www.micromedia.dk/wavecard/index.php
* @see http://www.micromedia.dk/wavecard/index.php?debug
*
*/
public class Transmitter extends JApplet {
Bilag D - Kildekode 83

private static final long serialVersionUID = 5811536125471100063L;
private static final int PERIOD_MIN = 10;
private static final int PERIOD_MAX = 1000;
private static final int PERIOD_INIT = 50;
private static final int DUTY_MIN = 0;
private static final int DUTY_MAX = 100;
private static final int DUTY_INIT = 50;
private static final int HIGH_CONTRAST = 0;
private static final int LOW_CONTRAST = 255;
private static final int COLOR_DEPTH_MAX = 255;
private static final int COLOR_DEPTH_MIN = 0;
private static final int COLOR_DEPTH_STEP = 1;
private static final int NUMBER_OF_ROWS = 4;
private static final int NUMBER_OF_COLUMNS = 4;
private static final int TEXT_FIELD_LENGTH = 15;
private static final int SYSTEM_LAYOUT = 2;
// System
private UIManager.LookAndFeelInfo looks[];
// Panels
private JPanel periodPanel;
private JPanel dutycyclePanel;
private JPanel contrastPanel;
private JPanel statusPanel;
private JPanel debugPanel;
private JPanel userPanel;
private JPanel controlPanel;
private DataPanel outputPanel;
// Debugging
private JLabel periodLabel;
private JSlider periodSlider;
private JLabel periodValueLabel;
private JLabel periodUnitLabel;
private JLabel dutycycleLabel;
private JSlider dutycycleSlider;
private JLabel dutycycleValueLabel;
private JLabel dutycycleUnitLabel;
private JLabel lowContrastLabel;
private SpinnerNumberModel lowContrast;
private JSpinner lowContrastSpinner;
private JLabel highContrastLabel;
private JSpinner highContrastSpinner;
private SpinnerNumberModel highContrast;
private JToggleButton operateButton;
// User components
private JTextField dataField;
private JButton detectButton;
private JButton transmitButton;
/**
* init() is the applet's main method where things are setup once
*/
public void init() {
try { // Set up the user interface
javax.swing.SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
createGUI();
}
});
} catch (Exception e) { // an unknown error occurred
System.err.println("createGUI() didn't successfully complete");
}
} // init
/**
* changeLookAndFeel() makes the user interface look
* like the user's operating system
* @param int look number
*/
private void changeLookAndFeel(int value) {
84 Bilag D - Kildekode

try {
UIManager.setLookAndFeel(looks[value].getClassName());
SwingUtilities.updateComponentTreeUI(this);
} catch (Exception e) {
e.printStackTrace();
}
} // changeLookAndFeel
/**
* getFrequency() calculates the frequency
* from the data panel's period and hacks
* it to return a decimal value
* @return double frequency in Hz
*/
private double getFrequency() {
double frequency = 1000.0 / (double)(outputPanel.getPeriod());
return Math.round(frequency * 100.0) / 100.0;
} // getFrequency
/**
* createGUI() sets up the panels, sliders and buttons
*/
private void createGUI() {
// Debug panel
periodLabel = new JLabel("Period:");
periodLabel.setLabelFor(periodSlider);
periodSlider = new JSlider(SwingConstants.HORIZONTAL, PERIOD_MIN, PERIOD_MAX,
PERIOD_INIT);
periodSlider.setMajorTickSpacing(PERIOD_MAX-PERIOD_MIN);
periodSlider.setPaintTicks(true);
periodSlider.setPaintLabels(true);
periodValueLabel = new JLabel("");
periodUnitLabel = new JLabel("ms");
DUTY_INIT);
dutycycleLabel = new JLabel("Duty cycle:");
dutycycleLabel.setLabelFor(dutycycleSlider);
dutycycleSlider = new JSlider(SwingConstants.HORIZONTAL, DUTY_MIN, DUTY_MAX,
dutycycleSlider.setMajorTickSpacing(25);
dutycycleSlider.setPaintTicks(true);
dutycycleSlider.setPaintLabels(true);
dutycycleValueLabel = new JLabel("");
dutycycleUnitLabel = new JLabel("%");
lowContrastLabel = new JLabel("Low:");
lowContrastLabel.setLabelFor(lowContrastSpinner);
lowContrast = new SpinnerNumberModel(LOW_CONTRAST, COLOR_DEPTH_MIN,
COLOR_DEPTH_MAX, COLOR_DEPTH_STEP);
lowContrastSpinner = new JSpinner(lowContrast);
highContrastLabel = new JLabel("High:");
highContrastLabel.setLabelFor(lowContrastSpinner);
highContrast = new SpinnerNumberModel(HIGH_CONTRAST, COLOR_DEPTH_MIN,
COLOR_DEPTH_MAX, COLOR_DEPTH_STEP);
highContrastSpinner = new JSpinner(highContrast);
operateButton = new JToggleButton(" Turn On ");
operateButton.setMnemonic(KeyEvent.VK_T);
periodPanel = new JPanel();
periodPanel.setLayout(new FlowLayout());
periodPanel.add(periodLabel);
periodPanel.add(periodSlider);
periodPanel.add(periodUnitLabel);
dutycyclePanel = new JPanel();
dutycyclePanel.setLayout(new FlowLayout());
dutycyclePanel.add(dutycycleLabel);
dutycyclePanel.add(dutycycleSlider);
dutycyclePanel.add(dutycycleUnitLabel);
contrastPanel = new JPanel();
contrastPanel.setLayout(new FlowLayout());
contrastPanel.add(lowContrastLabel);
contrastPanel.add(lowContrastSpinner);
contrastPanel.add(highContrastLabel);
contrastPanel.add(highContrastSpinner);
contrastPanel.add(operateButton);
Bilag D - Kildekode 85

statusPanel = new JPanel();
statusPanel.setLayout(new FlowLayout());
statusPanel.add(periodValueLabel);
statusPanel.add(dutycycleValueLabel);
debugPanel = new JPanel();
debugPanel.setLayout(new GridLayout(NUMBER_OF_ROWS, NUMBER_OF_COLUMNS, 0, 0));
debugPanel.setBackground(Color.LIGHT_GRAY);
periodSlider.addChangeListener ( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setPeriod(periodSlider.getValue());
periodValueLabel.setText("Frequency:" + getFrequency() + "Hz ("
+ outputPanel.getPeriod() + "ms)" );
dutycycleSlider.setValueIsAdjusting(true);
dutycycleSlider.setValueIsAdjusting(false);
}
} );
dutycycleSlider.addChangeListener ( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setDutycycle(dutycycleSlider.getValue());
dutycycleValueLabel.setText("ON-time:" +
outputPanel.getDutyHigh() + "ms OFF-time:" + outputPanel.getDutyLow() + "ms");
}
} );
lowContrast.addChangeListener( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setLowContrast( ((Integer)lowContrast.getValue()).intValue() );
}
} );
highContrast.addChangeListener( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
outputPanel.setHighContrast( ((Integer)highContrast.getValue()).intValue() );
}
} );
operateButton.addChangeListener( new ChangeListener() {
public void stateChanged(ChangeEvent e) {
if(outputPanel.isReady()) { // data panel is not transferring
if(operateButton.isSelected()) {
operateButton.setText(" Turn Off");
outputPanel.setMode("debugmode");
} else if(outputPanel.getMode() == "debugmode") {
operateButton.setText(" Turn On ");
outputPanel.setMode("idlemode");
}
} else { // data panel is busy
operateButton.setSelected(false);
}
}
} );
debugPanel.add(periodPanel);
debugPanel.add(dutycyclePanel);
debugPanel.add(contrastPanel);
debugPanel.add(statusPanel);
// User panel
userPanel = new JPanel();
userPanel.setLayout(new FlowLayout());
userPanel.setBackground(Color.WHITE);
dataField = new JTextField("Greetings", TEXT_FIELD_LENGTH);
detectButton = new JButton("Detect");
detectButton.setMnemonic(KeyEvent.VK_D);
transmitButton = new JButton("Program");
transmitButton.setMnemonic(KeyEvent.VK_P);
dataField.addKeyListener( new KeyAdapter() {
public void keyPressed(KeyEvent e) {
if (e.getKeyCode() == KeyEvent.VK_ESCAPE) {
86 Bilag D - Kildekode

} );
}
detectButton.doClick();
}
if (e.getKeyCode() == KeyEvent.VK_ENTER) {
transmitButton.doClick();
}
detectButton.addActionListener( new ActionListener() {
public void actionPerformed(ActionEvent e) {
if(outputPanel.isReady()) {
if(outputPanel.getMode() != "detectmode") {
operateButton.setSelected(false);
outputPanel.setMode("detectmode");
} else {
outputPanel.setMode("idlemode");
}
}
}
} );
transmitButton.addActionListener( new ActionListener() {
public void actionPerformed(ActionEvent e) {
if(outputPanel.isReady()) {
operateButton.setSelected(false);
outputPanel.setText(dataField.getText());
outputPanel.setMode("programmode");
}
}
} );
userPanel.add(dataField);
userPanel.add(detectButton);
userPanel.add(transmitButton);
// Output panel
outputPanel = new DataPanel(periodSlider.getValue(), dutycycleSlider.getValue(),
((Integer)highContrast.getValue()).intValue(), ((Integer)lowContrast.getValue()).intValue());
outputPanel.setBackground(Color.ORANGE);
// Control panel
controlPanel = new JPanel();
controlPanel.setLayout(new BorderLayout());
controlPanel.setBackground(Color.WHITE);
if(getParameter("debug") != null) // should be "!= null"
controlPanel.add(debugPanel, BorderLayout.NORTH);
controlPanel.add(userPanel, BorderLayout.CENTER);
// Setup panels
Container container = getContentPane();
container.add(controlPanel, BorderLayout.NORTH);
container.add(outputPanel, BorderLayout.CENTER);
// Show default values
periodSlider.setValueIsAdjusting(true);
periodSlider.setValueIsAdjusting(false);
dutycycleSlider.setValueIsAdjusting(true);
dutycycleSlider.setValueIsAdjusting(false);
looks = UIManager.getInstalledLookAndFeels();
changeLookAndFeel(SYSTEM_LAYOUT);
} // createGUI
} // Transmitter
Bilag D - Kildekode 87

8.2.1 D.3.2 DataPanel.java (version 2)
package transmit;
// Core packages
import java.awt.*;
// Extension packages
import javax.swing.JPanel;
/**
* 'DataPanel' is a JPanel used for transferring binary data
* from a normal computer screen on to an electronic device.
* The panel is used with the 'Transmitter' web application.
*
* @author Hasse Bylov - hasse@bylov.com
* @see http://www.micromedia.dk/wavecard/index.php
* @see http://www.micromedia.dk/wavecard/index.php?debug
*
*/
public class DataPanel extends JPanel implements Runnable {
private static final long serialVersionUID = -2997949170529730708L;
// off-screen buffer
private Image offscreen;
// visual control
private boolean bit;
private int period;
private int dutycycle;
private int highContrast;
private int lowContrast;
// mode select
private String mode;
private boolean ready;
// data to transfer
private String text;
// serial
private static final boolean START_BIT = true;
private static final boolean STOP_BIT = !START_BIT;
// encoding options
private static final char BYTE_LENGTH = 8;
private static final char DATA_BYTE = 10;
private static final char ASCII_OFFSET = 32;
private static final char START_BYTE = (128 - ASCII_OFFSET);
private static final char STOP_BYTE = (129 - ASCII_OFFSET);
private static final char MODULO = START_BYTE;
// panel constructor
public DataPanel(int period, int dutycycle, int contrastHigh, int contrastLow) {
super();
}
this.period = period;
this.dutycycle = dutycycle;
this.highContrast = contrastHigh;
this.lowContrast = contrastLow;
this.ready = true;
new Thread(this).start();
/*
* trivial getter/setter methods
*/
private boolean getBit() {
return bit;
}
public void setBit(boolean value) {
this.bit = value;
88 Bilag D - Kildekode

}
repaint();
public int getPeriod() {
return period;
}
public void setPeriod(int period) {
this.period = period;
}
private int getDutycycle() {
return dutycycle;
}
public void setDutycycle(int dutycycle) {
this.dutycycle = dutycycle;
}
public int getDutyHigh() { // ON-Time = D*T
return (getDutycycle() * getPeriod()) / 100;
}
public int getDutyLow() { // OFF-Time = (1-D)*T
return ((100-getDutycycle()) * getPeriod()) / 100;
}
public int getHighContrast() {
return highContrast;
}
public void setHighContrast(int high) {
this.highContrast = high;
}
public int getLowContrast() {
return lowContrast;
}
public void setLowContrast(int low) {
this.lowContrast = low;
}
public String getMode() {
return mode;
}
public void setMode(String mode) {
this.mode = mode;
}
public String getText() {
return text;
}
public void setText(String text) {
this.text = text;
}
public boolean isReady() {
return ready;
}
private void setReady(boolean ready) {
this.ready = ready;
}
/**
* dynamicDelay() holds the square wave signal
* for a given time
* @param int time
*/
private void dynamicDelay(int time) {
long bitPeriod = System.currentTimeMillis();
while((System.currentTimeMillis()-bitPeriod) < time) {
try {
Thread.sleep(1);
Bilag D - Kildekode 89

} catch (InterruptedException e) {
e.printStackTrace();
}
}
} // dynamicDelay
/**
* screenBinary() blinks the data panel according
* to the debug controls. Besides the trivial methods
* this is enough to control the test-application
*/
private void screenBinary() {
if(getDutyHigh() > 0) {
setBit(true);
dynamicDelay(getDutyHigh());
}
if(getDutyLow() > 0) {
setBit(false);
dynamicDelay(getDutyLow());
}
} // screenBinary
/**
* detectMode() blinks the data panel with a period
* defined by this.period
*/
private void detectMode() {
// keep high for this.period
setBit(true);
dynamicDelay(getPeriod());
// keep low for this.period
setBit(false);
dynamicDelay(getPeriod());
} // detectMode
/**
* calculateChecksum() finds the checksum of a string
* @param String text
* @return char checksum
*/
private char calculateChecksum(String text) {
int sum = START_BYTE;
for(int i=1; i = 0 ; i--) {
if(binary.charAt(i) == '0')
setBit(false);
else
setBit(true);
90 Bilag D - Kildekode

}
dynamicDelay(getPeriod());
// send stop bit
setBit(STOP_BIT);
dynamicDelay(getPeriod());
} // transmit
/**
* programMode() handles each step in the encoding process
*/
private void programMode() {
char checksum = calculateChecksum(getText()); // calculate
the checksum
transmit(START_BYTE);
// send start byte
transmit(checksum);
// send checksum byte
for(int i=0; i < getText().length(); i++) // loop
through characters in string
transmit((char)((getText().charAt(i)) - ASCII_OFFSET)); // - and send each
character
transmit(STOP_BYTE);
// send stop byte
} // programMode
image
/**
* run() is the default Thread loop, from where
* the program mode is controlled
*/
public void run() {
while(true) { // forever...
if(getMode() == "debugmode") { // test-application
screenBinary();
} else if(getMode() == "detectmode") { // blink for card detection
detectMode();
} else if(getMode() == "programmode") { // blink with data to program card
setReady(false); // lock program
// clear data panel
for(int i=0; i < DATA_BYTE; i++){
setBit(false);
dynamicDelay(getPeriod());
}
programMode(); // send programming signals
setReady(true); // release program lock
setMode("idlemode"); // return to idle mode
} else { // to avoid CPU overload, system needs idle time
dynamicDelay(50);
}
}
} // run
/**
* invalidate() removes the off-screen buffer
*/
public void invalidate() {
super.invalidate();
offscreen = null;
} // invalidate
/**
* update() overrides the default update()
* to NOT erase the background before painting
* @param Graphics g
*/
public void update(Graphics g) {
paint(g);
} // update
/**
* paint() puts everything in place in an off-screen buffer and then shows entire
* on screen at once.
* @param Graphics g
*/
public void paint(Graphics g) {
Bilag D - Kildekode 91

Color highColor = new Color(getHighContrast(), getHighContrast(),
getHighContrast());
Color lowColor = new Color(getLowContrast(), getLowContrast(),
getLowContrast());
if(offscreen == null) {
offscreen = createImage(getSize().width, getSize().height);
}
Graphics offscreenGraphics = offscreen.getGraphics();
offscreenGraphics.setClip(0, 0, getSize().width, getSize().height);
super.paint(offscreenGraphics);
if(getBit()) {
offscreenGraphics.setColor(highColor);
offscreenGraphics.fillRect(0, 0, getSize().width, getSize().height);
} else {
offscreenGraphics.setColor(lowColor);
offscreenGraphics.fillRect(0, 0, getSize().width, getSize().height);
}
g.drawImage(offscreen, 0, 0, null);
offscreenGraphics.dispose();
} // paint
} // DataPanel
D.3.3 index.php
/>
Prevas &mdash; Screen Transfer

endif; ?>
height="">