Technische Details / Fachchinesisch für Fortgeschrittene

i_h

Registriert
25. März 2005
Beiträge
1.696
Danke
79
SAAB
900 I
Baujahr
1992
Turbo
FPT
Moin

Hätt mal 2 etwas allgemeinere Fragen:
1. In welchem Bereich bewegen sich eigentlich die Öffnungszeiten der Einspritzventile? Und
2. in welchem Frequenzband spielen sich die Sachen ab, die der Klopfsensor empfängt?
 
Ahh danke. Dann sollte man ja mit einem Tiefpass der ab ~12kHz zumacht und 24kHz Abtastrate den Bereich bekommen, wo die Musik spielt (höchste Frequenz bei 9.5kHz).
Mit'm AVR wird das etwas eng, zumindest bei 10bit. Bei 8bit passt das aber ganz gut, da sind beim Mega48 laut Datenblatt 77kSps drinnen.


Hintergrund ist folgender: Eine SD Karte ist in null komma nix am AVR dran, und wenn man von den Brüdern 2 oder 3 zusammen schaltet hat man ca. 30 ADC Kanäle + mehr als genug IO Pins.
Klopfen und die Öffnungszeiten sind am zeitaufwendigsten zu messen, alles andere was man noch so messen könnte reicht locker mit 100hz.
Das Klopfen macht mit 16bit Paketen 48kB/s, Ventilzeiten max. 800 Byte/sek und der Rest bei 30 Kanälen mit 100Hz und 16bit pro Paket 6kB/s. Insgesamt also vll 60kB/s. Die SPI Hardware sollte bis zu 2MByte/s schaffen, die SD Karte sowieso.

Bei 60kB/s passen auf eine SD Karte mit 128MB 2180 Sekunden, oder halt 36 Minuten. SD gibt's ja aber auch mit 1GB und mehr, also theoretisch kann man problemlos 5 Stunden Fahrt aufzeichnen...
 
Günstige Speichermöglichkeiten gibt es inzwischen ne Menge.
Wie du schon schreibst, ist der AVR der Enpass. Das müssten dann schon mehrere sein. Und die SD-Card braucht auch Zeit zum Abspeichern der Blöcke - das muss man von der Übertragungsrate abziehen.

Aber spannendes Vorhaben!

Beste Grüsse

Roland
 
Naja, aber übliche SD Karten machen ja problemlos 1MB/s, und das sind dann doch etwas mehr als 60kB/s.
AVRs zusammenschalten ist vll ein bisschen aufwändiger, muss mal gucken wie hoch man den I2C so takten kann. Falls das nicht ausreicht kann man an den der auf SD schreibt auch 2 AVRs direkt an die IO Pins klemmen, DIL40 gibt ja genug her (was kleineres würd ich sowieso nicht nehmen) und die Ports sind sowieso bidirektional. INT Pins sind auch genug da.
Wäre auch endlich mal ein Projekt bei dem ich doppelseitige Platinen nehmen kann, hab alles da um die Dinger zu ätzen und bestücken, aber wegen 3 Drahtbrücken...


Ich denk fast das komplizierteste wird es an die ganzen Geber heranzukommen. Drehzahl, Klopfsensor, Ladedruck und Bremse liegt ja am APC Steuergerät an, müsste man also ein Adapterkabel fummeln (mit 2mal Koax für Klopfsensor).

Droklapoti ist vom APC nicht weit, muss man aber gucken wie die Lucas das auswertet (ebenso Drucksensor), hoffentlich einfach mit 'nem Spannungsteiler, dann kann das direkt an den ADC.

Zündzeitpunkt braucht ein bisschen Hardware. Soweit ich weis sitzt der Geber ja nicht wie beim 8V im Zündverteiler, zeigt also exakt an die KW oben ist. Dann reicht es möglicherweise ein paar Windungen um ein Zündkabel zu legen, und das mit ein paar R, C und Zener direkt an den uC.
Zeitdifferenz zwischen Zündung und OT kann man dann per Software bestimmen. Hab schonmal 'ne Seite gefunden wo sich einer 'ne Strobolampe selber gebaut hat, so kompliziert war's net.

