Frequenzerkennung 125-140kHz mit dsPIC machbar?

Was soll denn ein IIR 2.Ordnung ? Wenn die Frequenzen ja bekannt sind 
ist es viel einfacher. Das Signal gleichzeitig mit Sin & Cos der 
gesuchten Frequenz multiplizieren und integrieren. Die 
Frequenzunschaerfe bekommt man mit der weniger als unendlichen Laenge

@Detlef_a: ja genau sowas ähnliches mach ich gerade. Ich Taste mit z.B. 
12,5kHz ab und sehe jetzt den Bereich von 125-130kHz als 0-5kHz.
Nur muß da ein recht steiler Bandpass vor den ADC damit keine Aliases 
von anderen Frequenzen reinkommen. Den will ich eigentlich irgendwie 
vermeiden. Mehr als ein Tiefpass 3-4.Ordnung sollte es nicht werden 
(Platzprobleme).

Bin jetzt auf den Goertzel-Algorithmus gestossen der für meine Anwendung 
ggenau das richtige sein soll. Mal sehen ob ich überhaupt verstehe um 
was es da geht.


MfG Oli

Der Goertzel ? War nicht die Frage nach der Anwesenheit von Frequenzen ? 
Deswegen muss man die ja noch nicht bestimmen. Eine komplex 
multiplikation mit einem oder zwei sinussen ist viel einfacher.

Hallo Zacc

Der Ansatz klingt interessant (und recht einfach und schnell)

Bin leider recht neu in dem Thema deswegen nochmal nachgefragt:

Versteh ich das richtig: Sinus- und Cosinuswerte (von welcher Frequenz? 
Signalfrequenz? )in Tabelle und Eingangswerte damit multiplizieren 
(jeden Wert mit jeden oder wie?), dann die Ergebnisse aufaddieren und 
wenn Ergebniss Grenze übersteigt ist die Frequenz "da"?
Hat das ganze eine offiziellen Namen?


Trotzdem mal danke für alle Antworten

MfG
Oli

Das mag schon sein das der so schnell ist aber ich hab in meiner 
Sample/Berechnung ISR einen Portpin gesetzt den ich mit dem Oszi 
beobachte um zu schauen wie lang er in der ISR ist und irgendwie braucht 
mein IIR 1.Ordnung mit dem Sampling (braucht angeblich 11 Takte) und ein 
wenig Speicher umladen so lang das sich max. 30kHz (entspricht kSmpls/S) 
ausgehen.
Wie gesagt ich hab noch nix optimiert (Compiler gcc-C).
Werd mal den Assembler anschmeißen.

Seltsam ist - selbst wenn ich in der ISR einfach nur einen Wert aus 
einer Tabelle auf den DAC schreibe und dann einmal index++ mache dauert 
das so lang das max. 100kHz Interruptrate gehen. Ich glaub ich mach was 
falsch.
(Die ISR wird übrigends vom Timer getriggert)


MfG Oli

Guten Morgen

Hab gestern noch etwas mit dem ARM herumexperimentiert.

1.)
Mal rein in einer Endlosschleife Portpins getoggelt.
Ergebniss:
C Code mit gcc kompiliert: 2,4MHz Toggelrate,
Assembler: etwas über 8 Mhz Toggelrate.
Da ist sicher noch was drinn wo dann auch diverse Signalverarbeitung am 
ARM möglich ist.

2.)
Wenn ich jetzt rechne: 60Mhz, 400kSmpls/s -> 150 Takte Rechenzeit pro 
Sample

27Takte braucht er mind. bis er in der ISR ist,
143!!! Takte (hab mich gestern verlesen) braucht der ADC bis er fertig 
ist (da ergeben sich dann so ziemlich genau die angegebenen 400kSmpls/s 
bei 60Mhz Systemtakt)
Man kann während diesen 143 Takten zwar was anderes machen aber 
irgendwann brauch ich den Wert um zu rechnen. Wenn das dann auch noch 
100Takte braucht bin ich sowieso jenseits von gut und böse.

Mal sehen ob es geht den ADC direkt vom Timer zu triggern und die ISR 
dann vom "ADC fertig Interrupt". Da sollte sich das dann mit ASM 
Programmierung mal grade so ausgehen.

