Poprzedni temat

Jak zwykle po dłuższej przerwie, ale mam nadzieje że temat będzie dość ciekawy.

Mianowicie, niejako z konieczności, tym razem pod nóż trafił problem korekcji czasu wtrysku na podstawie wskazań sondy lambda.

Fabryczne oprogramowanie wydaje się działać poprawnie, ale niestety jak to jest w sumie z jego całością, jedynie w ograniczonym zakresie.

Po większych modyfikacjach kiedy parametry pracy silnika odstają za bardzo od założeń fabrycznych, zaczynają się problemy.

W tym wypadku modyfikacja polega na założeniu większych wtrysków, i dodaniu pewnego wspomagacza oddechu silnika .

Efekt dosyć spodziewany, bez modyfikacji oprogramowania, spalanie przerażające jak na tak mały silnik, i dodatkowo problemy przy dużym ciśnieniu. Jak można spodziewać się, chociażby bazując na prawach Morgana, przy spokojnej jeździe auto przelane benzynom, a kiedy jest potrzebna większa jej ilość, to jej brakuje. ( Jak znajdę chwile to postaram się wkleić wykres ).

Oczywiście takiego stanu rzeczy można się spodziewać, jednak w końcu po to jest sonda lambda żeby nie dopuszczać do takich sytuacji.

W tym wypadku po prostu fabryczne oprogramowanie nie jest przygotowane na takie rozbieżności i korekcja czasu wtrysku pomimo że osiąga skrajne wartości ( na jakie pozwala oprogramowanie ) jest niewystarczająca.

Niewykluczone że jest to kwestia dopasowania odpowiednich zmiennych, jednak najpierw trzeba by poznać dokładną zasadę działania tego kodu. Ale z pewnością ciekawszym rozwiązaniem ( przynajmniej dla mnie ) jest próba napisania własnego programu spełniającego to zadanie, a z pewnością dostarczy on sporo wiedzy na temat działania silnika. Oczywiście fabryczne oprogramowanie jest z pewnością dużo bezpieczniejsze i przewiduje sporo "awaryjnych" sytuacji, jednak z moich dotychczasowych obserwacji wynika że jednak jeżeli coś zaczyna się dziać od strony mechanicznej to ECU jest i tak bezradne.

Tak więc powoli spróbujemy zmierzyć się z tym tematem.

Zadanie wydaje się dosyć jasne - napięcie dostarczane przez sonde lambda informuje nas o składzie mieszanki ( w przypadku tej sondy jest pewne ograniczenie ), na zasadzie przełącznika - ubogo / bogato. Wynika to z charakterystyki sondy - jest ona bardzo czuła przy optymalnej wartości AFR i traci charakterystykę geometrycznie kiedy wartość AFR się od niej oddala.

No to na początek dużo nie myśląc tworzymy pierwszą wersje programu.

Jak widać nie jest ona zbyt obszerna, ale na początek musi wystarczyć.

Idea jest następująca

- wprowadzamy parametr korekcji wtrysku [KOREKCJA], jest to wartość stale modyfikująca aktualnie wyliczony czas przez oprogramowanie fabryczne.

- przy "sprzyjających" warunkach na podstawie odczytu napięcia sondy modyfikujemy + [LAMBDA] > [LAMBDA_DOCEL] / - [LAMBDA] < [LAMBDA_DOCEL] parametr [KOREKCJA] o wartość [KOREKCJA DIFF] = 1

... i to na tyle .

Pare wyjaśnień na temat kodu.

[DELAY] to licznik co jaki czas mamy próbowac zmieniać parametr [KOREKCJA], jeżeli jest większy od 0 to tylko go zmniejszamy.

Jeżeli spadnie do 0 to z powrotem ustawiamy go na wartość początkową i sprawdzamy kolejne warunki.

[ENGINE_RUNNING_MODE] jest to zmienna ustalana przez fabryczne oprogramowanie która oznacza tryb pracy silnika. Wartości 0..2 są w trakcie rozruchu. 3 to kilka początkowych sekund pracy silnika po rozruchu i wreszcie 4 czyli normalna praca.

Następnie sprawdzamy czy wogóle jest włączona opcja modyfikacji czasu wtrysku.

W przypadku gdy nie ma warunków do korekcji ustalamy ją na neutralną ( 0 ).

Jeżeli warunki zostały spełnione to odczytujemy aktualny stan

napięcia sondy ( 0 oznacza za dużo powietrza ), i w zależności czy jest powyżej czy poniżej docelowej wartości [LAMBDA_DOCEL] ustalamy parametr [KOREKCJA_DIFF] na +1 lub -1 (0xFFFF).