Temp. Sensor sitzt hoffentlich auch in 'nem Spannungsteiler, dann auch einfach an den ADC. Vielleicht noch eine grob einstellbare Referenzspannung auf's Board, die ADC haben 'n integrierten 20/100 Verstärker. Braucht man aber wahrscheinlich nicht.

Lambdasonde kann direkt an den ADC, Impedanz müsste hoch genug sein. Ansonsten halt noch'n OP davor.

Geschwindigkeit... gibt's das überhaupt als elektronisches Signal? Wenn ja dürfte das ja ein einfaches Rechteck sein, entweder per Polling oder man hängt einen Timer dran (bei 3 DIL40 AVRs sind im 9..12 Timer da, irgendeiner wird sicher übrig bleiben).

Öffnungszeit der Ventile ist nicht ganz so einfach. Länger als 10ms werden die ja kaum offen sein, dann isser bei 6000rpm einmal rum. Also ist 1ms vll realistisch, da sollte die Messgenauigkeit schon im Bereich 10us liegen.
Müsste man wahrscheinlich an ein INT Pin hängen, oder halt INT wenn sich der PORT ändert. Bei 16MHz ist ein Timer genau genug.

Was könnte man noch so messen? Lustig wären natürlich noch ein paar Drucksensoren, dann könnte man einerseits den Benzindruck messen, und andererseites alles mögliche an der K-Jet. Die Dinger sind allerdings nicht ganz billig, und Adapter für die Benzinleitungen fallen auch nicht eben vom Himmel.
An Kabelbäume komme ich problemlos ran, da finden sich genug Stecker.


Das Hauptproblem sind sicherlich die zeitkritischen Sachen. Klopfsensorwerte speichern dürfte nicht so kritisch sein, der ADC überschreibt den alten Wert erst, wenn er einen neuen hat. Macht bei 24ksps also 666 *evil* Takte um den Wert irgendwo zwischenzuspeichern, da passt also noch eine andere Interrupt Routine dazwischen.
Einspritzzeiten sind schon kritischer, wenn sich an den Ventilen was tut, muss der entsprechende Timer sofort gestoppt bzw. ausgelesen werden. Hmm... man könnte auch einen externen, eher niedrigen Takt (1MHz oder sowas) erzeugen, den man auf einen Timereingang gibt - wenn das Ventil offen ist. Dann hat man mind. 1 Umdrehung Zeit den Timer auszulesen und auf 0 zurückzusetzen, also 10ms. Auch kein Ding. Außer man will wirklich alle 4 Ventile messen. Aber ob man das braucht?
Zündzeitpunkt ist ähnlich kritisch und da kann man's nicht so wie bei den Ventilen lösen. Der AVR der dafür verantwortlich ist, kann also nur noch die Ports/ADC mit 100Hz abfragen, aber mehr ist dann nicht mehr drinnen. Genauigkeit von +/- 0.25° macht eine max. Granularität von 7us... ok, so kritisch ist's auch net.

Das könnte man vll auch zusammen mit den Einspritzzeiten machen, indem man einfach die Zeiten zwischen OT und den jeweiligen Ereignissen (Zündung, Ventile auf, Ventile zu) speichert. Sollte in Asm gehen, aber andere Zeitkritische Sachen lassen sich auf dem AVR dann ganz sicher nicht mehr machen.

Wenn der AVR an der SD Karte die Zeitreferenz stellt, reicht es eigentlich wenn der und der, der die Ventilzeiten/ZZP misst, das OT Signal bekommen. Darauf sollten sich beide problemlos synchronisieren lassen.
Wär vielleicht auch hilfreich, wenn der an der SD Karte hängende den Klopfsensor auswertet. Dann ließen sich die AVRs wahrscheinlich auch per I2C verbinden.



Scheint also schon machbar zu sein.
 
Ouha, langer Text und großes Vorhaben!

Ich sag mal, was mir spontan dazu einfällt.

