CAN-loggausta

[TPLtre]

Tuikun ketju tuli jo sotkettua tällä, joten eriytän aisan omaksi ketjukseen. Hankin CAN-loggerin josta saan tietyt mittausarvot näkyviin käyrinä skaalattuina samaan näyttöön. Vakiot saa sieltä ilman isompaa vaivaa, mutta ongelmana on, että Mersu ei kovin moneen vakiopyyntöön vastaile ja niihin joihin vastailee, niissä on joissain riittämätön skaala. Esim. ahtopaineelle käytetään yhtä tavua, eli skaala rajoittuu 0-255. Eli 0-2550 mbar abs. Samoin lambdan rajat ovat 1-2.

No sieltä saa kyllä logattua valmistajakohtaisetkin mittausparametrit, mutta niiden saaminen näkyviin plottauksena vaatii sitten oman CAN-tietokannan tekemisen. Olen tehnyt "ryöstökaapelin" väliin ja seurannut mitä * sieltä kyselee. Kaikki siinä mielessä selvää ja löydän kyllä multiframe-vastauksistakin haluamiani tietoja, mutta tuon tietokannan tekeminen tuottaa vaikeuksia.

Vastauksen visualisointia:



Kysely 0x7E0 on ECUlle ja vastaus 0x7E8. Siis kyse on väyläosoitteista. 0X7E1 olisi kysely TCU:lle ja vastaus 0x7E9. Sitten on service#, * käyttää 0x21:tä. Sitten parametri, tässä tapauksessa 0x08. Ja sitten tulee vastauksena litania dataa. Nyt tämä multiframe data pitäisi saada CAN-tietokannassa, DBC, koodattua plotterille näkyvään muotoon. Vastauksen ensimmäine tavu 0x10, kertoo että kyseessä on multiframe. Seuraava tavu kertoo sen pituuden. Sitten tulee varsin loogisesti? vastaus parametrikyselyyn 0x21, vastaus 0x61 ja perään parametrin numero, sama, 0x08. Sitten dataa loppu. (Tähän tulee sitten flow control kysyvästä päästä). Seuraavan 8 tavun paketin alku 0x2X kertoo sen olevan indeksi ja seuraava numero indeksin, eli 0x21 - 0x2F ja sitten alusta jos vielä venyy. Simppeliä tähän asti. Mutta miten koodata tuo DBC:ssä näkyväksi? Anyone?

Kyllä minä saan tämän kaiken näkyviin taulukkolaskimessa myös käyränä, mutta en siis edelleenkään näitä valmistajakohtaisia mittausarvoja tuossa plotterissa, jossa skaalaus on helppoa ja kaikki samalla aikajanalla.

[juusmo]

Foorumi ei taida olla ihan tulvillaan jengiä joka kykenee reverse engineeraamaan automaatioväylien liikennettä, mutta ajattelinpa nyt vain kommentoida että ainakin yksi kiinnostunut seuraaja on, joten tsemppiä projektille! Raportoi ihmeessä miten tutkimus etenee. Dokumentaatio on kiinnostavaa ja ehkä jopa jälkipolvia hyödyttävää, vaikkei täältä mitään apua saisikaan.

[björn]

Hep, toinen kiinnostunut ilmoittautuu!

[MJPfin]

Kyllä vaan, tieto on voimaa. Mitä paremmin saa selvyyttä mitä moottorissa ja voimansiirrossa tapahtuu niin sen paremmin saa säädettyä haluamiaan parametrejä. Kiinnostava aihe on, mutta äärimmäisen haastava. Onnea valitsemallasi polulla.

[TPLtre]

Päivitellään juu kun jotain uutta ilmenee. Muutama uusi mittausarvo löytyi mutta tässä on aika paljon kaikenlaista työn alla, että hieman aikaa kuluu kaikkeen muuhunkin. Nyt viimeksi ollut haussa ruiskutusennakko, mutta se ei ole vielä valjennut, edes starista. Ilmeisesti joku ansteuerbeginn-arvo pitäisi löytää asteina. Kamalan kätevää hakea vajaan neljän tuhannen mittauksen joukosta sitä yhtä haluamaansa mittausta developerissa kun jokainen listan päivitys vie sellaisen puoli minuuttia vähintään ja selaus taas takaisin haluttuun kohtaan vielä enemmän. Toki listaan saa useamman kerralla, mutta jos ei ollut siellä joukossa, niin uusiksi.

Tähänkin starin hitauteen olen löytänyt ainakin osittaisen syyn. Kun star saa eculta multiframe vastauksen ensimmäisen paketin, se lähettää takaisin pyynnön laittaa seuraavat 8 riviä tulemaan 20ms välein. Jos parametriin sisältyy enemmän rivejä, se vaatii taas uuden flow controlin lähettämisen kun 8 riviä on vastanotettu. Tuo kaikkien mitattavien parametrien kysely sitten, en ole sitä logannut, mutta kaiketi se samalla tavalla menee ja siinä tulee varmasti tosi paljon 8 tavun paketteja. Ei ole nähty diagnostiikalla olevan niin kiirettä. Eikä tietysti voikaan olla, koska siellä liikkuu aika paljon reaalidataa myös.