Następnie o tą wartość modyfikujemy aktualną wartość korekcji [KOREKCJA].

Na koniec jeszcze sprawdzamy czy wartośc korekcji nie przekroczyła zakresu maksymalnego.

+ [KOREKCJA_MAX]...[KOREKCJA]...[KOREKCJA_MIN] -

Co miało zostać powiedziane już zostało wystarczy tej teorii , a teraz czas na część bardziej interesująca - praktyczną.

Wgrywamy nowy program odpalamy auto i oto co otrzymujemy.

Dla porównania tak wygląda praca na oprogramowaniu fabrycznym.

Tutaj wyłączamy fabryczną korekcje lambda ( czas wtrysku jest brany jedynie z map )

A teraz najciekawsze włączamy teraz nasze nowe oprogramowanie.

(Duża częstotliwość aktualizacji korekcji)

A teraz zwiększamy czas pomiędzy aktualizacjami

Pozostaje jeszcze "rozszyfrować" wykresy.

Zielona linia to wartość napięcia sondy nisko to uboga a wysoko to bogato. ( Należy pamiętać o charakterystyce napięcia ). Wartosc 1 lambda to wartość 0x5A napięcia.

Czerwona linia to czas wtrysku.

Na samym dole wykresu "krzaczki" to aktualny stan licznika aktualizacja korekcji. Czarne trójkąty to [KOREKCJA] czasu wtrysku.

Mam wolną chwilę to parę uwag na temat tych wykresów. Ogólnie kolega Cinek napisał w sumie wszystko .

Jak widać oryginalne działanie można uzyskać moim sposobem odpowiednio dobierając częstotliwość zmian korekcji. Wynika to z tego że sonda działa z minimalnym opóźnieniem i jeżeli za szybko obniżamy czas wtrysku to w wyniku bezwładności układu to za mocno go zmniejszamy zanim układ na to zareaguje - wykres 3. Na wykresie tego nie widać ale auto w chwili maksymalnego "przycięcia" paliwa zaczęło się dławić. Dlatego lepiej zmniejszać powoli i czekać na rezultaty. Biorąc średnią z czasu wtrysku i tak zawsze spalanie wychodzi mniej więcej tak samo.

Trochę pokrętną arytmetyką ale wychodzi że odpowiedni czas wtrysku jest w granicach 0x190 co daje 400 * 2 = 0,8 ms.

Na drugim wykresie czas skoczyl ponad 0x200=512*2= 1ms i już auto zrobiło się mocno przelane - ze względu na charakterystkę geometryczną sondy wartości +/- 0x10 od 0x5A są miarodajne. Powyżej w sumie AFR może oznaczać +/- nieskończoność.

Dlatego w przypadku sond wąskopasmowych potrzebna jest oscylacja wokół optymalnego AFR.

Skoro temat wolnych obrotów wydaje się być przynajmniej na początek rozwiązany - kolejne testy będą dotyczyć jazdy. W przypadku "stabilnej" jazdy ( gaz w jednej pozycji ) to rozwiązanie również się sprawdzi ponieważ cały układ znajduje się w stanie równowagi.

Problemy zaczynają się w momencie gwałtownych zmian np. przy mocnym wciśnięciu gazu - zanim algorytm powoli zwiększając czas dojdzie wreszcie do odpowiedniego poziomu może minąć sporo czasu kiedy silnik nie będzie miał paliwa przy dużym doładowaniu, a czym to się kończy chyba wiadomo... .

Może jakieś pomysły jak usprawnić algorytm w momencie przyspieszania żeby dynamiczniej dopasowywał się do zmian

Zapraszam do dyskusji

wreszcie coś ciekawego i rzeczowego się dzieje

Dla mnie jesteś magik

Co do wykresu numer 2 to rozumiem że auto jest przelane.

Na wykresie numer 3 czas wtrysku zmienia się dość mocno w czasie (duża amplituda)

No i na ostatnim wykresie czas wtrysku zbliżony jest do tego na oprogramowaniu fabrycznym czyli ma małą amplitudę i można powiedzieć, że nie zmienia się w czasie

Dobrze zrozumiałem ????

PS 1. Silnik pracował na wolnych obrotach czy operowałeś gazem w trakcie pomiaru?

PS 2. Wogóle nie można się z Tobą skontaktować gdzie Ty się podziewasz ??

Nice Ja na razie pytania i komentarze kontrolne:

1. Czy to jest cały czas program od 1.1 SPI, który przystosowujesz do pracy z górą 1.2 MPI (turbo plus wtryski)? Czy stosujesz też "większy" MAP sensor? Pytam, bo sam ostatnio mocniej się wgłębiam w program od 1.2 MPI i widzę, że właśnie MAP sensor będzie największym problemem (ale nie nie do pokonania ). No a ewidentnie jest niezbędny.

2. Ten programik diagnostyczny to domniemam Twoje dzieło? Jakaś szansa na podzielenie się? Ja na razie mam tylko ten taki z ff co działa tylko w trybie tekstowym. Działa spoko, ale mi dużo rzeczy w nim brakuje, a własnego mi się nie chce (czytaj nie mam na razie czasu) pisać.

3. Mógłbyś trochę bardziej spróbować wyjaśnić dlaczego oryginalny program korekcyjny nie działa. Czy jest to tylko i wyłącznie za mała częstość korekcji? Czy może działałby, gdyby wszystkie mapy były ustawione dobrze pod (a) górę 1.2 MPI i (b) większe wtryski?

I tak jeszcze komentarzem do krótkiej dyskusji którą mieliśmy w poprzednim odcinku: po przestudiowaniu programu od 1.2 MPI jestem niemal pewien (dam se obciąć paznokieć), że wyliczony czas wtrysku można globalnie przeskalować przy uzyciu jednej lub dwóch map (zależnie od tego jak bardzo chcesz przeskalować i w którą stronę). Również, w programie 1.2 MPI prawie zawsze czas wtrysku jest liniowo zależny od wartość MAP sensora plus/minus korekcje. W momencie kiedy wstawiamy MAP o zakresie 2.5 bara czasy wtrysku autmatycznie skracają się o 2.36 raza (2.5/1.05 - 1.05 zakres normalnego MAPa). No prawie , są tam jeszcze małe szczegóły. Ale nie wiem jak to jest programie 1.1 SPI. Dla mnie program 1.2MPI ma tą dużą zaletę, że wszystkie najważniejsze mapy mają rozmiar 16x16 MAPxRPM, a nie 12x16 w 1.1SPI.

chyba wypadało by do Ciebie pisać teraz binarnie

1000111100100011100011111101010000001010111010111

mordunia, czy ty piszesz sam interfejs dla siebie? nie chciałbyś skozystać z jakiegoś programu freware i napisać piekną "dll" kę? czy wilisz zrobic program kiedyś, skompilować i sprzedawać za dobre $$???

> 1. Czy to jest cały czas program od 1.1 SPI, który przystosowujesz do

> pracy z górą 1.2 MPI (turbo plus wtryski)? Czy stosujesz też

> "większy" MAP sensor? Pytam, bo sam ostatnio mocniej się

> wgłębiam w program od 1.2 MPI i widzę, że właśnie MAP sensor

> będzie największym problemem (ale nie nie do pokonania ). No a

> ewidentnie jest niezbędny.

Własnie chyba o tym jeszcze nie pisałem, na początku było cały czas o 1.1, ale już od dłuższego czasu "przesiadłem" się na 1.2 MPI , głównie z tego powodu że ma on sporo wolnego RAM-u.

Co chociażby wykorzystuje i w tym momencie - ten krotki program znajduje się w ramie i dzięki temu nie trzeba programować eeproma tylko wysyłam go przez rs-a.

Oczywiście do większego ciśnienia potrzebny jest MAP o rozsądnym zakresie.

> 2. Ten programik diagnostyczny to domniemam Twoje dzieło? Jakaś

> szansa na podzielenie się? Ja na razie mam tylko ten taki z ff

> co działa tylko w trybie tekstowym. Działa spoko, ale mi dużo

> rzeczy w nim brakuje, a własnego mi się nie chce (czytaj nie mam

> na razie czasu) pisać.

Nad swoim pracuje dopiero, niestety zamiast skończyć w miesiąc to robię coś raz na miesiąc . Na tym etapie prac stworzenie wersji instalacyjnej trwało by z tydzień.

> 3. Mógłbyś trochę bardziej spróbować wyjaśnić dlaczego oryginalny

> program korekcyjny nie działa. Czy jest to tylko i wyłącznie za

> mała częstość korekcji? Czy może działałby, gdyby wszystkie mapy

> były ustawione dobrze pod (a) górę 1.2 MPI i (b) większe

> wtryski?

No właśnie problem jest taki ( w moim przypadku ) pomimo takiego ustawienia map, że auto praktycznie jeździ cały czas przelane ( jak na 2 screenie ) to przy depnięciu na maksymalnym ciśnieniu brakuje wtedy paliwa. Wtryski mają jeszcze zapas, ale no właśnie komp nie wyrabia. Wydaje mi się że napewno każde auto da się tak ustawić żeby działało ale napewno nigdy nie będzie to optymalne.