Zwei Chefs an der SD-Card erfordert klare Zeitfenster wer gerade darf und wer die 'Füße hochnehmen' muss. Wenn aber beide zu unterschiedlichen Zeiten ihre Daten in der SD ablegen, fehlt die klare zeitliche Zuordnung. Das Schreiben auf die SD-Card erfolgt in Blöcken und nicht wie beim RAM auf einzelne Bytes. Ich denk mal es wäre besser, wenn einer die erfassten Daten einsammelt und in einer festen Matrix ablegt.
Das Auslesen der SD-Card muss auch noch bedacht werden. Einfach in den PC schieben wird nix. Dazu müsste eine FAT32 auf der SD-Card vom AVR bedient werden... Ev. wieder über den AVR per RS232 auf den PC. Da brauchts dann aber ein kleines PC-Programm, um die Daten zu sortieren und in .txt o.ä. abzulegen.

Das Klopfsignal sollte mit einem Differenzverstärker aufgenommen werden. Dann reicht ein ADC und es wird genauer. Dazu ev. einen Rentner verwenden (OPA126 o.ä.) :biggrin:

Alle analogen Signale bitte über OPs, also niederohmig an den ADC.

Geschwindigkeit liegt am Tacho (oder Tempomaten) an. Ist PWM und kann über einen Zähler erfasst werden.

Druckgeber, z.B. MPX2100DP kann ich dir besorgen.

Das Zündmodul wird doch mit 12V angesteuert? Da hast du doch deine Zündimpulse.

Generell hast du mehrere Zeitkritische Messungen, von denen der AVR aber immer nur eine durchführen kann. Das solltest du in deinen Betrachtungen berücksichtigen.

Im Ganzen ein recht ambitioniertes Projekt. Viel Erfolg dabei.

Roland
 
Noch ist es ja nur 'ne Überlegung :biggrin:

An die SD Karte wollte ich nur einen AVR ranlassen, idealerweise den, der auch den Klopfsensor auswertet, weil die 48kB/s dann nicht von einem AVR zum anderen müssen.
Den Rest (12kB/s) müsste man eigentlich auch über I2C verschicken können, dann schicken die restlichen AVRs dem an der SD Karte die Messwerte per I2C wenn sie fertig sind (die zeitunkritischen wie zB. Droklaposition). Hab grad mal nachgeguckt, I2C ist bis 400kBit/s spezifiziert, reicht also. Notfalls läuft der sicher auch noch schneller, der ganze Bus wäre ja nichtmal 5cm lang.

Differenzverstärker klingt gut, das Ding wird am APC ja über 2 Kondensatoren eingekoppelt, also da liegt keine Leitung auf Masse. Die Frage ist, was für Amplituden an dem Ding anliegen. Hab hier 'n paar hübsche JFET OPAs rumliegen, Eingangsimpedanz irgendwo zwischen 1 und 2 pF. Am APC sind's 47nF.

Bei den restlichen Signalen würd ich mal die Impedanz angucken, der ADC braucht nicht besonders viel Strom, hat ja auch eine integrierte Sample&Hold Schaltung. An 10kOhm hatte ich bisher noch keine Probleme, und wenn die Gaspedalstellung nur noch auf 8 Bit genau ankommt...
Problematischer könnte die Spannung werden, 'n Spannungsteiler frisst auch Strom. Da muss dann wahrscheinlich doch 'n OP drauf.

Geschwindigkeit als PWM klingt auch gut, da könnte man im 100Hz Rythmus einfach den Zählerstand speichern. Überlauf kann man später per Software rausrechnen. Kilometerstand dürfte man damit auch recht genau haben.
Dafür geht allerdings noch'n Timer flöten.

Druckgeber... kommst du da billiger als Reichelt ran? Manchmal sind die Preise echt lustig, wenn ich beim großen C nachgucke sind die 19mal 32Kx8 15ns SRAMs die hier noch rumliegen 120€ Wert :eek:

Wegen der Zündung - wie wird dann eigentlich der ZZP eingestellt? Beim 8V isses doch so, dass man den OT Geber einfach verschiebt, indem man den Zündverteiler dreht. Der 16V hat den doch aber nicht mehr im Zündverteiler sitzen... oder doch?
Dann fiele die ZZP Messung raus, weil irgendwie braucht man dafür "richtiges" OT.

Bei den zeitkritischen Sachen muss ich mal gucken, aber so schlimm sollte es nicht werden. Die meisten Sachen würden ja im 100Hz Rythmus gemessen werden, und ob die Pedalposition nun exakt ist, oder auf +/- 5ms exakt...

