> Dziś uruchomiłem sobe freewareowy ComLite32 do śledzenia transmisji.

> Nie miałem zbyt dużo czasu więc tylko spoglądnąłem co tam ten

> AB-COM wysyła. Trochę dużo tych danych. Sądziłem że jak sobie

> ustawię tylko jeden parametr to wyczaję pojedyncze ramki ale nie

> będzie to takie proste bo zasuwają tam całe kilobajty. Może

> prościej gdzieś z netu ściągnąć jakiś opis protokołu? O ile jest

> : opis(

Problem polega na tym, że przy pomocy transmisji COM jest niejako analogowo emulowany inny protokół. Dlatego transmisja wygląda na dość śmieciową i dlatego nie działają przejściówki na USB (niezmiernie ważne są zależności czasowe które w przypadku przejściówki są niemożliwe do spełnienia)

Mam gdzieś opis protokołu, ale... po rusku

Po rusku za wolno mi idize czytanie żeby przez to przebrnąć. Jak kto chce to mogę poprzesyłać.

> Są tam dwa rezystorki i sprawa przełączania ogólnie jest prosta bo

> zawsze można to zrobić przełączane na tranzystorach aby było jak

> najszybciej.

ale w wersji 91/95 jest opór i zworka (0 ohm)

> No to by trzeba było sprawdzić. Mam OpelScannera ale nie widziałem

> nigdzie jakiejś informacji jak jest ten korektor ustawiony.

chyba nie dostrzegłeś

dla mojego c18nz pokazuje ustawienie:

> ale w wersji 91/95 jest opór i zworka (0 ohm)

> chyba nie dostrzegłeś

> dla mojego c18nz pokazuje ustawienie:

A jest już widzę

Muszę u mnie popatrzeć.

> Problem polega na tym, że przy pomocy transmisji COM jest niejako

> analogowo emulowany inny protokół. Dlatego transmisja wygląda na

> dość śmieciową i dlatego nie działają przejściówki na USB

> (niezmiernie ważne są zależności czasowe które w przypadku

> przejściówki są niemożliwe do spełnienia)

> Mam gdzieś opis protokołu, ale... po rusku

> Po rusku za wolno mi idize czytanie żeby przez to przebrnąć. Jak kto

> chce to mogę poprzesyłać.

Dziwne ale w podglądzie normalnie widziałem dane silnika te, które wyświetlają się w pierwszym oknie. Gdyby to była jakaś taka emulacja jak piszesz to nie powinienem zobaczyć w podglądzie ASCI tych literek. Jeseś pewny, że ta emulacja dotyczy komunikacji ze sterownikiem silnika a nie któryś inych urządzeń? Ja cyrylicę jeszcze chyba przetrawię, dawaj ten płotokół. Adres wysłałem na priva

> Dziwne ale w podglądzie normalnie widziałem dane silnika te, które

> wyświetlają się w pierwszym oknie. Gdyby to była jakaś taka

> emulacja jak piszesz to nie powinienem zobaczyć w podglądzie

> ASCI tych literek.

Podglądałem transmisję akurat z tempomatem. Rzuciłem okiem, stwierdziłem "śmietnik" i więcej nie patrzałem. Ale ciekawe to co mówisz, to nieco przybliża perspektywę "loggera"

> Podglądałem transmisję akurat z tempomatem. Rzuciłem okiem,

> stwierdziłem "śmietnik" i więcej nie patrzałem. Ale ciekawe to

> co mówisz, to nieco przybliża perspektywę "loggera"

Skrzystałem że sprawdzałem swój interfejs bo oddałem pożyczony. Co prawda też rzuciłem tyko okiem bo do pracy było śpieszno ale dałbym sobie głowę uciąć że w oknie ComLit'a znaki przekodowane na ASCI układały się w sensowne napisy. Sprawdzę to jeszcze raz ale dopiero późnym wieczorem. W każdym razie gdybyś podesłał ten ruski opis protokołu może on coś badziej sprawę rozjaśni.

Więc sie wziąłem i posprawdzałem co z tym korektorem jest. No i tak jak koledzy pisali ECU sobie sprawdza wartość na tym złączu po załączeniu stacyjki a później czy ten korektor się wyjmie czy zamieni to w ECU cały czas zapisana jest wartość którą sprawdził na początku. Tyle Sprawdziłem OpelScannerem przy załączonej stacyjce i grzebiąc przy korektorze. Później dopuściłem się testu przy odpalonym silniku i w tym przypadku ECU w ogóle nie zareagował na zmiany rezystancji na tym złączu. Zwarcie tego złącza zaowocowało wskazaniem przez OpelScannera 0 Ohm paliwo 91 oktanowe czyli z braku odpowiedniego paliwka mogę lać 91 i na kawałku drucika się pojeździ. Sprawdzałem też ile ECU potrzebuje czasu na zresetowanie czyli po prostu wyłączałem stacyjkę. No i wartość na złączu korektora zmieniała się dopiero po dłuższym wyłączeniu stacyjki więc żadna próba resetu nie wchodzi w grę. Zastanawia mnie praca sondy Lambda co prawda oscyluje ale jakoś tak nie za równo. Podpinałem też vectrę B i Corsę B i w tamtych silniczkach sonda oscylowała bardzo ładnie Nie wiem czy czasem jej nie wymienić zresztą wrzucę parę screanów to może ktoś coś podpowie

Nie jest tak źle trochę zaszumiony sygnał może zakłóceniami z WN ale działa poprawnie. Nie wydaje mi się aby to była wina sondy, może TTTM.

Więc spojrzałem dzis jeszcze raz i przyglądnąłem się dokładniej. Jestem pewny że to jest normalny 8 bitowy protokół komunikacyjny bazujący na RS232. Na screenie widać start danych. Na czerwono to znaki wysyłane przez program , niebieskie to zwracane przez ECU.

Przy czym oczywiście po każdym bajcie z AB-COMa, ComLite rejestrował echo - oczywiste gdyż działamy jako half-duplex po jednej wspólnej linii. Program weryfikuje podłączenie wysyłając "T". Sterownik zwraca kupę zer. Potem jedzie już do sterownika ramka komendy na którą otrzymujemy odpowiedź w której jest zawarty m in typ ECU, numer silnika (ten zaczynający sie od W0L0TG...) typ silnika Z16XEP itp... Potem jakies nastepne ramki. W Bloki pomiarowe niezależnie co miałem ustawione chodziła w kółko ramka:

Program - > 80 11 F1 02 21 01 A6 na którą ECU odpowiadał 109 bajtami danych. Wydaje mi się że tam zawarte są wszystkie parametry jakie odczytujemy w okienkach. Czyli nie ma raczej osobnych komend do odczytu pojedynczych parametrów tylko wjeżdża całość. No i teraz nie takie proste wyłuskać co jest co . Bez opisu protokołu i lub chocby opisu pól zwracanych przez ECu ani rusz

> Bez opisu

> protokołu i lub chocby opisu pól zwracanych przez ECu ani rusz

po pierwsze gratuluję Kolegom postępów w drążeniu tematu

nie bardzo mam czas przeglądać teraz www, ale kiedyś znalazłem parę

ciekawych rzeczy w linkach na tej stronce: http://www.andywhittaker.com/

polecam zwłaszcza linki w pod hasłem "Other GM ECU sites" na stronie

http://andywhittaker.com/ECU/GMACDelcoP4/tabid/67/Default.aspx

mam nadzieję, że coś tam pożytecznego znajdziecie

Dzięki może się przyda. Przyglądnę się temu po świętach bo na razie działam tylko na wyjazdowym 4 calowym PPC

> po pierwsze gratuluję Kolegom postępów w drążeniu tematu

> nie bardzo mam czas przeglądać teraz www, ale kiedyś znalazłem parę

> ciekawych rzeczy w linkach na tej stronce:

> http://www.andywhittaker.com/

> polecam zwłaszcza linki w pod hasłem "Other GM ECU sites" na stronie

> http://andywhittaker.com/ECU/GMACDelcoP4/tabid/67/Default.aspx

> mam nadzieję, że coś tam pożytecznego znajdziecie

Tez to przejrzalem i myslalem, ze bedzie cos Free, a tam co chwila powalajace na kolana ceny

Wcale głupie nie jest. Zaintersował mnie głównie taki opis protokołu. Gość pisze że doszedł do tego metodą prób i błędów bo nigdzie oficjalnie takich danych nie ma. Jest troszkę inny choć podobieństwo jakieś jest. Taki opis mieć dla naszych Asteriksów i można "góry przenosić".

> Wcale głupie nie jest. Zaintersował mnie głównie taki opis

> protokołu. Gość pisze że doszedł do tego metodą prób i błędów bo

> nigdzie oficjalnie takich danych nie ma. Jest troszkę inny choć

> podobieństwo jakieś jest. Taki opis mieć dla naszych Asteriksów

> i można "góry przenosić".

właśnie o to mi chodziło

nie znalazłem tylko na szybko w linkach, które podałem wyżej

przeszperam jeszcze Favoritsy, gdzieś miałem tego więcej

Przeglądnąłem i przetrawiłem conieco. Protokół z tych linków od azji to nie jest protokół zawarty w naszych opelkach. Jest inny. Bartek_j nie znalazł tej rosyjskojęzycznej dokumentacji ale przesłał mi normy ISO protokołu KP2000 na której bazuje komunikacja z ECU. Porównywałem i to jest to. Tzn dokumentacja ogólnie nakreśla normy wg których przebiega komunikacja natomiast konkretne działanie zależy już od implementacji danego ECU. Ramki się zgadzają, zgadza się suma kontrolna CS, natomiast nadal nie wiadomo jak zaszyte są w danych pola poszczególnych parametrów.

Poniżej ramka, która odpowiada za wszystkie dane jakie są odczytaywane przez AB-COMa.

komenda z ABCOMa = 80 11 F1 02 21 01 A6

poszczególne bajty

80 - physical addressing

11- Target address byte (11 to silnik)

F1 - Source address byte

02 - Additional length byte (ilość kolejnych dodatkowych danych, tu 2 kolejne bajty)

21 - readDataByLocalIdentifier

01 - recordLocalIdentifier (czyli rekord nr 1)

A6 - CS (suma kontrolna która jest sumą wszystkich poprzedzających bajtów modulo 256 czyli obcięta do bajta)

odpowiedź ze sterownika

80 F1 11 68 61 01 ... 102 bajty danych i 57 jako CS

80 - physical addressing

F1 - Source address byte

11- Target address byte

68 - nie wiem co to ???

61 - Positive Response Message

01 -ecordLocalIdentifier (czyli rekord nr 1 lub od rekordu 1)

...

response code

...

57 CS (suma kontrolna )

Mogę się mylić w tych moich dedukcjach.

I cóż nadal nie wiemy jak wydobyć parametry . Tzn bawiąc się w hackera można by próbować rozgryźć co jest co ale trudne to i trzeba mieć duuużo czasu i samozaparcia. Lepiej może gdzieś próbować znaleźć taką informację.

> odpowiedź ze sterownika

> 80 F1 11 68 61 01 ... 102 bajty danych i 57 jako CS

> 80 - physical addressing

> F1 - Source address byte

> 11- Target address byte

> 68 - nie wiem co to ???

> 61 - Positive Response Message

> 01 -ecordLocalIdentifier (czyli rekord nr 1 lub od rekordu 1)

> ...

> response code

> ...

> 57 CS (suma kontrolna )

te "68 - nie wiem co to ???", to pewnie ilość bajtów danych między 68h i CS, czyli 2 (61h i 01h)+102=104 czyli 68h.

Sprawdź dalej, czy to nie zbieg okoliczności.

PS. Nie musisz, zgadza się z tym ciągiem znaków, co wyżej podałeś, zawierającym VIN...

Pozdr.

> te "68 - nie wiem co to ???", to pewnie ilość bajtów danych między

> 68h i CS, czyli 2 (61h i 01h)+102=104 czyli 68h.

> Pozdr.

> Co ciekawe na stronie Toyoty rzeczywiście jako zalecane paliwo podają

> "bezołowiowa 95, lub wyżej"

> Natomiast na stronie Opla nic nie ma . Trzeba ściągnąć katalog, żeby

> się dowiedzieć, że zalecanym paliwem jest "benzyna"

z instrukcji:

a z tego można by wznioskować że zalanie 98 da niewiele a do uzyskania lepszego momentu obrotowego dla wyższych LO trzeba jakoś zaingerować pośrednio w kąt zapłonu

edit

nie tak naprawde to nic nie rozumiem z pkt 2 wynika że kąt adaptuje sie do lepszego paliwa LO=98, ale zalecają LO=95

rozczaiłem organoleptycznie pola danych w protokole Zabieram sie za program do logowania parametrów. Coraz bardziej mnie to wciąga

> rozczaiłem organoleptycznie pola danych w protokole Zabieram sie

> za program do logowania parametrów. Coraz bardziej mnie to

> wciąga

Gratuluję

A opiszesz co i jak ?

Domyślam się że doszedłeś zmieniając to i owo w "warunkach zewnetrznych" i patrząc co się zmienia w protokole. Potem "tylko" jeszcze wyczaić przelicznik i w domu..

Heh, znam ta satysfakcję, nic tak nie bawi jak drobne "hakerstwo"

Oczywiście oszukałem się jak idiota po sieci aby zdobyć jakieś info. Bez pełnego sukcesu. Coś tam było ale niejasne , niedopowiedziane, niedopisane, dziwne, podejrzane . Niestety wiedza tajemna, ludzie i serwisy na tym zarabiają wiec nikt się tym nie podzieli, choć żadnych praw autorskich w tym nie ma.

Zbudowałem sobie w końcu na PC-cie taki programik emulator mojego ECU (oczywiście emulator w ograniczonym sensie). Połączyłem ze sobą dwa interfejsy , swój i kolegi, zasiliłem z zasilacza, i połączyłem w domu PCta z laptopem. PC-t udawał ECU odpowiadał na ramki AB-COMa danymi zerżniętymi ComLitem w samochodzie. Przynajmniej robota komfortowa bo w domciu w ciepłych kapciach . Zmieniałem sobie poszczególne bajty danych i obserwowałem które się zmieniaja w ABCOMie. No i wiekszość tych ważniejszych dla mnie jest wyczajona. Przeliczniki są banalnie proste, albo bezpośrednie wartości albo w widoczny na oko sposób. Prawdę mówiąc najwięcej mi czasu zeszło na opanowanie COMa. Jakiś dureń wymyślił żeby transmisja OBD2 działała z niestandardową prędkością 10400. No a wszystkie komponenty COMa w Delphi są budowane dla standardowych prędkości w PCtach czyli 9600 ...etc. Znalazłem gdzieś w swoich archwiach komponent ze żródłami i musiałem go przerobić i przekompilować. Drugim utrudnieniem była przesiadka na Pascala na Delphi - wieki w tym nie działałem (zawodowo siedzę w sprzęcie i klepię w C).

Czy to będę publikował ? Dużo przepisywania bo mam na razie na kartce papieru spisane a nie wiem na ile jest to na tym forum interesujące. Ale jak ktoś chce to w wolnej chwili udostępnię. Natomiast jak zrobię logera to chętnie się nim podzielę żeby zobaczyć jak to z tym katem zapłonu jest w innych silnikach. No i przymierzam się do zbudowania MAP emulatora, ale to pewnie trochę później jak już będzie loger żeby można sobie było wszystko ładnie obserwować i badać w oparciu o jakieś dane a nie tylko "wycucie".

Odzywam się w końcu w temacie. Choć coraz bardziej taki monologiczny wątek się zrobił Mam wieści dobre, złe i znowu dobre

W wolnych chwilach wypociłem ten program. Wyszło coś takiego

Pięknie działa, dane logują się w oknie, które można zapisać do pliku tekstowego a potem to wciągnąć excelem i wysmarować wykresy. Niestety działa ale tylko z wcześniej zbudowanym emulatorem ECU . I tak: ABCOM działa z emulatorem ECU, działa z ECU , loger działa z emulatorem ale nie działa przy podłączeniu do ECU. I co najgorsze wiem chyba dlaczego. I to jest ta zła wiadomość. Mianowicie ABCOM zanim rozpocznie transmisje wystawia na linię niski stan przez 25ms. Po kolejnych 25ms wysyła komendę i transmisja normalnie się odbywa. Wydumałem jak ustawić niski stan linii przez taki czas - wysyłam "0" z prędkościa 300bd. Niestety przełączenie z 300bd na 10400 zabiera windozie na tyle dużo czasu, że nie jestem w stanie wystartować transmisji szybciej niż po 270ms. A to widocznie jest za późno - i kupa bo ECU nie odpowiada na moje zawołania choć są identyczne jak z ABCOMa. Z poziomu windozy i Delphi nie jestem w stanie tego nijak obejść. Wydaje mi się, że jedynie odwołując się bezpośrednio do komend BIOSa można to obejść ale ja tego nie potrafię i nie chce mi sie rozgryzać. Stąd zapewne wynikają problemy z zainicjowaniem komunikacji przy korzystaniu z przejściówek USB-RS232 bo się wtedy czasówki rozjeżdżają. Drugą różnicą jaką jeszcze zabserwowałem to fakt, że ABCom wysyła komendy z odstępami między bajtami 4ms. Ja mogę albo wysyyłać całego stringa bajt po bajcie. Gdy wysyłam po jednym bajcie wtedy odstepy sięgają 50ms. Nie wiem czy ma to znaczenie ale też nie jestem w stanie tego obejść.

Trochę mi piórka opadły i już się zastanawiałem czy nie odpuścic sobie i powrócić na mymłono rodziny Ale?

Zaświtała mi kolejna pomysła Nie wiem czemu na to wczesniej nie wpadłem bo jest prostsze do realizacji. Zamiast budować wielki program i próbować inicjować transmisję mogę sczytywać sprzętowo ramki wysyłane z ECU podczas komunikacji z ABCOMem i tylko je dekodować. Wystarczy TxD z wtyczki podłączyć do drugiej wtyczki , no i mieć drugiego COMa Mój laptok niestety ma tylko jednego sprzetowego COMa ale nic nie stoi na przeszkodzie żeby użyć do tego wirtualnego COM zbudowanego na przejściówce USB-COM. W pracy się pelęta taki więc go użyję. Czasówki jake wprowadzi USB nie powinny mieć znaczenia bo tylko będę czytał dane a ich chronologia zostanie zachowana. Zrobię więc tak ,że przebuduję obecny loger a w zasadzie go uproszczę. No cóż i sie odezwę za jakiś czas co z tego wyszło, o ile ktoś w ogóle jest tym wątkiem jeszcze zainteresowany. Bo może truję

Witam!

Moze Cie naprowadze troche, a moze sie myle .

Bawiac sie roznymi interfejsami ale USB z lapkiem nie posiadajacym COM, wpadalem na pomysl w AB-comie w pliku OPELDATA zaczelem zmieniac wartosci polaczenia. Z 10400 w tym pliku zmienialem, co 300 baud w dol.

I za ktoryms razem zadzialalo, interfejs polaczyl sie na tym zmiejszonym.

Niby tam na sztywno sa wpisane wartosci dla KW2000 10400, a on korzysta z tego pliku w trakcie polaczenia.

Problemy czasowe: widać biblioteka pod delphi do COMa nie jest zbyt dobra. Jakiej używasz? Ja kiedys używałem co prawda pod CBuilderem borlandowskim kilku różnych "komponentó" do comportu. I każdy się inaczej zachowywał wprowadzając swoje upierdliwości. Sterownie "przez BIOS" pod indozą raczej niedobrym pomysłem jest. Trzeba by by raczej po API windowsowym popatrzeć. A programik logujący którym logujesz co ABCOM grzebie po porcie co pokazuje ? Bo jeżeli pokazuje dobrze, to znaczy że odwołuje się do porty przez standardowe API (byc może z pośrednictwem jakiejś biblioteki), bez cudowania jakiegoś bardzo niskopoziomowego. Z resztą takie cudowanie w windowsie ze względu na mech. ochrony itp jest trudne dość (ale wykonalne - trzeba własny system device stworzyć.). Chociaż zawsze mozna obejść mechanizmy ochrony przez GiveIoPerm... No, ale to juz NTG...

Jak widać zależności czasowe przy tej komunikacji są kluczowe, dla tego że jest to można powiedzieć emulacja jakoegoś tam protokołu przy pomocy RS232...

A co do pomysłu z odpalonym jednocześnie abcomem i logowaniem, to jest to IMHO jaknajbardziej słuszny pomysł. Jeszcze lepiej było by to zrealizowac czysto programowo przechwytując dane odbierane przez ABCOM..

> Witam!

> Moze Cie naprowadze troche, a moze sie myle .

> Bawiac sie roznymi interfejsami ale USB z lapkiem nie posiadajacym

> COM, wpadalem na pomysl w AB-comie w pliku OPELDATA zaczelem

> zmieniac wartosci polaczenia. Z 10400 w tym pliku zmienialem, co

> 300 baud w dol.

> I za ktoryms razem zadzialalo, interfejs polaczyl sie na tym

> zmiejszonym.

> Niby tam na sztywno sa wpisane wartosci dla KW2000 10400, a on

> korzysta z tego pliku w trakcie polaczenia.

Wg mnie prędkość transmisji ustawiana na wirtualnych COMach nie ma znaczenia. Trochę w tym temacie "służbowo" działałem. I tak kryterium jest transmisja USB, która rządzi się swoimi prawami a parametry predkości dostępne w interfejsie zostają tylko dla zachowania kompatybilności.

edit

chociaż coś pieprzę, przeciez po drugiej stronie kabla jest normalnie rs232, pochchrzaniło mi się z wirtualnym comem ale portowanym wewnątrz systemu

> Problemy czasowe: widać biblioteka pod delphi do COMa nie jest zbyt

> dobra. Jakiej używasz? Ja kiedys używałem co prawda pod

> CBuilderem borlandowskim kilku różnych "komponentó" do comportu.

> I każdy się inaczej zachowywał wprowadzając swoje upierdliwości.

Wszystkie jakie zgromadziłę jeszce kiedyś jak się więcej delphi bawiłem są skompilowane dcu i nie da się w nich ustawic 10400. Tylko jeden prościacki komponent miałem ze źródłami którego można było przerobić.

> Sterownie "przez BIOS" pod indozą raczej niedobrym pomysłem

> jest. Trzeba by by raczej po API windowsowym popatrzeć. A

> programik logujący którym logujesz co ABCOM grzebie po porcie co

> pokazuje ?

dla ABCOm i loggera pokazuje to samo, tzn róznica jst taka że na ramkę z ABCOMa ECU odpowiada a na taką samą z loggera już nie Ale wina wydaje mi się jest po stronie czasówek i niezainicjownia ECU do dyskusji.

> Bo jeżeli pokazuje dobrze, to znaczy że odwołuje się

> do porty przez standardowe API (byc może z pośrednictwem jakiejś

> biblioteki), bez cudowania jakiegoś bardzo niskopoziomowego. Z

> resztą takie cudowanie w windowsie ze względu na mech. ochrony

> itp jest trudne dość (ale wykonalne - trzeba własny system

> device stworzyć.). Chociaż zawsze mozna obejść mechanizmy

> ochrony przez GiveIoPerm... No, ale to juz NTG...

te tematy słabo znam

> Jak widać zależności czasowe przy tej komunikacji są kluczowe, dla

> tego że jest to można powiedzieć emulacja jakoegoś tam protokołu

> przy pomocy RS232...

> A co do pomysłu z odpalonym jednocześnie abcomem i logowaniem, to

> jest to IMHO jaknajbardziej słuszny pomysł. Jeszcze lepiej było

> by to zrealizowac czysto programowo przechwytując dane odbierane

> przez ABCOM..

też tak dumałem ino jak? Jak dla mnie prościej( co znaczy szybciej) bypasem na drugi port.

> chociaż coś pieprzę, przeciez po drugiej stronie kabla jest normalnie

> rs232, pochchrzaniło mi się z wirtualnym comem ale portowanym

> wewnątrz systemu

Virtualny to jest insza inszosc .

W tym grzebalem a nie ruszylo.

Grzebalem na standartowych ustawieniach (jak cos pochrzanilem, to przywracalem system z backupa) a jedynie w samym Ab-comie w tym pliku, co podalem zmienialem baudy w dol.

Zainspirowalo mnie do tego ustawienia w OpelTech2, tam mozna zmieniac korekcje polaczenia KW 2000.

> Virtualny to jest insza inszosc .

> W tym grzebalem a nie ruszylo.

> Grzebalem na standartowych ustawieniach (jak cos pochrzanilem, to

> przywracalem system z backupa) a jedynie w samym Ab-comie w tym

> pliku, co podalem zmienialem baudy w dol.

> Zainspirowalo mnie do tego ustawienia w OpelTech2, tam mozna zmieniac

> korekcje polaczenia KW 2000.

Dzięki za sugestie. Ale juz zdecydowałem się że zrobię tylko szpiega. ABCOM komunikuje się super i z wszystkimi silnikami więc lepiej bedzie dodrobić sczytywacz danych niż budować skomplikowany parser do komunikacji, który jak widać oprócz poprawności ramek uzależniony jest mocno od zależności czasowych. Wygrzebałem z szuflady przejściówkę USB-RS232 - dobrą starą na sterowniku prolifica. Dziś mam po południu czas to sie pobawię i może wkrótce coś z tego wyjdzie.

Niestety przejściówa USB nie chce chodzić na 10400. Dlatego więc żadne przejściówki nie chodzą z OBD2. Czyli klops. ma ktoś jakiś pomysł?

ABCom działa na przejściówce Prolifica USB2COM, ale Tech2 na PC już nie. Pozdr.

> ABCom działa na przejściówce Prolifica USB2COM, ale Tech2 na PC już

> nie. Pozdr.

Widocznie scalak w tej przejściówce ma mozliwość pracy dla niestandardowej prędkości 10400. Niestety ten który posiadam nie. Gdy ustawie 10400 chodzi po 9600 więc bajty otrzymuję przekłamane.

Może jakoś wirtualnym portem by to obskoczył? Ale nie mam nic pod ręką. Musiałoby to być coś co się podkleszczy pod COMa z którego korzysta ABCOM , zasysa dane otrzymywane przez ABComa i wyrzuca na wirtualny COMx. Marnie to widzę. Cholera czemu nie mam lapka z dwoma COMami sprzętowymi.

> ABCom działa na przejściówce Prolifica USB2COM, ale Tech2 na PC już

> nie. Pozdr.

masz może jakiś namiar na tą przejściówkę?

> czemu nie mam lapka

> z dwoma COMami sprzętowymi.

jakie masz wymagania wobec takowego lapka?

mam na stanie jednego niepotrzebnego, 2xCOM, euroscan na tym chodził

jakby co to priv

> jakie masz wymagania wobec takowego lapka?

> mam na stanie jednego niepotrzebnego, 2xCOM, euroscan na tym chodził

> jakby co to priv

Dzięki ale raczej nie będą kupował drugiego laptopa. Albo zastosuję tą przejściówkę która łyka 10400 albo zrobię sobie na jakimś u-kontrolerku konwersję z 10400 na 19200 albo opanuję czasówki w delphi.

Są fajne programy które umożliwiają współdzielenie portu szeregowego dla kilku aplikacji ale niestety wszystkie działają pod NT, XP a na lapku postawiony jest W98. Zresztą ABcom na XP podobno nie chce działać.

Jak mam problem z samochodem, przejściówkę pożyczam od jednego kolegi, laptopa od innego. Laptop to Packard Bell, ma WinXP. Przejściówka USB->COM nie jest firmowa, elektronika zatopiona we wtyku, wiem tylko, że była trochę droższa od innych na Allegro, bo tam była kupiona. Mam od niej sterowniki, mogę ci wysłać na priv, jak mi napiszesz jak to się robi. ABCom, Opelscanner oraz program do instalki LPG na tym zestawie chodzą. Może moje sterowniki zadziałają... tylko pamiętaj, testowałem na XP, nie wiem jak będzie na W98.

I jeszcze jedna ważna uwaga: najpierw instalujesz sterowniki, a po instalacji podpinasz interfejs. To ważne!!!

Pozdr.

> Jak mam problem z samochodem, przejściówkę pożyczam od jednego

> kolegi, laptopa od innego. Laptop to Packard Bell, ma WinXP.

> Przejściówka USB-

> I jeszcze jedna ważna uwaga: najpierw instalujesz sterowniki, a po

> instalacji podpinasz interfejs. To ważne!!!

> Pozdr.

Sterowniki to raczej zależą od chipa na którym jest oparty. Ja mam przejściwke prolifica opartą o PL2303. Cóż nie ważne bedę próbował na inne sposoby. Mam jeszcze koncepcję żeby pożyczyć RSa na PCIMCA.

> Sterowniki to raczej zależą od chipa na którym jest oparty. Ja mam

> przejściwke prolifica opartą o PL2303. Cóż nie ważne bedę

> próbował na inne sposoby. Mam jeszcze koncepcję żeby pożyczyć

> RSa na PCIMCA.

RS na pcimcia jest można powiedzieć funkcjonalnie równoważny takiemu sprzętowemu.

Ale jak masz do mikrokontrolerków zacięcie to może "translator" lepiej zrobić. Tylko najlepiej wziąc większy kontrolerek coby miał dwa UARTy....

> Ja mam

> przejściwke prolifica opartą o PL2303.

Ja też, ale sterowniki sterownikom nie równe, co ci szkodzi spróbować... no, chyba, że tu chodzi tylko na WinXP, to co innego...

Pozdr.

> Ja też, ale sterowniki sterownikom nie równe, co ci szkodzi

> spróbować... no, chyba, że tu chodzi tylko na WinXP, to co

> innego...

> Pozdr.

nic mi nie szkodzi , ściągałem najnowsze ze strony producenta ale wyślij. Adres chciałem wysłać na priva ale masz zapchane konto. Musisz usunąc niepotrzebne.

> RS na pcimcia jest można powiedzieć funkcjonalnie równoważny takiemu

> sprzętowemu.

> Ale jak masz do mikrokontrolerków zacięcie to może "translator"

> lepiej zrobić. Tylko najlepiej wziąc większy kontrolerek coby

> miał dwa UARTy....

Też się nad tym zastanawiałem dlatego zamierzam pożyczyć a nie kupować . uC - że tak powiem na drugie mam na imię, bardziej chodzi, że chciałem szrajbnąć coś bardziej uniwersalnego co można każdemu podesłać mailem żeby uruchomił. Z uC ja sobie poradzę ale to co zrobie zostanie w praktyce tylko dla mnie. A sądzę wystarczy jeden malutki uC z jednym UARTem, który będzie odbiorczy a nadawczy łatwo zaemulować na taimerze. Prędkość wyjściową się zrobi 14400 lub 19200 to bez buforowania się obejdzie.

To znowu ja . UDało się choć z problemami. Tzn wróciłem do wcześnijszej koncepcji próby wymuszenia na linii stanu niskiego. Wymyśliłem żeby wymusić stan niski 25 ms na lini korzystając z lini modemowej RTS portu szeregowego. Sprawdziłem jeszcze czy ABCOM nie miesza tą linią i jakież było moje zdziwienie gdy okazało się że podczas inicjacji rónocześnie ze stanem na linii Tx jest zmieniany RTS. Widocznie nie wszystkie rozwiązania kontrolerów RS232 potrafią wystawiać na Tx stały stan i programista przewidział awaryjne wyjście z którego skwapliwie skorzystałem . Zmodyfikowałem interfejs łącząc nieużywany kanał MAX232 z RTS we wtyczce DB9 oraz łącząc przez diodę z bazą pierwszego tranzystora. Potem tylko w programie opowiednio dobrałem czasy opóźnień na timerach i działa. Tzn. super działa z mojego stacjonarnego kompa z XP. Natomiast ze starego lapka z W98 troche gorzej bo czasy sa wydłużone o spore opóźnienia. Postanowiłem cóż spróbuje się połączyć. No i od strzału nie chciało załapać musiałem tak z dobrych kilka razy wyzwalać aż ECU w końcu łapało a potem to już jak po sznurku. Wygląda, że krytycznym jest czas rozpoczecia transmisji po zwolnieniu linii. ABCOM robi to w 25s. Mnie się huśtało miedzy 40-60ms ale za któryms razem łapało i ramki śmigały jak tralala. Będę próbował coś z tym jeszcze zrobić. Więc pojeździłem po miescie i pozbierałem dane z logera. Zbierałem dla zakresów 1500, 2000, 2500 rpm z +-50 dla pracy na benzynie a potem na LPG, logujac aktualny kąt i ciśnienie. Ponieważ przedziały obrotów zrobiłem dość szerokie, gdyż chciałem aby w miare latwo i szybko danych nałapać, przez to wyniki były troche rozstrzelone bo wyprzedzenie zapłonu dość mocno zależy od rpm. Ale od czego Excel i możliwość wyznaczenia linii trendu z wielomianu. No i fajnie wyszło. Na niebiesko benzyna na czerwono LPG.

Widać że dla LPG mocniej wyprzedzany jest zapłon zwłaszcza dla niżych obrotów i mniejszego ciśnienia bezwzględnego (czyli buta). Znaczy że ECU korzysta ze stuku puku i jakoś sobie te mapy dopasowuje, Róznice nie sa jednak powalające, ciekawe czy może dłuższej perspektywie, gdyby pojeździć np kilkadziesiąt km na danym paliwie różnice te nie pogłebiłyby się? Coż następny etap to może próba zbudowania choćby prowizorycznego emulatora MAPa bo jak widać z wykresów można by tym przesuwać zapłon w zakresie dobrych kilkunastu stopni.

> Znaczy że ECU korzysta ze stuku puku i jakoś sobie te

> mapy dopasowuje, Róznice nie sa jednak powalające, ciekawe czy

> może dłuższej perspektywie, gdyby pojeździć np kilkadziesiąt km

> na danym paliwie różnice te nie pogłebiłyby się? Coż następny

> etap to może próba zbudowania choćby prowizorycznego emulatora

> MAPa bo jak widać z wykresów można by tym przesuwać zapłon w

> zakresie dobrych kilkunastu stopni.

Tak dla zrozumienia. Czy przedstawione wykresy opisują zależność kąta wyprzedzania zapłonu od stopnia uchylenia przepustnicy, przy danej prędkości obrotowej?

Analizując punkty na wykresie 2 można odnieśc wrażenie, że linia trendu nie jest zbyt dobrze dopasowana do surowych danych, chyba należałoby skorzystac z innej funkcji.

jestem pod wrażeniem. Rozrzut rzeczywiście jest spory, ale widać, że sprzęt działa.

Oby tak dalej

> Tak dla zrozumienia. Czy przedstawione wykresy opisują zależność kąta

> wyprzedzania zapłonu od stopnia uchylenia przepustnicy, przy

> danej prędkości obrotowej?

Sygnał podciśnienia bezwzględnego z MAP sensora czyli w pewnym stopniu proporcjonalne do uchylenia przepustnicy.

> Analizując punkty na wykresie 2 można odnieśc wrażenie, że linia

> trendu nie jest zbyt dobrze dopasowana do surowych danych, chyba

> należałoby skorzystac z innej funkcji.

Może, tak wyliczył excel, nie jestem matematykiem.

> jestem pod wrażeniem. Rozrzut rzeczywiście jest spory, ale widać,

> że sprzęt działa.

> Oby tak dalej

Wynika to zapewne z szerokiego zakresu jaki przyjąłem +-50rpm. Czyli dla np 1500 załapywał dane w przedziale 1450-1550. Gdyby zawęzić do +-10 byłoby lepiej ale wtedy trudno się wstrzelić w obroty żeby loger zaliczył punkti trzeba się ojeździć autem jak dureń. Oczywiście można by łykać wszystkie spływające dane i wykreślić charakterystyke 3D tylko jak to potem analizować? Ale też się cieszę że coś z tego wyszło. Choć wszystko się sprzysięgło przeciwko uparłem się jak cholera Ciekaw jestem czy bazując na parametrach odczytywanych z ECU można by się pokusić o wykresy momentu albo mocy? Taka własna dupohamownia

W pewnym stopniu jeśli przyspiesza się w miarę powoli. Ale jeśli depnie się od razu do dechy to podciśnienie maleje prawie do zera i ECU leje paliwem ile fabryka dała. Warto by taką ewentualność sprawdzić, bo przy LPG w takich przypadkach silnik lubi sobie kaszlnąć ogniem w dolot. A przyspieszenie zapłonu może to ograniczyć

> W pewnym stopniu jeśli przyspiesza się w miarę powoli. Ale jeśli

> depnie się od razu do dechy to podciśnienie maleje prawie do

> zera i ECU leje paliwem ile fabryka dała. Warto by taką

> ewentualność sprawdzić, bo przy LPG w takich przypadkach silnik

> lubi sobie kaszlnąć ogniem w dolot. A przyspieszenie zapłonu

> może to ograniczyć

Tzn chodziło mi bardziej czy dałoby się wyznaczyc ch-kę momentu i mocy naszego pojazdu. Tak na szybko na chłopski rozum musi się dać. Moment obrotowy jest proporcjonalny do siły a w zasadzie jest odpowiednikiem siły w ruchu obrotowym. Znając masę swojego pojazdu i znając przyspieszenie możemy wyznaczyć moment. Wsiadamy do auta wrzucamy 4 i jedziemy od np 1000rpm do 6000(wystarczy) Przyspieszenie otrzymamy próbkując w określonych interwałach czasu prędkość. Moc jest to nic innego jak iloczyn momentu obrotowego i prędkości obrotowej a to też możemy zlogować. Żeby miało wszystko rece i nogi i jakieś sensowne jednostki należałoby sobie przypomnieć wzory fizyczne i przeliczniki KM/kW czyli cofnąć się do czasów szkoły, a to już trudniej Kolejne wyzwanie ? Kwestia na ile dokładnie dałoby się to wyliczyć -problem np z dokładością masy auta. Czy o czymś zapomniałem ?

No pewno że zapomiałem. Przeciez nie podrózujemy w próżni. Opory powietrza!!! Musielibyśmy jeszcze dodać siłę oporów powietrza a to już nie takie proste bo trzeba znać Cx i umieć to wyliczyć a może być jeszcze wiatr etc.. do bani

Tutaj był podobny wątek o obliczaniu elastyczności silnika i też jakoś ucichł.

> Tutaj był podobny wątek o obliczaniu elastyczności silnika i też

> jakoś ucichł.

Ciekawe.