Skoro mamy do dyspozycji sonde lambda to trzeba z niej maksymalnie korzystać.

Problem jest dosyć złożony bo chociaż na teorii mechaniki nie znam się za bardzo, ale póki co na ten temat dowiedziałem się co nieco od osób kompetentnych - prosty przykład auto można wystroić na prostej drodze tak żeby nawet bez korekcji mniej więcej było ok, ale wystarczy zmienić obciążenie np. jechać pod dużą górkę i już będzie wtedy problem.

Nie wiem, może popełniam błąd w założeniach, ale wygląda na to że fabryczne oprogramowanie traktuje sonde jako jedynie pomocniczy instrument. A ja chce zrobić odwrotnie - oprzeć wszystko na tym odczycie tak żeby tak naprawdę mapy nie miały dużego wpływu na działanie.

Taki układ samostrojący się. Oczywiście zakładam że w trakcie prób skrystalizuje się jakiś pomysł na sensowną auto-modyfikacje map w miejscach gdzie za bardzo trzeba korygować czas wtrysku.

Prawdę mówiąc już były takie próby, ale jednak stwierdziłem że sonda lambda będzie lepszym rozwiązaniem. Co zresztą widać - malutkim programikiem można w miarę skutecznie zastąpić oryginalne oprogramowanie.

> I tak jeszcze komentarzem do krótkiej dyskusji którą mieliśmy w

> poprzednim odcinku: po przestudiowaniu programu od 1.2 MPI

> jestem niemal pewien (dam se obciąć paznokieć), że wyliczony

> czas wtrysku można globalnie przeskalować przy uzyciu jednej lub

> dwóch map (zależnie od tego jak bardzo chcesz przeskalować i w

> którą stronę). Również, w programie 1.2 MPI prawie zawsze czas

> wtrysku jest liniowo zależny od wartość MAP sensora plus/minus

> korekcje. W momencie kiedy wstawiamy MAP o zakresie 2.5 bara

> czasy wtrysku autmatycznie skracają się o 2.36 raza (2.5/1.05 -

> 1.05 zakres normalnego MAPa). No prawie , są tam jeszcze małe

> szczegóły. Ale nie wiem jak to jest programie 1.1 SPI. Dla mnie

> program 1.2MPI ma tą dużą zaletę, że wszystkie najważniejsze

> mapy mają rozmiar 16x16 MAPxRPM, a nie 12x16 w 1.1SPI.

No.... ja bym się raczej o nic nie zakładał, funkcja licząca czas wtrysku jest bardzo złożona i nie jest napewno zależna jedynie od ciśnienia - można by o tym naprawdę dużo napisać. W grę wchodzą również takie czynniki jak temperatura ,właśnie sonda lambda, a nawet aktualny tryb jazdy - np. jak wciskamy gaz to przez chwile mamy doładowanie czasu wtrysku o wartość zależną od różnicy ciśnienia przed i po wciśnięciu.

W przypadku turbo największym problemem jest charakterystyka przyrostu ciśnienia - oprogramowanie często się gubi wręcz zakłada awarie czujników, ponieważ w N/A jest ścisła zależność miedzy obrotami,ciśnieniem, i poziomem otwarcia przepustnicy. Są to z pewnością zależności liniowe i na tej zależności oparte jest całe oprogramowanie.

PS. Uzupełniłem trochę opis wykresu - i czekam na pomysły jak usprawnić algorytm w przypadku przyspieszania .

> chyba wypadało by do Ciebie pisać teraz binarnie

> 1000111100100011100011111101010000001010111010111

> mordunia, czy ty piszesz sam interfejs dla siebie? nie chciałbyś

> skozystać z jakiegoś programu freware i napisać piekną "dll" kę?

> czy wilisz zrobic program kiedyś, skompilować i sprzedawać za

> dobre $$???

Tak program pisze w sumie tylko do użytku własnego o jego rozpowszechnianiu wogóle nie myślałem, dlatego to wszystko powstaje w takich bólach. Dll raczej się nie sprawdzi bo w moim programie oprócz możliwości zmiany map potrzebuje właśnie modułów do wykresów i jeszcze kilka przydatnych dodatków.

Moduł modyfikujący mapy już mam od dawna, jednak stwierdziłem że nie do końca on jest taki przydatny, w sumie właśnie stąd ten temat - po co robić coś samemu jeżeli ECU może zrobić to automatycznie i o wiele dokładniej. ( Mam taką przynajmniej nadzieje ).