Kritisch sind wie gesagt die Ventilöffnungszeiten. Da aber nie 2 Ventile gleichzeitig offen sind, könnte das ein AVR alleine machen. Der kann seine restlichen IO/ADC Pins dann per Poll abfragen und die Daten verschicken.

Ach ja, ausgelesen wird die Sache per "dd if=/dev/sdd1 of=outfile" ;). Da braucht's auch kein Dateisystem auf der SD Karte. Die Anfänge der Blöcke kann man ja irgendwie markieren, dann lässt sich beim Auslesen recht einfach feststellen wo die Aufzeichnung aufhört. Dafür 'n C Programm zusammenzuhacken ist das geringste Problem... ich seh den Code schon vor mir ;).

Wie groß sind eigentlich die Blöcke auf der SD Karte? Der ATMega32 hat 2kB Ram, wenn die Dinger wie bei HDDs 512 Byte groß sind, ist das kein Problem. Den meißten Ram braucht man eh net, weil die Daten ja gleich auf SD wandern.
 
kollege hat grad fürn projekt verschiedene (mini)SD karten am an nem AVR zwecks speed getestet. ob mit filesystem oder wie auch immer weiss ich jetzt nicht. falls interesse besteht kann ich ihn ja mal löchern...
 
Hmm i_h - da wir hier ja eh unter uns sind - ich glaube du solltest das Projekt erst mal in kleinen Schritten beginnen und mit den gewonnenen Erfahrungen das Konzept erstellen. Die Technik birgt doch noch einige Tücken.

Schnapp dir mal ein Datenblatt einer SD-Card - da musste erst mal durch. Die Blockgrösse war, glaube ich 256Byte + einige Extra. Da gibts wohl auch Routinen für. Den AVR hast du. Die S&H-Schaltung läd einen Kondensator am ADC-Eingang, d.h. das Meßsignal wird mit einer - wenn auch sehr kleinen - Stromspitze belastet, was den Meßwert bei steigender Impedanz der Signalquelle zunehmend verschlechtert. Man muss sehen, wie genau mann's haben will, aber ein OP kostet ja nix. Dann Wechselspannung an den Eingang und wenn das in Exel vorliegt, sehen wir gerne weiter ;-)

Beste Grüsse

Roland

Ups - doch noch einer :-)
 
Ich werd das alles erstmal nacheinander auf'm Steckbrett austesten, aber im Endeffekt hab ich fast alle Teilprobleme schonmal irgendwo gehabt und gelößt, bis auf die SD Karte -> http://www.ulrichradig.de/site/atmel/avr_mmcsd/ .
Das mit den OPs ist auch kein Ding, dann sitzen halt noch 2 bis 4 LM324 drauf (+ einer für'n Klopfsensor). Macht dann 8 bis 12 Kanäle.

Der größte Aufwänd wird wohl sein das alles zusammenzufügen.
 
Ups - doch noch einer :-)

...Lauscher sind auf. Eure kryptischen Fachtermini schrecken zwar etwas ab, sich per Laienwort an eurem Stammtisch zu beteiligen, aber ich denke, ich habe geschnallt, worum es geht :biggrin: :biggrin: :biggrin:
 
Ich werd das alles erstmal nacheinander auf'm Steckbrett austesten, aber im Endeffekt hab ich fast alle Teilprobleme schonmal irgendwo gehabt und gelößt, bis auf die SD Karte -> http://www.ulrichradig.de/site/atmel/avr_mmcsd/ .
Das mit den OPs ist auch kein Ding, dann sitzen halt noch 2 bis 4 LM324 drauf (+ einer für'n Klopfsensor). Macht dann 8 bis 12 Kanäle.

Der größte Aufwänd wird wohl sein das alles zusammenzufügen.

Na, dann mal ran ans Steckbrett - so viele Bauteile sind's ja nicht.
Noch zwei Anmerkungen zur Struktur der gespeicherten Daten:
- Um die Daten im PC vernünftig verarbeiten zu können, sollten sie am besten im schon AVR in ASCII und nicht im Binärcode angelegt werden. Das erhöht natürlich den Speicherbedarf deutlich. Alternativ schreibst du dir ein PC-Programm, dass dann die Daten auseinanderfriemelt.
- Du brauchst eine zeitliche Zuordnung der Messwerte. Das geht am einfachsten, wenn du die schnellste Abtastung, also wohl den Klopfsensorwert als Zeitbasis nimmst und alle anderen Werte zur gleichen Zeit in einem Block ablegst, auch wenn sie sich nicht geändert haben. Andernfalls müsstest du an jeden Messwert einen Timecode hängen, was die Auswertung nicht gerade vereinfacht...

Beste Grüsse

Roland

Moin Nachbar ;-)
 
