CIS IBUS Car PC mit Raspberry Pi

  • sorry für mein Unwissen: x18122?


    auch irgendwo im Kofferraum? darauf bezog sich die Aussage vor ein paar Seiten nämlich... I forgot that :-D

  • Ja, wie gesagt, da läuft ein einzelners rotgelbes Kabel zur Heckklappenwarnleuchte, wo dieses Signal draufliegt. X18122 ist ein Stecker im Beifahrerfußraum. (Laut WDS alles, ich hab die Leitung selber noch nicht gefunden, weil die (so vermute ich) am einfachsten hinter der C-Säulenverkleidung zu finden ist.)


    Am Navi selber gibt es dieses Signal nicht, das legt sich per Busbefehl schlafen.


    Edit: Ach Du hast ja nen E46, da musst Du im WDS selbst mal suchen, ob Du das auch hast.

  • Hi all) i have some question=)
    can i use coaxil digital input in DSP? now i connect raspberry instead of radio module. i have no cd-changer. I tried to connect digital audio to dsp but do not play. I should like to enable this input? or my sound card is wrong? i use PCM2704

  • Zitat

    Original von PeteAU
    Nice work. I've also installed a RPi in my E46 and made a custom board for ibus/power supply: http://forum.e46fanatics.com/showthread.php?t=940693&page=2


    I will have to catch up and read the 39 pages here to see the differences between yours and my installation.


    Sorry for the English :)


    Nice work, your uc controlled power supply looks a lot more professional than mine ;)


    I posted the schematics and pcb layout of my uc controlled supply some pages before along with some pictures.


    I did not connect the power supply to the ibus and did not use any relays, like you. Instead I switch the pi voltage only with a mosfet and the uc communicates with the pi using two gpio pins and has some binary inputs for car signals like ignition or sleep signal.


    --------------


    Nachdem ich nun mit meinem hardwarekrempel fertig bin, habe ich mir die ganze chose ins auto gebaut und in Produktivbetrieb genommen. Das Gehäuse ist derzeit eine Amazon- buchversandverpackung aus Pappe, die ordentlich befestigt sömtliche Komponenten, also die hdd, den Hub, den Pi und die Spannungsversorgung enthält u d mit entsprechenden Löchern für die Anschlüsse versehen wurde ;)


    Diese habe ich nun temporär mit Klettband m kleinteilefach der Reserveradmulde untergebracht.


    Demnächst schustere ich mir ein Gehäuse, welches schön zwischen cd-wechsler und Navirechner in das Seitenfach gehängt werden kann.


    Da ich mich bisher noch nicht mit der openbm-installation befasst habe, habe ich die letzten beiden Tage meine Carmedia-installation von voreinigen Wochen verwendet.


    Der Produktivtest hat einerseits gezeigt, dass meine versorgungsplatine eins-a funktioniert.


    Andererseits muss ich Carmedia als unbrauchbarfürmich bezeichnen. Auf einem Linuxrechner scheint es kaum sinnvoll nutzbar zu sein. Mein hauptanspruch an den carpc ist die Musikwiedergabe, daher lege ich dort mein Hauptaugenmerk drauf. Carmedia schaft es nicht, meine Sammlung in seine Datenbak einzulesen. Das mag an der größe von 200gb liegen oder an der externen Festplatte.


    Die wiedgabe über Music Files funktioniert zwar, ist aber für mich nicht brauchbar. Die wiedergabe hat häufig grauenhafte Attefakte und vor allem brechen 99% der Titel mittendrin einfach ab. Ich muss dann manuell den nachsten Titwl anfordern, damit ich wieder etwas höre. Manche titel werden einfach garnicht abgespielt.


    Das Programm selbst reagiert manchmal gar nicht oder mit großer Verzögerung. Einige Male ist es kommentarlos abgestürzt.


    Unter windows ist carmedia denke ich echt eine sehr schöne Software, unter Linux mit Mono und speziell auf dem Pi eher nicht benutzbar.


    Gruß

  • Zitat

    Andererseits muss ich Carmedia als unbrauchbarfürmich bezeichnen. Auf einem Linuxrechner scheint es kaum sinnvoll nutzbar zu sein. Mein hauptanspruch an den carpc ist die Musikwiedergabe, daher lege ich dort mein Hauptaugenmerk drauf. Carmedia schaft es nicht, meine Sammlung in seine Datenbak einzulesen. Das mag an der größe von 200gb liegen oder an der externen Festplatte.


    Genau zu dem Schluss bin ich auch nach zwei/drei Testfahrten gekommen.


    Schau dir mal das RaspBMC Image an, ist noch sehr rudimentär, allerdings funktioniert Musikwiedergabe schon problemlos. Die Datenbank kann sehr viele MP3s einlesen und auch super verwalten, Playlists, Smartplaylists, Coveranzeige etc. pp. (XBMC eben).
    Ich habe gestern angefangen ein XBMC-Fenster für das visuelle PDC für den Skin zu bauen. Außerdem bin habe ich angefangen ein Testgateway zu programmieren mit dem man IBUS Signale simulieren kann um nicht immer im Auto testen zu müssen. Leider habe ich mich dann den halben Tag daran aufgerieben, das auch unter Windows zum laufen zu bringen (Für Tests). Aber ich bekomme dort einfach die Python Bibliothek nicht im Netbeans gelinkt (cygwin mit g++ und make) :(


    Ein guter Skinner könnte damit sicher das nette CIC von BMW nachbauen - das wär doch mal was ;)

  • Hmm, wenn ich jetzt auch noch anfange, zeug für das alles zu programmieren, dann brauchen wir allmählich ne funktionierende Lösung für EIN aktives github repo. Entweder wir zentralisieren alles im psyborg repo oder wir nehmen das raspopenbm-repo. Sonst haben wir irgendwann tausend zerfledderte baustellen :)

  • Da hast du vollkommen Recht. Problematisch daran ist momentan nur, das es zwei verschiedene Ziele gibt und unterschiedliche Komponenten betroffen sind, die evtl. voneinander abweichen werden.


    1. PC/Pi ersetzt nur CD-Wechsler und sorgt für Multimedia, es bleibt sonst alles Original. (Nur Tasten die im Wechselmodus ohne Funktion sind nutzbar - 1,2,3,4,5,6,info,phone,<,>,<>,clock,sel,rechter dreh-/drückknopf)
    2. PC/Pi ersetzt alles und benutzt umgebautes Navi-Display (Alle Testen nutzbar, Psyborgs Ansatz)

  • Er kann auch alles ersetzen und Braucht kein umgebautes Display. Geht doch mit dem Standard bm auch.


    Ich bspw bräuchte das wechsler und radioplugin gar nicht. Mir würde ein einschalten des Video Signals über die rückfahrkamera bei AUX reichen. Radio und Wechsler würde ich dann ja ganz normal bedienen können.


    Aber softwareseitig wären für solche Unterschiede doch auch nur eine Einstellung in irgend einem Menü nötig.

  • Momentan gibt es imho mehrere Baustellen:
    - Skin an die Auflösung anpassen (800*480? müsste der BM haben) momentan kann man in einigen Listen beim 702p Skin kaum was erkennen.
    - OpenBM-Gateway anpassen damit die OnMessage-Callback einen Pointer auf die Instanz des Python-Daemon bekommt (damit Flags gesetzt werden können um aufeinanderfolgende Messages korrekt interpretieren zu können - short/long press, nur auf Msg reagieren wenn Pi-Bild aktiv, PDC-Änderungen und Timouts)
    - Settings für den Python-Daemon welche Audio- und Videoeingangsschnittstelle benutzt werden soll, damit die verschiedenen Scenarios abgedeckt und korrekt gesteuert werden (CD-In, Aux-In, CIS-IBUS- oder Rückfahrkamera-Bild)

  • Der bm hat leider nur 400x240. 800x480 wäre ein traum ;) da ist die openbm hardware weit voraus. Ich glaube im xbmc wiki gibts ein brauchbares skinning tutorial. einfach nur größere Schrift statt nen ganzen neuen skin hältst du nicht für ausreichend? Zumindest für den Anfang meine ich mal.


    Morgen versuch ich mich mal an der Installation im bisherigen zustand. Hattest du das raspbmc Image mit den modifikationen des patchs schon irgendwo geuppt?

  • Oh echt? Irgendwo hatte ich das gelesen. Okay.. das ist natürlich wirklich wenig :(


    ein ganz neuer Skin wird sicherlich nicht benötigt, die Schriftart einfach zu vergößern wird aber wohl leider auch nicht aureichen. Ich habe mal die Auflösung in der Addon.xml angepasst. Leider wird es selbst auf 720*480 nicht herunterskaliert sondern ab Rand abgeschnitten, es werden fast alle Elemente absolut positioniert.


    Für den Anfang reicht es auch so wie es momentan ist, man kann es schon noch erkennen, allerdings ist das lesen eines Track-Namens während der Fahrt nicht wirklich möglich. Vom Einstellen von Repeat und Shuffle im Sideblade will ich mal lieber gar nicht erst anfangen ;)


    Code
    Hattest du das raspbmc Image mit den modifikationen des patchs schon irgendwo geuppt?


    Eine neuere Version habe ich noch nirgends geuppt, die Modifikationen müssen am Source des OpenBM Moduls durchgeführt werden damit man es mit der aktuellen boost library kompilieren kann. Im Image ist noch das von schlanD kompiliert Modul. Macht aber nix, da ich nur testweise Änderungen am Source vorgenommen habe (um es zu verstehen). Ich habe noch keine wirklich einsetzbäre Änderung vorgenommen, ausser das kompilierbar machen :lol::lol:


    Ich habe gerade mal ein Pull Request für den Patch auf github gemacht, dann kann man direkt eine kompilierbare Version runterladen..


  • The relays are only for video switching, not the power. I guess OpenBM scared me when I saw some Python, the Pi isn't very fast at executing something that heavy. Also I don't use the Resler interface, my board has its own so I save both Pi's USB ports for other uses.


    My software is very small & light (16KB compiled) and basically emulates a keyboard to fool xbmc.


    How do you wake your system up when its gone to sleep if the uC isn't on the ibus?


    Info at: http://www.classiccomputing.info/pibus/

  • Zitat

    I guess OpenBM scared me when I saw some Python, the Pi isn't very fast at executing something that heavy.


    The heavy part is written in C++ using the very fast boost libraries (openbm-gateway, openbm module) only the communication between openbm module and xbmc is realised in python:


    openbm-gateway <--tcp--> openbm module <--c-Extension--> openbm addon


  • The usagee of openbm combined with raspbmc on the pi has a big advantage imho: raspbmc runs in the framebuffer and does not require Xorg.
    The core of Openbm is still c++ and thus the system is quite fast. The users datobi2k and schland from here do run the openbm system on the pi in their car. I will also start with it in the next days. I spent the last two months mostly by doing the supply stuff.


    Because my PCB lacks an ibus connection atm (wont be a big thing to make the next one with an ibus interface) i have to use binary inputs generated by the car to start and shutdown the pi. Atm i use a rising edge on the ignition position 1 (connector r) to turn the power on. A falling edge on that pin is afterwards used to start a 15 minute timer. When the timer is not stopped before it reaches the 15 minutes (by pressing a manual override switch on the pcb or by re-switching the ignition on), a shutdown on the pi is triggered. When the shutdown was successful, the power is being switched off.


    There is a wire in the car that goes LOW when the car goes to sleep. So imstead of using my current setup, one could easily use that wire instead and get rid of tha 15 minute timer.


    But for now I am to lazy to search that wire in the back of the car, so i use the solution described above.

  • Zitat


    The usagee of openbm combined with raspbmc on the pi has a big advantage imho: raspbmc runs in the framebuffer and does not require Xorg.


    Not only that: If we all use this system we can all benefit of patched bugs and additional features. Hence, everybody is encouraged to contribute to the project.


    Zitat


    The core of Openbm is still c++ and thus the system is quite fast.


    Exactly, it is just very lightweight system running in background not even consuming much CPU power. Openbm-gateway is implemented completely asynchronous, hence CPU consumption is minimal. However, as already pointed out, in order to have xbmc "talking" to it, something on XBMC side is required, which is written in python. But this is not a big issue, since all XBMC plugins are rather python scripts and openbm-plugins doesn't take much CPU power, since here again, the implementation is event based.


    Zitat


    Atm i use a rising edge on the ignition position 1 (connector r) to turn the power on. A falling edge on that pin is afterwards used to start a 15 minute timer. When the timer is not stopped before it reaches the 15 minutes (by pressing a manual override switch on the pcb or by re-switching the ignition on), a shutdown on the pi is triggered. When the shutdown was successful, the power is being switched off.


    You can also directly connect to IBus and use the data running over it to control your timer. If car goes to sleep then there will be no communication over the ibus and hence it stays HIGH. (Here one need to check if it goes to LOW when car is in deep-sleep). Just connect your timer input to IBus and restart timer if something happens on the bus. If nothing happens for at least 5 minutes, then you can be sure, car is sleeping.


    Nice thing about connecting to IBus, that your Pi will start as soon as there is communication again, which happens when you unlock the car for example. This way you can enter the car and your XBMC is already running ;)

  • Zitat

    Original von psyborg


    Not only that: If we all use this system we can all benefit of patched bugs and additional features. Hence, everybody is encouraged to contribute to the project.


    Yep I'd prefer to collaborate, otherwise it's too hard for one person to make progress. At the moment I can't use OpenBM because my hardware isn't using the TH3122, so I do collision-detect/retransmit in software.


    I believe OpenELEC doesn't use Xorg either, or am I wrong?


    Zitat


    Exactly, it is just very lightweight system running in background not even consuming much CPU power. Openbm-gateway is implemented completely asynchronous, hence CPU consumption is minimal. However, as already pointed out, in order to have xbmc "talking" to it, something on XBMC side is required, which is written in python. But this is not a big issue, since all XBMC plugins are rather python scripts and openbm-plugins doesn't take much CPU power, since here again, the implementation is event based.


    To get information from xbmc back to OpenBM? I never do that, what do you use it for?


    So, what is the preferred xbmc skin for the low-res monitor? I've been experimenting using "diffuse" with some larger fonts. It's not bad, but some menus require LEFT/RIGHT and UP/DOWN which is annoying when using the rotary encoder.


    Another thing I was thinking of trying is switching the video to PAL to see if it's a little sharper. I get the feeling the TV/VIDEO module has some kind of low-pass filter softening the video too much. Maybe there's a cap to be removed :)

  • Zitat


    Yep I'd prefer to collaborate, otherwise it's too hard for one person to make progress. At the moment I can't use OpenBM because my hardware isn't using the TH3122, so I do collision-detect/retransmit in software.


    I think this shouldn't be a big issue, as long as you can provide some information about the collision, you can use the openbm-gateway code for you. Take a look into IBus.cpp in the gateway/server code, there is a method getCTS() which need to be handled appropriately if not using a chip able to detect collisions. Everything else like retransmitting is done by the gateway.



    Zitat


    To get information from xbmc back to OpenBM? I never do that, what do you use it for?


    You probably mean "back to BMW". Take a look here:
    KLppIstZ-Js


    So, what do you think, what information is transmitted from XBMC back to BMW :) :) :) (look how radio and obc are controlled)


    Zitat


    Another thing I was thinking of trying is switching the video to PAL to see if it's a little sharper. I get the feeling the TV/VIDEO module has some kind of low-pass filter softening the video too much. Maybe there's a cap to be removed :)


    This is due to the fact, that TV/VIDEO is running over one cable I think, hence all three colors are overlayed over one line. Navigation is, however, connected through 3 lines, each for each color. Hence, you can't expect better quality over the TV/VIDEO line.

  • Zitat

    I believe OpenELEC doesn't use Xorg either, or am I wrong?


    you are right, same as raspBMC, but openelec removed some basic functionality from the OS to get the fastest system. So you have no apt, very frustating when you need to all this stuff on your own.


    Zitat

    To get information from xbmc back to OpenBM? I never do that, what do you use it for?


    Sending requests, like getting the time from cars bc i.e., the Pi loses his time everytime you disconnect him from power. Without internet connection he can't sync from the net.


    Zitat

    So, what is the preferred xbmc skin for the low-res monitor? I've been experimenting using "diffuse" with some larger fonts. It's not bad, but some menus require LEFT/RIGHT and UP/DOWN which is annoying when using the rotary encoder.


    At the moment the best experience is with the "old" confluence vertical, every daily use operations are controlled by up/down/press, but some text is very small (like in playlists) - here somebody (who is able and has time) has to work on abit..

  • Zitat


    At the moment the best experience is with the "old" confluence vertical, every daily use operations are controlled by up/down/press, but some text is very small (like in playlists) - here somebody (who is able and has time) has to work on abit..


    Here's my slightly modified "diffuse" skin.
    The left/right thing is annoying in a few places (settings), but should be fixable. The file-list screen needs the overscan adjusted.
    wY7_PGp_LwE