Nie wiem czy moje rozumowanie jest do końca dobre ale wydaje mi się, że o tym czy wciskamy gaz delikatnie czy mocno komp bierze informacje z mapsensora. W N/A będzie się to spisywało ale w turbo jest pewna bezwładność turbiny i zanim zmieni się wartość ciśnienia to mija jakiś czas. Może warto by było zbierać informacje z aktualnego położenia przepustnicy?? jeśli kąt otwarcia przepustnicy zmieni się znacznie w krótkim czasie to będzie znak, że pałujemy, natomiast jeśli zmiana kąta w czasie będzie mała to będzie oznaczało że delikatnie wciskamy gaz.

Teraz jeśli byśmy mieli informacje o aktualny położeniu przepustnicy i ciśnienia to będziemy wiedzieli co dokładnie dzieje się z autem. Jeśli zmieni się wartość ciśnienia w kolektorze bez zmian położenia przepustnicy to będzie znak, że zwiększyło się obciążenie (np. podjazd pod górę) a jeśli szybko zmienia się położenie przepustnicy to będzie znak że kierowca pałuje.

Mam nadzieję że moja wypowiedź jest zrozumiała i może coś pomoże.

> No właśnie problem jest taki ( w moim przypadku ) pomimo takiego

> ustawienia map, że auto praktycznie jeździ cały czas przelane (

> jak na 2 screenie ) to przy depnięciu na maksymalnym ciśnieniu

> brakuje wtedy paliwa. Wtryski mają jeszcze zapas, ale no właśnie

> komp nie wyrabia. Wydaje mi się że napewno każde auto da się tak

> ustawić żeby działało ale napewno nigdy nie będzie to optymalne.

> Skoro mamy do dyspozycji sonde lambda to trzeba z niej maksymalnie

> korzystać.

No, ja się nie znam aż tak, ale z tego co słyszałem, to do takich zabaw to lambda szerokopasmowa, która powie Ci ile dokładnie jest przelane/niedolane.

> Problem jest dosyć złożony bo chociaż na teorii mechaniki nie znam

> się za bardzo, ale póki co na ten temat dowiedziałem się co

> nieco od osób kompetentnych - prosty przykład auto można

> wystroić na prostej drodze tak żeby nawet bez korekcji mniej

> więcej było ok, ale wystarczy zmienić obciążenie np. jechać pod

> dużą górkę i już będzie wtedy problem.

W tym tkwi sedno. Wydaje mi się, że ten komp bierze na takie rzeczy poprawkę, znaczy się, sprawdza jak ma się otwarcie przepustnicy do MAPa i obrotów i wtedy mniej więcej wie, czy jedzie z górki, czy pod, czy z przyczepą czy bez

> Nie wiem, może popełniam błąd w założeniach, ale wygląda na to że

> fabryczne oprogramowanie traktuje sonde jako jedynie pomocniczy

> instrument.

No właśnie, bo jest wąskopasmowa.

> No.... ja bym się raczej o nic nie zakładał, funkcja licząca czas

> wtrysku jest bardzo złożona i nie jest napewno zależna jedynie

> od ciśnienia - można by o tym naprawdę dużo napisać. W grę

> wchodzą również takie czynniki jak temperatura ,właśnie sonda

> lambda, a nawet aktualny tryb jazdy - np. jak wciskamy gaz to

> przez chwile mamy doładowanie czasu wtrysku o wartość zależną od

> różnicy ciśnienia przed i po wciśnięciu.

Nie powiedziałem, że zależy tylko od ciśnienia. Ale ciśnienie jest pierwszą bazą do wyliczeń, reszta jest dodawana procentowo. Także koniec końców czas wtrysku zależy prawie że liniowo od MAP sensora. A w każdym razie tak jak napisałem wcześniej: zmienisz charakterystkykę MAPa - czasy wtrysku zmienią się odpowiedni liniowo. Tak, żeby to poprzeć, to z tego co widzę to główna mapa wtrysku 16x16 jest tylko mapą korekcyjną wyliczenia opartego najpierw na MAPie. A funkja licząca paliwko jest faktycznie skomplikowana, ale ma jedną zaletę z tego co widzę - jest bardzo "sekwencyjna". Znaczy się schmat blokowy jest długi w pionie i wąski, przez co łatwy do analizy

> W przypadku turbo największym problemem jest charakterystyka

> przyrostu ciśnienia - oprogramowanie często się gubi wręcz

> zakłada awarie czujników,

