Beiträge von Dani

So, ich Update mal den aktuellen Stand derzeit:

- Beim aufschließen geht Licht an
- Beim abstellen vom Motor wird die ZV geöffnet (da ich das automatische verriegeln aktiv hab ganz praktisch) und das Licht angesteuert zum Aussteigen
- Beim abschließen passiert nichts. wird am Schlüssel nochmal auf abschließen gedrückt wird das Licht erneut angesteuert

Tippblinken wird nochmal ne Ecke komplizierter als es sowieso schon ist. Unterbrechen ist kein Problem, derzeit hab ich eher ein Problem das passende TriggerSignal zu finden um es zu aktivieren.

Als nächstes hab ich noch vor beim 2ten mal abschließen direkt alle Fenster zu schließen ohne den Knopf am Schlüssel gedrückt halten zu müssen.

In jedem Fall werden die Funktionen langsam etwas praktischer
Delay hab ich auch komplett entfernt bekommen (ca. 50ms). CPU-Auslastung ist dadurch leicht höher. Bin jetzt bei ca. 1% im Schnitt mit dem Programm.

edit: okay.. fenster zu hab ich grad noch programmiert. morgen mal testen. heute nicht mehr^^

edit2: was ich in jedem fall noch machen werde sobald meine Relais platine kommt. das booten vom navi über den GPIO anschluss vom pi steuern. vmtl. in meinem fall mit unterbrechung der remote-leitung zu den endstufen, dass musik erst mit Radiostellung startet und nicht schon vorher losgeht

Ich komme aus Heilbronn (BW). Vorbeikommen könntest wegen mir schon mal^^

Zitat von HotSpot

Danach gehts zum Optimierer. Werde ihn auf ca. 255PS mit 510Nm abstimmen lassen. Mehr wäre durchaus möglich, allerdings macht dann das ZMS und auch die Kupplung probleme.

Mehr als 260PS machen auch die Injektoren nicht mit, das liegt nicht nur an ZMS und Kupplung. Und ob die Serienkupplung die 510Nm WIRKLICH mitmacht, darüber reden wir dann nochmal wenn das mal 6 Monate so gefahren bist

Zitat von ZwoCa

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

Jupp. Motor läuft wäre nicht das Kriterium, sondern eben bus schläft. wenn der bus schläft darf er schlafen. VOR dem aufschließen vom Auto will ich gar nichts machen damit. wüsste auch nicht was ich tun wollte^^

Zitat von ZwoCa

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.

joa, es geht darum, dass er eben beim aufschließen schon an sein sollte um coming home zu machen.

Zitat von ZwoCa

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.

das wird sich wohl zeigen. da er eh keine nennenswerte beschäftigung hat (da möglichst sauber programmiert, auch wegen möglichst geringem delay eben), mache ich mir wegen wärme wenig sorgen. Kälte wird sich zeigen.

Zitat von ZwoCa

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.

Darüber hatte ich auch schon nachgedacht, das wäre aber wirklich so eine "last step" geschichte.

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

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).

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.

Das klingt schonmal nicht ganz schlecht @Adi-320i. sieht man ja dann wie weit es da ist.
Da ich eigentlich so gar nicht der Programmierer bin (Systemintegrator eben), wäre es halt super da jemand zu haben der den programmiertechnischen Teil dann wirklich drauf hat. Ich hab halt mehr so die Schnittstellen, kbus usw im Kopf als das Code da reinhacken
Dennoch hats bis hierhin verdammt gut geklappt mit Python (ist ja auch nicht gerade die schwerste Sprache). Nur fürs formatieren der Strings, Checksummen- und Längenberechnung, Multithreading usw. hab ich halt ne Ecke gebraucht. Das ist eigentlich schon zu tief in der Materie für einen nicht Programmierer. Wer sich mal damit beschäftigt hat, der wird mich garantiert verstehen :'D

Achja. Wer kein Wort von alldem versteht, bitte einfach still und heimlich weiterscrollen

So. Nach Auskunft des Forums liegt die letzte Nachricht hier mehr als 586 Tage zurück und ich soll ein neues Thema erstellen. macht aber nix, es gibt Neuigkeiten.

Nachdem ich mir nun das Erisin eingebaut hab, hat es mich wieder in den Fingern gejuckt hier weiterzumachen.
Hab mir nen Raspberry Pi A+ bestellt aufgrund der geringen Stromaufnahme, und den mit einem Resler Interface ausgestattet.

Nach einiger Einarbeitung in Python hab ich nun ein Programm am laufen das die einzelnen Datenpakete vom Bus auswertet und ggf. ein event triggert woraufhin eine action ausgelöst wird.
Die events laufen jeweils in einem eigenen thread, d.h. ich kann parallel Dinge verarbeiten und auslösen ohne den normalen Ablauf aufzuhalten.
Da ich bspw. Tippblinken auch in einem eigenen Thread starten würde, könnte ich den thread auch wieder unterbrechen falls der Blinker in die andere Richtung betätigt wird. Soweit die kurze und knappe Theorie.

Praxis sieht so aus, dass ich mir mal ein Coming Home geschrieben hab das mir Abblendlicht+Standlicht hinten ansteuert wenn ich auf den Öffnen Knopf an der Fernbedienung drücke.
Die nächsten Steps werden jetzt das Automatische entriegeln beim Motor abstellen und dann werd ich das mit dem Tippblinken mal versuchen anzugehen.
Soweit bin ich mir inzwischen recht sicher, dass ich das auch umsetzen kann kurzfristig.

Da diese Dinge aber auch schon diverse andere am Markt erhältliche Produkte können (elight, intravee, UM-Ibus usw.), und ich das Projekt nicht nur aus kostengründen auf der Rapsberry Pi Basis mache (raspberry pi 25€+resler Interface), kommt das Interessante dabei noch:
Ich hätte gerne Schnittstellen:
Zum einen Bluetooth zum Android based Navi, Handy oder Tablet. Für diese Art von Schnittstelle (Bluetooth - kbus) gibt es bereits ein OpenSource Projekt, welches man halt noch etwas anpassen müsste für die eigenen Bedürfnisse. Problem dabei ist, dass es effektiv nur eine Weiterleitung der ibus pakete über bluetooth ist und umgekehrt. Ich hätte gerne am Ende eine Android App mit der ich die implementierten Funktionen vom Raspberry komfigurieren kann.
Zum anderen (für die ganz fortgeschrittenen): Schnittstelle über UMTS zum Abfragen von Livedaten und Ansteuern von Funktionen. Da sehe ich noch das zusätzliche Problem, dass man eine Server Komponente braucht über die das gemanaged wird aufgrund sich ändernder IP-Adresse usw. ob das jemals realistisch wird weiß ich derzeit noch nicht.

Gerade für die letzten beiden Punkte wäre interessant ob jemand nicht nur Interesse an dem Projekt hat, sondern sich auch aktiv hilfreich einbringen kann was die Python Programmierung insbesondere bzgl. der Schnittstellen anbelangt, und/oder was App-Entwicklung für Android angeht.
Wer hier einfach nur schnorren will ist aber definitiv fehl am Platz. Ich werde sehr sparsam mit der Herausgabe von dem von mir programmierten Code sein, das sag ich gleich vorab bevor jemand weint

Das ist ne Ecke zu weit leider^^

Hätte sonst mal DME testweise getauscht.
Hab schon zig DMEs gesehen die angeblich repariert wurden oder angeblich überhaupt nicht defekt waren und es dennoch waren. Und die Aussagen kamen von Firmen die sich auf so Reparaturen spezialisiert haben...