ECU #5

Szórakoztam kicsit az alvázszámmal (VIN). Átírtam OP-COM-ban és kiolvastam MPPS-el. Egy érdekes dolgot fedeztem fel, bár a jelentősége nem túl nagy. Ha akár 1 karakter is megváltozik az alvázszámban, akkor az azt tartalmazó teljes blokkot áthelyezi egy másik helyre. Ha előtte a 0x4000-en (16384) volt, akkor 0x6000-re (24576), ha pedig fordítva, akkor fordítva. Ezért is lehet két különböző helyen a biztonsági kód, mivel az is ebben a blokkban van.
Másik érdekesség, hogy ugyanezen blokk mögé 122 bájtos szekvenciákat illeszt, ha hosszabban megy az autó. Jobb ötletem nincs, minthogy itt tárolhatja a módosító értékeket a befecskendezéshez, de a 122-ből csak nagyjából 10 bájt, ami úgy tűnik, hogy változik adott binárison belül. A többi érték azonos, de más binárisokban az is eltérő. Annyira nem lényeges most, túl sok időt nem szántam rá.

Írás
Túl voltam tehát az első írási műveleten. Igaz, hogy csak egy korábban lementett binárist írtam vissza, de mégis fontos lépés volt. Jöhettek a továbbiak. Továbbra is kis lépésekben haladtam. Fogtam a 1317a térképet (ez az első a második részben) és a 09391263 BA-ban lévő értékekkel írtam felül. Alig van eltérés az 12210453 EB-hez képest, mindössze 13 érték változott, és azok sem jelentősen. Felírtam, de nem működött. Az autó nem indult el és ezt a hibát dobta:

P0601 - Internal Control Module Memory Checksum Error

Ez az aggodalmam már a kezdetektől fogva megvolt. Létezik egy ellenrző összeg (checksum), ami a binárisban el van rejtve valahol és azt a célt szolgálja, hogy illetéktelenül vagy véletlenül ne lehessen módosítani a programot. A számításának módja és az értéknek a pontos helye motorvezérlő függő. Z22SE-hez ezzel kapcsolatban semmilyen további információ nem található.
Az MPPS figyelmeztet, hogy korrigálni kell a checksum-ot az írás előtt, és erre a programban van is egy gomb. Be kell adni az eredeti fájlt és az újat, de azt mondja nem találja. WinOLS szintén kínál checksum korrekciót, de azzal sem sikerült eredményt elérnem. Ha nem tudtam volna checksum-ot generálni, akkor az egész projekt meg lett volna lőve. Legalábbis lényegesen lelassult volna. Aztán eszembe jutott a KESS. Annyira nem volt régen, hogy használtam, de a kezdeti 3 kiolvasáson kívül minden mást az MPPS-el csináltam. A KESS leírásában rémlett, hogy szerepelt az automatikus checksum korrekció, de írni bármit lehet. Az eredeti fájl itt is szükséges volt, és nagy megkönnyebbülésemre valóban felírta rendesen. Nem dobott hibát és indult az autó is.
Nem voltam rest, rögtön visszaolvastam az egészet. Összehasonlítva a módosítás előttivel egyetlen különbség látható. A 0x8000 és 0x8001 (32768,32769) helyeken változott csak. Ez a kettő lesz a cheksum:

A KESS jókor mentett, mert, ha ezt nem tudta volna biztosan visszaküldöm. A checksum-ra majd még visszatérek kicsit később.

Klónozás
A korábbi grafikonok azt mutatták, hogy az eredeti ECU passzol a legjobban az autóhoz. Mindenképpen vissza akartam térni erre, mert ez adja a legjobb alapot. Fogtam hát a 09391263 BA-ról lementett teljes programot és felírtam a 12210453 EB ECU-jára. Itt legalább annyira izgultam, mint az első írásnál, mert ha külön azonosítójuk van, akkor lehetséges, hogy a hardver is különbözik valamennyire és ahhoz akár más program is kellhet. De nem volt gond. Ehhez még a KESS sem kellett. Felment rendben és működött is minden, ahogy kell. Megfordult a fejemben, hogy az egész immo-s szenvedést meg lehetett volna spórolni ezzel a 10 perces írással, de ebben azért nem vagyok teljesen biztos. Főleg amiatt, amit az alvázszámról is írtam. Mintha nem mindent ebben a progiban tárolna az ECU. A lényeg viszont az, hogy valószínűleg minden Z22SE progi használható a többi hardverben is.