Das kommt in binär drauf, ist viel einfacher das später zu konvertieren, ala

fread(blabubb ein wert nach integer)
outfile << integerwert

Mehr isses nicht (streams können leider nicht mit binärwerten umgehen). Auf'm Rechner kostet ein prinft bzw. cout garnix, auf'm AVR...
C/++ ist überhauptkein Problem, im Gegensatz zu vielen anderen finde ich, dass das eine der schönsten Sprachen überhaupt ist ;).

Die Zuordnung hatte ich mir folgendermaßen gedacht:

Es gibt 3 Gruppen von Messwerten. Einmal Klopfsensordaten, die mit konstanter Geschwindigkeit aufgezeichnet werden (halt 24ksps, also zwischen 2 Werten liegen exakt 41.66us). Die könnte man vll zu Blöcken von 124 16bit Werten zusammenfassen und die 4 Bytes die zu 256 noch fehlen mit dem Time Stamp (exakte Zeit für den ersten oder letzten Wert) auffüllen. Dadurch bleiben die Daten auch bei langer Aufzeichnungszeit synchron (wäre aber garkein Muss, weil die Takte sowieso alle vom Systemtakt abgeleitet sind).

Der 2. zeitkritische Wert sind die Ventilöffnungszeiten. Da würd ich direkt im AVR die Öffnungszeit bestimmen, und die speichern. Mir fällt aber grad ein, dass eigentlich nicht nur das "wie lange" interessant ist, sondern auch das "wann".
Also die Öffnungsdauer kann man gut im AVR bestimmen, dann reicht es wenn man zuordnen kann, zu welcher Umdrehung der Wert gehört - schneller als 100Hz dreht der Motor nicht.
Das "wann macht das Ventil auf" muss man dann wohl mit exaktem Timestamp speichern, sprich der AVR der das erkennt schickt dem an der SD Karte irgend 'n Code der sagt worum es geht (Ventil 3 hat grad aufgemacht) und den Timestamp wann das passiert ist.
Wenn wirklich alle 4 Ventile erfasst werden sollen, macht das bei 32bit Timestamps etwas über eine Stunde (bei 1us Auflösung). Den Überlauf danach kann man später in Software rausrechnen, reicht also völlig. Datenrate liegt dann bei max. 2.4kB/s für alle 4 Ventile und 16bit identifier. OT Sensor sieht ähnlich wie die Ventile aus.


Die 3. Gruppe umfasst alle anderen Signale, die nicht so besonders zeitkritisch sind. Die kann man denke ich einfach sammeln und in Blöcken ablegen. Wenn die mit 100hz ausgelesen werden macht das 100 Blöcke pro Sekunde, jeden kann man mit einem Timestamp versehen.
Dann weis man zwar nicht wann innerhalb der 10ms die so ein Block umfasst das Signal bestimmt wurde, aber das braucht man auch nicht so wirklich. Wenn man schnell auf's Gas tritt hat man das Pedal in vll. 0.5sek auf dem Boden, macht also 50 Werte.
Dazu kommt, dass die Zeitabstände zwischen den einzelnen Werten kaum Jitter haben werden, weil das Auslesen ansich deutlich schneller als in 10ms geht, und immer in der gleichen Reihenfolge ausgelesen wird.
 
Schonmal drüber nachgedacht einen DD-WRT Router zu nehmen ?
Der dürfte schnell genug sein, kann SD, HDD, USB bedienen, und somit jegliche Hardware, die man sich so wünscht.

/To
 