On mulla jo siitä palvelupyynnöstä 0x21:kin jonkinlainen nälemys, normaali olisi 0x22, mutta star käyttää tätä. Palaan myöhemmin tähän, jos käsitykseni tarkentuu. CAN-väylään ei uskalla ihan mitä vaan työntää vain nähdäkseen mitä tapahtuu. Voi tapahtua jotain tai sitten ei. Mutta voi tapahtua myös jotain todella harmillista. Haluan ymmärtää edes likimain mitä olen tekemässä ennen kuin teen sen.

Hieman jokamiestä kiinnostavaakin ifoa. Se yleistesterin palvelupyyntö 0x01 on tämä minkä sisältö wikistäkin löytyy: https://en.wikipedia.org/wiki/OBD-II_PIDs. Otetaan ahtopaine, PID 0x0D. Mersu vastaa siihen kyllä, mutta sen datapituus on vain yksi tavu, 0-255. Ja tämä * 10 on absoluuttista painetta. Olen aika monta kertaa nähnyt kysymyksen mitä sen pitäisi olla? Vakiosoftalla tuota luokkaa. Ja yleismallin testeri kertoo, että maks. ahto on 1.55 bar (ylipainetta). No se tarkoittaa että ahdin kykenee saavuttamaan yleistesterin vastauksena saaman maksimiarvon ja käyränä se näyttää tasalakiselta vuorenhuipulta. Todennäköisesti meni hetkellisesti yli, jonkin verran, ja tämä hyvä, mutta ei se kerro mitään siitä paljonko meni yli. Se kertoo että parametrin arvo ei voi enempää olla. Tästä syystä monella se maksimiarvo ahtopaineelle on Motonetin pihassa tasan 1.55 bar. Valmistajakohtainen PID kertoo sen kahdella tavulla, jolloin saadaan todellinen lukema.

[TPLtre]

Saa näitä mun jorinoita kommentoida muutkin, kuin reverse engineeriä harrastavat, esim siitä mitä nuo starin antamat mittausarvot oikein edustavat. Olettaisin, että vaikkapa tuo ahtopaine on MAPin antama arvo, joka ei sisällä mitään lämpötila- tai ilmanpainekorjaimia?

[jruoho]

Moro TPLTre,

Meinasin jo jotain samantapaista kirjoitella, kun olen sähköisen B-mallin CAN-väylää reverse-engineerannut OVMS-mokkulan kanssa. Toistaiseksi olen tyytynyt vain passiiviseen väylän kuunteluun. Kuuntelemalla on löytynyt melkein kaikki info, mitä mittaristossa on tarjolla. Vain se tärkein info on hukassa, eli ajoakun varaustila. Koitin myös vähän kysellä noilla SAE J1962 -viesteillä, mutta auto ei vastaa mitään. Ei se tosin vastaa yleismallisille OBD-mokkuloillekkaan mitään (Staria en omista).

DBC:hen olen tutustunut vain vähän. Alussa ajattelin käyttää sitä dokumentointiin, että muutkin voisi hyötyä omasta vaivannäöstä, mutta laiskuus on vienyt voiton. Nyt kommentoin vain OVMS:n vehicle-modulin c-koodiin.. DBC:stä osaan nykyisellään vain yksittäisten viestien dekoodaukset, ja nekin huonosti.
Tuskin sinulle mitään apua vielä, mutta mainostetaan nyt kuitenkin. Tässä mun omat reverse-engineeraukset: https://github.com/r151809/Open-Vehicle ... cedesb250e
Tuo OVMS-mokkulan sorsat on ihan C++:aa, eli monimutkaisemmatkin enkoodaukset olisi helppo purkaa, jos ne vain keksii.

Jatkossa tuossa voisi olla jotain synergia etuja, ehkä. Ainakin minulle apu kelpaisi Kiinnostaisi kovasti nähdä mitä Star huutelee väylälle, että saisi itsekkin jotain vastauksia autolta. OBD-Y-haarakaapelia en ole vielä saanut aikaiseksi.
Nimimerkin perusteella voisit olla Treelta, eli kaffittelu tai muu tapaaminen voisi onnistua sen puolesta.

Jarkko

[AK47]

Saa näitä mun jorinoita kommentoida muutkin, kuin reverse engineeriä harrastavat, esim siitä mitä nuo starin antamat mittausarvot oikein edustavat. Olettaisin, että vaikkapa tuo ahtopaine on MAPin antama arvo, joka ei sisällä mitään lämpötila- tai ilmanpainekorjaimia?

Jäsen RAM on joskus muistaakseni CAN väylään perehtynyt nimenomaan siinä mielessä että sinne voisi rakentaa oman laitteen juttelemaan tai kuuntelemaan ohjauspyörän nappeja yms.

Itseä CAN väylän ihmettely muutoin kun starilla kiinostaa myös. Esimerksiksi se että meneekö se nukkumaan kun pitäisi ja jos ei mene miksi ei... Nimimerkillä akku tyhjänä muutaman kerran...

Millainen laitteisto tuo on millä sitä CAN väylää tutkit?

