Beiträge von PhreakShow

    Also ohne Witz, so heftig wie sich das HUD wehrt, könnt man meinen da ist irgendwas im Busch. Ich krieg mit dem Board von oben ums Verrecken keinen Link hin, deswegen ein neuer Ansatz:


    Das HUD hat, wie auch das CID, einen Indigo-Chip drauf. Im Prinzip ist das anscheinend ein Demultiplexer, oder De-Serializer. Aus dem APIX-Datenstrom werden Bilddaten, Steuerungsinfos für Hintergrundbeleuchtung, etc, entpackt und an die einzelnen Teilnehmer verteilt. Wenn ich einen Sender einstellen will, dass er mit dem Indigo reden kann, müssen beide das gleiche Protokoll sprechen. Das will ich nun rausfinden.


    IMG_8271.JPG


    Hier ein Foto der HUD-Platine. Links der Indigo, mittig der HSD-Anschluss. Nach was suchen wir?


    Im Entwicklungsprozess muss es vmtl möglich gewesen sein, die Dinger zu debuggen, bevor es überhaupt einen Link zur Serie geben kann. Also suchen wir Lötpads, die unbestückt sind und mindestens eine handvoll Leitungen anbinden. Laut Datenblatt des Indigo ist die Verbindung per SPI möglich. Für SPI brauchen wir sinnvoll mindestens:


    MOSI (Master out Slave in)
    MISO (Master in Slave out)
    Masse
    Takt


    Und oft noch Chipselect, damit der Teilnehmer weiß dass er gemeint ist. Also mindestens fünf Signale, wovon eines quasi überall auf der Platine verfügbar ist...


    IMG_8275.jpg


    Guck an, was haben wir da? Der Anordnung nach ist das der vorgesehene Platz für ein Widerstandsnetzwerk, wie man drumrum einige sieht. Ergibt auch Sinn, zur Sicherheit und Strombegrenzung kann man das mal machen.
    Hinter dem rechten Kringel ist der gesuchte, unbestückte Header auf der Platine.


    Was mich echt viel Zeit (mind. einen Tag) gekostet hat, war die korrekte Beschaltung mit Widerständen... nur in der Konfiguration bekomme ich hin und wieder Antworten vom Indigo:


    IMG_8276.JPG


    Ich hatte kein Netzwerk, deswegen habe ich zwei Pullups manuell eingelötet. Der eine hätte vmtl genügt, der zieht die ChipSelect-Leitung im Ruhezustand nach 5V, und wird von der Master-Gegenstelle bei Kommunikation nach Masse gezogen. Dann weiß der Indigo, dass er jetzt gemeint ist und ab gehts... jetzt hätt ich gern ein Abbild des Flashes, und ne Doku was wo steht :)

    Würde TV in den Headunit-Optionen einschalten und das Videobild am CVBS-Eingang anschließen, da gibts sicher Adapter. Danach der HU noch "sagen" dass ein TV-Modul verbaut ist, und ab gehts.

    Zum Thema Werkzeuge habe ich noch etwas. Wenn ich auf dem HUD endlich mal ein Bild bekomme, möchte ich ja zwischen Serienbild und Nivi-Bild umschalten. Dazu muss ich den APIX-Link trennen und neu verbinden.
    Das kann man elektrisch tun über FPGAs und Scheiß, das ist ein riesen Fass das ich nicht öffnen möchte. Meine Hoffnung ist, dass die höchsten wesentlichen Frequenzen im APIX-Datenstrom klein genug sind um den Datenstrom mechanisch, mit einem HF-Relais zu schalten. Dazu muss ich wissen, was da denn so für Frequenzanteile drin ist.


    Das kann man entweder über eine Fouriertransformation aller gemessenen Werte tun (wie das manche Oszilloskope können), über mit einem Heterodyn-Spektrumanalysator. Da Oszis über 1GHz sündhaft teuer sind, kommt bei mir letzteres zum Einsatz.


    IMG_8267.JPG


    Damit möchte ich dem APIX-Link zu Leibe rücken, sobald ich einen passenden Tastkopf habe. Davon hängt dann ab wie penibel ich die Leiterbahn auslegen muss, welche Leiterbahn-Längendifferenzen in Ordnung sind (abhängig von der Wellenlänge der Signale), etc. Aber noch fehlt mir ein APIX-Link...

    Mal als Einschub zwischendurch, weil ich immer wieder Nachrichten bekomme in denen Leute fragen, mit welcher Hardware ich die Spielereien auf dem CAN und LIN anstelle:


    IMG_8260.JPG


    Bisher habe ich immer das obere Teil benutzt, das ist ein chipkit max32 mit dem Network Shield für 2x CAN, die kann man fertig kaufen.


    Das hat aber Nachteile: Es sind keine Anschlusskabel dran, es ist riesig und sperrig, es gibt keine vernünftigen Gehäuse, es wird über einen Linearregler versorgt und bei der Menge an Peripherie wird der sauheiß.


    Deswegen habe ich die letzten Wochen eine eigene Platine entwickelt, auch mit einem PIC32. Die hat 50mm x 37mm, passt in übliche Gehäuse und hat nur das nötigste drauf.
    Zwei CAN-Transceiver (TJA1043 und 1042), erster kann den Linearregler bei Busaktivität einschalten, ansonsten ist alles spannungsfrei und kann an Dauerplus hängen.
    Zwei LIN-Transceiver (bzw ein Gehäuse mit zwei integrierten, TJA1021 bzw TLE7268), kann auch bei Busaktivität den Regler wecken.
    Ein Vierkanal-Highside-Treiber mit Bums, wenn man mal was schalten will.
    Vier ADC-Eingänge zum Einlesen beliebiger Taster.


    Das Ding hat zwar auch einen Linearregler, aber da habe ich mich absichtlich für entschieden. Schaltregler sind oft üble Strahlenkanonen und stören u.a. Radio- und GPS-Empfang.
    Ich denke den werden wir im Forum noch öfter sehen :)

    Sicherlich unterschiedliche Entwickler, das CID wird vom Alpine gebaut und das HUD schnitzt glaub ich der Conti. "Standard" ist so ne Sache, APIX ist in der Hinsicht wie CAN. Der kann ja auch mit 100kBit/ oder 1MBit/s oder allem dazwischen laufen, und APIX kann iirc 500MBit oder 1Gbit haben, APIX2 dann 3GBit. Aber das ist nicht der einzige Parameter den man braucht.

    Danke. Das wird noch spannend :)


    Gestern mal gaudihalber das HUD statt des CID angeschlossen, es kommt nicht mal ein APIX-Link zustande. Irgendeine Einstellung auf dem "physical layer" ist schon falsch.
    Das Board hat eine Status-LED, die geht aus wenn der Link steht. Deswegen sieht man die auch nicht in meinem Foto. Beim HUD bleibt die an.


    Das gemeine ist, die Firmware vom NBT ist schnell entpackt und durchsucht, weil ein richtiges Dateisystem dahinter steht.
    Die Firmware vom Kombi habe entpackt vorliegen, und dort sehe ich einige APIX-relevante Daten, aber nicht die richtigen, wie mir scheint. Das Durchsuchen ist auch wesentlich schwieriger, weil das einfach ein Haufen hexadezimaler Werte in einem Hexeditor ist.

    IMG_8252.JPGIMG_8253.JPG


    Der APIX1-Link steht schon mal. Gegenstelle ist hier ein F30-8,8"-Display. das Videosignal kommt per HDMI von meinem Notebook.


    Problematisch bei der ganzen Geschichte ist, aus den Unmengen an Parametern die richtigen auszuwählen und für die auch noch die richtige Werte zu kennen.


    Dummerweise ist auf dem Display ein Watchdog aktiv, der das Display auf "no signal" schaltet wenn keine Bilddaten kommen. Ebenfalls dummerweise ist das ganze nicht plug n play, sondern man muss allerhand Werte zum Display schicken bevor das überhaupt irgendwas tut.


    Am schlimmsten von allem ist, dass das Display alles sauber ignoriert was man so schickt, bis es mit einer speziellen Sequenz freigeschaltet wurde. Das Display hat natürlich keinen CAN, wie das in den E90-Modellen der Fall war, sondern die Kommunikation läuft einzig über APIX. Von den Entwicklern wurde anscheinend im APIX-Protokoll vorgesehen, dass man auf der Empfängerseite Peripherie steuern muss, z.B. Motoren, Dimmung per PWM, Lichteffekte, etc. Über diese Sidebandkommunikation kann man auf verschiedene Busse (I2C, SPI) Kommandos schicken, so eben den unlock, die Helligkeit, etc.


    Praktisch, dass man alles nötige findet, wenn man an den richtigen Stellen sucht. Dazu muss man die Firmware ausgewählter Steuergeräte (zB NBT) entpacken, oder auf der Konsole eines NBT die entsprechenden Dateien suchen und den Inhalt benutzen, um das Display in gang zu bringen.


    Das war der erste Streich, um überhaupt eine APIX-Verbindung lauffähig zu bekommen. Als nächstes muss man das noch irgendwie aufs HUD übertragen.