DFT fuer AVR

"Martin Laabs"

Mein Vorschlag: Du solltest vorher eine Aufnahme auf dem PC machen und die Frequenz bestimmen die du suchst. Danach dann ermitteln, welche Abtastfrequenz du brauchst und dann den Block so klein wie möglich wählen. Wenn du das geschickt machst, kann schon ein ca. 16 Zahlen langer Block ausreichen und dann brauchst du logischerweise nich viel Ram.

Da der Code einer DFT in knapp 25 Zeilen passt, sollte sich der benötigte Flashspeicher auch in Grenzen halten. Falls Interesse besteht hab ich einen Code in Pascal da den man 1:1 nach C umsetzen könnte.

lg,

Markus -

Martin Laabs schrieb:

Falls die Lösung wirklich für das Problem tauglich ist, würde ich das ganze mit dem Goertzelalgorithmus probieren. Damit kann man ausgewählte Frequenzpunkte einer DFT auswerten. Die typische Anwendung ist DMTF-Decodierung.

Grüße, Benjamin

Martin Laabs schrieb:

Sie hat dafür bestimmt einen Ausgang.

Gruß Dieter

Nee. Das ist eine aeltere Wandheizung aus DDR-Zeiten. Die ist vollmechanisch.

Tschüss Martin L.

Martin Laabs schrieb:

Dann spendier ihr ein Thermoelement, bei den Temperaturen in der Flamme ist doch die Auswertung kein Problem. Andere Möglichkeit (so wirds in elektronisch gesteuerten Heizungen gemacht) ist die elektrische Leitfähigkeit der Flamme.

Gruß Dieter

Naja, ich will an der Heizung eigentlich nichts verändern. Denn an so einer Gasheizung rumzuschrauben halte ich für nicht ungefährlich. Ich werde es heute mal mit einem Mikrofon am Computer probieren und berichten.

Viele Grüße Martin L.

"Wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus."

Schau Dir mal den dsPIC30 an. Der ist für so etwas deutlich besser geeignet.

Mit freundlichen Grüßen

Frank-Christian Krügel

Nein, ich nicht.

Habe mich vor laengerer Zeit mal etwas belesen. FFT kann man meiner Erinnerung nach "in place" machen, also mit nur dem RAM, den man ohnehin fuer die Messpunkte braucht (plus ein oder zwei Register fuer Zwischenergebnisse natuerlich). Die Werte im Zeitbereich werden mit den Amplituden der Spektral- linien (bzw. vorher den Zwischenergebnissen) ueberschrieben.

16-Punkte-FFT braucht also grob gesagt RAM fuer 16 Werte.

Habe das aber noch nie selber programmiert. HTH

Grusz, Rainer

"Frank-Christian Kruegel" schrieb:

Warum eigentlich ,,deutlich''?

Das wesentlichen Element, das man für DSP braucht (den Hardware-Multiplizierer) hat der ATmega auch, und die Multiplikationsbefehle sind offenbar sehr mit Bedacht hinsichtlich DPS-Funktionalität gewählt worden. Es gibt auch eine Atmel-Appnote dafür.

Kann gut sein, dass der dsPIC da mal irgendwann nachgezogen hat (m.E. nach ist er einiges jünger), aber persönlich möchte ich einen PIC nicht mehr im Traum programmieren. Eine schlechte Erfahrung reicht, und ein g'scheiter Compiler, den ich hobbymäßig benutzen kann (sprich: der wenig oder nichts kostet und auf Unix läuft) war dafür zumindest seinerzeit nicht aufzutreiben.

(Der OP klang auch nicht gerade, als wollte er eine 10000er Serie dafür auflegen. Da gelten dann sicher andere Prämissen.)

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Nun. Es ist so: Ich mag die Architektur von den PICs nicht sonderlich und habe mit den AVR's mehr Erfahrung. Nun brauche ich keine pure Rechenleistung weil es sich eh nur um ein paar Sampels handelt die nicht in Echtzeit verarbeitet werden müssen. Von daher ist ein evt. Vorteil von den dsPICs eher vernachlässigbar.

