Projekt: IBUS Komfortfunktionen über Raspberry Pi realisieren

    Müsste mal noch die Leistungsaufnahme vom Pi messen mit dem Interface dran, der dürfte bei < 1 Watt liegen.
    Braucht man eben noch einen effizienten DC/DC Wandler, um da nicht ordentlich Strom zu verbraten, und schon hat man überhaupt keine Probleme den Pi 24/7 Laufen zu lassen.
    Rein theoretisch müsste meine Autobatterie mit dem Pi gut 60 Tage durchhalten bis sie leer ist. Das wäre dann vernachlässigbar.


    Andererseits könnte man (wenn man das ganze auf Pi basis fertig entwickelt hat) immernoch über eine andere Hardware nachdenken. Das "portieren" des Codes ist dann reine Fleißarbeit wenn man beide Sprachen beherrscht.

    Ich gebe zu bedenken, dass Autobatterien nicht zyklenfest sind. Die haben es gar nicht gerne langsam entladen zu werden, sondern sind dafür ausgelegt, dass kurzzeitig große Ströme fließen (Anlassen) und sie so schnell wie möglich wieder voll geladen werden.


    Klar, bei 1W ist das vielleicht noch nicht so dramatisch (man Stelle sich ein paar Stunden mit Stand-/Parklicht am unbeleuchteten Bordstein vor). Aber die Rechnung Batteriekapazität / Strom ist hier nicht das Hauptproblem.


    Der RPi A+ an sich kommt ohne Last mit rund 0,5 W aus. Aber mit Bluetooth, UMTS, Resler-Interface bist du schnell bei 5W würde ich schätzen (die meisten USB-Dongles sind nicht gerade auf Energieeffizienz ausgelegt). Wenn du dann gar den KBUS hoch ziehst kommen wir vermutlich in den Bereich des Standlichts ;)
    Also vorher mal genau nachrechnen und vor allem -messen, ob deine Wünsche so überhaupt umsetzbar sind oder dann nicht doch eher ein µC & Verzicht auf "Spielereien" wie UMTS sinnvoller ist.

    Mir ging es zwar in erster Linie um die Auslastung des Cores des Pi's. Allerdings ist der Strombereich dabei natürlich auch nicht zu verbachlässigen. Hier könnte man doch noch über ne Powercap wie bei Hi-end HiFi Autoanlagen nachdenken, um Leistungsspitzen bei Belastung des Pi's abzufangen. Je nachdem wie weit du die Sache tatsächlich treiben willst. Denn wenn wir zu dem Punkt kommen, Livedaten via UMTS an nen Server zu schicken, dann brummt der Pi bestimmt auch mal etwas Leistung durch...



    Gesendet von iPhone mit Tapatalk

    Davon gehe ich aus ;)
    Die Stromaufnahme des Pi ist lächerlich, schon ein Elko in der Größenordnung http://www.reichelt.de/Elkos-S…F-1000-10K-G/3/index.html sollte völlig ausreichen, um die Spannung zu stabilisieren (nichts anderes macht ja ein Powercap - nur halt in einer brachial anderen Größenordnung).


    Mein Beitrag vorhin hat sich im Übrigen eher auf das Problem des 24/7 Betriebs, den Dani angesprochen hat, bezogen. Da macht dann eben auch Kleinvieh großen Mist bzw. können ein paar Watt schon zu viel sein.


    EDIT: Link funktioniert nicht, aber ich dachte an einen 40 Cent SMD-Elko. Also quasi "Vogelfutter".

    Zitat von Adi-320i

    Sorry, jetzt ergibt mein Post mehr Sinn. Hab es editiert. Um Leistungsspitzen abzufangen, eben wie bei kräftigen HiFi-Anlagen. Oder hab ich jetzt einen Denkfehler?


    Ja, hast du. Weil du keine Lastspitzen durch den Pi hast die die Batterie nicht an könnte ;)


    Bzgl. Stromverbrauch... Pi A+ braucht mit WLAN Stick noch immer unter 1 Watt. Mach ich mir also keine sorgen. Und das Resler interface braucht deutlich weniger als ein WLAN Stick.
    UMTS ist eh Zukunftsmusik. Das könnte man auch auf nen 2ten Pi legen der nur im Betrieb an ist um Daten abzufragen wenn das auto verliehen ist bspw. (die idee dazu kommt NICHT von mir. mein auto bekommen eh nur leute denen ich 100% vertraue, da brauch ich das nicht).

    Trotzdem die Frage: Wie gedenkst du mit dem KBUS umzugehen, wenn der Motor nicht läuft? Falls der immer aktiv sein soll, müsstest du den Bus-Master (IKE) aktiv halten. Der KBUS gibt spätetens 20 Minuten nach Zündung aus Ruhe. Man könnte ihn wieder aufwecken - aber dann wacht eben eine ganze Reihe von Steuergeräten auf. Und die Bordelektronik im E46 ist aus eigener Erfahrung - beim "Basteln" mit dem KBUS hab ich mir schon 2 mal ne leere Batterie beschert, jeweils innerhalb weniger Stunden - nicht gerade sparsam...

    Ich brauch den Bus nicht aktiv zu halten. Der Bus wird ja von alleine aktiv wenn ich aufschließe.
    Solange schläft alles, bis auf den Pi, der eben darauf wartet, dass der Bus aufgeweckt wird.


    Da das einen kurzen Moment dauert, braucht mein Coming home beim Aufschließen derzeit auch 1,5 bis 2 Sekunden bis es angeht nach dem aufschließen. Weil erst der Bus geweckt werden muss, und dann erstmal kurz ein paar Nachrichten drüber gehen, bis das GM dazu kommt sein "hey, hier hat jemand aufgeschlossen" zu senden.


    P.S.: Mein Pi läuft gerade übern Zigarettenanzünderadapter schon den ganzen Tag drausen durch. Jedes mal wenn ich rausgehe um mir ne Kippe ausm Auto zu holen weck ichs einmal kurz auf, das coming home geht an, und dann is wieder gut.
    Wetten, dass ich nacher einsteigen und losfahren kann und der Bus brav geschlafen hat bis dahin? ;)


    kleines edit dazu:
    der raspberry liest einfach den stream aufm bus ein. ist aufm bus nichts, dann macht er auch nichts. sprich: erst wenn er überhaupt ein (gültiges!) Datenpaket empfangen hat, macht er überhaupt irgendetwas. Will heißen wenn aufm Bus nichts los ist, ist auch der Raspberry völlig im idle bis auf den listener eben der auf datenpakete wartet.
    schließe ich jetzt auf, dann erwacht der bus zum leben und irgendwann sendet das Grundmodul eben die Nachricht auf den Bus, dass von Remote aufgeschlossen wurde (inkl. Schlüsselnummer). Diese Nachricht würde z.B. die Sitze dazu bewegen sich dem Schlüssel entsprechend einzustellen. In dem Fall reagiert eben der Raspberry auch auf die Nachricht und sendet per Diag an das LSZ, dass ich gerne abblendlicht und standlich hinten an hätte.
    Und genau so passiert das derzeit auch bereits ;)

    Deshalb ja die Frage, was du mit dem Bus anstellst, wenn der Motor nicht läuft. ;)


    Jetzt wird mir auch klar, was du eigentlich vor hast. Der RPi bleibt "always-on", damit er sofort da ist. Außerdem sparst du dir die Problematik, einen sauberen shutdown durchzuführen.
    Wenn es bei dem Watt Leistung bleibt, dann ist das durchaus 'ne sinnvolle Variante.



    Um mal noch einen anderen möglichen Fallstrick anzusprechen: Hast du dich schon mal über die Temperaturempfindlichkeit des RPi informiert? Zumindest die Nicht-Plus-Variante lief ja ohne Kühlung mitunter ganz schön heiß. Italienurlaub im Sommer, 60°C Umgebungstemperatur im Auto - was macht er da? Nur ins Throttling gehen oder gleich komplett den Betrieb einstellen? Auch zweistellige Minustemperaturen können ICs zum Problem werden, wenn sie nicht darauf ausgelegt werden.


    EDIT: Für später könnte man im Übrigen den zusätzlichen Zwischenschritt über USB (KBUS -> UART -> USB -> RPi) einsparen. Der RPi hat ja genügend GPIOs um direkt an die UART des TH3122 im Resler-Interface zu gehen.