Speedster
Már az elejétől azt a pillanatot vártam a legjobban, amikor eljutok odáig, hogy a Speedster-hez írt programot kipróbáljam. Az összehasonlító táblázat alapján jelentős változásokra lehetett számítani. Ez meg is lett, de nem úgy ahogy vártam.
A 09391263 BA és a 12202073 BZ bináris közt a második szekciótól hátrafelé 99%-ban a második részben vannak az eltérések, és csak alig néhány dolog a harmadik részben. Ennek ellenére nem akartam kockázatni csak a térképek átírásával, ami amúgy is macerásabb lett volna, hanem fogtam 0x8000-től (32768) a 12202073 BZ programot és betettem a 09391263 BA megfelelő helyére. Az írás ismét gond nélkül ment MPPS-el.
Írás után elmentem a szokásos tesztkörre, de reményeim hamar szertefoszlottak, az út felénél pedig alig vártam, hogy hazaérjek. Nemhogy javult volna, hanem érezhetően romlott. Olyan volt mintha a gázpedál sokkal érzéketlenebb lenne, és ennek megfelelően sokkal kevésbé reszponzív az autó is. Igazából erőtlen volt, alig akart menni és 3000 körül többször is teljesen befulladt. Nem erőltettem nagyon a dolgokat, de egyszer elforgattam, hogy legyen a felső tartományból is adat. Ott már érezhetően erőre kapott, de az is lehet, hogy csak az aljához képest tűnt jónak.
Elkészítettem a korábbi grafikonokat. Érdemes összenézni a többivel.
A fuel trim értékek zavarosabbak, mint a másik három együtvéve.

Kopogás tekintetében talán egy fokkal jobb, mint az STO, de ugyanúgy messze elmarad az eredetitől. Az is lehet, hogy csak azért nem rosszabb, mert annyira nem erőltettem a menetet.

Az EGR a legfurcsább az egészben. Míg a másik 3 nagyjából egyforma volt, ez sokkal másabb képet mutat. A korábbiak nem mentek 60%-os nyitás fölé, ez viszont többször belecsíp a 100%-ba is.

Az EGR változásának végülis örülök, talán könnyítheti a térkép megtalálását.

Mindent összevetve eléggé kételkedem, hogy ez valóban a gyári Speedster program lenne. Mechanikusan a motorok közt nincs lényeges különbség. Nem tudom elképzelni, hogy ez abban az autóban az elvárásoknak megfelelően működne.

ECU #4

Rendkívül meglepődtem, amikor a rendeléstől számítva alig több, mint két héttel és a várt szállítási idő előtt szintén két héttel már meg is érkezett az MPPS. Itt a mellékelt szoftverrel semmilyen probléma nem volt. Feltelepítettem, működött. Mivel az egész cucc csak egy darab kábel, sokkal kényelmesebb használni, mint a KESS-t. Első alkalommal arra voltam kíváncsi, hogy pontosan ugyanazt olvassa-e ki, mint a KESS. Persze azon felül, hogy képes-e egyáltalán olvasni. Tökéletesen működik. Nagyjából ugyanazt a negyed órás olvasási időt hozza, mint a KESS, és a kiolvasott bináris is egyezik a korábbival. Nehéz lett volna az ellenkezőjét elképzelni, de úgy voltam vele inkább leellenőrzöm, minthogy később ezen kezdjek el rágódni egy esetleges probléma kapcsán. Egy apró kellemetlenség kötődik csak az MPPS használatához. Olvasás után mindig bejegyez 4 hibakódot:

P0602 - Control Module Programming Error
P0606 - Powertrain Control Module Processor Fault
P1681 - TPS Monitoring Fault (Throttle Position Sensor)
P0607 - Electronic Throttle Control Motor Failure

Mindegyik "Not present" státuszú így könnyedén törölhető.

Immo
Mindkét újonnan beszerzett ECU-t az immo karikával és a kulcsba való chip-el együtt kaptam. Az immo vezérlőjét legjobb tudomásom szerint csak úgy lehet kicserélni, ha kivesszük a gyújtáskapcsoló zárbetétjét. Mivel ezelőtt erre még soha nem volt erre szükségem nem is csináltam korábban, de nem is nagyon akartam most elkezdeni. A célom az volt, hogy az eredeti ECU-t probléma esetén a legegyszerűben vissza lehessen tenni, ebbe pedig nem fér bele a kormányburkolattal, gyújtáskapcsolóval és immo-vel való pepecselés. A tesztkörökre az bizonyult a legegyszerűbbnek, hogy csak simán lehúzom a csatit a vezérlőről és az ECU-hoz tartozót hagyom lógni a vezeték végén. Hosszabb távon ez nem túl esztétikus és nem is igazán praktikus. Idővel a vezetétek is elfáradhatnak, kidörzsölődhetnek és a chip is elmozdulhat. Ez utóbbi történt az 12210453 EB tesztkörén, amit a korábbi posztban említettem. Természetesen van megoldás, de ilyet sem csináltam még azelőtt.

