i_h

Nachdem ich gestern am Überlegen war die Daten mit'm Hammer in die SD Karte zu meißeln (das blöde Ding wollte einfach net mit mir bzw. dem AVR reden), hat die Sache heute endlich geklappt. Die 1GB Karte weigert sich zwar nach wie vor, aber die 16MB Karte die noch rumliegt tut einwandfrei. Liegt wahrscheinlich an den 320 Ohm Impedanz der Datenleitungen zur Karte (SD braucht 3.3V, AVR 5V, also einfacher Spannungsteiler...), die 16MB Karte läuft, seitdem ich 'n paar Waitstates drinnen hab, einwandfrei (high speed ist natürlich was anderes; ich frag mich wann mir sowas einfällt bevor ich ewig rumprobiere und rummesse, ist nicht das erste mal, dass irgend'ne Übertragung net läuft weil's zu schnell ist). Hab mal 'n Poti an den ADC gehängt und ein bisschen dran rumgedreht, kann sich eigentlich schon sehen lassen. Hab erstmal ein Sample alle 50ms genommen, also 20Hz. Ist auch'n 21gang Präzisionstrimmer, da kann ich eh net so schnell rumdrehen. Daten auslesen war auch kein Ding, hab das Diagram mal angehängt... Mist, aus irgendeinem Grund lässt der mich die net anhängen. Na dann halt über Webspace: http://www.jfuhlemann.de/tmp/poti.png Y ist der ausgelesene ADC Wert (10bit, also 0..1023), X die Samplenummer. Erstaunlich wie konstant man das Poti per Schraubenzieher drehen kann (letzter Teil) *g* EDIT: Jetzt mit ordentlichem Zeitbezug (Sekunden). An den roten Punkten hat er gemessen, hab außerdem ein normales Poti genommen. Sind ca. 66Hz. 1 Sektor schreiben dauert 200ms (kein Wunder bei 10us delay pro gesendetem Bit), und weil das noch ohne Interrupts läuft, wird in der Zeit nix gemessen. http://www.jfuhlemann.de/tmp/poti2.png

Waren glaub keine der Stammuser. Da mich mein Gedächtnis bei der Aussage von hft aber schon nicht getrügt hat, und ich mir sicher bin mindestens 2mal von Usern gelesen zu haben die'n 8V Lader im Softturbo ohne Probleme fahren (zur Erinnerung - der Fuel Cut ist beim Softi niedriger eingestellt), und ich im Moment eigentlich auch was anderes zu tun hab, such ich die jetzt nicht extra raus. Irgendwo hier schwirren sie rum, wer sucht der findet.

Es ging auch eher darum was die Aussage in der Praxis bedeutet. Ich hab heut früh nämlich selber schon geschrieben, dass genau das passieren soll (Lader kann nicht mehr abregeln - weil ich mich noch an hfts Beitrag erinnern konnte, daher hab ich die Info). Auf der anderen Seite sind hier, seitdem ich das gelesen hab, auch einige aufgetaucht, die mit dem 8V Lader problemlos im Softturbo fahren. Desswegen habe ich geschrieben, dass er sich "[...] wahrscheinlich auch fahren" lässt. Dazu hab ich nochmal genau das geschrieben, was ich eben grad geschrieben hab. Und ich hab meinen Beitrag nicht umsonst mit Wörtern wie "wahrscheinlich" gewürzt, weil ich es nicht genau weis. Jetzt erklär ich schon Satz für Satz Beiträge die ich vor ein paar Stunden geschrieben hab...

Und um nochmal ganz deutlich zu zeigen das mein Alzheimer noch nicht weiter fortgeschritten ist: http://www.saab-cars.de/showthread.php?t=11487&page=3 Ich zitiere mal: übrigens von hft. Ich hab mich oben also richtig erinnert.