Tschüss Martin L.

"Rainer Ziegenbein"

Also bevor hier weiter "spekuliert" wird, poste ich mal einfach einen DFT-Code in Pascal. Dann wird schnell klar, wie er funktioniert, was er macht und was er für Anforderungen bei 16 Samples setzt. Der Code ist möglicherweise noch nicht der schnellste, weil er die Register nicht optimal benutzt, aber das kann man ja leicht ändern.

isign = 1 bei Werte nach Frequenzraum isign = 0 bei Frequenzraum nach werte

Das Werte Array sieht so aus:

1 2 3 4 5 6 7 8 Wert 0 Wert 0 Wert 0 Wert 0

Das Frequenzarray hat folgenden Aufbau: Kann auch sein dass im und re vertauscht sind. So genau weiß ich das nicht mehr.

1 2 3 4 5 6 7 8 re im re im offset im re im

CONST nn=16; nn2=2*nn; (* 2*nn *) TYPE gldarray = ARRAY [1..nn2] OF real; //MG_array = array [0..128] of smallint;

PROCEDURE four1(VAR data: gldarray; nn,isign: integer); FUNCTION sngl(x:real):real;

implementation

FUNCTION sngl(x:real):real; BEGIN sngl := x END;

PROCEDURE four1(VAR data: gldarray; nn,isign: integer); (* Programs using routine FOUR1 must define type TYPE gldarray = ARRAY [1..nn2] OF real; in the calling routine, where nn2=nn+nn. *) VAR ii,jj,n,mmax,m,j,istep,i: integer; wtemp,wr,wpr,wpi,wi,theta: double; tempr,tempi: real; BEGIN n := 2*nn; j := 1; FOR ii := 1 TO nn DO BEGIN i := 2*ii-1; IF (j > i) THEN BEGIN tempr := data[j]; tempi := data[j+1]; data[j] := data[i]; data[j+1] := data[i+1]; data[i] := tempr; data[i+1] := tempi END; m := n DIV 2; WHILE ((m >= 2) AND (j > m)) DO BEGIN j := j-m; m := m DIV 2 END; j := j+m END; mmax := 2; WHILE (n > mmax) DO BEGIN istep := 2*mmax; theta := 6.28318530717959/(isign*mmax); wpr := -2.0*sqr(sin(0.5*theta)); wpi := sin(theta); wr := 1.0; wi := 0.0; FOR ii := 1 TO (mmax DIV 2) DO BEGIN m := 2*ii-1; FOR jj := 0 TO ((n-m) DIV istep) DO BEGIN i := m + jj*istep; j := i+mmax; tempr := sngl(wr)*data[j]-sngl(wi)*data[j+1]; tempi := sngl(wr)*data[j+1]+sngl(wi)*data[j]; data[j] := data[i]-tempr; data[j+1] := data[i+1]-tempi; data[i] := data[i]+tempr; data[i+1] := data[i+1]+tempi END; wtemp := wr; wr := wr*wpr-wi*wpi+wr; wi := wi*wpr+wtemp*wpi+wi END; mmax := istep END END;

end.

Und Rainer hat insofern Recht, dass dieser Code noch suboptimal ist, weil hier das Ergebnisarray eine Spiegelung ist. Ich kenne aber keine schnelleren Codes. Schnellere Codes würden mich allerdings ebenfalls interessieren. egal welche Sprache.

lg,

Markus -

Man sollte vll noch erwähnen, dass der gepostete Code natürlich auf Genauigkeit getrimmt ist. Es gibt natürlich noch DFT die auf Bytes oder integer arbeitet, aber sowas hab ich auch noch nie benutzt, weil die logischerweise immer ungenau sind. Aber dafür halt viel schneller.

lg,

Markus

