Protokół Nawigacji Kenwood - reverse engineering

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.


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:


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.





Edit

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.





Edit

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.



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.