Niestety pierwsza próba stworzenia mojego interfejsu pod USB zakończyła się porażką. Tak jak się spodziewałem konwertery i samo przesyłanie danych USB do UART wprowadzają pewne losowe opóźnienia i ciężko jest w ten sposób zainicjować poprawnie komunikacje z ECU. Ponieważ nie posiadam w tym momencie oscyloskopu (planuje kupić używany oscyloskop analogowy lub w ostateczności złożyć samemu jakąś zabawkę), nie potrafię w tym momencie nawet dokładnie powiedzieć jakiego rodzaju są to przesunięcia i zakłócenia. Najprostszym rozwiązaniem byłoby wstawienie mikro-kontrolera który zadbałby o właściwą synchronizacje. Chciałbym jednak najpierw zobaczyć jak to wszystko wygląda pod oscyloskopem, więc na razie interfejs na USB odkładam do szuflady.
Oczywiście nie oznacza to, że nie próbowałem zdobyć informacji na temat czujników na inne sposoby :)
Zdobyłem kompletną dokumentacje do kontrolerów stosowanych w różnych markach samochodów. Dzięki temu pewnie uda mi się w końcu połączyć z samym sterownikiem wyciągniętym z jakiegoś wraka. Podając odpowiednie impulsy na jego wejścia również będę w stanie określić w jaki sposób odczytywać wartości z jego czujników. Jest to jednak droga kosztowna, dlatego tymczasem próbuje jeszcze inaczej :)
Idea jest taka żeby stworzyć emulator ECU pracujący na komputerze do którego będą się łączyć programy diagnostyczne. Dzięki takiemu emulatorowi byłbym w stanie na bieżąco modyfikować wartości czujników i w ten sposób dowiedzieć się wszystkiego czego potrzebuję :)
Taki emulator udało mi się napisać w miarę szybko a dzięki wirtualnym portom COM wszystko można zrobić na jednym komputerze, bez potrzeby spinania dwóch maszyn kabelkiem Null-modem. Oczywiście znowu pojawiają się tutaj pewne problemy ale już zupełnie innej natury :/
Problem oczywiście leży w samych programach diagnostycznych. Autorzy takich programów wymuszają na użytkowniku kupienie interfejsu swojej produkcji i z innymi program nie chce współpracować, a tym bardziej nie można ustawić komunikacji przez zwykły port COM. Wygląda na to, że w sieci do Opla dostępne są tylko dwa programy: AutoScanner i OP-COM. Przy czym AutoScannera narazie nie używałem.
Z OP-COM jest sprawa o tyle ciekawa, że w sieci krąży jego beta wersja (Opel Tech2) nie zawierająca w ogóle odczytu czujników oraz wersja crackowana znana jako AB-COM.
Opel tech2 nie nadaje się więc do użycia a sporo użytkowników go poleca na forach :) Zresztą przeczytajcie tutaj sami co napisał autor programu. Natomiast AB-COM wygląda na to, że źle odczytuje bloki pomiarowe. Nie pokazuje mi napięcia z sondy Lambda, a inne wartości też nie zgadzają się do końca.
Jest jeszcze dostępne demo OP-COM, ale jak na razie nie chce "współpracować" :P Wersja demo jest spakowana programem Pecompact, który na szczęście da się łatwo wypakować. Być może głębsze wniknięcie w kod programu rozwiąże ten problem. Z tego powodu kod źródłowy emulatora zamieszczę dopiero za jakiś czas, po rozwiązaniu tego typu problemów. Być może dodam do niego funkcje emulacji któregoś z interfejsów współpracujących z OP-COMem.
piątek, 8 października 2010
środa, 22 września 2010
Interfejsy diagnostyczne do samochodów
W poprzednim wpisie napisałem, że większość schematów interfejsów które można znaleźć w sieci jest niekompletna lub zła. Tym razem chciałbym napisać coś więcej na ten temat i wytłumaczyć niektóre niuanse związane z tworzeniem takiego interfejsu.
Mimo wszystko pewne standardy istnieją i obowiązują wszystkich producentów aut. W każdym standardzie pierwsze co jest zdefiniowane to właśnie właściwości elektryczne. Opis ten dotyczy warunków jakie maja panować podczas przesyłania danych oraz w jaki sposób ma się zachowywać podczas transmisji kontroler w samochodzie i urządzenie testujące. Skupie się tutaj przede wszystkim na protokołach zdefiniowanych przez ISO-9141 i ISO-14230, ponieważ oba te standardy są zgodne w warstwie elektrycznej.
Z tych standardów wynika kilka najważniejszych rzeczy:
- zakres temperatur w jakich pracujemy waha się pomiędzy -20C a +50C. Należy wiec pamiętać, że charakterystyki wielu elementów (np. rezystorów) zależą mocno od temperatury
- akumulator daje napięcie w granicach 12-14V, jednak tester powinien pracować poprawnie w granicach 8-16V
- komunikacja przebiega po "jednym drucie", tzw. linii K. Linia K jest oczywiście dwu-kierunkowa, czyli obsługuje nadawanie i odbieranie danych
- kodowanie danych na linii K jest identyczne jak podczas transmisji szeregowej UART (RS232) w formacie 8N1 (czyli 8 bitów danych, brak parzystości, jeden bit stopu, brak kontroli przepływem).
- linia K musi być podciągnięta do zasilania z akumulatora (tzw. pull-up) poprzez opornik 510 ohm 5%
- stan traktowany jako logiczne 1 na linii K to minimum 90% napięcia akumulatora
- stan traktowany jako logiczne 0 na linii K to maksymalnie 10% napięcia akumulatora. Prąd maksymalny 100mA
- tester nie powinien podawać na linie K napięcia wyższego od napięcia akumulatora, ani napięcia poniżej -1V
Jak widać nie ma tutaj żadnej magii. Wszystkie problemy z podłączeniem do danego sterownika wynikają tylko z tego jak bardzo dany interfejs nagina wyżej wymienione zasady i jak mocno trzyma się wyznaczonych parametrów elektrycznych. Od strony sterownika sytuacja zresztą wygląda podobnie.
Teraz przyszedł czas by się zastanowić jaką funkcjonalność powinien posiadać interfejs. Tak naprawdę mowa tutaj tylko o trzech rzeczach. Po pierwsze więc, musimy wziąć pod uwagę, że układy AVR czy inne chipy pracują przy napięciu 3.3V lub 5V. Interfejs powinien zatem konwertować poziom napięć pomiędzy 12-14V a napięciami TTL (czyli 5V lub 3.3V). Po drugie powinien poprawnie rozpoznawać stany logiczne 0 i 1, i po trzecie umożliwić nam nadawanie danych po linii K.
Oczywiście możemy tutaj użyć gotowych układów scalonych w stylu Si9243, L9637, MC33290 lub innych które zrobią to wszystko za nas. Trzeba jednak pamiętać, że są one drogie i trudno dostępne. Na dodatek w bardzo prosty sposób można poradzić sobie samemu, wykorzystując zaledwie 1-2 tranzystory, kilka oporników i komparator napięć LM393 lub LM339N. Dodatkowo ponieważ np. komparator LM339N jest poczwórny będziemy mogli bez problemu dołożyć obsługę linii L (linia ta służy tylko do inicjowania połączenia i występuje tylko przy starszych sterownikach w standardzie ISO-9141). Obsługę linii L realizujemy identycznie jak linii K.
Komparator napięć odwali za nas większą cześć brudnej roboty, czyli konwersje napięć oraz określenie stanu logicznego na linii K. Sam komparator jest zasilany napięciem ~12V z akumulatora (pracuje przy napięciach 2-36V). Konwersje napięć robimy w bardzo prosty sposób. Wystarczy jego wyjście podciągnąć pod 5V lub 3.3V.
Rozróżnianie stanów logicznych najlepiej jest zrobić podając napięcie odniesienia na nóżkę wejścia odwracającego układu poprzez dzielnik napięcia. Dzielnik napięcia można zrobić z dwóch rezystorów 10k ohm podciągniętych do +12V lub wykorzustując rezystory 10k ohm i 5k ohm podciągnięte do +5V. Jak widać dużo zależy tutaj od naszej fantazji :)
Całość układu może wyglądać tak jak na schemacie poniżej. Trzeba jednak pamiętać, że nawet tutaj można dokonać pewnych modyfikacji np. wyjście TXD można puścić poprzez pojedynczy tranzystor a nie dwa (tworzące bramkę NOT). Do złącza serial można doczepić układ MAX232 konwertujący poziomy napięć do standardu RS232, FT232 będący konwerterem USB-UART, czy też Atmega328p używany w Arduino.
Mimo wszystko pewne standardy istnieją i obowiązują wszystkich producentów aut. W każdym standardzie pierwsze co jest zdefiniowane to właśnie właściwości elektryczne. Opis ten dotyczy warunków jakie maja panować podczas przesyłania danych oraz w jaki sposób ma się zachowywać podczas transmisji kontroler w samochodzie i urządzenie testujące. Skupie się tutaj przede wszystkim na protokołach zdefiniowanych przez ISO-9141 i ISO-14230, ponieważ oba te standardy są zgodne w warstwie elektrycznej.
Z tych standardów wynika kilka najważniejszych rzeczy:
- zakres temperatur w jakich pracujemy waha się pomiędzy -20C a +50C. Należy wiec pamiętać, że charakterystyki wielu elementów (np. rezystorów) zależą mocno od temperatury
- akumulator daje napięcie w granicach 12-14V, jednak tester powinien pracować poprawnie w granicach 8-16V
- komunikacja przebiega po "jednym drucie", tzw. linii K. Linia K jest oczywiście dwu-kierunkowa, czyli obsługuje nadawanie i odbieranie danych
- kodowanie danych na linii K jest identyczne jak podczas transmisji szeregowej UART (RS232) w formacie 8N1 (czyli 8 bitów danych, brak parzystości, jeden bit stopu, brak kontroli przepływem).
- linia K musi być podciągnięta do zasilania z akumulatora (tzw. pull-up) poprzez opornik 510 ohm 5%
- stan traktowany jako logiczne 1 na linii K to minimum 90% napięcia akumulatora
- stan traktowany jako logiczne 0 na linii K to maksymalnie 10% napięcia akumulatora. Prąd maksymalny 100mA
- tester nie powinien podawać na linie K napięcia wyższego od napięcia akumulatora, ani napięcia poniżej -1V
Jak widać nie ma tutaj żadnej magii. Wszystkie problemy z podłączeniem do danego sterownika wynikają tylko z tego jak bardzo dany interfejs nagina wyżej wymienione zasady i jak mocno trzyma się wyznaczonych parametrów elektrycznych. Od strony sterownika sytuacja zresztą wygląda podobnie.
Teraz przyszedł czas by się zastanowić jaką funkcjonalność powinien posiadać interfejs. Tak naprawdę mowa tutaj tylko o trzech rzeczach. Po pierwsze więc, musimy wziąć pod uwagę, że układy AVR czy inne chipy pracują przy napięciu 3.3V lub 5V. Interfejs powinien zatem konwertować poziom napięć pomiędzy 12-14V a napięciami TTL (czyli 5V lub 3.3V). Po drugie powinien poprawnie rozpoznawać stany logiczne 0 i 1, i po trzecie umożliwić nam nadawanie danych po linii K.
Oczywiście możemy tutaj użyć gotowych układów scalonych w stylu Si9243, L9637, MC33290 lub innych które zrobią to wszystko za nas. Trzeba jednak pamiętać, że są one drogie i trudno dostępne. Na dodatek w bardzo prosty sposób można poradzić sobie samemu, wykorzystując zaledwie 1-2 tranzystory, kilka oporników i komparator napięć LM393 lub LM339N. Dodatkowo ponieważ np. komparator LM339N jest poczwórny będziemy mogli bez problemu dołożyć obsługę linii L (linia ta służy tylko do inicjowania połączenia i występuje tylko przy starszych sterownikach w standardzie ISO-9141). Obsługę linii L realizujemy identycznie jak linii K.
Komparator napięć odwali za nas większą cześć brudnej roboty, czyli konwersje napięć oraz określenie stanu logicznego na linii K. Sam komparator jest zasilany napięciem ~12V z akumulatora (pracuje przy napięciach 2-36V). Konwersje napięć robimy w bardzo prosty sposób. Wystarczy jego wyjście podciągnąć pod 5V lub 3.3V.
Rozróżnianie stanów logicznych najlepiej jest zrobić podając napięcie odniesienia na nóżkę wejścia odwracającego układu poprzez dzielnik napięcia. Dzielnik napięcia można zrobić z dwóch rezystorów 10k ohm podciągniętych do +12V lub wykorzustując rezystory 10k ohm i 5k ohm podciągnięte do +5V. Jak widać dużo zależy tutaj od naszej fantazji :)
Całość układu może wyglądać tak jak na schemacie poniżej. Trzeba jednak pamiętać, że nawet tutaj można dokonać pewnych modyfikacji np. wyjście TXD można puścić poprzez pojedynczy tranzystor a nie dwa (tworzące bramkę NOT). Do złącza serial można doczepić układ MAX232 konwertujący poziomy napięć do standardu RS232, FT232 będący konwerterem USB-UART, czy też Atmega328p używany w Arduino.
wtorek, 14 września 2010
Diagnostyka samochodowa
Diagnostyka samochodowa to nie tylko przykręcanie i rozkręcanie śrubek. Od dawna samochodowe silniki i inne podzespoły sterowane są elektronicznie. Jeżeli więc posługiwanie się kluczami nasadowymi, płaskimi czy grzechotką nie jest naszą mocną stroną, możemy również tuningować i monitorować pracę naszego autka elektronicznie. Robimy to poprzez wbudowany system diagnostyczny (OBD ang. On-Board Diagnostics).
System diagnostyczny zwykle składa się z różnych podzespołów (np. sterownik silnika, sterownik ABSu czy wspomagania kierownicy), które są połączone i tworzą wspólną sieć, podobną do sieci komputerowej. Na chwile obecną istnieje kilka standardów tego typu sieci. Nas jednak najbardziej będą interesowały tylko trzy spośród nich, najszerzej wykorzystywane w europie:
- ISO 9141-2: Wykorzystywany szeroko do roku 2000. Jego obsługa jest bardzo prosta i szczegółowo zdefiniowana, sygnalizacja opiera się o złącze UART a maksymalna długość pakietu to 12 bajtów.
- ISO 14230: Znany również jako KWP2000 (Keyword Protocol 2000). Jest to rozwinięcie standardu ISO 9141-2, ale kompatybilny z nim tylko w warstwie elektrycznej. Rozmiar pakietu może sięgać nawet 255 bajtów. Niestety wiele z jego funkcji standard ISO pozostawia do zdefiniowania dla producenta samochodu. Poprzez taki zabieg bez odpowiedniej dokumentacji praktycznie można tylko odczytać kody błędów. Nie trzeba chyba też dodawać, że z tego powodu implementacja KWP2000 może się różnić nawet w obrębie tego samego producenta.
- ISO 15765: Czyli sieć CAN, wykorzystywana praktycznie we wszystkich pojazdach od roku 2008. Oferuje przede wszystkim dużo wyższe prędkości transmisji.
Jakiś czas temu uzbrojony w tego typu informacje postanowiłem stworzyć swoje własne urządzenie do obsługi interfejsu diagnostycznego. Zmotywowały mnie przede wszystkim dwie sprawy, czyli brak obrotomierza oraz zapalanie się kontrolki check engine (sygnalizującej nieprawidłowe działanie któregoś z podzespołów lub nieprawidłowe odczyty z czujników).
Na początku nie byłem nawet pewien jaki protokół jest wykorzystywany w moim samochodzie. Wkrótce okazało się, że jest to KWP2000, przyszedł więc czas na budowę całego urządzenia oraz interfejsu. Jak widać wszystko opierało się o Arduino.
Niestety na każdym kroku największym problemem jest brak odpowiedniej dokumentacji. Mimo kilku prób nie udało mi się połączyć bezpośrednio z sterownikiem silnika co prawdopodobnie przyśpieszyłoby cały proces testowania
Wnioski z tych eksperymentów są takie, że większość schematów publikowanych w internecie jest niekompletna lub zła, a dostęp do informacji dla kogoś z poza branży utrudniony do granic możliwości. W końcu jednak przyszedł czas na pierwsze udane połączenie dzięki interfejsowi, którego schemat musiałem dopracować opierając się na poprzednich próbach i dokumentacji standardu.
Wkrótce potem podczas lutowania płytki z interfejsem spaliłem wyświetlacz LCD. Nie ma tego złego coby na dobre nie wyszło i tak nowa płytka posiada już wyświetlacz graficzny.
Jak widać na zdjęciach obecna wersja posiada niewielkie możliwości. Potrafi odczytać i skasować kody błędów, oraz zresetować sterownik (ECU ang. Electronic Control Unit).
W planach mam stworzenie interfejsu podpinanego poprzez złącze USB do komputera. Dzięki niemu w prosty sposób będę mógł podglądać komunikacje innych programów na złączu diagnostycznym i w ten sposób zebrać dalsze informacje potrzebne do obsługi protokołu KWP2000 również dla innych marek i modeli samochodów.
System diagnostyczny zwykle składa się z różnych podzespołów (np. sterownik silnika, sterownik ABSu czy wspomagania kierownicy), które są połączone i tworzą wspólną sieć, podobną do sieci komputerowej. Na chwile obecną istnieje kilka standardów tego typu sieci. Nas jednak najbardziej będą interesowały tylko trzy spośród nich, najszerzej wykorzystywane w europie:
- ISO 9141-2: Wykorzystywany szeroko do roku 2000. Jego obsługa jest bardzo prosta i szczegółowo zdefiniowana, sygnalizacja opiera się o złącze UART a maksymalna długość pakietu to 12 bajtów.
- ISO 14230: Znany również jako KWP2000 (Keyword Protocol 2000). Jest to rozwinięcie standardu ISO 9141-2, ale kompatybilny z nim tylko w warstwie elektrycznej. Rozmiar pakietu może sięgać nawet 255 bajtów. Niestety wiele z jego funkcji standard ISO pozostawia do zdefiniowania dla producenta samochodu. Poprzez taki zabieg bez odpowiedniej dokumentacji praktycznie można tylko odczytać kody błędów. Nie trzeba chyba też dodawać, że z tego powodu implementacja KWP2000 może się różnić nawet w obrębie tego samego producenta.
- ISO 15765: Czyli sieć CAN, wykorzystywana praktycznie we wszystkich pojazdach od roku 2008. Oferuje przede wszystkim dużo wyższe prędkości transmisji.
Jakiś czas temu uzbrojony w tego typu informacje postanowiłem stworzyć swoje własne urządzenie do obsługi interfejsu diagnostycznego. Zmotywowały mnie przede wszystkim dwie sprawy, czyli brak obrotomierza oraz zapalanie się kontrolki check engine (sygnalizującej nieprawidłowe działanie któregoś z podzespołów lub nieprawidłowe odczyty z czujników).
Na początku nie byłem nawet pewien jaki protokół jest wykorzystywany w moim samochodzie. Wkrótce okazało się, że jest to KWP2000, przyszedł więc czas na budowę całego urządzenia oraz interfejsu. Jak widać wszystko opierało się o Arduino.
Niestety na każdym kroku największym problemem jest brak odpowiedniej dokumentacji. Mimo kilku prób nie udało mi się połączyć bezpośrednio z sterownikiem silnika co prawdopodobnie przyśpieszyłoby cały proces testowania
Wnioski z tych eksperymentów są takie, że większość schematów publikowanych w internecie jest niekompletna lub zła, a dostęp do informacji dla kogoś z poza branży utrudniony do granic możliwości. W końcu jednak przyszedł czas na pierwsze udane połączenie dzięki interfejsowi, którego schemat musiałem dopracować opierając się na poprzednich próbach i dokumentacji standardu.
Wkrótce potem podczas lutowania płytki z interfejsem spaliłem wyświetlacz LCD. Nie ma tego złego coby na dobre nie wyszło i tak nowa płytka posiada już wyświetlacz graficzny.
Jak widać na zdjęciach obecna wersja posiada niewielkie możliwości. Potrafi odczytać i skasować kody błędów, oraz zresetować sterownik (ECU ang. Electronic Control Unit).
W planach mam stworzenie interfejsu podpinanego poprzez złącze USB do komputera. Dzięki niemu w prosty sposób będę mógł podglądać komunikacje innych programów na złączu diagnostycznym i w ten sposób zebrać dalsze informacje potrzebne do obsługi protokołu KWP2000 również dla innych marek i modeli samochodów.
piątek, 10 września 2010
Język powiadomień Exchange 2007
Z jakiegoś dziwnego powodu czasami Exchange wysyła powiadomienia systemowe (np. o niedostarczonym mailu) w innym języku niż życzyłby sobie tego użytkownik. Poprzednia wersja (Exchange 2003) wykrywała automatycznie ustawienia językowe Outlooka i w zależności od nich wiadomość była widoczna w odpowiednim języku. W nowszej wersji (Exchange 2007) nie wystarczy zmienić ustawienia w Outlooku. Tego typu właściwości są wbudowane w skrzynkę pocztową na serwerze.
Najprościej zmianę tego typu ustawień przeprowadzić z pomocą power shella, niestety Exchange Management Console nie daje nam nawet takiej możliwości. Na początek pobieramy i sprawdzamy ustawienia językowe naszej skrzynki
$Mailbox = Get-Mailbox adrb
$Mailbox.Languages
Jako wynik otrzymujemy:
LCID Name DisplayName
---- ---- -----------
1031 de-DE German (Germany)
Następnie zmieniamy język na angielski i zapisujemy zmiany:
$Mailbox.Languages = "en-US"
Set-Mailbox -Instance $Mailbox
Najprościej zmianę tego typu ustawień przeprowadzić z pomocą power shella, niestety Exchange Management Console nie daje nam nawet takiej możliwości. Na początek pobieramy i sprawdzamy ustawienia językowe naszej skrzynki
$Mailbox = Get-Mailbox adrb
$Mailbox.Languages
Jako wynik otrzymujemy:
LCID Name DisplayName
---- ---- -----------
1031 de-DE German (Germany)
Następnie zmieniamy język na angielski i zapisujemy zmiany:
$Mailbox.Languages = "en-US"
Set-Mailbox -Instance $Mailbox
Subskrybuj:
Posty (Atom)