Lm393 albo inny dowolny komparator i masz konwerter k-line do słuchania a jak się uprzesz to będzie działało na dzielniku z 2 rezystorów albo rezystorze 2k i diodzie zenera 4v7 . Można też zrobić na 2 tranzystorach pnp i rezystorze 1k . Przykładów realizacji konwertera k-line na logikę ttl realizacji tego jest tyle co twórców a jak byś się uparł to taki układ wyjmiesz z byle grata z auta od radia przez sterownik silnika , bsi lub prawie każdy inny moduł który się diagnozuje wystarczy poszukać .
To zanim doczekasz się tego układu to może napiszesz jakie parametry chcesz odczytać i jak zamierzasz to zrobić . Bardzo mnie ciekawi to jak chcesz to zrobić . Jak napiszesz kolejno co będziesz robił to powiem ci czy coś z tego będzie
Zobaczymy ile odczytam od tego zależy reszta prac. Reszta łączenia tradycyjnym KWP . 5bitow na sekundę przez 2 sekundy i otrzymał zwrotkę z ECU. Potem 3 bajty które wynikają z standardu ISO, czwarty mode, piąty zapytanie, szusty suma kontrolna. Co chcesz jeszcze wiedzieć ?
Jako ze mam parcie szukam co chwile czegoś nowego. I wyczytałem coś co nie musi być w moim aucie ale może...
"Type of data exchanged
The data transmitted by the PPS tool
and the ECUs are carried on a single
K Line.
Using an oscilloscope, it is possible
to observe signals of this type with
ECU-specific communication times:
• Communication the throughput is
generally 10,400 bits per second.
• For ECU downloads, the throughput
may attain 62,500 bits per second.
These signals are interpreted, first in
the form of bits, then in the form of
bytes:
Example: 82D0F12180E4
Drażni mnie słowo "Może". I może dlatego nie radzą sobie elmy ?
Rozbije jeszcze stringa z informacjami:
89F1D0 61C2 6F6EA37300AAB2 17
89 - Liczba bajtów użytecznych
F1 - Numer ECU (target)
D0 - Numer ECU (source)
61C2 6F6EA37300AAB2 - użyteczne dane
17 - suma kontrolna
Informacja którą przedstawiłeś jest zgodna z dokumentacją i z tym sobie z pewnością poradzisz . Twoja przewaga jest taka że masz fabryczny tester więc możesz sobie to i owo podsłuchać podczas komunikacji . W prawdzie czeka cię jeszcze kilka niespodzianek po drodze ale jak się zmobilizujesz i pomyślisz to osiągniesz sukces . W zasadzie robiąc tego typu urządzenie możesz pokusić się o więcej niż tylko parametry bieżące . Tu można spokojnie zrobić sobie odczyt , kasowanie błędów , parametry . tyle że to samo będziesz miał kupując chińska kostkę na wifi lub BT i odpalając w telefonie odpowiednią aplikację . Tyle że w twoim przypadku będziesz miał satysfakcję z realizacji tego zagadnienia samodzielnie .
Właśnie nie bo chińskie kostki nic nie czytają. Gdyby tak było nie kombinował bym. I tak jest dobrze bo jak zaczynałem temat byłem zielony a teraz jest jakaś nadzieja.
Od jakiegoś czasu auta muszą być wyposażone w system diagnostyki pozwalający okreslić czy samochód zanieczyszcza środowisko z powodu uszkodzenia kluczowych dla emisji spalin czujników.
Kazdy mechanior ma mieć możliwość sprawdzenia która sonda w wydechu padła by samochód jak najszybciej przestał truć
Producenci muszą umieszczać w tym protokole dane o sondach, czujniku temperatury płynu i tylko tyle muszą.
Jak chcą to mogą tam umieścić odczyt większej ilości parametrów , ale nie muszą i dlatego w jednych autach coś po EOBD poczytasz a w innych ubogo.
Może Ci sie nawet świecić lampka "Check engine" a interfejs EOBD napisze Ci że "nie ma błędów związanych z emisją spalin" bo zepsuł się inny czujnik.
Sprzęt diagnostyczny nie korzysta z EOBD tylko protokołów producenta.
Już nawet w Polonezie na jednopunkcie odczytasz czas wtrysku przez ALDL a przecież EOBD tam nie ma Hahahaha
Niemniej ten projekt trochę mnie zastanawia.
Dane nie są stale wypluwane na złącza. Czasem trzeba zainicjować tryb diagnostyki danego modułu
Wtedy ECU odpowiada na konkretne zapytania.
Teraz przemyślmy Twój projekt. Jeśli podłączysz się swoim Bordcompuetrem z tyłu gniazda diagnostycznego to dalsza diagnostyka Planetem nie bedzie już możliwa po właczeniu "zapłonu" chyba że przewidzisz coś takiego w tym Bordcomputerze że będziesz go odłaczał na czas diagnostyki.
Bardzo łątwo jest na przykład wyłączyć fabryczny Immobilisser w Bosch`owskich EDC15 EDC16 poprzez złącze diagnostyczne.
Jedną z metod obrony może być właśnie zwarcie linii diagnostycznych do masy.
Wracając do Twojego projektu to zauważ że instalacje LPG nie podłaczają się do linii diagnostyki w celu czytania informacji o czasie trwania wtrysku.
Biorą ją same prosto z wiązki.
Były kiedyś instalacje które się podłaczały do EOBD ale to tylko dlatego że kasowały błędy dotyczące emisji spalin właśnie
Planet nie diagnozuje tego po eobd poza tym ta norma obowiązywała z tego co pamiętam do 2010 r po nim producent sterownika nie ma obowiązku implementować tego typu protokołu w sterownikach a jak już go tam znajdziemy to będzie występował w bardzo okrojonym zakresie , tak będzie też z blokami pomiarowymi i błędami . Reszta będzie niedostępna lub opatrzona opisem specyficzny błąd producenta . Większość nowych sterowników jest wyposażona w dwie magistrale jedną k-line do trybu diagnostyki i obd a drugą najczęściej can do przesyłania informacji i odczytu parametrów z innych modułów , jednak te informacje często nie mają nic wspólnego z protokołami diagnostycznymi . Poza tym wiele nowych aut ko kooperacje i takim sposobem w citroenie znajdziesz komunikację rodem z fiata , w oplu z renault-a a w VW z mercedesa . ELM327 ma swoje nowsze wcielenia w których jest większa liczba protokołów i łatwiej się nim posługiwać niż pisać cały protokół od nowa , poza tym can pracuje ze znacznie większą prędkością 125k, 250k 500k i 1M bps co oznacza że jest to minimum 10 razy szybciej od kwp , do tego jest to sieć w która każdy węzeł wysyła co ma do wysłania więc informacji jest ogromna ilość . Odnalezienie tego co nas interesuje nie jest takie proste...
Niveasoft tak jak piszesz trzeba zainicjować rozmowę z ECU. I pytać o konkretne rzeczy które chce się uzyskać.
Moje IMMO nie do ruszenia BSI + ECU - taki model auta.
Co do LPG to nic nie zmienia bo czas wtrysku gazu podawany jest jako zwrotka do ECU. Dlatego trzeba w niektórych autach montować emulatory to poziomu paliwa...
kamyczek Nie mam CANa a wyżej opisałem jak wygląda protokół w moim aucie to dane z Peugeota.
Mam problem z dostaniem BUSa z ISO Na TxRx. Mogę zrobić to jak na schemacie ?
Możesz będzie działało jedyna wada to brak zabezpieczenia linii przy zwarciu do 12V. Ładniej z komparatorem analogowym . Linka do układu ,który potrzebujesz masz na p.w kłopotu z dostępem nie ma i to najbardziej popularny i najczęściej stosowany konwerter w tych rozwiązaniach .
...a na znanym portalu leżą sobie L9637 po 5 złotych
Co do interfejsu to wiesz że normalnym stanem dla TX kiedy nie nadaje jest stan wysoki...wtedy masz linię K zwartą tym tranzystorem. Dlatego najcześciej dawało się dwa tranzystorki. Jeden z nich odwracał logikę.
Wpisz "k-line to microcontroller" i przełącz na obrazy dla zapytania.
Co do tego immo to tak tylko przewrotnie dodam, bo forum nie jest do omijania zabezpieczen, że to nie jest takie znów trudne
..a z LPG chodziło mi o to że sygnał dla instalacji LPG brany jest z instalacji a nie złączem diagnostycznym.
Za ten czas to sobie możesz zrobić płytkę w zasadzie nie ma tam niejasności otwierasz pdfy i rysujesz schemat trawisz i masz gotowca ewentualnie jak chcesz mieć uniwersalny moduł to dorysyj tam CAN np. z MPC2515 i driverem 82c250 i będziesz miał zabawę do woli
musze sprawdzić czy "FFFFFFC133FFFFFFF13E23FFFFFF81FFFFFFF1107E0" to wysyła ELM czy nadaje ECU. Dziś koło 22 będę w aucie więc sprawdzę. Ale jak na razie mało wiem.
O czym ty kolego Niweasoft piszesz na linii k jest na stałe podciągnięta do +12V przez rezystor ok 510 om możesz to sobie sprawdzić miernikiem w aucie . To co odczytujesz terminalem średnio mi się podoba używasz programowego czy sprzętowego uarta ?
co jest odpowiedzią a co pytaniem wynika z nagłówka ramki tyle że to co tu widzę niczego normalnego mi nie przypomina .
No własnie tez nie bardzo mi to się z zgrywa ze standardem ISO. Program napisałem w C. Nie chciałem go tu wpychać bo to temat Bascom. A Uart chyba sprzętowy. Mam 4 uarty z Mega2560 używam serial2. A transmisja po prostu "Serial2.baud(10400);" Mogę wkleić cały kod jeżeli to coś da. I czemu tak dużo F ? Czy to przez to podciągniecie do +12V ? Bo wysypuje mi się te stringi tak co 2s.
Nie wiem z kim tu rozmawiać.
Zrozumcie więc obaj. Żeby uzyskać informację o obrotach należy nadać na linii dane. Linię mamy jedną. W stanie wysokim i nadanie danych polega na zwieraniu jej do masy. Nadajemy co chcemy dostać i czekamy. Za chwile układ wywołany odpowiada.... koledzy .. tą sama linią zwierając ją do masy.. nadając bajty. pozostawiam bez komentarza...
Możesz dalej słuchać Kamyczka albo zacząć myśleć.
Zmieniłem wyświetlanie z HEX na ASCII i są krzaki. Ale połączyłem się do terminala na PC zadalem mu odpowiedni baudrate i przekazuje wszystko idealnie. Rano podepne do auta i zobaczę jakie informacje mi wyświetli. Nivea ja cię rozumiem (choc nie zawsze rozmawiamy w tym samym języku) jedna linia 2 kierunkowa a linia L jest tylko jednostronna.
O co nie zapytam wyświetla to. Ale to może dlatego że nie jest skomunikowany z ECU
No i Lipton. Krzaki. Pytanie tylko czy to nie wina przejściówki kline-ttl. Tylko jak to sprawdzić ? Wlutować się pod elma zaraz za PICiem ? Pomysły mi się kończą.
Linia K jest podciągana do 12V i da się określić kiedy ktoś żąda odpowiedzi
Kiedy ktoś odpowiada owszem bo na linii k zmienia się stan z wysokiego na niski ale jak chcesz określić że ktoś żąda odpowiedzi po tym ze jest tam stan wysoki ? , taki sam jest gdy nikt nie gada . To czy ktoś wymaga odpowiedzi wynika tylko i wyłącznie z ramki , odpowiedź może być pozytywna , negatywna lub jej nie być jak urządzenia nie ma lub nie rozumie tego co wysyłasz . Ja bym się niveasoft dobrze zastanowił nad tym co piszesz i kogo wiedzę kwestionujesz . Kline to magistrala w której trzeba otworzyć sesję i w niej zapytać o coś poza tym ją podtrzymywać bo jak odbiornik nie dostanie odpowiedniej ramki z testera to ją po prostu zamknie . Podsłuchaj sobie ramki Juni[]r z podłączonym testerem to zobaczysz co tam się dzieje podczas komunikacji .
Nasze toki rozumowania na pewno są różne, więc postaram się wyjaśnić swój.
Podsłuchiwałem już rameczki pomiędzy różnymi modułami. Kiedy w szereg na linii wstawisz rezystor 1R a po obu stronach rezystora podłaczysz komparator to spadek napięcia po jednej ze stron rezystora określa która strona zwiera linię transmisji czyli nadaje.
Tak więc jeśli Junior ma Planeta albo tego Elma to można łatwo okreslić gdzie kończy sie zapytanie o obroty a gdzie nastepuje odpowiedź sterownika.
Teraz ma tylko pogląd szyny a nie wie kto co nadał.
Tyle z mojej strony
to co napisał niveasoft ma sens , ale tylko dla stanu w którym będzie stan niski na linii k generowany przez sterownik ale resztę da się ogarnąć programowo przy pomocy mikrokontrolera o ile nie ma innej metody tą też dojdziemy do tego kto do kogo . Jednak patrząc na protokoły z serii kwp łatwo odgadnąć kto pyta a kto odpowiada . patrząc na to co pokazuje kolega na terminalu nie wygląda to na coś co można do tego kwp przypasować z wielu powodów .
No to sprawdziłem poprawność terminala na 10k4 baud. Wysłałem z laptopa terminalem informacje poprzez kabel BRC LPG (ftdi-kline) do mojej przejściówki i na wyświetlaczu pojawiły się informacje spójne. Znaczy to ze ani mój samochód ani ELM nie gadają po 10k4. Dość dziwne przecież to standard. Pan Kamyczek namówił mnie na analizator stanów logicznych ale do piątku pewnie nie dotrze do paczkomatu. Może on powie z jaka prędkością gadać.
-edit-
Postanowiłem połączyć terminal PC + moje LCD i ELM. Wynik niespodziewany
Zapytałem ELMa o 010F
na co PC wyświetliło:
33 F1 81 66 E4 00 C1 33 F1 81 66
A LCD
0FFFFFFC133FFFFFFF1FFFFFF8166
Skąd ta rozbieżność jeżeli sam PC z LCD gada dobrze....
Pomyślałem sobie jeszcze o tym co powiedział kolega Niveasoft "kto sucha, kto mówi". Wiem że chodziło mu o wstawienie oporu na lini i z której strony wyższe napięcie tam jest nadawanie. Nie wiem jak zbudować coś takiego ale... Posiadam 4 UARTy sprzętowe. Może użyje 2 na raz. Do jednego podłącze jedną stronę a do drugiego drugą. Czyli np: ELM nawija do RX1 wyświetla mi to na LCD na żółto i zarazem wysyła na TX2 do ECU. A ECU podpinam do RX2 wyświetla na biało i zarazem wysyła do TX1. Problem w tym że zamówiłem tylko jeden L9637d Chyba ze Niveasoft ma jakiś wypaśny i prosty sposób na sprawdzenie kto mówi...
Wiem ze to nie BASCOM ale dla każdego pewnie zrozumiałe.
Code: c
Log in, to see the code
I mam w zmiennych InByte i InByte2 wartości wysyłane
A no masz tylko że musisz jeszcze zbudować mechanizm który będzie rozpoznawał że np. 3 kolejne odpowiedzi mogą być związane z jednym zapytaniem ja bym wstawił np. kilka bajtów o tej samej wartości , albo string odp: w odbiorniku a pyt: w nadajniku Pomysł bardzo ciekawy i funkcjonalny
Hahahaha
Chyba ze Niveasoft ma jakiś wypaśny i prosty sposób na sprawdzenie kto mówi...
