Mildere panikk slo ikke inn før rundt 15- tiden på Søndag, etter noen timers jobbing på helligdagen. Mesteparten av teksten i rapporten var ferdig, men det var mye annet som også måtte gjøres.

Blant annet:

• Korrekturlese
• Oppdatere enkelte kapittler
• Tegne noen figurer til oppdateringene
• Skrive konklusjon
• Skrive sammendrag
• Sette sammen vedlegg
• Binde inn rapportene
• Skrive ut i farger (duplex)

Sistnevnte viste seg å være spesielt vanskelig, siden skolen ikke har en fargeskriver som kan skrive ut på begge sider (ihvertfall ikke tilgjengelig for studentene). En av prosjektmedlemmene hadde en slik blekkskriver som kunne skrive ut i duplex, men med alle sidene ville det ta ganske lang tid å skrive ut alle fire eksemplarene (++). Og for å kunne skrive ut, måtte jo rapporten faktisk være ferdig.

Etter intens jobbing fram til rundt 05.00 mandag morgen, ble det fattet vedtak om at vi trengte litt søvn. Det eneste som gjensto da, gjøre de siste rettelsene, skrive ut, og binde inn.

Rapporten skulle leveres kl 12.00, og med tanke på at fargeskriveren brukte omtrendt en time på et eksemplar, ble det ganske tidskritisk de siste timene, spesielt med kø ved innbindingsmaskinen.

De fire eksemplarene som måtte leveres inn til 12.00 ble likevel levert i tide, med 7 minutters margin!

Etter at rapporten ble levert, hadde vi en ting til på planen den dagen, og det var å få opp partyteltet. Siden vi har plass ute, trengte vi et telt som kan huse utstyret og materialet vi skal stille ut. Siden Expo-messen begynner på onsdag, har vi bare idag og imorgen på å bli ferdig med forberedelsene, og der var første steg å få opp teltet. Noe er ferdig, og andre ting må fortsatt ordnes, så nå er det tilbake til forberedelsene, og muligens noe søvn

Hvis noen skulle være interessert, skal vi holde en presentasjon ved vår stand (teltet ved embla antennen) kl 11.00 på torsdag.

Velkommen til Expo 2008, ved Høgskolen i Østfold, avd. for ingeniørfag.

Videre har Expo-katalogen og programmet for dagen kommet ut i papirform. Hvis man vil ha tak i en, kan man kontakte høgskolen.

Fremover vil rapporten og utstillingen ta en del av vår tid, siden det nå er kort tid igjen før leveringsfristen. Expo skal planlegges, plakater skal lages og diverse annet kontorarbeid må ferdigstilles ganske kjapt. Vi håper også på å få tid nok til avsluttende testing.

Vi hadde allerede “manuelle” tilpasningskretser på pre-prototypen, men bestemte oss for å bruke en litt mer stabil løsning, nemlig Freescales MCZ33290. Denne er bygget for å omgjøre 0- 12 V signelene på K-line til vanlige 0 - 5 V signaler (UART).

Oppdatering 14 mai:

Kretsen er testet (med funksjonsgenerator og oscilloskop), og fungerer etter spesifikasjonen. L-line må kontrolleres manuelt, men det er lagt inn en transistor for å imøtekomme det kravet. Programmering mot dette grensesnittet begynner imorgen.

Takk til Freescale for vareprøven av komponenten.

Denne modulen kan kontrolleres på litt forskjellige måter, men vi har valgt å bruke SPI (Serial Peripheral Interface). Når vi utviklet og designet “utviklingsbrettet” (se tidligere post) satte vi av plass til denne modulen, og SPI linken der fungerte uten videre problemer slik at jeg kjapt fikk opp en kommunikasjon der.

Etterhvert som jeg fortsatte programutviklingen fant jeg det nødvendig å kople opp den andre modulen også, da jeg ikke fant noen god løsning for å teste opp mot en PC. I kjent stil fant jeg fram lyskassa og etsebadet og lagde et enkelt breakout kort til den andre modulen (den har 2mm spacing mellom bena, så den passer ikke på et vanlig koplingsbrett). Siden ethernetmodulen kjører på 3,3V og mikrokontrolleren kjører på 5 V fikk jeg en del problemer med returen på SPI linken. Dette ble ikke noe problem på utviklingskortet da det har en del kortere baner enn ledningene mellom kontrollerkortet og modulen i det nye oppsettet.

