Viena aišku: nepaisant savo amžiaus, K-Line nėra toks paprastas, kaip norėtųsi ar atrodytų! Vienas didžiausių iššūkių bandant dekoduoti K-Line yra tas, kad skirtingi gamintojai (OEM) žinutes koduodavo ir dekoduodavo skirtingai.
Žemiau – keli svarbiausi faktai apie K-Line (ISO 9141):
• K-Line palaiko duomenų perdavimo spartą nuo 5 bit/s iki 50 kbit/s
• Dvikryptis pusiau dupleksinis (half duplex) magistralės ryšys
• Manchester tipo signalo kodavimas
• Vienos gyslos (single ended) magistralė
Kita problema – su K-Line gali būti naudojami keli skirtingi formatai. Dažnai tai paaiškinu sakydamas, kad kalba ta pati, tik akcentai skirtingi! Juos atskirti yra didelė kliūtis, ant kurios užkliuvau ir aš, bandydamas dekoduoti Steve'o įrašą, o viskas priklauso nuo inicializacijos sekos, kai prie automobilio prijungiamas diagnostikos skaitytuvas. Peržiūrint šį PSDATA failą taip pat verta prisiminti, kad jis buvo įrašytas bandant susisiekti su Pico NVH programine įranga, siekiant gauti variklio ir važiavimo greitį. Šis dokumentas pasirodė esąs itin vertingas.
Toliau pateikta informacija paimta iš jo. Gali būti naudojami 3 protokolai, ir nors jie šiek tiek panašūs, tai yra atskiri ir skirtingi protokolai. Tie 3 yra –
1. K-Line (ISO 9141) su 5 bodų inicializacija
2. KWP2000 (ISO 14230) su 5 bodų inicializacija
3. KWP2000 (ISO 14230) su greitąja inicializacija
Tai, kad bandome susisiekti su NVH, yra svarbu. Mat NVH bandys kelis skirtingus ryšio būdus, kol sulauks atsako, o NVH palaiko tiek ISO 9141, tiek ISO 14230.
Žinodamas, kad kodavimas paremtas Manchester tipo signalais, pagalvojau išbandyti šį dekoderį PicoScope programoje. Deja, tai nepavyko. Dėl skirtingo antraštės ir naudingosios apkrovos (payload) duomenų ilgio K-Line viduje, Manchester dekoderyje neįmanoma nustatyti duomenų ilgio, nes jis keičiasi su kiekvienu paketu. Kitas dažnai minimas kodavimas – UART (Universal Asynchronous Receiver/Transmitter, universalus asinchroninis imtuvas / siųstuvas). Jis leidžia dekoduoti kiekvieną atskirą baitą, tačiau, deja, neparodo, kaip sudarytas paketas. Vis dėlto tai labai naudinga siekiant suprasti, kaip šis tinklas bendrauja.
Pradėkime nuo ISO 9141 inicializacijos sekos, naudodami tiek Pico, tiek pirmiau minėtą dokumentą, ir pritaikydami UART dekoderį. Iš dokumento žinome, kad naudojama 5 bodų sparta ir tam tikra ieškotina seka, apimanti 2 sekundžių perdavimą, kurio metu bus aukštas lygis, trunkantis 400 ms. Tai galime atpažinti Pico ir patikrinti laiko liniuotėmis.
Žinodami, kad tai mus dominanti sritis, dabar galime pritaikyti dekoderį, o kad išvengtume painiavos, galime nustatyti, kad dekoderis veiktų tarp liniuočių šioje srityje.
Pagal dokumentą, tai diagnostikos skaitytuvas siunčia į magistralę adresą 33 5 bodų sparta, ir tai trunka iš viso 2 sekundes. Po to turėtų sekti ECU atsakas su sinchronizacijos baitu 55, kuris turėtų atsirasti per 20–300 ms. Sąmoningai nustačiau savo laiko liniuotes ties 2,300 sekundės, kad parodyčiau, jog iš automobilio atsako nėra.
Kadangi atsako nėra, o mes bendraujame su NVH, NVH pereina prie kito protokolo – šiuo atveju ISO 14230. Žinome, kad yra 2 ISO 14230 tipai: vienas naudoja 5 bodų, kitas – greitąją inicializaciją. Kadangi 5 bodų versija naudoja tokią pačią inicializaciją kaip ir ISO 9141, sinchronizacijos baitas turėtų atsirasti 300 ms po to, kai adresas 33 patenka į tinklą. Jo vis dar nesant, iškart pereiname prie KWP2000 greitosios inicializacijos.
Ši seka prasideda 50 ms trunkančiu žadinimo (wake-up) šablonu, po kurio iškart eina ryšio pradžios užklausa iš diagnostikos skaitytuvo į automobilį.
TECHNINIS PATARIMAS
Skirtingos duomenų perdavimo spartos ypač apsunkina dekodavimą, nes pirmiausia ją reikia nustatyti. Yra paprastas būdas rasti bet kurio tinklo bodų spartą naudojant Pico liniuotes. Pirmiausia suraskite mažiausią bitą duomenų pakete ir kiekviename bito krašte padėkite po laiko liniuotę. Toliau pažiūrėkite dažnį liniuočių legendoje – tai ir bus jūsų bodų sparta.
10,4 kHz galima versti kaip 10,4 kBaud. Įsidėmėkite tai, nes tai svarbu pritaikant bet kurį dekoderį.
Vėlgi, naudodami PDF dokumentą kartu su UART dekoderiu, pradedame matyti ryšį tarp dokumento ir to, ką rodo Pico. Pirmoji informacija iš diagnostikos skaitytuvo pagal dokumentą sudaryta iš šių baitų
1. C1 – formato baitas
2. 33 – paskirties adresas
3. F1 – šaltinio adresas
4. 81 – ryšio pradžios užklausos ID
5. 66 – kontrolinė suma
Būtent tokie dekoduoti duomenys ir randami naudojant UART dekoderį Pico, ir jie eina tiksliai po 50 ms žadinimo signalo.
ECU atsakas turi panašų formatą, tačiau papildomai apima raktinius baitus (key bytes). Raktiniai baitai yra visuose 3 inicializacijos tipuose ir yra būtini nustatant, ar tolesniame automobilio ir testerio ryšyje bus naudojamas ISO 9141, ar ISO 14230. ISO 9141 atveju raktiniai baitai bus arba 08 08, arba 94 94, o ISO 14230 atveju jų yra apie 19 skirtingų tipų! OBD ryšiui naudojant ISO 14230 reikalaujama, kad būtų naudojami tik raktiniai baitai 8F E9. Laikantis to paties užklausos šablono, atsakas turėtų atrodyti taip –
1. Formato baitas
2. Paskirties adresas
3. Šaltinio adresas
4. Paslaugos ID (Service ID)
5. Raktinis baitas 1
6. Raktinis baitas 2
7. Kontrolinė suma
Žiūrėdami į tolesnius duomenis Pico, matome štai ką –
Daugiau informacijos apie raktinius baitus rasite šiame dokumente.
Po šios inicializacijos sekos eina pirmoji duomenų užklausa iš diagnostikos skaitytuvo. Ji gali skirtis priklausomai nuo to, ko ieškote. Kadangi naudojame tai NVH tikslams, ieškome variklio ir važiavimo greičio, kuriuos rasime Service 1 PID 00. Diagnostikos skaitytuvo užklausa turi atitikti standartą, nustatytą raktiniais baitais, kad būtų teisinga antraštė. Šiame pavyzdyje naudojamo automobilio raktiniai baitai yra 8FE9, o teisinga skaitytuvo užklausa turėtų būti C2 33 F1 01 00 C4. Tai matyti ir Pico –
Atitolinus įrašo vaizdą, pradedate matyti dėsningumą tarp diagnostikos skaitytuvo užklausos ir automobilio atsako.
Čia turiu padėkoti Kim Anderson, nes toliau pateikta informacija tapo daug lengviau prieinama būtent dėl Kim indėlio dekoduojant šiuos duomenis. Kim maloniai ėmėsi kurti skaičiuoklę, kuri naudoja iš Pico eksportuotus duomenis. Kai pradedate narplioti duomenis, dėsningumai tampa aiškūs!
Pažiūrėję į su NVH įrašytą trasos (trace) failą, taip pat pastebėsite ryšį tarp Pico dekoduotų duomenų ir OBD registravimo trasos faile.
Toliau, naudodami trasos failą, galime nustatyti, kad dvi užklausos 0C ir 0D yra atitinkamai variklio ir važiavimo greičiui.
Tačiau dabar jau galime pabandyti nustatyti, kuris ECU atsako diagnostikos skaitytuvui – padarydami pagrįstą spėjimą! Mes prašome variklio ir važiavimo greičio, tad būtų visai neblogas spėjimas teigti, kad šaltinio adresas, pažymėtas 10 pirmiau esančioje lentelėje, iš tikrųjų yra mūsų variklio ECU.
Ateityje tiksliai dekoduoti K-Line teks tik tada, kai bus prijungtas diagnostikos skaitytuvas, nes taip gausime tuos svarbius raktinius baitus po automobilio ir skaitytuvo inicializacijos. Iš čia matysime, kaip bus pateikiami duomenys ir kokia informacija prieinama. Kad gautumėte kuo daugiau informacijos, rekomenduojame nustatyti 5 s/dalj. ir apie 2 MS/s diskretizacijos dažnį. Taip bitai bus pakankamai detalūs, kad juos būtų galima dekoduoti.
Tikiuosi, kad tai kuo nors padės ir parodys, kad, nors Pico neturi specialaus dekoderio, vis tiek galime naudoti įrankius, kad iš neapdoroto signalo išgautume daugiau informacijos. Dar kartą ačiū Kim Anderson, Barney Donohew ir Steve Smith už pagalbą rengiant šią medžiagą.
Straipsnis išverstas iš Pico Technology bibliotekos su gamintojo leidimu. Originalas: picoauto.com. PicoScope įrangą rasite mūsų kataloge.