Hallo Leute, ich will demnächst mit der Entwicklung einer kompletten Telemetrie für meinen alten VW Käfer beginnen. Grund hierfür ist es, das Fahrzeug A zu verstehen und B evtl. Feintuning / Fehlersuche besser abwickeln zu können. Starten will ich mit der Erfassung folgender Parameter: Kühler: - Drehzahl Ventilator - Kühlflüssigkeitstemperatur - 100°C Schalter (ab dann wird der Ventilator gestartet) Zündung: - Zündzeitpunkte von den einzelnen Zylindern - Drehzahl Fahrzeug - Drosselklappenöffnung in % - Einspritzung ins % So nun wirds technisch, wieso ich auch in dieses Forum hier schreibe: Der Aufbau soll möglichst universell aufgebaut werden: D.h. alles Sensoren = Slaves Pro Sensor spendiere ich einen uC mit AD-Wandler, der den Sensorwert aufbereitet dem Master bereitstellt. Also: physikalisch zu erfassende Größe -> AD Wandler -> Umrechnung im uC auf den normierten Wert -> Digitalisierter Wert steht zur Anholung bereit Der Master sammelt zentral alle Daten der Sensoren auf und legt sie in einen Datenlogger ab oder zeigt Sie per RS232 (später per Funk) direkt auf dem PC an. Das Datenprotokoll habe ich mir wie folgt vorgestellt: Jede Sensorelektronik (= Sensor + ADWanlder + uC + evtl Datenübertragungstreiber) beinhaltet folgenden Datenframe: Wer bin ich| Was bin ich | aufbereiteter normierter Wert z.B. Kühltemp. Sensor| Tempsensor | 80 Wer bin ich deshalb, da es z.B. mehrere Drehzahlsensoren geben kann und mehrere Temp sensoren. Der Master hat dann eine Art lookup Table Wer bin ich: 001 = Kühlertemp 002 = Ventilator 003 = Zündzeitpunkt Zylinder1 004 = Zündzeitpunkt Zylinder2 005 = ... 006 = ... Was bin ich: 001 = Temp.Sensor 002 = Drehzahlsensor 003 = Strommesser (Hall element zur Berührungslosen Zündzeitpunktmessung) 004 = ... 005 = ... Das Datenframe für z.B. die Kühlertemp bei 80°C sieht also wie folgt aus |1|1|80| Der Master weiß dann, dass es der Kühler ist, ein Temp Sensor und die Richtige Einheit Grad sind. [Da der slave uC alle Werte eines Sensors normiert darstellt]. Nun die Frage an euch: 1a. Welchen uC würdet Ihr für die Slaves nehmen? (Möglichst lötbaren SMD kein Ballgrid vorerst, UND es soll immer der gleiche sein für jeden Slave) 1b. Welcher uC für den Master? 2. Welche Datenübertragungsart würdet Ihr für die Anwendung im Motorraum nehmen? CAN, RS23, ... Stichwort EMV 3. Soll es ein uC sein der CAN auch kann oder ein uC und ein getrennter Treiber der das Signal zu CAN etc. wandelt? 4. Was für ein Kabel würdet Ihr nehmen? Geschrimt oder doch nur einzelne Leitungen zu einem Telemtriekabelbaum zusammenfassen ohne Schirm? Ich habe mich für 4 Leitungen entschieden: 5V, GND, 2x Data (RX, TX etc.). Reicht das? 5. Was für einen Datenlogger würdet Ihr mir empfehlen? Gekauft, im Master implementiert? 6. uC inklusive AD Wandler oder extra AD Wandler? 7. Echtzeitfähigkeit? Ich denke wenn die Daten leicht verzögert ankommen, bei einer VorOrt Einstellung dürfte das auch nicht tragisch sein. Oder habe ich da etwas nicht bedacht? Spannung soll 5V sein, da gängige Sensoren dazu gefunden werden können. Oder würdet Ihr mir sogar 3.3V oder niedriger empfehlen? 5V werden auf der Masterplatine erzeugt und von dort aus allen Slaves weitergereicht. Somit spar ich mir Spannungsversorgungen. Das System wird gestartet durch die Zündung und auch beendet durch die Zündung (vorerst). In Zukunf könnte ich mir dann vorstellen, dass das Loggen erst aufhört wenn die Motortemperatur auf 40° abgesunken ist, um das Verhalten der Ventilatoren etc. zu betrachten. Vorab: Ein bisschen was von Elektrotechnik verstehe ich schon ;) Mach ich hauptberuflich. Diese Schaltung habe ich hier mit Atmels schoneinmal aufgebaut für 3 Sensoren, und das an und abstecken und die alleinige Erkennung der Sensoren klapt wunderbar. Nur will ich das jetzt so klein wie möglich optimieren und eben Automotivtauglich machen. Wobei der Käfer ja nur zu guten Tagen gefahren wird. Der Winter ist Tabu. Also dann, bitte alles schreiben was euch einfällt bzw. fals jmd. schonmal soetwas gemacht hat, dann gerne auch einen Link dazu schicken. Kosten sollen erstmals zweitrangig betrachtet werden. Es geht ja schließlich um mein heilig´s Blechle :) Ich hoffe auf rege Antworten, da ich schon lange sowas vorhabe und jetzt die Zeit dafür habe ;) Also im Grunde will ich einen Coolen uC finden mit dem ich schnell universelle Sensoren bauen kann, wie Sie mir in den Kopf kommen und diese dann auch in den Sensorstrang einbauen (plug and Play). Viele Grüße Masterz
Käfer mit Wasserkühlung ist schon mal ein guter Anfang.
Ich weiß, nachgerüstete Wasserkühlungen sind vielleicht bei dem ein oder anderen Käferfreak nicht gern gesehen. Aber das habe ich schon genug in anderen Foren diskutiert ;)
Und die Einspritzanlage wurde auch nachgerüstet?
Der Mexico Käfer hatte jahrelang Einspritzung. Gibt es auch eine ABE dazu.
Georg G. schrieb: > Der Mexico Käfer hatte jahrelang Einspritzung Den Käfer mögen die Raben fressen!
@ Bernd Hubert Wie viele Jahre Zeit hast du für dein Projekt geplant?
Hi Leider hilft dir meine Antwort genau so wenig wie die letzten Beiträge ;-) Bin aber sehr interessiert an deinem Projekt und hoffe es nimmt bald Gestalt an. Was passieren kann, wenn du an der Zündung rumspielst muss ich dier ja nicht erzählen.. An deiner Stelle würde ich mich an CAN halten, da sehr störsicher und Industriestandart. Einen spezifischen uC kann ich dir nicht empfehlen, habe selbst nur mit PICs gearbeitet aber ohne CAN. Macht es wirklich Sinn nur Analogsensoren zu verwenden? Plugandplay seh ich kein Problem, musste halt alles abscannen am Anfang. Ich könnte mir vorstellen, dass die Stromversorgung Probleme machen könnte. Zum einen bei der Erzeugung (12V vom Auto alles andere als schön) und zum anderen wegen den langen Leitungen zu deinen Sensoren (EMV). Tipps zur Abschirmung werden dir bestimmt andere geben können. ps.Wie wärs noch mit einem hübschen Touchscreen?
berliner schrieb: > Wie viele Jahre Zeit hast du für dein Projekt geplant? Spielt das hier eine Rolle oder ist mal wieder ein Trollversuch? > 2. Welche Datenübertragungsart würdet Ihr für die Anwendung im Motorraum > nehmen? CAN, RS23, ... Stichwort EMV CAN > 3. Soll es ein uC sein der CAN auch kann oder ein uC und ein getrennter > Treiber der das Signal zu CAN etc. wandelt? > 6. uC inklusive AD Wandler oder extra AD Wandler? Schau, dass du möglichst alles integriert bekommst. Spart Aufwand und Geld. > 1a. Welchen uC würdet Ihr für die Slaves nehmen? (Möglichst lötbaren SMD > kein Ballgrid vorerst, UND es soll immer der gleiche sein für jeden > Slave) Basierend auf obiger Aussage kommen hier sehr, sehr viele in Frage. Hast du denn schon mal was mit µC gemacht und hast schon gewisses Vorwissen Präferenzen Tools / etc.? > 1b. Welcher uC für den Master? Siehe oben. Am besten das selbe Derivat wie für die Slaves (nur in einer größeren Variante). Du willst dich sicher nicht in 2 Controller einarbeiten, 2 mal Tools kaufen, etc. > 7. Echtzeitfähigkeit? Ist bei einem halbwegs durchdachtem Konzept wohl eher eines deiner kleinsten Probleme.
Hallo Leute, danke für eure Antworten. Lassen wir mal das Fahrzeug außen vor. Es sollte nur den Hintergrund der Anwendung beschreiben und soll hier bitte nicht diskutiert werden. > Wie viele Jahre Zeit hast du für dein Projekt geplant? Hallo? In wieviel Jahrhunderten entwickelst Du denn bitte deine Elektronik? Ich habe das ganze ja schon hier auf dem Tisch liegen und als ersten Schritt reicht es mir völlig aus die Drehzahl meines Kühlers auszulesen. D.h. ein Master ein Slave und eine Visualisierungsprogramm. Wenn dass erstmal steht dann ist der Rest copy & paste. Also wunder ich mich über diese Aussage. > Basierend auf obiger Aussage kommen hier sehr, sehr viele in Frage. Das ist eben mein Problem.. Wenn ich mich durch alle Familien durchwühlen müsste, dann würde die obere Aussage wieder stimmen.. Es würde Jahre dauern. Deshalb hier die Frage nach "gängigen" uC. > Hast du denn schon mal was mit µC gemacht und hast schon gewisses Vorwissen Präferenzen Tools / etc.? Ja ich bin Elektro-Ing. Matlab AVR-Studio Arm-Programmierung alles schon gehabt.. Daher auch das Anliegen jetzt etwas "größeres" zu Planen. Ich würde der einfachheit halber aber ein uC der AVR-Familie bevorzugen, da ich damit die meisten Projekte abgearbeitet habe. >Am besten das selbe Derivat wie für die Slaves (nur in einer größeren Variante). Sehr guter Tipp. An die Variantenvilfalt des gleichen Typs habe ich gar nicht gedacht. > Was passieren kann, wenn du an der Zündung rumspielst muss ich dier ja nicht erzählen.. Da Sensorik -> Read Only, denke ich wirds nicht so kritisch sein. Ich greif ja nicht ein, sonder greif nur ab. Und ja die Zündung ist immer wieder ein Zeitfresser.. sollte aber auf dieser Ebene beherrschbar sein. > Zum einen bei der Erzeugung (12V vom Auto alles andere als schön) und zum anderen wegen den langen Leitungen zu deinen Sensoren (EMV) Hatte ich auch im Hinterkopf. D.h. doch 12V Sensorleitung legen und auf jeder Platine einen DC-DC Wandler samt erprobten EMV Pi Filter? Wird dann doch etwas teurer, aber wenns dadurch läuft solls mir auch recht sein. > ps.Wie wärs noch mit einem hübschen Touchscreen? Ich habe in meinem Non-Automotive Aufbau schon ein LCD oder wahlweise ein TFT Bildschirm dran und das ganze wird schon Plug & Play fähig erkannt. Alles mit dem gleichen Konzept: LCD oder TFT verstehen den gleichen Datenframe wie Ihn der Master empfängt und an die Anzeige weitersendet. Somit: einmal die Schnittstelle zur Anzeige generiert und eine Lookup hinterlegt, und schon kann ich alle Sensoren anschließen. Beim Stichwort Anzeige, habe ich in meinem Non-Automotive Projekt schon den Datenframe um Wer bin ich| Was bin ich|aufbereiteter Normierter Wert| Was ist mein Max Wert| Was ist mein Min Wert| erweitert. So kann ich in meiner Dynamischen Anzeige auch die überschrittenen Werte schön in rot visualisieren. Funzt auch schon. Aber das soll im Automotiv Projekt zu allerletzt implementiert werden. Langfristiges Ziel sollte die Auswertung am iPad sein über das WLAN netztwerk. Aber das ist erst der übernächste Schritt. Aber das Fundament steht schon. Also für weitere PRODUKTIVE Antworten bin ich immer sehr Dankbar! Vor Allem welcher uC geeignet wäre und Datenlogger im uC realisieren oder extern? Viele Grüße
Da ist der käfertechnische Fortschritt spurlos an mir vorbei gegangen. Mein erster Käfer war von 1970..... Es gibt fertige Sensoren mit CAN jedoch würde ich räumlich nahe beieinander liegende Sensoren z. B. Motorraum in einem Knoten bearbeiten. Es ist trotzdem möglich, die Nachricht jedes Sensors gemäß deiner Vorstellung auf verschiedenen ID zu senden. Gruß Otto
Da du die Daten für Feintuning verwenden möchtest, hast du dir bestimmt schon Gedanken gemacht, wo du die Wassertemperatur messen willst: Zylinderkopf-Austritt, Kühler-Eintritt, Motorblock-Eintritt, ???. Oder die Ansauglufttemperatur (sehr wichtig für die Füllung): Vor Luftfilter, an der Drosselklappe, im Saugrohr, ???. Interessant wird es auch mit der Einspritzzeit. Da muss aus der elektrisch gemessenen Zeit noch die (spannungsabhängige) mechanische Verzugszeit heraus gerechnet werden. Aber da hast du bestimmt die passenden Datenblätter. Wenn deine Einspritzung elektrisch funktioniert, solltest du überlegen, ob es nicht sinnvoller ist, die Daten aus der Diagnose Schnittstelle zu entnehmen. Wenn es aber eine mechanische K-Jetronik ist, lass alle Gedanken an Feintuning gleich fahren. Das geht vernünftig nur auf der Fliessbank.
Hallo Georg, manche Daten sollen für´s Feintuning manche für die schnellere Fehlersuche verwendet werden, wie oben schon angedeutet. Ich will keinen Prüfstand bauen, bitte nicht falsch verstehen, sondern mit dem Projekt meine beiden Hobbys verschmelzen, überschaubare alte Fahrzeuge und elektrotechnik in Richtung Telemetrie. Aber das sei dahingestellt obs für manchen Sinn macht oder nicht .. > Es gibt fertige Sensoren mit CAN jedoch würde ich räumlich nahe beieinander liegende Sensoren z. B. Motorraum in einem Knoten bearbeiten. Es ist trotzdem möglich, die Nachricht jedes Sensors gemäß deiner Vorstellung auf verschiedenen ID zu senden. Interessanter Ansatz aber das habe ich noch nicht ganz durchschaut? Könntest das mal genauer erklären? Also alle Sensoren direkt an einen uC hängen? Und dort dann alle Werte aufbereiten? Ich wollte auf jedenfall für jeden Sensor einen uC spendieren, so sieht man den Fortschritt schneller (Sensoren können einzeln entwickelt und sofort getestet werden). > Es gibt fertige Sensoren mit CAN Will ich eigentlich nicht haben, da das meiste vorerst abzweigen von Spannungen sind, die sowieso schon im Fahrzeug vorhanden sind (z.B. Kühlertemp-Sensor über einen simplen Spannungsteiler). Aber prinzipiell könnte ich doch selbst gebaute Sensoren mit meiner Datenfram-Logik (Was bin ich , wer bin ich etc.) ja nicht verknüpfen, da die selbst gebauten Sensoren ja ein anderes Frame enthalten als die dazugekauften? Dann hätte ich doch keine Plug & Play fuktionalität, oder hab ich da was nicht bedacht? Danke für eure Anregungen, das hilft mir sehr viel schon von Anfang an, in bestimmte Fettnäpfchen NICHT reinzutreten :) Viele Grüße
Bernd Hubert schrieb: >> Es gibt fertige Sensoren mit CAN jedoch würde ich räumlich nahe > beieinander liegende Sensoren z. B. Motorraum in einem Knoten > bearbeiten. Es ist trotzdem möglich, die Nachricht jedes Sensors gemäß > deiner Vorstellung auf verschiedenen ID zu senden. > > > Interessanter Ansatz aber das habe ich noch nicht ganz durchschaut? > Könntest das mal genauer erklären? > > Also alle Sensoren direkt an einen uC hängen? Und dort dann alle Werte > aufbereiten? > > Ich wollte auf jedenfall für jeden Sensor einen uC spendieren, so sieht > man den Fortschritt schneller (Sensoren können einzeln entwickelt und > sofort getestet werden). > Ganz einfach, Variante A: Sensor 1 / µC 1 / ID 1: Antwortet bei Anfrage nach ID 1 Sensor 2 / µC 2 / ID 2: Antwortet bei Anfrage nach ID 2 Variante B: Sensor 1 / µC 1 / ID 1: Antwortet bei Anfrage nach ID 1 Sensor 2 / µC 1 / ID 2: Antwortet bei Anfrage nach ID 2 Du hängst einfach beide Sensoren an den gleichen µC, und bei nachfrage Antwortet er sowohl auf ID 1 als auch auf ID 2, du weisst nicht mal, ob da ein oder mehrere Controller dran hängen... Dann noch einen Tipp vom Informatiker: Nimm doch zur Auswertung ein kleines Linux Board oder sowas, z.B. Raspberry PI, Gnublin, UDOO oder whatever. Dann lässt du einen Webserver laufen und kannst ohne App mit jedem Mobilen Device zugreiffen, obs dann ein Notebook, Android, iPhone ist ist völlig egal. Mit HTML 5, JS, SVG ist eine Visualisierung viel einfacher realisierbar als mit einer App, und funktioniert Plattform übergreifend. (Falls gewünscht kann ich dir gewünschte Links raus suchen...) Edit: Die Forensoftware interpretiert meine "/" falsch:-/ mfg Andreas
Andreas B. schrieb: > Du hängst einfach beide Sensoren an den gleichen µC, und bei nachfrage > Antwortet er sowohl auf ID 1 als auch auf ID 2, du weisst nicht mal, ob > da ein oder mehrere Controller dran hängen... So wärs verständlicher: Du hängst einfach beide Sensoren an den selben µC, und bei nachfrage Antwortet er sowohl auf ID 1 als auch auf ID 2, du weisst nicht mal, ob da ein oder mehrere Controller dran hängen...
Hallo Andreas, dass bringt mich doch schonmal deutlich weiter. Danke für deine Beitrag. Einen Raspberry habe ich auch noch hier rumliegen, der gerade nichts zu tun hat. Das ist eine sehr gute Idee. Mit den Sensoren, will ich jedoch je Sensor einen uC spendieren. Das hat auch noch andere Gründe, dass ich die Sensoren anderweitig auch noch weiternutzen will. Somit einmal entwickeln -> mehrfach verwenden. Außerdem finde ich die 1 Sensor ein uC Lösung bei mehrerern Sensoren im Starng simpler nachzuvollziehen. Wenn Du links hast, dann bitte immer her damit. Alles schon entwickeltes. Wie gesagt: vorerst reicht es mir weiteren Input zu bekommen wi ich: 1. die uC miteinander am besten verkabeln kann? Lose adren oder doch ein abgeschirmtes USB Kabel abzwicken und verbinden? Aber da wird der Kabelbaum ganu schön dick. Ich denke mal mit CAN und losen ungeschirmten Leitungen sollte ich doch schon weit kommen? 2. Zwecks EMV: Lieber aus 12V Batterie -> 12V Sauber aufbereiten und dann an alle Sensoren verteilen die einen 12V -> 5V DCDC Wandler beinhlaten oder doch lieber 12V Batterie -> auf 12V zu 5V DCDC Wandler und dort EMV Schutzmaßnahmen betreiben? Wird die Sensorplatine eben größer :( An sich habe ich bei ATmel keine wirklich kleinen abgespeckten uC mit AD Wandler und CAN Schnittstelle gefunden. Die uC sind alle ziemlich groß. Ist Atmel überhaupt dafür der richtige Hersteller? Oder lieber einen anderen (mir noch nicht bekannten) aussuchen? Hat da jmd. Erfahrungen? Viele Grüße und danke für jedes Feedback! P.s. Webserver gefällt mir sehr gut! Hab ich auch noch einen Baustein rumliegen. Eigentlich hatte ich unterbewusst genau die Webserverlösung gesucht.. !!
Hmm, wenn ich schnellere Fehlersuche höre, dann sträuben sich mir die Nackenhaare. Entweder du sorgst durch deine Bastelei dafür daß eine einfache aber zuverlässige bisher mechanische Lösung jetzt schneller kaputt geht weil du Elektronik dazubaust und an den Steckverbindern herumfriemelst oder du wunderst dich daß der Käfer immer noch fährt obwohl dein Sensorik Verhau dir sagt, daß nichts mehr eingespritzt wird, die Drosselklappe auf 540° steht und die Zündung nur noch auf 2 Töpfen funktioniert. Aber trotzdem viel Spass beim Basteln
Man führt nie 5V-Versorgungsspannung durch das Fahrzeug. Überlege bitte, was bei einem Kurzschluss zu UBat passieren würde. Man verwendet auch keine DC/DC-Wandler, sondern Automotive-low-drop-Regler.
Elektroingenieur, ja klar ;-) merkt man sofort
Otto schrieb: > Man verwendet auch > keine DC/DC-Wandler, sondern Automotive-low-drop-Regler. Eindeutig "Jein". Durch versetzte Massepotentiale gibt es recht beeindruckende Effekte. Mit einem kleinen 12V/5V Wandler mit galvanischer Trennung kann man sich in einigen Fällen das Leben durchaus einfacher gestalten. Für ein Einzelstück sind die zusätzlichen Kosten irrelevant.
Hallo Leute, kaum zu glauben wieviel Blindleistung manche User hier generieren.. > Entweder du sorgst durch deine Bastelei dafür daß eine einfache aber > zuverlässige bisher mechanische Lösung jetzt schneller kaputt geht weil > du Elektronik dazubaust Z.B. bei der Drehzahlmessung meines Kühlerventilators. Da greife ich in den höchst Kritischen Prozess des Ventilators ein?!? Z.B. bei der Zündstrommessung der einzelnen Zündkabel über Hall-Elemente? Da greife ich auch in den Prozess eins, sodass ich mein Fahrzeug zerschieße? Hallo!! Messen heißt Read Only! > Man führt nie 5V-Versorgungsspannung durch das Fahrzeug. Überlege bitte, > was bei einem Kurzschluss zu UBat passieren würde. Ich hätte den Strom den dei Sensoren verbrauchen abgeschätzt, und dann noch einen kleinen Pufferwert draufgesetzt -> I_Sicherung = I_max_Sensoren + Pufferstrom Bei einem Kurzschluss -> Sicherung futsch und gut is. Aber da das anscheinend nicht der richtige Weg ist und ich noch keine automotive Sachen entwickelt habe, lasse ich mich gerne belehren.. Aber wenn ich auf jedem Modul aus 12V 5V generiere und dann ein Kurzschluss stattfindet wie wird das dann "normalerweise" abgedeckt? einen extra 12V Strang mit einer Sicherung aufbauen? > Man verwendet auch > keine DC/DC-Wandler, sondern Automotive-low-drop-Regler. Ok, ich hatte gedacht mit der Potentialtrennung hole ich mir weniger Probleme auf die Platine, aber dann muss ich mal nach einem Automotive-low-drop-Regler suchen. Oder kannst Du mir da einen empfehlen? > Elektroingenieur, ja klar ;-) merkt man sofort Ganz großer Satz! Keine Antwort ist oftmals auch eine Option.. Also über weitere hilfreiche Beiträge der restlichen motivietern Leute hier im Forum, deren Motivation die Elektronik ist und nicht die Ideen andere Leute runterzumachen, freue ich mich sehr. Viele Grüße
Mal ein Alternativvorschlag für die Sensoren: Silabs hat 8051-kompatible Controller mit getrimmtem Oszillator, relativ gutem ADC und LIN-Bus für wenig Geld. Zusammen mit einem passenden LIN-Transceiver hätte man dann eine preisgünstige und sehr kompakte Lösung - wenn die Datenrate ausreicht, und einem 8051 nicht fremd ist.
Bernd Hubert schrieb: > Zündstrommessung der einzelnen Zündkabel über > Hall-Elemente Geht bestimmt, würde ich aber nicht machen. Kapazitiv abgreifen ist einfacher und du bekommst bei passendem Aufbau noch eine Info über die geschätzte Höhe der Zündspannung.
MatzeIhring schrieb: > Andreas B. schrieb: >> ...an den gleichen µC... > > So wärs verständlicher: > ...an den selben µC... Sorry, ich bin Schweizer, selbe gibts bei uns nicht, bei uns ist alles das *gleiche*=) Bernd Hubert schrieb: > Hallo Andreas, > > dass bringt mich doch schonmal deutlich weiter. Danke für deine Beitrag. :-) > > Einen Raspberry habe ich auch noch hier rumliegen, der gerade nichts zu > tun hat. Das ist eine sehr gute Idee. Also ein Raspberry PI hat schon mal ordentlich Ressourcen, da musst du nicht so darauf achten was du für Software verwendest... Häufig wird der Apache2 als Webserver verwendet, aber z.B. nginx ist sparsamer, und unterdessen auch sehr verbreitet (wichtig wegen Dokumentationen etc.) http://de.wikipedia.org/wiki/Nginx Dann brauchst du Serverseitig natürlich eine Skriptsprache oder sowas, mein Favorit ist da meist PHP, weil PHP ist sehr weit verbreitet, und es gibt für fast alles PHP Libraries. Technisch gesehen gibt es besseres als PHP, z.B. Python, aber wenn du noch keine Präferenzen hast würde ich dir zu PHP raten. Du kannst mit PHP (php-cli) z.B. auch die Serielle Schnittstelle einlesen, falls gewünscht: http://code.google.com/p/php-serial/ > > Wenn Du links hast, dann bitte immer her damit. Alles schon > entwickeltes. Für die Javascriptbasis: http://jquery.com/ (DER Standard heute) Dann für die Charts ein JQuery Plugin, z.B. http://www.flotcharts.org/ http://www.jqplot.com/tests/line-charts.php Daten nachladen kannst du per Ajax, z.B. http://api.jquery.com/jQuery.ajax/ Willst du Daten speichern, so hast du mehrere Möglichkeiten, z.B. Datenbank (z.B. MySQL, Administration über PhpMyAdmin) XML (simplexml) Oder Serialisierung (serialize, unserialize), einfachste Variante, aber nicht portabel... Das waren jetzt mal Infos ins blaue hinaus, bei konkreten Fragen kann ich ggf. auch konkrete Antworten geben;-) mfg Andreas
>Mal ein Alternativvorschlag für die Sensoren: Silabs hat 8051-kompatible >Controller mit getrimmtem Oszillator, relativ gutem ADC und LIN-Bus für >wenig Geld. Zusammen mit einem passenden LIN-Transceiver hätte man dann >eine preisgünstige und sehr kompakte Lösung - wenn die Datenrate Auch eine gute Idee! Aber ich denke LIN ist eher für Anwendungen außerhalb des Motorraums gedacht. Ich sehe eine 1Leiterübertragung ziemlich kritisch an, wenn im nahen Umfeld noch ein Zündverteiler rumgeistert. Hat da jmd. schonmal Erfahrungen mit gesammelt, konkret LIN in einem EMV versuchten Umfeld eingesetzt? Für den ersten Start will ich jetzt das Problem stark vereinfachen, und dazu noch einige Tipps einsammeln. Vereinfachung 12V-Spannungsüberwachungs-"Sensor" als Slave und einen Master der die Spannungswerte zyklisch einließt und an RS232 ausgibt. So habe ich auch die erste Baustelle diagnostiziert. Die Versorgung. Was würdet Ihr mir empfehlen? 1. 12V Batterie -> 12V gefiltert mit Sicherung abgesicherte Spannungsversorgung -> Automotive Drop Down 12V/5V -> auf Sensorik? 2. 12V Batterie -> Automotive Drop Down 12V/5V -> EMV Filterung auf Sensorik? Gibt es schon eine Aufbereitungsschaltung für die 12V Batteriespannung (Ich denke da müssen Zwischenkreiskondensatoren verwendet werden oder?), sodass ich einen netzteilähnlichen Zustand für meine Elektronik erreichen kann? Für die Vereinfachung würde ich dann die aufbereitete Spannung an der Batterie abgreifen und diese dann über CAN oder LIN an den Master schicken und so den ersten Test OHNE jeglichen Einriff in das Fahrzeug machen. Was haltet Ihr von dem Vorgehen? Schritt 2 wäre dann: Die Daten nicht direkt über RS232 sondern in einen Datenlogger einzuspeisen. @ Andreas: > Willst du Daten speichern, so hast du mehrere Möglichkeiten, z.B. > Datenbank (z.B. MySQL, Administration über PhpMyAdmin) > XML (simplexml) > Oder Serialisierung (serialize, unserialize), einfachste Variante, aber > nicht portabel... Das geht nur wenn ich dann den Master an meine Raspberry hänge oder wie meinst Du das genau? Ist das Ablegen der RAW-Daten in einen Flashspeicher der als Speichermodul auch wie ein Slave angesprochen wird nicht auch eine alternative? Dann könnte ich mir einen kleinen Baukasten zusammenschustern von dem ich dann die Daten an den in Schritt 3 eingesetzten Raspberry Pi schicken könnte? Oder ist das zu kompliziert gedacht?
Sollte der CAN-Bus noch aktuell sein kann ich dir als Transceiver den SN65HVD1050D empfehlen. Ist im SOIC Gehäuse (SMD aber Lötbar) und verträgt laut Datasheet Temperaturen zwischen -40° und 150°
LIN ist deutlich langsamer als CAN und wird i. A. für Sensoren und Komponenten verwendet, welche keine großen Datenmengen benötigen (z. B. Außenspiegel)
LPC11C24. 48 MHz, 32 KB Flash, 8 KB RAM, LQFP48-Gehäuse => Cortex M0 mit CAN-Controller- UND -transceiver onchip! => keine weiteren Bauteile außer Quartz und Spannungsversorgung nötig.
> LPC11C24. 48 MHz, 32 KB Flash, 8 KB RAM, LQFP48-Gehäuse
Genau mit dem größeren Chip der im Mbed verbaut ist, habe ich meine
non-automotive Anwendung programmiert. 1A das Eval Board!
Mich ärgert eben nur, dass LQFP ->48<-
48 Pins wobei ich nur eine Hand voll brauche. Und in kleiner finde ich
den nicht von NXP :(
Ok also CAN ist gesetzt.. jetzt geh ich mal auf die Suche nach einem
schmaleren Package mit nicht soviel schnick schnak..
Die 12V auf 5V Versorgung? Hat dazu keiner einen Tipp, wie ich mir schon
von Beginn an, die Probleme von meiner Elektronik halte?
Laut dem Datenblatt: http://www.nxp.com/documents/data_sheet/LPC11CX2_CX4.pdf ist LQFP48 das einzige verfügbare Package. Ist schon nicht so einfach zu verarbeiten, aber du sparst halt ne Menge Bauteile und mit 4 bis 6 Euro ist der MC auch nicht so teuer, verglichen zu Mitbewerbern. Toolchain ist auch komplett kostenlos nutzbar.
Zuerst musst du dich von der Annahme trennen, dass es sich um eine 12V-Versorgung handelt. Die Bordnetzspannung kann im12V-System dauerhaft und ohne Fehler bis zu 14, 3V betragen. Hinzu kommen dann noch die diversen Bordnetzpulse, welche zum Teil auch negativ sind. Eine Verpolschutzdiode ist daher zwingend. Anschließend folgt vor dem Spannungsregler ein Elko, welcher in der Lage ist, die Schaltung während der Einbrüche weitet zu versorgen. Der Spannungsregler schließlich muß ebenfalls die (nun nur noch positiven) Pulse vertragen. Sieh dich mal bei Infineon um - die haben in ihren Datenblättern auch Applikationen.
Hallo Leute, ARM hört sich schon ganz gut an. Ich schwanke über die Kinetis K10 Serie (die kleinste Serie mit CAN), oder was ich eugentlich eleganter finden: Das Freescale Freedomboard. Hat aber kein Can. Zum Freedowmboard dann einen CAN Baustein, indem ich dann das SPI-Signal des Boards zum CAN wandeln kann. Was haltet Ihr von der Idee? Vorteil Freedomboadr: Presi unschlagbar! Online Compiler mit dem man wirklich unter 1h schon Code testen kann.. aber die Verbindung zum CAN habe ich noch nie realisiert. Meint Ihr über SPI könnte das klappen?? Schöne Grüße!
>Ich schwanke über die Kinetis K10 Serie (die kleinste Serie mit CAN), >oder was ich eugentlich eleganter finden: > >Das Freescale Freedomboard. Hat aber kein Can. Schönen Exoten hast du dir da rausgesucht. Falls du Hilfe aus diesem Forum möchtest würde ich einen STM32 oder was von NXP vorschlagen. Such hier halt mal nach Freescale. >Online Compiler mit dem man wirklich unter 1h schon Code testen kann.. Ich halte nichts davon meinen Code zum Hersteller zu senden. >aber die Verbindung zum CAN habe ich noch nie realisiert. Meint Ihr über >SPI könnte das klappen?? Klappen tut das schon, ist aber teurer. Nimm einen Controller mit integriertem CAN. Das kommt besser, du brauchst meist nur noch einen Transceiver.
:
Wiederhergestellt durch Moderator
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.