Dlatego napisałem, że największym problemem jest przestrojenie kompa na inny MAP.

> w sumie właśnie stąd ten temat

> - po co robić coś samemu jeżeli ECU może zrobić to automatycznie

> i o wiele dokładniej. ( Mam taką przynajmniej nadzieje ).

Wydaje mi się że sonda wąskopasmowa nie da rady ogarnąć tego tak dobrze jak wymyśliłeś, raczej szerokopasmowa by się przydała do tego.

Widzę jeszcze jeden problem licząc tylko z sondy jak przyciśniesz to on i tak będzie dążył do 14.7 (umownie) a przydało by się czasami więcej.

Sądzę że program powinien robić tylko małą korektę względem sondy przy normalnej jeździe, nie powinien robić korekty przy pełnym otwarciu przepustnicy i na wolnych obrotach.

Wielkość korekty powinna być +- 10 % ale żeby można było tą wartość bez problemu zmieniać.

Zrobiłeś interfejs przez SPI bo kiedyś było poruszone o tych pinach przy motce ale nigdy odpowiedzi nie było?

Jeszcze jedna ciekawostka którą obiecałem wstawić, czyli główny grzech przy dużym ciśnieniu - brak paliwa. Tym bardziej że tutaj widać jasno że mechanicznie wtryski mają odpowiedni zapas wydajności, jedyny problem jest z czasem ich otwarcia.

Jak sobie na spokojnie obejrzałem wykres, to w sumie wydaje mi się to trochę takie ciekawe jak można z niego wyczytać co działo się w danym momencie z autem. Proponuje bez czytania objaśnień spróbować zasymulować sobie działania kierownika

Legenda do wykresu

Niebieskie - lambda ( na dole za mało paliwa )

Różowe - czas wtrysku

Bladoczerwone - ciśnienie ( wartość wyliczonych indeksów z odczytu napięcia )

Zielone - obroty ( tak samo jak map )

Szare/bladozielone - położenie przepustnicy

Parę słów komentarza, główny powód wstawienia wykresu występuje w miejscach 2 i 8 - chwilę wcześniej ( 1 i 7 ) został wciśnięty gaz do oporu , jak widać czas wtrysku został zwiększony ale został zablokowany na parę sekund jazdy z pełnym ciśnieniem. Dopiero od 2 i 8 korekcja działa prawidłowo i jest wystarczająco dużo paliwa.

Jest to powtarzalne działanie tutaj próba po próbie, wcześniej było to samo, a więcej już prób przeprowadzać nie zamierzam . "Odblokowanie" wtrysku wydaje się być bez żadnej przyczyny - nie odpuszczona przepustnica i stałe ciśnienie w dolocie. Wygląda jakby został użyty jakiś licznik. ( Przed 3 przepustnica została trochę odpuszczona ale to już po odblokowaniu wtrysku )

Co do zagadki to teraz wyjaśnienie, pomiar był robiony dosyć dawno więc też miałem problem z odtworzeniem tamtej sytuacji.

Po (3) odpuszczony gaz i wrzucenie 5 biegu (4) a następnie hamowanie silnikiem aż do 6 - widać odcięcie paliwa po wykresie lambdy ( brak paliwa w mieszance ). Poziom TPS zaznaczony odpowiada zamkniętej przepustnicy. Czas wtrysku jak widać jest "zamrożony" ale nie zerowany jednak wtryskiwacze nie pracują.

W (5) ładnie widać współzależność parametrów - lekkie otwarcie przepustnicy = zwiększenie ciśnienia = zubożenie mieszanki.

W punkcie numer (6) wrzucenie na luz , a następnie 4-rki i za chwilę ponowne pełne przyspieszenie (7).

Wykres ciśnienia pokazuje jak EBC próbuje unormować ciśnienie doładowania na stałym poziomie (9), najpierw mocny "strzał" ciśnienia potem mocniejsze prewencyjne przyhamowanie turbiny i potem już tylko delikatna korekcja.

Znaczy się co? Że robiłeś brum brum brum... Tak mnie się w każdym razie wydaje...

Teraz jeszcze parę słów na temat przewodni czyli sposobów korekcji składu mieszaki aby otrzymać optymalne osiągi samochodu. Padło już parę propozycji, dodam jeszcze swoje spostrzeżenia.

Ogólnie problem można podzielić na trzy części :

(a) "stabilną" jazde - tzn ze stałą prędkością. Wydaj mi się że jest to najlepszy przypadek kiedy można ustawić auto za pomocą map i wymaga jedynie niewielkiej korekty za pomocą sondy lambda.