Kontrollerkortet er et lite kort produsert av et firma ved navn Olimex, som prosjektet forøvrig har arvet fra Ole Martins tidligere prosjekt “WCI”. Det var jo bygd opp rundt en ATmega16 og 5 V drift, så for å fikse SPI problemet mitt bygde jeg det om til 3,3 V med en ny MAX (UART -> RS232) og en ATmega16L som begge kan kjøre på 3,3 V. Så etter å ha kranglet litt med en defekt mikrokontroller, og erstattet den, fungerer alt som det skal. Så nå har jeg et ypperlig testoppsett, og er klar for å programmere en transparent link.

Samtidig har vi en enkel måte å sende forskjellige pakker til bilen, slik at vi kan undersøke hvordan ECUen vil svare på disse “forespørslene”. Vi mangler en bil som bruker CAN-bus som kommunikasjonsmetode på OBD-kontakten, men håper at vi kan få tak i en snart.

Selv om kretsen fra Elm Electronics var (og er) til god hjelp når vi skal undersøke kommunikasjon med diagnosekontakten i bil, har vi avskrevet den som en del av løsningen. I steden skal en CAN-mikrokontroller fra Atmel ta dens plass.

Ved hjelp av eksempelprogramvare fra Atmel, går det også her sakte men sikkert fremover.

Over til noe mer administrativt, ble det andre møtet mellom oss, oppdragsgiver og høgskolens veiledere gjennomført på fredag før helgen. Det ble noen detaljer i den tekniske løsningen som vi må se nærmere på senere.

I tillegg begynner fristen for innlevering av prosjektpresentasjon til expo katalogen å nærme seg. Vi har allerede begynt å tenke på denne, samt selve utstillingen.

Tidligere i uka har vi også vært på besøk hos oppdragsgiver, men da med mindre oppløftende resultater. Vi har hatt en del problemer med kortet til platformen. Mye kontaktfeil som har blitt rettet opp, og et par slurvefeil under kretsdesignet.

Vi har riktignok kun fått testet at det fungerer mot én bil (testcelle) med K-Line. CAN delen av utviklingsplatformen er foreløpig ikke uttestet i praksis på grunn av tekniske problemer med respektive testcelle, men ser ut til å fungere bra ut i fra de testene vi har gjort her på labben.

Så nå ser vi fram i mot å begynne å utvikle programvare og nettverksinterface til platformen, og vi håper at ikke utviklingsplatformen byr på særlig flere problemer.

Mest sannsynlig kan vi ikke bruke ELM-kretsen direkte, men den er en god støttespiller for å bli kjent med bussene. Framover vil vi hovedsaklig benytte oss av kretsen til å finne hvilke hastigheter som faktisk kjører på diagnose protokollene. Vi har lett en del i forskjellig dokumentasjon, men åpenbart finner vi ikke et entydig svar på det, så å måle det i praksis vil iallefall gi oss en anelse om hvor vi befinner oss.

Legger også ut et bilde av platformen som også er forberedt på å knyttes opp mot to forskjellige Atmel kontrollere, et ethernet interface og RS232. Bilder fra uttestingen av bl.a. ELM-kretsen kommer fortløpende etter som vi tester.

Flere deler av prosjektet er sammenfallende for begge alternativene, slik at det ikke medfører ulemper i forhold til noen av løsningene.

Første prosjektmøte ble gjennomført mandag 7. April kl 08.30, med alle deltakere og veiledere tilstede. Det ble diskutert rundt forprosjektrapporten, løsningene og valg av mobilt nett.

Videre kan det også se ut som om evalueringskitet fra Atmel og kretsen fra Elm Electronics kan hjelpe oss å kartlegge viktige detaljer om OBD-grensesnittet, og ting vi trenger å vite om selve diagnostikkprosessen.

Vi håper også at det spesialiserte AUTO102 kitet dukker etterhvert, men vi har nok å jobbe med for nå.