Das kommt in binär drauf, ist viel einfacher das später zu konvertieren, ala
fread(blabubb ein wert nach integer)
outfile << integerwert
??? Was hat das jetzt mit Integerwert zu tun?
Mir fällt aber grad ein, dass eigentlich nicht nur das "wie lange" interessant ist, sondern auch das "wann".
Das ist doch der Punkt. Man will doch wissen, in welchem zeitlichen Verhältnis die Ereignisse zueinander stehen. Da ist es am einfachsten, man hat eine .txt-Datei in der alle Ereignisse zu einer Zeit duch Tabs oder sonstwas getrennt in einer Zeile stehen, dann mit Exel einlesen und Kurven betrachten. Dein Ansatz geht natürlich auch, aber da hast du jedesmal nach einer Testfahrt eine hübsche Fleiskärtchenoption...
 
Der Router könnte Dir Deine Kurven direkt zu Hause auf den Drucker jagen ;)
 
Die SD Karte an den AVR zu bekommen ist wohl eines der kleinsten Probleme - das sind wie gesagt alles nur kleine Probleme, das große Problem besteht darin das alle kleinen Probleme realisiert werden wollen.

Idealerweise wird das 0815 Hardware. 3 ATMega32 per I2C verbinden macht 2 Leitungen, an den einen die SD Karte macht 3 Leitungen, 'n paar Widerstände usw., dann noch an die beiden anderen je 2 LM324, die können nah an die AVRs ran, macht das Layout einfacher. An sämtliche Eingänge Zener, wer weis was da so für Spitzen drauf sind.
VCC und VCCA sind auch schnell erzeugt, wegen den ungünstigen EMV Bedingungen noch ein paarmal 100nF an günstige Stellen, an die AVRs sowieso.
Spezielle Hardware muss für den Klopfsensor her, notfalls auf eine kleine Extraplatine (bekommt man sicher auf 2x2cm), die per Stecker an einen ADC.

Also ich seh da kein Problem. Für die OPs muss noch 'ne negative Spannung her, aber Ladungspumpen hab ich sogar rumliegen.
HF-Technisch ist das glücklicherweise 'n Witz (sogar der Klopfsensor), von daher...

@901fpt

fread liest einen Binärwert, cout schreibt so wie's dasteht einen ASCII Wert ;). Das ist die Konvertierung.

Das zeitliche Verhältnis wird doch mitgespeichert??
 
Moin
Hätt mal 2 etwas allgemeinere Fragen:
1. In welchem Bereich bewegen sich eigentlich die Öffnungszeiten der Einspritzventile? Und
2. in welchem Frequenzband spielen sich die Sachen ab, die der Klopfsensor empfängt?


Moin moin,

sag mal, welchen Zweck sollen die gewonnen Erkenntnisse dienen?
Die Daten aufzunehmen und zu wissen was sich tut ist eine (schon ambintionierte) Sache.
Die interpretation eine andere.
Wohin soll die Reise gehen?

Liebe Grüße
Martin
 
Erkenntnis ;)

Mich interessiert einfach mal wie die Lucas so rumregelt, wie zB. auf die Lambdawerte reagiert wird, auf was für Frequenzen das APC wie reagiert, usw.
Außerdem ließe sich das zur Diagnose bei Problemen sicher gut einsetzen.

Aus den Daten kann man sicher noch mehr machen, zB. 'n digitales APC, aber das überlass ich erstmal anderen.

Und um es nochmal zu sagen - im Moment ist das alles nur 'ne Überlegung. Ich werd mir mal eine SD Karte bestellen und das Interface vom AVR zusammenbasteln/proggen, dann werd ich erstmal 'n paar Testwerte draufschreiben und gucken ob das soweit funktioniert. Der nächste Schritt wäre dann vll mal einfach kontinuierlich die Lambdawerte draufzuschreiben, ohne Zeitbezug und alles. Das Zeugs kann dabei auch auf'm Steckbrett bleiben.
 
Der Router könnte Dir Deine Kurven direkt zu Hause auf den Drucker jagen ;)

Hm, bei 5 Stunden Fahrt dann doch bitte auf die Rolle im benachbarten Architekturbüro :biggrin: !

@i_h
Genau. Schritt für Schritt.
Ich hab schon die hübschesten Gebilde nach dem ersten Schritt zusammenstürzen sehen. Drei Leute planen zwei Monate und dann kommt so ein Depp von Praktiker und macht wieder alles putt...
 
Zurück
Oben