DFT fuer AVR

M

Martin Laabs

Guest
Hallo,

hat jemand schon mal eine DFT für einem Atmel AVR progammiert und
weis wie viel Flash und SRAM diese in etwa beansprucht?
Hintergrund: Bald ist wieder Winter und ich baue gerade für meine
Gasheizung eine intelligente Regelung und will nun akustisch erkenne
ob sie ein oder ausgeschaltet ist.
Ich will daher einfach die Frequenzspektren von "Heizung aus" zu "Heizung
ein" unterscheiden.

Viele Grüße
Martin L.
 
"Martin Laabs"

hat jemand schon mal eine DFT für einem Atmel AVR progammiert und
weis wie viel Flash und SRAM diese in etwa beansprucht?

Ich will daher einfach die Frequenzspektren von "Heizung aus" zu "Heizung
ein" unterscheiden.
Click to expand...
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 - http://www.pSCIT.com
 
Martin Laabs schrieb:
hat jemand schon mal eine DFT für einem Atmel AVR progammiert und
weis wie viel Flash und SRAM diese in etwa beansprucht?
Click to expand...
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:

Gasheizung eine intelligente Regelung und will nun akustisch erkenne
ob sie ein oder ausgeschaltet ist.
Click to expand...
Sie hat dafür bestimmt einen Ausgang.


Gruß Dieter
 
Dieter Wiedmann <Dieter.Wiedmann@t-online.de> wrote:
Martin Laabs schrieb:

Gasheizung eine intelligente Regelung und will nun akustisch erkenne
ob sie ein oder ausgeschaltet ist.

Sie hat dafür bestimmt einen Ausgang.
Click to expand...
Nee. Das ist eine aeltere Wandheizung aus DDR-Zeiten. Die ist vollmechanisch.

Tschüss
Martin L.
 
Martin Laabs schrieb:

Sie hat dafür bestimmt einen Ausgang.

Nee. Das ist eine aeltere Wandheizung aus DDR-Zeiten. Die ist vollmechanisch.
Click to expand...
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
 
Dieter Wiedmann <Dieter.Wiedmann@t-online.de> wrote:

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.
Click to expand...
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.
 
On 23 Sep 2005 14:51:11 GMT, Martin Laabs <98malaab@gmx.de> wrote:

hat jemand schon mal eine DFT für einem Atmel AVR progammiert und
weis wie viel Flash und SRAM diese in etwa beansprucht?
Click to expand...
"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
 
Martin Laabs wrote:

hat jemand schon mal eine DFT für einem Atmel AVR progammiert
Click to expand...
Nein, ich nicht.

und weis wie viel Flash und SRAM diese in etwa beansprucht?
Click to expand...
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 <dontmailme@news.invalid> wrote:
On 23 Sep 2005 14:51:11 GMT, Martin Laabs <98malaab@gmx.de> wrote:

"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.
Click to expand...
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"

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.
Click to expand...
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;
data[j+1] := data[i+1];
data := 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-tempr;
data[j+1] := data[i+1]-tempi;
data := data+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 - http://www.pSCIT.com
 
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
<Dieter.Wiedmann@t-online.de>:

Martin Laabs schrieb:

Sie hat dafür bestimmt einen Ausgang.

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

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.

Oder einen Mikroschalter an einem Ventil/Thermostaten/etc. Wenn das Ding
Click to expand...
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 <98malaab@gmx.de>:

Dieter Wiedmann <Dieter.Wiedmann@t-online.de> wrote:

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.

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.

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

--
Martin
 
On Fri, 23 Sep 2005 19:26:55 +0000 (UTC), j@uriah.heep.sax.de (Joerg Wunsch)
wrote:

"Frank-Christian Kruegel" <dontmailme@news.invalid> schrieb:

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

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.
Click to expand...
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.

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.
Click to expand...
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
 
"Frank-Christian Kruegel" <dontmailme@news.invalid> schrieb:

Schau Dir mal den dsPIC30 an. Der ist für so etwas deutlich besser
geeignet.
Click to expand...
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. ;-)
 
In article <nrp8j11tho2hq591tkvtg36mernrlsi1jq@4ax.com>,
"Frank-Christian Kruegel" <dontmailme@news.invalid> writes:
<...>
|> 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:

Naja, ich will an der Heizung eigentlich nichts verändern.
Denn an so einer Gasheizung rumzuschrauben halte ich für nicht
ungefährlich.
Click to expand...
Gas kann man, im Gegensatz zu Strom, riechen, man Odorierung.


Ich werde es heute mal mit einem Mikrofon am Computer probieren
und berichten.
Click to expand...
Wozu einfach wenns auch kompliziert geht.


Gruß Dieter, pragmatisch.
 
akustisch erkenne
Wirklich breite technische Anwendung haben solche Systeme
Click to expand...
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
 
Dieter Wiedmann wrote:

Gas kann man, im Gegensatz zu Strom, riechen, man Odorierung.
Click to expand...
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.) http://de.wikipedia.org/wiki/Erdgas
2.) http://de.wikipedia.org/wiki/Ethanthiol
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top