Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Protokół Nawigacji Kenwood - reverse engineering

gaspaccio 24 Lip 2016 21:16 9363 7
  • Parę miesięcy temu wpadłem na pomysł żeby podłączyć coś ciekawszego do stacji multimedialnej Kenwood niż tylko stary system nawigacji Denso. Projekt leży od paru tygodni i możliwe, że nigdy nie ujrzy ostatecznej wersji. Pomyślałem, że opis komunikacji się komuś przyda a szkoda żeby został zapomniany w szufladzie jak cała reszta.
    Protokół Nawigacji Kenwood - reverse engineering

    A) Konfiguracja sprzętu do prób
    Bazowałem tutaj na stacji multimedialnej Kenwood KVT-522DVD i module nawigacji DV-3200. Oba sprzęty maja już po kilka lat, ale do radia można podłączyć również nowsze moduły nawigacji więc prawdopodobnie nowsze modele nie różnią się w tej kwestii. Zresztą wątpię aby Kenwood wymyślał koło dwa razy skoro stare działa.

    Radio z Nawigacją jest łączone za pośrednictwem standardowego dużego złącza DIN13. Rozkład wyprowadzeń został odczytany z instrukcji serwisowej:
    Protokół Nawigacji Kenwood - reverse engineering

    1. RED / wideo 0,7Vpp
    2. D-GND / masa części cyfrowej
    3. NC
    4. REMO / TTL / Linia przesyłająca sygnał pilota zdalnego sterowania. Jego odbiornik znajduje się na forcie radia
    5. GREEN / wideo 0,7Vpp
    6. V-GND / masa wideo
    7. A-GND / masa audio
    8. R audio / prawy kanał
    9. BLUE / wideo 0,7Vpp
    10. TX / TXD -> monitor / w kierunku monitora TTL
    11. RX / RXD <- monitor / dane z monitora TTL
    12. L audio / lewy kanał
    13. SYNC / synchronizacja wideo


    B) Komunikacja:
    Parametry transmisji to: 4800, 8, Odd, 1
    Odczytałem to przez podsłuch linii RX/TX za pomocą klona USBee a potem metoda prób i błędów tak dobrałem parametry dekodowania sygnału żeby ukazało się coś sensownego.
    Stacja multimedialna jest urządzeniem nadrzędnym. W momencie podciągnięcia linii odbiorczej w radiu zaczyna ono nadawać 010FFF0F (o samej strukturze takiej paczki później) wysyła ją cyklicznie co sekundę i mniej więcej z takimi interwałami musi dostawać odpowiedź z modułu nawigacji 8134FF84. Gdy tak się dzieje załącza ekran i umożliwia wyświetlanie sygnału RGB. Oraz zaczyna wysyłać do nawigacji dane z panelu dotykowego.

    Paczka danych:
    Paczka danych od radia i od nawigacji może mieć różną długość, każda z nich składa się jednak z kilku rozpoznawalnych części




    Przykładowa paczka: 010FFF0F:
    01 - prefiks
    0F - informacja
    FF - separator
    0F - suma kontrolna - jest to suma danych 010FFF podzielona przed modulo256 (%256)

    Radio i nawigacja wiele różnych komunikatów i o ile jestem w stanie powiedzieć co one przesyłają o tyle zasadność ich kopiowania jest zbędna. Przykładem jest na przykład odpowiedź z nawigacji zaraz po pierwszym nawiązaniu komunikacji z całym stosem danych. Mogę się tylko domyślać że chodzi o tym i jakiś rodzaj daty ponieważ zmienia się ona w czasie.


    Paczka danych z radia:
    010FFF0F - cyklicznie co 1s, sprawdza czy po drugiej stronie jest podłączone urządzenie
    210105FF26 - występuje razem z 010FFF0F w interwałach 1s. określa na jakie źródło sygnału włączone jest radio - tutaj źródło sygnału "Nawigacja" jest włączone przyciskiem skrótu
    210001FF21 - jak wyżej - gdy włączone jest źródło wideo
    210301FF24 - jak wyżej - gdy źródło "Nawigacja" włączone jest z menu "Source"
    Jak widać paczka zaczynająca się od 21* określa w jakim aktualnie trybie znajduje się radio. Jest ich więcej niż opisałem, ale nie sprawdzałem wszystkich.
    03HHVVFF** - paczka która określa współrzędne dotyku na ekranie gdzie HH to współrzędne w poziomie a VV w pionie. Minimalne wartości tutaj to 0000 dla dolnego lewego narożnika i 7F7F dla górnego prawego. Widać więc ze rozdzielczość jest dramatycznie mała bo zaledwie 128x128. Należy jednak pamiętać ze ekran ma tylko7” więc nie jest to mocno odczuwalne . Możliwe że Kenwood chciał maksymalnie ograniczyć ilość danych. Ramki te są odświeżane również rzadko, bo co 100ms.

    Protokół Nawigacji Kenwood - reverse engineering



    Edytuj

    01FF0F - oderwanie palca od ekranu dotykowego, Wcześniejsza ramka od współrzędnych pojawia się w momencie dotknięcia ekranu ta natomiast sygnalizuje moment oderwania palca.

    Paczka danych z nawigacji:

    8134FF84 - odpowiedź nawigacji na 010FFF0F
    Oprócz tego jestem pewien że istnieją jeszcze paczki wyciszające radio lub inne źródło w momencie komunikatów od nawigacji tego jednak jeszcze nie sprawdzałem.

    C) Sygnał wideo
    Sygnał wideo to RGBS czyli RGB z połączonym sygnałem synchronizacji. Pierwsze próby wykonywałem z kartą NVIDIA GTX750Ti. Sygnał RGB można bezpośrednio podłączyć ze złącza VGA natomiast S wymaga konwersji. Zastosowałem układ jak z poniższego schematu. Jest on po części kopią układu instrukcji serwisowej.

    Protokół Nawigacji Kenwood - reverse engineering



    Edytuj

    GTX750 umożliwia regulację timingów sygnału RGB w bardzo szerokim zakresie, więc ponownie metodą prób i błędów udało się uzyskać stabilny obraz na wyświetlaczu radia Kenwood. Potem za pomocą programu Phoenix EDID designer utworzyłem wsad EEPROM tak żeby dało się oszukać dowolną kartę graficzną, że podłączony jest do niej prawdziwy monitor. Wymaga to oczywiście podłączenia prawdziwej kości EEPROM do linii DDC w złączu VGA.
    Protokół Nawigacji Kenwood - reverse engineering Protokół Nawigacji Kenwood - reverse engineering


    Próby z pamięcią do której załadowałem EDID pokazały, że nie wszystkie karty graficzne będą w stanie obsłużyć obraz o takich parametrach. Nowoczesne karty graficzne są przystosowane do częstotliwości odświeżania poziomego w granicach 30kHz i więcej. Tutaj natomiast mamy niecałe 16kHz. Próbowałem uruchomić wygnał wideo z dwóch laptopów z kartami ATI ale bezskutecznie. Udało mi się natomiast z Intelem GMA950 ale dopiero po wygenerowaniu własnego sterownika.

    Układ testowy:
    Celem tego tematu nie jest omówienie kompletnego urządzenia a jedynie protokołu komunikacji i sygnału wideo. Opisze jednak w kilku zdaniach moje wstępne "dzieło". Do obsługi linii RX/TX użyłem mikrokontrolera AVR który udaje moduł nawigacji i zgłasza cyklicznie paczkę 8134FF84. Jednocześnie odczytuje on wszystkie dane wysyłane od radia i szuka w nich sygnałów dotyku. Następnie za pomocą interfejsu USB HID wysyła do komputera (lub czegoś innego, np. Paspberry PI) Program został napisany w C z użyciem biblioteki V-USB tak skonfigurowanej, że AVR zgłasza się w systemie jako ekran dotykowy. Jak już wiedziałem jak przesłać sygnał wideo użyłem do tego celu Raspberry Pi i konwertera HDMI->VGA oraz tak skonfigurowałem timingi HDMI aby obraz był przyswajalny dla Kenwooda. Co z tego wyszło można obejrzeć na filmie.


    Fajne!
  • #2 25 Lip 2016 22:15
    DJ_KLIMA
    Poziom 12  

    Taka sztuczka, video analogowo rgb ale trzeba udawać poprawną komunikację, gratuluje, mi osobiście by się nie chciało.

  • #3 26 Lip 2016 19:33
    Gostek
    Poziom 17  

    Super! Miałem taaaaki plan, żeby też się kiedyś za to zabrać. Po pierwsze dlatego dlatego, że irytowal mnie komunikat o bezpieczenstwie, po każdym włączeniu zasilania, po drugie, żeby przełączac źródło na kamere cofania. W moim samochodzie (SAAB 9-5) jest fabryczny monitor multimedialny Kenwooda, ale w wersji dla SAABa. Oryginalnie była tam nawigacja KNA-DV2200, potem zmieniłem na KNA-DV3200, a potem na KNA-G520 która jeździ ze mną do tej pory.
    Z panelem LCD w KVT-520 też walczyłem - podłączyłem panel z innego Kenwooda, kombinując synchronizację i.t.p bramkami TTL :) wszystko jeszcze leży w garażu :).
    Skończyło się na zeskanowaniu sygnału oryginalnych pilotów Kenwooda, a potem wygenerowaniu nieistniejących za pomocą AVR'a - nie pamiętam już co z tego wyszło :)

    Tak czy inaczej, gratuluję entuzjazmu :)

  • #5 28 Lip 2016 19:49
    Gostek
    Poziom 17  

    Milek79 napisał:
    Po co AVR? Przecież RPi ma UART.


    PC też ma...:)
    RPi był podłączony tylko do testów. Mając AVR jako emulator NAVI, można podłączyć inne żródło video, bez potrzeby jeżdżenia z RPi.

  • #6 03 Sie 2016 10:10
    Krazykilla
    Poziom 12  

    Witam!

    Posiadam samochód Nissan Primera P12 z oryginalnym monitorem, który również ma wejście RGBS.

    W odróżnieniu do autora tematu, ja chciałbym wymienić cały monitor, aby dodatkowo podłączyć stację multimedialną.

    Czy jest możliwe przekonwertowanie sygnału RGBS na RGBVH (czyli zwykłe VGA)? Jeśli nie, to czy istnieje jakiś prosty konwerter do zamiany RGBS na Composite Video?

  • #7 03 Sie 2016 14:17
    gaspaccio
    Poziom 16  

    Witam
    istnieje całkiem prosty konwerter: MC1377
    Znalazłem go przy szukaniu materiałów do moich prób:
    Link do artykułu

    Układ jest jeszcze dostępny w niektórych sklepach za mniej jak 10zł, więc można próbować.

  • #8 03 Sie 2016 15:24
    Krazykilla
    Poziom 12  

    Dziękuję za odpowiedź.

    Konwersja RGBS do Composite wydaje się więc banalna.
    Otwarta pozostaje sprawa Konwersji RGBS na RGBVH (VGA). Czy ktoś może spotkał się z podobnym konwerterem/układem? Czy jest to w ogóle możliwe? Domyślam się, że ogólnie to wszystko jest możliwe, ale żeby jeszcze było cenowo przystępne :D

    EDIT:
    Szukałem i coś znalazłem:
    Do wytworzenia "czystego" Csynca oraz Vsynca z composite video można użyć LM1881:
    Protokół Nawigacji Kenwood - reverse engineering

    Do otrzymania czystego Hsync potrzebne są 3 brami AND:
    Protokół Nawigacji Kenwood - reverse engineering

    Dokładniejszy opis na: http://shmups.system11.org/viewtopic.php?f=6&t=53367&start=30

    W moim przypadku już posiadam "czysty" Csync z racji sygnału RGBS. Może ktoś widział lepsze rozwiązanie?

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME