A mostani részben azt fogom megosztani, hogyan is sikerült kapcsolatot létesítenem az autóval BT-on keresztül más programokkal. Mivel a Peugeot iOn-ról (és ikertestvéreiről) sok jót el lehet mondani, de azt nem, hogy okosak lennének - a szó mai értelmében - így kénytelen vagyok kicsalogatni belőle azokat az infókat, amik nekem fontosak. Első körben megnézem milyen kész megoldások vannak a neten.

BT - kész megoldások telefonra

Mivel az ESP32 nevű lapka fel van vértezve a BT kapcsolathoz szükséges HW-rel, így kézenfekvő ötlet volt ezt használni. A legelső lépés az, hogy sikerüljön kapcsolódni az adapterhez, minden más ez után jöhet.

Android telefonra sok hasznos és még több haszontalan alkalmazás van, ami képes BT-is CAN adapterrel beszélgetni, így ki is próbáltam párat ezek közül, ami kifejezetten ehhez a kocsihoz készült. A legelterjedtebb (és állítólag a leghasználhatóbb) ezek közül a caniOn nevű. Ennek a leírásában is szerepel, hogy mindenképp minőségi adaptert hasznjunk, pl azt ami nekem is van. Ami viszont aggasztóbb, hogy a fórumokon sokat olvastam róla, hogy mennyire nem stabil a BT kapcsolat bizonyos telefonokkal. Gondoltam a zsemeben lapuló tavalyi csúcsmodellel biztos nem lesz ilyen gond, pedig de! Nem a telefon modernségétől, vagy gyorsaságától függ, hogy jól fut-e rajta a program, hanem... fogalmam sincs mitől. A stabilitás jelen esetben annyit jelent, hogy amikor fut a program, akkor általában sikerül neki kapcsolódni az adapterhez és el is kezdni szipkázni az adatokat, de rendszerint pár másodperc - jobb esetben 1-2 perc - után a BT kapcsolat megszakat és kb fél percet várni kell, mire újra sikerül létrehozni a kapcsolatot. Ez eléggé elkeserített, gyanakodni kezdtem, hogy talán nem jó az adapter, vagy ilyesmi, de később kideürlt, hogy nincs annak baja.

BT - megoldás PC-re

Ezután kis pihenő következett, majd amikor a céges töltőt is beüzemelték, újabb lökést kapott a projekt, mert most már tényleg jó lenne tudni, ha kész a töltés, nem elég annyi hogy "reggelre tuti kész lesz", mint amikor otthon töltöttem. Hosszas keresgélés után ráakadtam egy can4eve nevű programra. Ezt egy lelkes - talán német - úriember készítette és publikálta. Láthatóan nagyon sok munkaóra van a projektben és mivel gyaníthatóan a fejlesztője Java programozó, ezért a teljes projekt Java-ban készült. Bizony, egy arra mérsékelten alkalmas programnyelvben! Ez kicsit megijesztett, de gondoltam egy próbát megér. Fél nap alatt sikerült is lebuildelnem a projektet, (JavaFX kell hozzá...) és még aznap ki is próbáltam menet közben a kocsin a produktomot. Meglepődtem, de teljesen flottul ment az egész! Ez bizakodással töltött el, hiszen akkor mégsem a BT adapterrel lesz a gond...

Bár a Java lenne az utolsó választásom ha programnyelvet kellene ehhez a feladathoz választanom, de az az előnye megvan a dolognak, hogy ebben van a legnagyobb jártasságom: sok éven keresztül dolgoztam aktív Java fejlesztőként. A teljes forráskód fent van a neten, sokat lehet belőle okosodni! Én is elég sok ötletet merítettem belőle, bár nyilván nem a UI-hoz közeli részek érdekeltek - főleg nem a JavaFX - hanem a kommunikáció és a különböző értékek számítása.

Modem? Komolyan?

Elkezdtem hát a kutatómunkát és elég hamar kiderült, hogy a BT CAN adapterem ugyanúgy működik, mint a leggagyibb kínai adapter - legalábbis a kommunikációs protokoll szempontjából. Ami viszont ledöbbentett, hogy az adaptert pont úgy kell megszólítani, mint egy modemet kellett a '90-es években! Ez nem vicc! Az ELM327 nevű chip egy kanadai cég terméke. Szerintem nagyon nem új cucc már, de a protokoll sokat nem változott, legfeljebb újabb és újabb parancsokkal bővült az idők során. Továbbra is AT-parancsokkal kell üzengetni az adapternek, amire az "OK"-kat küld vissza, vagy rosszabb esetben "?" karaktert.

Találtam egy típusspecifikus fórumot is, ahol sok tolajdonos osztja meg a tapasztalatait egymással a kis elektromos miniautóval kapcsolatban és szerencsére van köztük olyan tulaj is, aki elkezdte hekkelni is a járművét. 

Perifériák a kocsiban

Egy mai modern autó úgy épül fel, hogy sok különböző kis számítógép dolgozik benne egymás mellett és ezek mind ugyanarra a CAN buszra küldenek adatokat és onnan is olvassák ki a többi periféria adatait. Alapvetően ez egy olyan busz, ahol sok egyenrangú egység van felfűzve egymás mellé és nincs kifejezetten főnök közöttük. A legtöbb részegység folyamatosan küldi a buszra azokat az adatokat, amiket maga gyűjt össze és ebből a mérhetetlen sok adatból minden periféria kiszűri a neki fontosakat. Okosan ki van ez a dolog találva, bár manapság már látszanak a gyenge pontjai a rendszernek.

A probléma ezzel az összeállítással csak annyi, hogy a buszon közlekedő adatoknak csak nagyon kis része van szabványokban lefektetve - és jellemzően csak azok, amik a hagyományos járművek emissziós értékeihez kapcsolódnak. A protokoll egységesítése pont azért jött létre, hogy a 2000-es évek elejétől kezdve minden autót lehessen egységesen vizsgáztatni, vagyis egy műszaki vizsga alkalmával egy szabványokban lefektett műszerrel ki lehessen olvasni, ha túl sok károsanyagot ereget a jármű menet közben.

Minden más, ami nem a kibocsátáshoz kapcsolódik, az nem szabványos, hanem gyártónként eltér, jellemzően minden gyártó kidolgozza hogy a saját járművében melyik periféria milyen címen milyen adatokat közöljön a többi perifériával. Ez oda vezet, hogy hacsak valaki nem fér hozzá ipari titkokhoz, akkor elég sziszifuszi munka kideríteni, hogy melyik csomgaban mi lehet. Ebben van annyi szerecsém, hogy a jármű már lassan 10 éve piacon van és sokan kezdték már ezt kigobozni.