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.
środa, 22 września 2010
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)
-
Tekst wyjątkowo jest w języku angielskim Before you start reading, p lease read article on lwn , if you have not already done so . The ...
-
Będzie to kontynuacja ostatniego wpisu na temat wymiany kontrolera w Monoprice Maker Ultimate / Wanhao D6. Niestety temat kalibracji dru...
-
Niedawno zostało odkryte kilka problemów w Linuksowej obsłudze protokołu TCP. Najpoważniejszy problem o sygnaturze CVE-2019-11477 umożl...