OP-COM-al elvégezhető az ECU és az immo párosítása. A művelet ebben a dokumentumban le van írva és nem is tűnik bonyolultnak, mégis sikerült egy kis kerülőutat beiktatnom a megoldás felé.
Az elmélet röviden a következő:
 - végy egy reset-elt ECU-t, vagy reset-eld a régi helyén (régi immo-val),
 - add meg a biztonsági kódot,
 - párosítsd össze az immo-t és az ECU-t.

A reset-et jelen esetben az OP-COM megfelelő funkciójával lehet végrehajtani. Ilyenkor elvileg elfelejti a hozzá tartozó immo beállításokat. Autótól függ, hogy immo párosítás nélkül az autó elindul-e vagy sem, esetleg csak korlátozott ideig (pl: 10 indítás). A helyzetet bonyolítja, hogy az ECU reset funkció elérhető az "Engine/Z22SE/Programming" és a "Body/Immobiliser II/Special Functions" menüben is. Bár az is elképzelhető, hogy a két funkció nem teljesen azonos, mert csak az utóbbinál említi, hogy az autó nem fog elindulni a reset után.

Arról nem tesz említést, ami ugyan nyilvánvaló, hogy ez csak az újabb párosításig érvényes, mégis így rendesen meggondolja az ember akar-e kattintani.

A biztonsági kód sem az eredeti ECU-hoz, sem a tartalékhoz nem állt rendelkezésemre, de erre a problémára már más megtalálta a megoldást előttem. A kód a binárisból bármilyen bűvészkedés nélkül kiolvasható a 0x40aa vagy a 0x60aa címen. Ekkor még ugyan nem volt számomra egyértelmű, de csak egy biztonsági kód van, és nincs az immo számára külön mégegy.

Hiába volt már az eredeti ECU egy dobozban teljes biztonságban, némileg tartottam a művelettől, mert ha az immo-t elállítom, akkor se így se úgy nem fog működni az autó. Egy próbával kezdtem. A tartalék ECU-t reset-eltem és visszapárosítottam a saját immo-jához. Az OP-COM válaszüzenetei néha eléggé szűkszavúak, így valójában nem tudom, hogy a művelet tényleg végrahajtódott-e vagy csak sikertelen lett és ezért működött minden ezután. A következő lépésben pedig hibát vétettem. Átdugtam az eredeti immo-t, és azzal próbáltam meg újra reset-elni, de ez nem sikerült. Azzal a ténnyel szembesültem, hogy az Immobiliser II menüben hiába írom be a jó biztonsági kódot, amikor elkezdené a reset-et, akkor rossz kód hibaüzenettel félbehagyja, mivel ebben a helyzetben két élő biztonsági kód létezik. Egy az immo-hoz és egy az ECU-hoz, így lehetetlen végrehajtani a műveletet. Abban a pillanatban nem tudatosult bennem, hogy valahol hibáztam, ezért keresni kezdtem a lehetséges megoldásokat. Átállítottam az alvázszámot (VIN), és a Mechanical Key Number-t is (aminek pontos célját most sem ismerem). Nem segített. Akkor valahogy teljesen logikusnak tűnt egy olyan gondolatmenet is, hogy mégsem az ECU-t párosítom az immo-hoz (Engine Controller installed), hanem fordítva (Immobilizer installed). A sok próbálkozás után eljutottam oda, hogy már egyik immoval sem indult az autó. Ezt végül sikerült valahogy visszacsinálni, de elegem lett a dologból és a további ténykedéseket elhalasztottam másnapra, hogy tiszta fejjel át tudjam addig gondolni az egészet.

Másnap minden világosnak és egyértelműnek tűnt. Újra kezdtem volna a reset-el, de azt írta, hogy a "Security Wait Time Active", várjak.

Először le sem esett mi ez az üzenet, így próbálgattam tovább, de ugyanaz. Utána eszembe jutott, hogy olvastam róla a fenti doksiban. Ha többször hibás kódot írunk be, akkor letilt az ECU először csak kis időre, majd folyamatosan hosszabbra. Azt még csak véletlenül sem írja ki, hogy mennyit is kellene várni, és az ilyen témájú neten talált bejegyzések arról szólnak, hogy csak úgy telik az idő, ha közben a gyújtás rajta van. Bármilyen zavaró tényezőre újra kezdi. A maximális idő több, mint 21 óra. Az egész helyzettel kapcsolatban azonban több dolog is furcsa volt. Az egyik, hogy tudtam, hogy nem írtam be rossz kódot sokszor, csak előző nap 1-2-szer, amikor az eredeti immohoz írtam a tartalék ECU kódját és fordítva, de azokat mindig követte a helyes kód is, aminek elvileg nulláznia kellene a számlálókat. A másik, hogy indult az autó. A harmadik pedig, hogy a "Measuring Blocks" menüben "Inactive"-ként szerepelt ez a paraméter.