Das Problem ist dann nur das für die Hauptschleife dann genau garkeine 
Zeit mehr überbleibt

3.)
Deswegen ja meine Frage ob der dsPIC da nicht vielleicht die bessere 
Wahl wäre (richtigen TI oder Analog DSP kann ich mir vermutlich nicht 
leisten).
ARM7 hat den Vorteil das ich da Board und Programmierequipment schon 
habe. Aber wenn mir jetzt jemand sagt das das mit dsPIC locker von der 
Hand geht (oder der gar noch unterfordert ist) dann würd ich mir sogar 
die Mühe machen auf diesen umzustellen.


MfG
Oli


P.S.: Juhu Freitag - noch wenige Stunden und dann ab ins Wochenende

Mein Ansatz mit Sinus und cosinus zu multiplizieren ist der Ansatz den 
man fuer Fourierkoeffizienten im Allgemeinen nimmt. Die Sin/ Cos We\rte 
nimmt man natuerlich aus einer Tabelle.

Primitiv-Vorschlag.

Auf einen analogen Tiefpass (Spannungsteiler) Signal draufgeben. Die 
Spannung muss sich dann über die Frequenz am ADC-Eingang einstellen. Nur 
noch ADC auslesen und Fenster kontrollieren. Mit einer hohen 
ADC-Auflösung wird das Ergebnis recht scharf.

Sebastian

Hallo

@andreas:
DMA hat er leider nur für USB (LPC2148).
Ich hätte bisjetzt nicht entdeckt das der auch für was anderes zu 
gebrauchen ist.

Das mit dem "ab und zu" verarbeiten klingt aber interessant. Ich möchte 
halt gern mind. 4800bps über dieses "Powerline" System (nur hat die Line 
über die es geht kaum Power :-) ) schaufeln. Dh. wenn ich mind. doppelt 
so schnell berechnen kann sollts eigentlich passen. Werd am Abend 
Versuche machen.

Wenn wirklich mit AVR oder MSP430 machbar dann wär das natürlich ein 
Traum, nur dürften die ADCs zu langsam sein.

@Sebastian:
Das mit dem analogen FM Demodulator funktioniert aber wahrscheinlich nur 
wenn der Betrag der Eingagsspannung bekannt ist bzw. mit einer 
automatischen Verstärkungsregelung (siehe Radio).
Außerdem will ich auf Analogtechnik so weit wie möglich verzichten, für 
viel mehr als die CPU ist eigentlich nicht Platz


MfG Oli

>27Takte braucht er mind. bis er in der ISR ist,
>143!!! Takte (hab mich gestern verlesen) braucht der ADC bis er fertig
>ist (da ergeben sich dann so ziemlich genau die angegebenen 400kSmpls/s
>bei 60Mhz Systemtakt)
>Man kann während diesen 143 Takten zwar was anderes machen aber
>irgendwann brauch ich den Wert um zu rechnen. Wenn das dann auch noch
>100Takte braucht bin ich sowieso jenseits von gut und böse.
was haelst du davon:

1

volatile int oldval;

2

3

isr(){

4

  start_adc():

5

  calculate_iir(oldval);

6

  wait_for_adc();

7

  oldval = adcval;

8

}

dann hast du keine probleme mit den mind. 143 takten ;)

Hallo n!x

Ja so ähnlich passiert das jetzt auch.
Der ADC ist jetzt so eingestellt das er ca. 200Takte für ein Sample 
braucht. Immer wenn er fertig ist triggert er die ISR und sampled gleich 
weiter.

Also von der Verarbeitungsgeeschwindigkeit ist das jetzt durchaus OK. 
Hab etwas mit Assembler optimiert. Das was der gcc produziert ist 
sowieso irgendwie recht müllig wenns schnell sein muß: z.B. verwendet er 
kaum einmal andere Register als r2 und r3. Und er fügt "sinnlose" 
Registerkopierbefehle ein nur damit z.B. immer r2 (oder halt r3) 
Zielregister ist.
Und so Sachen wie banked Register (bei FIQ) kennt scheint er auch nicht 
zu kennen.

MfG Oli