Am Fri, 23 Sep 2005 18:49:27 +0200 schrieb Dieter Wiedmann :

Oder einen Mikroschalter an einem Ventil/Thermostaten/etc. Wenn das Ding vollmechanisch ist, dann muß sich doch da irgendwas bewegen, wenn sie einschaltet, ein mechanischer Schalter (oder induktiver Näherungsschalter/Lichtschranke,...) kann das erkennen.

--
Martin

Am 23 Sep 2005 17:20:19 GMT schrieb Martin Laabs :

Dann pick das Thermoelement auf das Abgasrohr, auch das wird schnell heiß, wenn die Flamme an ist.

--
Martin

Deutlich deswegen:

- Multiply-and-Accumulate Befehle für Filter

- bit reverse Adressierung, um FFTs effizient implementieren zu können

- 16,32,40 Bit Festkommaformate, zwei 40 Bit Accus

- Hardware-Loops, damit pro Takt ein Filter Tap

- gegenüber den AVRs teilweise bessere Peripherie

Eine normale FFT braucht bei n=64 125µs, bei n=128 283 µs, bei n=256 635µs. Die passende DSP-Bibliothek gibts fertig zum Download.

Gegenüber den normalen PICs (die ich auch nicht besonders mag, aber mit dem C18 Compiler ist es erträglich), ist das Programmiermodell deutlich komfortabler geworden - kein Vergleich zu den 18F oder gar 16F Serien.

Ok, ich mach das ganze für Geld, und die paar 100¤ für Compiler, Bibliotheken und JTAG-Debugger pro Architektur sind da nie ein Problem.

Mit freundlichen Grüßen

Frank-Christian Krügel

|> Gegenüber den normalen PICs (die ich auch nicht besonders mag, aber mit dem |> C18 Compiler ist es erträglich), ist das Programmiermodell deutlich |> komfortabler geworden - kein Vergleich zu den 18F oder gar 16F Serien.

Dann sollte Microchip aber endlich mal das "PIC" aus dem Namen rauswerfen, wenn sie was verkaufen wollen. Für mich ist das ein "don't use"-Signal, da mache ich lieber noch mit 8051 rum.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Martin Laabs schrieb:

Gas kann man, im Gegensatz zu Strom, riechen, man Odorierung.

Wozu einfach wenns auch kompliziert geht.

Gruß Dieter, pragmatisch.

Wirklich breite technische Anwendung haben solche Systeme nicht. Es wird seit den 60er Jahren in Atomkraftwerken wegen der Probleme direkt an den Brennstäben Sensoren anzubringen mit solchen indirekten Verfahren experimentiert. Genaue Temperaturmessung ist so wohl nicht möglich aber grobe Abschätzung von Betriebszuständen. Und man hofft auf Frühdiagnose von Ausfällen ( "da klappert schon wieder eine rausgefallene Schraube durch den Kühlkreislauf ...").

Mit Beschleunigungssensoren werden solche Messungen an Motoren häufiger gemacht, typisch synchronisiert auf Drehzahl des Motors. Da gehts aber nicht um breites Rauschspektrum sondern Spektrallinien die man fein auflösen will. Als Alternative zur FFT werden deshalb auch ChirpZ und andere DFT-Varianten verwendet.

MfG JRD

Naja, so ist die Aussage nicht ganz richtig.

Die wenigsten Gase kann der Mensch riechen. Das Gas um das er hier speziell geht, nämlich das Erdgas so wie es ins Haus kommt, besteht zu großen Teilen aus Methan. Methan und die anderen Bestandteile des gewonnen Erdgases ist für Menschen erstmal völlig geruchslos.

Darum wird dem Erdgas extra ein Duftstoff beigemischt, nämlich Ethanthiol. Ansonsten hättest Du keine Chance, das Erdgas zu riechen.

Solche Duftstoffe werden auch noch anderen Gasen beigemischt, damit man "sie" riechen kann.

Details finden sich auch unter:

1.) 2.)