Próbáltam várni gyújtáson, akkusarut levenni és várni, de nem segített. Tanácstalanságomban fogtam a korábban lementett binárist és visszaírtam, az MPPS-el. Ez volt az első írás művelet, így már duplán izgultam, de minden rendben volt vele. Az MPPS tehát nem csak olvasni, de írni is képes. Hurrá. Resetelni viszont ezután sem tudtam. Hosszas rágódás után nagy nehezen sikerült mégis megfejtenem, hogy az előző nap átírt alvázszám (VIN) okozta a problémát. Ez valamiért a teljes program újraírásával sem íródott felül. Vagyis inkább úgy tűnik máshol is tárolódik, mert az OP-COM (és az MPPS) nem a binárisban lévő alvázszámot jeleníti meg.
Reset után párosítás és minden működött. Régi immo az új ECU-val.

Térképek
Az elmúlt idők eseményi mellett folyamatosan nézegettem a binárisokat és próbáltam összegyűjteni a lehetséges térképeket. Olyannyira jól ment, hogy összesen 110-et találtam belőlük. Gondoltam, hogy sok lesz, de ennyire nem számítottam. Az persze egyáltalán nem biztos, hogy mind valóban térkép és az is lehet (valószínű), hogy az összeset nem is találtam meg. Főként a kis méretűeket nehéz azonosítani. A keresést főleg az ECU #2-ben leírtak szerint végeztem. Az igazsághoz hozzátartozik, hogy az ECU-k közti eltérések nem merülnek ki a megtalált térképek közti különbségben. Van ahol teljesen rendszertelenül is látni akár 1-2 bájtnyi eltéréseket. Sajnos eddig nem találtam semmilyen hivatkozást vagy kapcsolódási pontot, ami a korábban említett egydimenziós számsorokat (pl: fordulatszámértékek) a térképekkel összekötné. Van tehát egy rakat értelmezés nélküli számhalmazom. Megkerestem ezt a 110 térképet az eredeti ECU binárisában, a tartalékéban, a chiptuningos binárisban és a Speedster-nek tulajdonítottban, majd összefogtam egy doksiban az egészet kiemelve az eltéréseket. Most már "csak" meg kell fejteni melyik mit csinál.
A chiptuning-os ECU binárisban bejegyzett adatai között a következők is megtalálhatóak: "(c)2008 www.sto-chiptuning.com". Ezért is hivatkoztam STO-ként az előző posztban is a képeknél erre az ECU-ra. A cég még ma is létezik, de a honlapjuk szerint Z22SE-hez nem árulnak programot. Nem kizárt, hogy egyedileg autóhoz igazították, bár továbbra is az a megérzésem, hogy nem erről van szó. A kiolvasott binárist egy beállított védelem miatt a WinOLS először nem engedte megnyitni, de hexeditorban ez könnyen orvosolató a "NOREAD" érték törlésével. Nem is igazán értem miért alkalmaznak ilyen gyenge szintű védelmet.

ECU #3

Teltek múltak a hetek. Alig győztem kivárni, hogy megérkezzen a KESS. Végül a becsült kiszállítási idő végén túl majdnem egy héttel ért ide. A késésnél csak az lombozott le jobban, hogy a mellékelt CD-n lévő fájlok nagy többsége (főleg tömörített állományok és médiafájlok) hibás vagy sérült volt. Szoftver nélkül pedig az eszköz használhatatlan. Alapvetően csak egy KSuite-ra lett volna szükségem és a CD-n volt is legalább 10 különféle verzió, de egyiket sem tudtam használni. Elkezdtem a kínaival levelezgetni, de a reményeim kezdtek szertefoszlani. A megrendeléstől számítva már több, mint egy hónap eltelt és még mindig nem volt semmi a kezemben, amivel ki tudtam volna olvasni a saját ECU-mat. Arra gondoltam, ha a KESS mégsem jönne össze, akkor mielőbb kell egy alternatíva. Rendeltem gyorsan egy MPPS-t méghozzá a V13.02-t, mert elvileg az is támogatja a Z22SE-t és olcsóbb, mint az elérhető újabb változatok. Igazából a V13 aprópénz a KESS mellett is, így sokat nem kockáztattam. Csak már megint sok idő lesz mire megérkezik. Az átlátszó csatlakozóban lévő kis panel eléggé kevésnek tűnik a KESS óriási dobozával szemben, de ha erre a célra árulják legalább olvasni csak tudok majd vele.