Wynika to z faktu że nie ma w tym wypadku problemu z brakiem znajomości obciążenia ponieważ ładnie rozwiązuje to główna mapa korekcji wtrysku RPM x MAP.

Zakładając że jedziemy ze stałą prędkością jesteśmy w punkcie x ( stałe obroty i ciśnienie ). Jeżeli zmieni się obciążenie zaczną spadać obroty ( kierunek przeciwny do zielonej strzałki ) , jeżeli chcemy zachować prędkość musimy bardziej uchylić przepustnice a wtedy zmieni się ciśnienie ( w stronę różową ) czyli znowu będziemy jechać ze stałymi obrotami ale z większą ilością powietrza.

W trakcie jazdy po normalnej drodze powinny być używane komórki w linii czerwonej czyli większa prędkość = większe obroty z większą ilością powietrza. Jedynie w zależności od obciążenia ( choćby bieg na którym jedziemy ) będą to linie równoległe do czerwonej. Przy takim założeniu jesteśmy w stanie przygotować tak mapę aby otrzymać zawsze prawidłową mieszankę. Problem dopiero pojawi się jeżeli wykres wyjdzie poza tablice, wtedy nie jesteśmy w stanie ustalić rożnej korekcji dla zmieniających się warunków

Trochę to zawiłe nie wiem czy wyjaśniłem odpowiednio - przykład jadać np. jak wcześniej napisane z przyczepą musimy trzymać gaz mocno wciśnięty żeby jechać 100 km/h. Czyli sytuacja nietypowa bo duże ciśnienie a małe obroty zwiększamy ciśnienie aby przyspieszyć i dochodzimy do maksymalnego a potem zwiększają się tylko obroty. ( wykres niebieski ).

A teraz jadąc bez balastu , aby jechać 100 km/h będziemy potrzebować mniej powietrza przy takich samych obrotach a jak wciśniemy gaz maksymalnie to będziemy używać praktycznie tych samych komórek co wcześniej, ( taka sama korekcja ) a skrajnie różne obciążenia.

Niestety położenie przepustnicy nic nam nie powie o obciążeniu bo praktycznie jest ono tożsame z ciśnieniem w kolektorze.

Jakby zastanowić się chociażby nad podanym przykładem to jedyny pomysł jaki przychodzi mi do głowy to pomiar przyspieszenia - bo to napewno zdecydowanie by się różniło. Tylko tak trochę wygląda to na wróżenie z fusów i raczej nie będzie miało sensownej dokładności. Mini hamowania programowa to nie może być dobry pomysl Ale prawdę mówiąc nie mam pomysłu jak inaczej można by było rozróżnić obciążenie, pozostaje jedynie jednak korekcja sondą lambda.

(b) Problem drugi to sytuacja "niestabilnej" jazdy, czyli gwałtowne zmiany jak spore uchylenie przepustnicy, mapa korekcyjna zupełnie się wtedy nie sprawdza bo będą brane wartości jak dla zupełnie innego trybu jazdy - najpierw duży ruch po osi różowej a potem jedynie po zielonej. Dopóki auto nie osiągnie docelowej prędkości dla zmienionego ciśnienia na pewno nie da się za pomocą tej mapy ustalić idealnie mieszanki.

Jak zostało wcześniej zaproponowane w tym konkretnym przypadku nie powinno się używać w ogóle korekcji sondą. Na pewno ten konkretny przypadek wymaga lekkiego nadmiaru paliwa tylko w jaki sposób go zagwarantować ? Wiadomo że za duże przelanie również nie jest za dobre.

© I problem bardzo zbliżony do (b)

Przykładem może być próba przyspieszenia od 1000 do 6000 obr, na różnych biegach - przepustnica uchylona maksymalnie = maksymalne ciśnienie tylko zwiększające się obroty czyli wszystkie wartości brane z map używających tych parametrów (RPM x MAP) będą takie same bez względu czy będziemy jechać od 20km/h do 80 km/h czy 80 km/h do 160 km/h a jednak przez opory powietrza obciążenie będzie zupełnie inne. Czyli ustawić tak żeby nie brakowało przy max osiągalnym obciążeniu, ale wtedy auto nie będzie maksymalnie efektywne ( przelanie przy mniejszym obciążeniu ).

Pomimo tego wydaje się jednak że praktykowany jest sposób bez sondy, chociażby właśnie w przypadku tego ECU, do wyliczania czasu brana jest wartość neutralna tak jakby AFR był cały czas optymalny. Nie bardzo mnie to jednak przekonuje, nie mogę znaleźć powodów dyskwalifikująych taką metodę a korzyśći według mnie są na pewno.