Soso, und das vom Meister der "hier hast'n Knochen"-Mentalität... Vielleicht ist das ja auch altersbedingt, aber wenn ich was zu einem Thema weis (oder glaube zu wissen) behalte ich das nicht auf Biegen und Brechen für mich und gebe irgendwelche unbegründeten Aussagen von mir (genau das ist es, wenn man eine Antwort ohne Begründung hinschreibt). Einige Leute hier scheinen es aber nötig zu haben, das man sie erstmal 'ne Runde anbetet, bevor sie wiederwillig mit 'nem klitze kleinen bisschen von ihrem Wissen rüberrücken, frei nach dem Motto "mein Wissen ist mein Kapital" und Erwerbsregel 1. Habt ihr das wirklich nötig? Ich war früher mal in 'nem anderen Forum unterwegs, hatte da >10mal so viele Beiträge wie hier und konnte zu vielen Themen was sinnvolles beitragen. Aber wenn ich irgendwo geantwortet hab, hab ich mir nicht jedes Wort aus der Nase ziehen lassen.

Soll ich den Beitrag raussuchen? Glaub der kam von hft. Also werd bitte spezifischer. Entweder du schreibst was du meinst, oder du lässt es sein. Aber diese "hier hast'n Knochen"-Mentalität geht mir so ein bisschen auf den Keks.

Mit lässt er sich wahrscheinlich auch fahren. Es heist zwar das Wastegate wäre zu eng für die Abgasmenge vom 16V, aber es fahren einige mit 8V Ladern rum, und es funktioniert problemlos. In Realität heist das dann wahrscheinlich, dass der Lader nicht mehr unter 0.1Bar oder sowas geregelt werden kann...

Ich denke nicht, dass ich das in C++ aufziehen werde. Mit C und ein paar Zeigerspielereien ist man fast noch flexibler, vor allem aber braucht es weniger Platz. Compiliert wird die Sache aber nicht mit winavr sondern avrgcc (die Linuxversion, aber sonst identisch). Mit gcc auf AVR hab ich bisher noch nicht sooo viel Erfahrung (hab schon einiges damit gemacht, aber "langjährig Erfahrung" würde ich es nicht nennen), mit ausgewachsenen Rechner + gcc allerdings schon.

Ich denk mal der GCC geht als vernünftiger Compiler durch :) Reichelt hat heut die SD Karte geliefert und das, was ich für meinen improvisierten SD Slot brauch. Wenn ich morgen dazu komme werd ich den AVR mal ein paar Daten draufprügeln lassen.

Lies nochmal den Text durch, es ging darum, dass die Aussage kein "LOOOOL" wert ist...

Zu DEM Cabrio gehört auch kein APC... Softturbos wurden meines Wissens nie mit APC ausgeliefer, korrigier mich, wenn ich falsch liege.

Wie gesagt, so abwegig ist das nicht. Mein roter Turbo hat zB. KEINE Befestigungsmöglichkeit für einen Klopfsensor. Kann nicht so ganz verstehen, warum die Frage ein "LOOOOOL" wert ist...

Ab '82 sollten alle das Gewinde im Block haben. Mein '81er Turbo hat's nicht, da gab's noch kein APC.

Sind ja alles andere Autos ;). Den in der mitte hatte ich 'ne weile. Hübscher 8V Turbo, aber total runtergeritten. Hätte man vielleicht in Rostumwandler einlegen können.

Die Dinger reißen meistens garnet, sondern werden einfach übermäßig dünn (ist ja Litze, wenn da immer mal eine Ader reißt...). An den Stellen fällt dann soviel Leistung ab, dass sie durchschmoren.

Abhängig davon wie durchgesessen sie ist, wird sie immer weniger warm, weil die Übergangswiderstände steigen.

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.

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??

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.

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.

Noch ist es ja nur 'ne Überlegung 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 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.

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.

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

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?

Der Unterschied zwischen den Red Boxen und den normalen ist, dass erstere bei steigender Drehzahl den Ladedruch nicht (so weit) zurückfahren, und dadurch kommt dann auch mehr Leistung raus. Also wer meint seine Redbox bringe nicht mehr als eine normale und das bei 3000rpm austestet, hat das Prinzip nicht verstanden. Beim 9000 gibt's den Übergang gelb/rot übrigens nicht, da kommen erstmal ein paar rote Striche und danach fängt erst der rote Bereich an. Den 9000 gibt's auch mit mehr als 185PS ...