Közben a kínaival sikerült annyit elérnem, hogy feltöltött egy adag szoftvert valahová, de abból éppen a KSuite hiányzott. A kommunikáció újabb 1 hétig tartott, és ezután nem is próbálkoztam vele többet, mivel nagy nehezen rátaláltam egy 2.28-as verziójú KSuite-ra a neten. Nem volt egyszerű, mert alig néhány elérhető darab van (minden verziót figyelembe véve), azok közül pedig valami vagy csak nem működik, vagy még vírusos is mellé. A jó KSuite-al már csak az volt a probléma, hogy nem volt benne az ezközhöz szükséges driver. Azt viszont sikerült az eredeti CD-ről levadászni. Végre működik. Az utólag küldött állományban egyébként valami token reset alkalmazás van, de hogy ezt mikor is kellene használni, az nem egyértelmű. Talán jó lesz még valamikor, de remélem inkább nem lesz rá szükség.

Élő adat
Ahhoz, hogy a jövőben bármilyen módosításnak a hatását meg tudjam figyelni szükséges lesz valamilyen visszacsatolás. Már jóval korábban szert tettem egy OP-COM-ra, de eddig nem sok mindenre használtam.

Az OP-COM bőséges (61) mennyiségű élő adat figyelését és logolását teszi lehetővé:

Time; Battery Voltage; Main Relay; Fuel Pump Relay; APP Sensor 1 (Accelerator Pedal Position); APP Sensor 2 (Accelerator Pedal Position); Calculated Pedal Position; APP at Idle Position (Accelerator Pedal Position); TP Sensor 1 (Throttle Position); TP Sensor 2 (Throttle Position); Calculated Throttle Position; Throttle Position; Engine Speed; MAP Sensor (Manifold Absolute Pressure); MAP Sensor (Manifold Absolute Pressure); Coolant Temperature; Coolant Temperature; Intake Air Temperature; Intake Air Temperature; A/C Information Switch (Air Conditioning); Brake Switch 1; Brake Switch 2; Clutch Switch; Vehicle Speed; Cruise Control Tip Switch; Cruise Control; Vehicle Speed in Cruise Control Range; EGR Valve (Exhaust-Gas Recirculation); EGR Position Command (Exhaust- Gas Recirculation); EGR Position Feedback (Exhaust Gas Recirculation); Fuel Tank Ventilation Valve; Knock Control; B1S1 O2 Sensor Heater (Bank 1 Sensor 1); B1S1 O2 Sensor (Bank 1 Sensor 1); B1S1 Air/Fuel Ratio (Bank 1 Sensor 1); B1S2 O2 Sensor Heater (Bank 1 Sensor 2); B1S2 O2 Sensor (Bank 1 Sensor 2); B1S2 Air/Fuel Ratio (Bank 1 Sensor 2); B1 Long Term Fuel Trim (Bank 1); B1 Short Term Fuel Trim (Bank 1); Requested Torque (Traction Control); A/C Relay (Air Conditioning); A/C Cutoff Mode (Air Conditioning); Malfunction Indicator (MI); Service Vehicle Soon (SVS) Indicator; Fan Relay 1; Fan Relay 2; Idle Speed Offset; Ignition Dwell Angle; Ignition Spark Angle; B1 Knock Sensor Signal (Bank 1); Knock Retard Cylinder 1; Knock Retard Cylinder 2; Knock Retard Cylinder 3; Knock Retard Cylinder 4; Ignition Status; ETC Limp Home Mode (Electronic Throttle Control); Total Misfire; Crank Angle Sensing Error Learn Attempts; Fuel Tank Ventilation Valve; Tank Sensor; Tank Sensor

Ahol a név kétszer szerepel, ott különböző értéket mér/jelez. Például a hőmérsékletszenzoroknál voltban és °C fokban. Az első adatgyűjtés érdekes információkkal szolgált. Kiderült, hogy a kopogásszenzor bizonyos üzemállapotokban néha bejelez, de jó volt végre látni a fuel trim-eket, és az EGR működését is.

Short Term Fuel Trim
Short Term Fuel Trim (STFT1 and STFT2) is the computer’s immediate response to adjust the air/fuel ratio. In positive corrections, fuel is added to adjust for a lean condition, while negative corrections respond to a rich condition. STFT corrections represent the current engine run cycle and react very quickly to O2 sensor input. If you were to create a large vacuum leak at Idle by disconnecting the PCV hose, the computer would immediately add positive fuel trim to balance the mixture. Short Term Fuel Trim is not stored in Keep Alive Memory (KAM) after shut down and automatically resets to 0 for the next start/run cycle.