( Chociażby opisywany wcześniej przypadek, jak dla mnie oprogramowanie nie powinno dopuszczać sytuacji kiedy brakuje paliwa szczególnie przy dużym ciśnieniu, chyba że w N/A nie jest to takie groźne )

I jeszcze na koniec jak zostało wcześniej napisane, oczywiste jest że dużo lepiej sprawdzała by się sonda szerokopasmowa.

Ale sytuacja nie jest beznadziejna - tutaj taki przykład i pytanie ( czy średnie AFR jest takie samo na wykresie po lewej i po prawej ).

I jeszcze mała dygresja - bez względu na rodzaj sondy ( dla 1lambda obie mają taką samą dokładność ) a pomimo tego chociażby na wolnych obrotach niemożliwe jest uzyskanie ciągłego idealnego AFR,

czyli wydaje mi się że technika PWM może zdać egzamin napewno nie tak dobrze jak sonda szerokopasmowa ale można uzyskać w miarę stabilne trochę większe AFR. W końcu punkt oscylacji nie musi być wokół punktu 1 lambda.

> Zrobiłeś interfejs przez SPI bo kiedyś było poruszone o tych pinach

> przy motce ale nigdy odpowiedzi nie było?

Ponieważ nie było więcej pytań to uznałem że temat jest wyjaśniony - SPI fabrycznie jest ustawione na zrzucanie cyklicznie wybranych parametrów tj. RPM,MAP czyli tych samych co euroscanem, ale robi to automatycznie i z dużo większą częstotliwością - przynajmniej tak wynika z kodu bo tego nie sprawdzałem.

Komunikacja odbywa się po RS-sie tylko z zupełnie zmienionym oprogramowanie komunikacyjnym.

W sumie daje on tylko podstawowe możliwości jak zapis / odczyt dowolnej komórki pamięci, lub zrzut zdefiniowanych wcześniej sekwencji komórek ( co jest dużo szybsze w przypadku tworzenia wykresów ), tak jak to jest przy SPI.

Strasznie duża ilość informacji do przetworzenia na raz. Dodam od siebie, że dla mnie z programu widać, że przy jeździe normalnej (a) komp faktycznie nie używa położenia przepustnicy. Sprawdza natomiast, tak mi się wydaje, różnicę ciśnień, obecnego i poprzedniego, czyli patrzy chyba, jak dobrze silnik sobie radzi? I dopowiednio koryguje paliwo. Do tego uwzględnia tonę innych parametrów. Bez zaglądania w kod, z tego co pamiętam w przypadku (b) gwałtownych zmian występuje "proste" wyliczenie na podstawie obecnych obrotów, ciśnienia i wahań przepustnicy (znaczy się jak bardzo chcielibyśmy przyspieszyć/zwolnić). Nic więcej nie jest brane pod uwagę. Ale w przypadek (b) się jeszcze nie zagłębiałem.

W każdym razie ewidentne dla mnie jest, że przy wymuszonym doładowaniu musisz mieć szerszy MAP sensor, bo to on jest bazą do dawki paliwa. Bez tego wszystko to siądzie, chyba, że przepiszesz cały program, tak jak próbujesz (i chwała Ci za to ). I na to pytanie mi nie odpowiedziałeś, czy używasz "większego" MAPa?

Weź jeszcze też pod uwagę aspekt wydajności kompa, bo chyba tak na prawdę o to się wszystko rozbija. Możesz napisać oczywiście mega program, który będzie korygował dynamicznie cały czas na podstawie wszystkich czujników. Ale, np. przy obrotach 6000 jeden cykl pracy wynosi 10ms (komp nie otwiera wtryskiwaczy na więcej niż jeden obrót, to też już zauważyłem). W czasie tych 10ms musisz zrobić *wszystko* (włączając obsługę przerwań itd itp) co jest Ci potrzebne do wyliczenia nowej dawki paliwa. Stąd wydaje mi się taki a nie inny algorytm w tych kompach - dużo danych wyliczonych eksperymentalnie pod dany silnik i mało obliczeń.

> Dodam od

> siebie, że dla mnie z programu widać, że przy jeździe normalnej

> (a) komp faktycznie nie używa położenia przepustnicy.

Właśnie se przypomniałem, że jest tam gdzieś odwołanie do procedury, która być może jednak używa położenia przypustnicy do policzenia czegoś. Ale wpływ tego jest chyba minimalny, muszę w każdym razie zajrzeć jeszcze raz, żeby wiedzieć na pewno.