[TPLtre]

Jatkossa tuossa voisi olla jotain synergia etuja, ehkä. Ainakin minulle apu kelpaisi Kiinnostaisi kovasti nähdä mitä Star huutelee väylälle, että saisi itsekkin jotain vastauksia autolta. OBD-Y-haarakaapelia en ole vielä saanut aikaiseksi.
Nimimerkin perusteella voisit olla Treelta, eli kaffittelu tai muu tapaaminen voisi onnistua sen puolesta.

Moi Jarkko,

Juu asun Tampereella, mutta en juurikaan ole siellä, kun työ vie ympäriinsä. Viikonloput yleensä kyllä. Pelkäänpä että minun starista ei sinulle juuri apua ole. Minulla ei toimi Xentry ja syy on se, että tämä versio on levykuvasta tehty, koska varkaat löi ikkunan sisään kotipihassa ja sieltä lähti alumiinisalkku ja siellä vanha läppäri. Onneksi MUX oli kiinni autossa ja piilossa, joten ei niin kovasti harmittanut. Paitsi tietysti se lasi. Omaan autoon kun DAS riittää, niin en ole sitten jaksanut nähdä asiasta vaivaa. Mutta kun puhutaan ajoakusta, niin se kertoo sen verran uudemmasta autosta, että ei onnistu DAS:illa.

Tuon purkin valmistajalla on vapaasti(kenen tahansa) ladattavissa yksi versio DBC:stä, mutta se sisältää vain perusparametrit ja minä tarvitsen valmistajakohtaisia. En ole aivan niin softaorientoitunut, että sen muokkaaminen olisi mikään läpihuutojuttu.

Tässä nyt sitten opiskelen sivussa vielä saksaa EDC16 funktionsrahmenin avulla ymmärtääkseni mitä siellä oikein liikkuu.

Millainen laitteisto tuo on millä sitä CAN väylää tutkit?

Tuo minun purkki on CanEdge1. Löytyy netistä haulla. Käsittääkseni tuo purkki ei ainakaan CAN-väylää hereillä pidä, eli sikäli olisi sopiva, ehkä. Pysyy silti itse hereillä, koska OBD2-portista tulee kiinteä +12. Miten sillä nyt sitten saisi CAN-väylän nukahtamisen selville, ehkä katsomalla aikaleimasta koska siellä on lakannut puheet. En ole tutkinut asiaa tuolta kannalta.

Toinen asia sitten on, pystyykö moista edes OBD2-portin kautta selvittämään. Jo omassa W164:ssa on 5 CAN-väylää ja niiden yhteinen solmukohta on Central Gateway. Mutta voi sen kytkeä mihin tahansa niistä kun kaivaa piuhat esille.

[TPLtre]

Lisäksi autossa voi olla myös muita dataväyliä, K-väylä ja LIN-väylä. Itselläni ei ole näitä. LIN-väylä on yksinkertaisempi kuin CAN ja sitä käytetään ohjaamaan vähänpätöisempiä tehtäviä, kuten ikkunoiden avausta yms. (Yksijohtoinen, halvempi tehdä, mutta myös häiriöarempi).

Minun tietämykseni ei vielä riitä siihen pitääkö mahdollisesti hämähäkin seitin yksi haara sitten central gatewayn ja sitä myötä koko verkon hereillä, vai voiko vain yksi haara yksinään olla akkua tyhjentämässä. Saattaa olla että se on sitten koko verkko tai ei mitään. Ainakin ovet pitää olla kiinni ja avain pois lukosta, että ECU:n väylä sammuu, joten varmaan se on koko verkko sitten hengissä.

[jruoho]

Ihan geneerisellä ELM327-kloonillakin voi kuunnella passiivisesti. Ennen tuon OVMS:n tilaamista kokeilin sen verrran, että jotain siellä liikkui. ATMA -komento sarjaporttiin ja sieltä tuli tulostuksia. Caristan adapteri valitteli niin usein buffer-virhettä, että datan tulkintaan ei ollut mitään realistisia mahkuja. Jollain nopeemmalla adapterilla, homma voisi onnistuakin. Mutta sen hereilläolon sillä voisi helposti tunnistaa.

OVMS:n kanssa olen käyttänyt SavvyCAN -sovellusta. Sekin tukee jollain tapaa DBC-formaattia. Käppyröitä se osaa näyttää aika hyvin, eli mittausdatan tunnistamisessa se on aika kätevä työkalu.

Jarkko

[TPLtre]

No se on sarjaväylä, että monenlaista sovellusta löytyy kyllä. Siinähän tarvitaan vain jokin CAN-USB muunnin ja tietokoneeseen jokin sovellus. Linuxille esim on Can-Utils. Mutta silloin siihen tarvitaan se PC. Jonka tietysti saa myös toimimaan loggerina, mutta harvapa siihen lähtee. Tuollainen pieni purkki on kätevä kun voi vain jättää kiinni ja avata login myöhemmin.

Tuo SavvyCAN taitaa mennä minulta aika paljon ohi, kun jo githubin mainitseminen saa vähän kananlihalle.