Long Term Fuel Trim
Unlike STFT, Long Term Fuel Trim (LTFT1 and LTFT2) is learned over time while in closed loop operation. It is stored in the KAM and also used for open loop fuel calculations (like start up and wide open throttle). LTFT is a coarser adjustment and also works to keep STFT within specification.

Forrás

Az első olvasás
Már jóelőre beszereztem egy tartalék ECU-t. Semmi esetre sem szerettem volna valami véletlen hiba folytán egy használhatatlan autót, ami elmondások alapján néha odafigyelés mellett is előfordul. Az eredetivel (09391263 BA) megegyezőt nem találtam értelmes áron, így a tartalék egy 12210453 EB számú lett, ami egy G Astrából származik. Kicsit talán más, de elméletileg ugyanúgy kell vele működnie az autónak. Egy olvasásra legalábbis biztosan jó lesz.

Az olvasáshoz nem cseréltem meg a kettőt, csak áttettem a csatikat az újra, az akksira pedig töltőt tettem, mert elméletileg stabilizált 12V kell a művelethez. Ment minden, mint a karikacsapás. Nagyjából 15 perc alatt végzett. Nem túl gyors, de nem is vészesen lassú. Annyira simán ment minden, hogy miután visszapakoltam az eredetit kiolvastam abból is a tartalmát, annak ellenére, hogy megfogadtam, ahhoz semmi esetre sem nyúlok. Az olvasás itt is rendben volt. Legalábbis úgy tűnt. Miután végeztem beüzemeltem az OP-COM-ot, hogy reset utáni élő adatot lássak, de valamiért nem látszott benne semmi. Sem a hardverinformációs-, sem az élő adatok, az autó pedig nem indult. Indítózásnál csak tekert és tekert. Hibakód semmi. Kicsit levert a víz, mikor a helyzet nem javult többszöri próbálkozásra (gyújtás le-fel, ODB ki-be) sem. 5 perc múltán eljutottam oda, hogy le kell venni az akkusarut, amivel szépen visszaállt a rend. Hogy mi lehetett a probléma, nem tudom.

A kiolvasott programokat összevetettem a már meglévő megfelelőikkel, amiből az derült ki, hogy a második résztől (0x8000, 32768) fogva teljesen megegyeznek. Így bizonyítást nyert, hogy a már meglévő programok valódiak, és hogy az egyforma azonosítójú ECU-k a járműazonosítós részt leszámítva nagy hajlandóságot mutatnak az egyezésre.
Ha jól rémlik tavaly tavasszal volt, amikor kölcsönkaptam egy chiptuning-os ECU-t, ami előtte szintén G Astrához tartozott. A pontos eredete nem ismert, de gyanítottam, hogy csak valamilyen egyenszoftver. Akkor kíváncsiságból beraktam és használtam egy darabig (1-2 hét). Valamivel ugyan élénkebb lett tőle az autó, de nem igazán tetszett a járáskultúrája, ezért egy idő után visszadtam. Most ismét elkértem, hogy kiolvassam róla a programot és nézzek egy élő adatot is. 1 hét csúszással a másik kettőhöz képest ez is megtörtént. Ez az ECU már 09391283 BC számú.

A kiolvasás után logoltam reset (legalább fél óra áramtalanítást tekintek annak) utáni élő adatokat. Hogy pontos legyek először az eredetit néztem, majd egy másik napon először a 09391283 BC-t és utána a 12210453 EB-t. Utóbbi alkalommal a motor teljesen nem is hűlt ki. Az eredmények értelemszerűen nem közvetlenül összehasonlíthatók, hiszen bár próbáltam hasonló módon vezetni a körülmények mások voltak.

A 3 mérés részletei ebben a táblázatban találhatóak. A számok közt nehéz meglátni a fától az erdőt, ezért néhány érdekesebb dolgot grafikonon is megjelenítettem.

Fuel trim
Látszik, hogy indításnál mindegyikkel dús a keverék. A 09391283 BC-n vannak a legnagyobb kilengések (más a grafikonok skálázása is) és az eredetin a legkisebbek, de egyébként elég hasonlóak. Leginkább ±5% alatt kellene lennie az értékeknek, így egy kis korrekció valószínűleg jót tenne. A 12210453 EB-nél immo miatt nem indult egy ideig, azért vízszintes az eleje.

Kopogásszenzor
A kopogásszenor aktivitása az egyes hengereknél. Jól látható, hogy a 09391283 BC-n nagyon sokszor közbeavatkozik. Lehet, hogy ez érződött rajta. Az is elképzelhető, hogy mégsem egyenprogram, és adott konfigurációval vagy csak 100-as benzinnel is jobb lenne. Persze, az is előfordulhat, hogy csak húztak itt-ott az értékeken és ez sült ki belőle. Az eredeti egyértelműen sokkal jobb.

EGR
Látható, hogy bizonyos hőmérséklet eléréséig nem nyit az EGR, és hogy a nyitás mértéke szoros összefüggésben van a szívócső nyomással. A két cseredarab nagyon egyformán működik, az eredetinél viszont csak kissé magasabb üzemi hőmérsékleten kezd el működni, és eddig rejtély, hogy a mérés második felében miért is nem nyitott egyáltalán.

Gázreakció
Kíváncsi voltam vajon látszik-e a fordulatszám kitartás. Nem vagyok benne teljesen biztos, hogy az, de a grafikonon jól látható, hogy amikor elveszem a pedálról a lábam, azt a pillangószelep csak bizonyos késéssel követi. A logolás során a mintavételi frekvencia nem állandó, de nagyjából 2-4 tizedmásodpercenként történik, így teljesen pontosan ezzel a módszerrel amúgy sem lehetne kimutatni.

ECU #2

A bináris, ASCII-ban megjelenő olvasható részleteivel ellentétben a különböző számábrázolási formátumokban szereplő számokból a fontosakat elég nehéz kiszűrni a lényegtelenek közül. Most azonban éppen ez a feladat, hiszen az egyes térképek is számhalmazokból állnak, és éppen ezeket a számokat keresem.

WinOLS
Hexeditor-ból rengeteg féle van. Van, amelyik jobban használható és van amelyik kevésbé, azonban nem találtam olyat, ami a teljes hex fájlt át tudná fordítani az általam kívánt számformátumra. A témában való olvasgatás során elég hamar belebotlottam a WinOLS nevű progiba, ami kifejezetten motorvezérlő programok analizálására, szerkesztésére lett fejlesztve. Kész szerencse, hogy még ingyenes is. Ebben megtalálható a hexeditor-okból hiányolt funkció, a tetszőleges formátumra való átfordítás, és még nagyon sok más is. Többek közt képes önállóan különböző térképeket felismerni, ha szepel az adott motorvezérlőről infó az adatbázisában. De nem, nincs olyan szerencsém, hogy a Z22SE programban akár egyetlen térképet is találjon önállóan. A WinOLS használata egyébként csak korlátozottan intuitív és a kevés fellelhető leírás sem volt számomra túl könnyen emészthető. Szerencsére létezik egy véleményem szerint hiánypótló videósorozat, amely különböző példákon keresztül mutatja be a használathoz szükséges fogásokat. Ez az első rész, és közel 50 további videó található még ettől a felhasználótól.

Számábrázolás
A bináris, tizenhatos (hexadecimális) számrendszerben megjelenített értékeit attól függően, hogy milyen hosszúság szerint tagoljuk átválthatjuk különböző formátumú decimális értékekre. Jelenleg csak a 8,16 és 32 bit-es számoknak van jelentőségük. Ezek azonban lehetnek előjelesek vagy előjel nélküliek (signed, unsigned) és változtatható a bájtsorrendjük is (low/high, high/low).
A 8 bites számok 0-255 (előjel esetén -128-127), a 16 bites számok 0-65535 (előjel esetén -32768-32767), a 32 bites számok 0-4294967295 (előjel esetén -2147483648-2147483647) tartományban vehetnek fel értéket. Nem tudom itt melyek fordulhatnak elő, így valószínűleg mindet végig kell majd nézni.

Stratégia
Ahhoz, hogy a visszafejtés a lehetőségekhez képest minél inkább hatékony legyen, a következő startégiákat használom majd:
 - Publikus információk begyűjtése: Különböző, főleg benzines, nem feltöltött motorokhoz keresek majd térképeket, hogy lássam milyenek léteznek egyáltalán és milyen értékeket alkalmaznak ezekben. 
 - Mintakeresés: A legtöbb térkép egy olyan két dimenziós számhalmaz, amelyben egy adott értéktartományban jellegzetes ismétlődések figyelhetők meg. Ezeket viszonylag egyszerű felismerni.
 - Jellegzetes értékek keresése: Vannak olyan értékek (pl: fordulatszám, hőmérséklet, nyomás, terhelés), amelyek meg kell, hogy jelenjenek a programban. Ezekre célzottan keresek majd.
 - Több program összehasonlítása, különbségek keresése: Talán így kiszűrhetőek a különböző autókhoz, különböző szempontok megírt részletek.
Ha lehetővé válik majd a program olvasása és írása, akkor kiegészül a következőkkel:
 - Ismert beállítás változtatás és a programban való módosult érték megfigyelése: Kérdés, hogy tudok-e ilyet. OPCOM-al lehet ezt-azt állítani, de nem ismerem mélyebben a lehetőségeket.
 - Programmódosítás és hatáselemzés.

Analízis
Sok-sok nézegetés után elsőként az tűnt fel, hogy a program 3 jól elkülönített fő részből áll. A WinOLS az összesítő képen ezt grafikusan is meg tudja jeleníteni.

A zöld/rózsaszín/lila valamilyen adat, a szürke viszont csak FF-ekkel van feltöltve. Ez a fajta tagoltság a normál nézetben a gördítősávon is megfigyelhető. A második rész éppen egy szép kerek (2¹⁵) számú helyiértéknél 32768-nál (0x8000) kezdődik. Itt több tíz olyan mintát találtam, melyeket ezentúl lehetséges térképeknek tekintek. Ami nagyban erősíti a meggyőzdésemet, az az, hogy minden egyes minta előtt szerepel, hogy az hány oszlopból áll.

Ezen a képen két 13x17-es térkép látható. A sorok száma (17) nem jelenik meg. Bár van olyan térkép, ahol a sor és az oszlop számának megfelelő érték is szerepel közvetlenül a térkép előtt, de annyira kevés esetben, hogy inkább véletlennek tekintem mintsem utalásnak.
Ilyen a felső egy kicsit rendezve:

Ilyen 3D-ben:

Jellegzetes értékekből leginkább csak fordulatszám sorozatokat találtam. Vannak ugyan egyéb számsorok is, de nem egyediek annyira, hogy bárminek is biztosan tulajdonítani lehessen. Ezek a fordulatszám értékek:

Sajnálatos módon nem közvetlen a térképek előtt szerepel, így nem tudni pontosan mihez is tartozik, és a térképek előtt/mögött sincs semmilyen hivatkozás a tengelyekre vonatkozóan. A fentebbi képen is jól látható, hogy a két térkép, csak két 0-val van elválasztva egymástól. Minden bizonnyal egy harmadik helyen van meghivatkozva melyik térkép mit használ. Ebben az esetben viszont nem világos miért szerepeltetik többször is ugyanazokat a számsorozatokat. És az is elég nagy talány számomra, hogy az alsó fordulatszámérték (800) miért szerepel háromszor.

A második részt így a konfigurációs adatok helyének tekintem, a harmadik részt pedig magának a programtözsnek (core). Ez utóbbi a 09391263BA (Vectra B) és 12202073BZ (Speedster, VX220) esetében gyakorlatilag teljesen megegyezik, ami azért jó hír, mert a térképek amiknél jelentős eltérés van valószínűleg szabadon cserélhetők. Az első részt nem nagyon tudom hova tenni, ennek a végén található például az alvázszám és hardver,- szoftverazonosítók (16384-től, 2¹⁴, 0x4000)). Lehetséges, hogy az immo-hoz tartozó adatok is ide kerülnek.

(Így leírva talán nem is tűnik annyira bonyolultnak, de valójában hetek mentek el míg eljutottam eddig a pontig, és az már jól látszik, hogy messze még a vége.)

Kütyü
Ekkorra már úgy ítéltem meg nem lesz kidobott pénz, ha rendelek egy eszközt.
Az ismertebbek közül a választék nagyjából a következő termékekből áll: MPPS, KESS V2, KTAG, FgTech Galletto. Itt olvasható egy összehasonlítás róluk. A KTAG nem képes OBDn keresztül kommunikálni, így számomra esélytelen, az MPPS túl olcsó és a többihez képest túl egyszerűnek néz ki képeken, így elvetettem azt is. A Galletto és a KESS V2 közül pedig inkább az utóbbit ajánlják a különböző fórumokon. Már ha ajánlanak egyáltalán valamit, mert ezek csak kínai klónok. Működésük bizonyos esetekben erősen kérdéses. Sajnos az eredeti termékek több tízszer többe kerülnek, így az egyszeri hobbi autós vagy ilyet vesz vagy semmilyet. Legyen KESS.

Az Ebay-en Kínából rendelt dolgoknak talán legnagyobb hátránya, hogy sokszor akár 1 hónapba is beletelik mire megérkeznek. Nincs mit tenni várok, és tovább vizsgálom a meglévő progikat.