Forum: Digitale Signalverarbeitung / DSP Filterdesign lernen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von KarlD (Gast)


Bewertung
0 lesenswert
nicht lesenswert
N'abend!

Aktuell versuche ich mich gerade etwas mit FIR-Filtern.
Dabei nutze ich den FilterDesigner der bei der MATLAB DSP Toolbox 
beiliegt.
Ich habe gelesen, dass -60dB als Stopband-Unterdrückung schon sehr gut 
ist und sich in Hardware nur mit großem Aufwand erreichen lässt.
Bei einem Tiefpass mit den Durchlass- und Sperrfrequenzen von 2,7k und 
3k und einer Abtastrate von 48k errechnet mir Matlab einen Filter mit 
mehr als 300 Taps. Dabei hatte mein Professor vor ein paar Wochen noch 
erwähnt, dass oft der Fehler gemacht wird mit zu optimistischen Angaben 
zu arbeiten und so auf paar hundert oder gar tausend Taps kommt. Diese 
sehen zwar schön aus, lassen sich dann aber auf Mikrocontrollern eher 
weniger realisieren (wenn es um die Verarbeitungsgeschwindigkeit geht). 
Selbst bei einer Unterdrückung von -30dB komme ich aber noch auf knapp 
200 Taps. Ich frage mich, ob ich etwas grundsätzlich falsch mache?
Als Design Method habe ich Equiripple ausgewählt bzw. es war schon 
vorausgewählt. Die anderen machen es aber auch nicht besser.

von Guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja 300Hz von Pass zu Stop sind halt schon eine Hausnummer das sind ja 
ca. 90db/dec wenn du da 30db ansetzt.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Eigentlich ist es einfach: Randbedingungen erfassen und in den 
Designprozess einfließen lassen.

Randbedingungen:
- Designzeit
- Modularität
- Erweiterbarkeit
- Flexbilität

- Rechenzeit
- Rechengeschwindigkeit

- Echtzeitfähigkeit
- Echtzeitänderungungsfähigkeit

- Resourcenverbrauch
- Stromverbrauch


Siehe auch
Beitrag "Re: Vivado und MATLAB"
Abschnitt "Praktisches Ausprobieren"

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

So'n Filterdesign mit ner Toolbox ist halt eine Holzhammermethode. Die 
geht schon immer irgendwie, ist aber nicht immer "schoen". Ich wuerd's 
so aus'm Handgelenk raus mit 2 Teilfiltern loesen. Einem Filter F1, das 
durch Einfuegen von diversen Nullen einen periodischen Frequenzgang, 
aber dadurch auch steile Flanken hat, und einem zweiten Filter, was dann 
enspannter ist, und nur Sperrdaempfung "weiter hinten" machen muss. Die 
20 als Filterordnung ist einfach nur mal ein Anfangswert.

Also so z.B.:
f1=(firls(20,[0 0.1125*4 0.125*4 1],[1 1 0 0]));
uf1=upsample(f1,4,0);

f2=(firls(20,[0 0.1125 0.5-0.1125 1],[1 1 0 0]));

freqz(conv(uf1,f2));

Das ganze wird dann ein Filter, was 40MACs/cycle braucht, und da wird 
man dann wahrscheinlich auch noch was mauscheln koennen.
Vielleicht geht's mit 3 Teilfiltern noch schoener, aber das ist dann 
halt etwas experimentieren...Also das Gegenteil von Toolbox.

Gruss
WK

von Helmut S. (helmuts)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du den Übergang weniger steil machst (2700Hz,3300Hz), dann 
benötigst du nur die Hälfte der Koeffizienten.
Wenn man statt 48000Hz mit 24000Hz arbeitet, dann halbiert sich auch die 
Zahl der Koeffizienten. Das ginge mit einem Multiratefilteransatz.
https://de.mathworks.com/help/dsp/ug/multirate-filters.html

Beachte auch den Ripple im Durchlassbereich. Da möchte man nicht gerade 
1dB haben. 1dB = 10^(1/20) entspricht 12% ripple im Durchlassbereich. 
Bei Audio ist das vermutlich egal, bei einem Messgerät eher nicht.

: Bearbeitet durch User
von Christoph M. (mchris)


Bewertung
0 lesenswert
nicht lesenswert
Bitte Impulsantwort und Frequenzgang als Bild posten.

von Gustl B. (gustl_b)


Bewertung
1 lesenswert
nicht lesenswert
Guck dir mal pyfda an.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Beachte auch den Ripple im Durchlassbereich. Da möchte man nicht gerade
> 1dB haben. 1dB = 10^(1/20) entspricht 12% ripple im Durchlassbereich.
> Bei Audio ist das vermutlich egal, bei einem Messgerät eher nicht.
Das ist auch beim Audio nicht wirklich egal :-) Es ist nur oft nicht 
anders zu machen. Mikrofon- und Lautsprecherkennlinien müssen 
beispielsweise sehr aufwändig hingebogen werden, um 1dB Abweichung zu 
unterschreiten.

Beitrag #6092067 wurde von einem Moderator gelöscht.
Beitrag #6092166 wurde von einem Moderator gelöscht.
von W.S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb im Beitrag #6092166:
> I believe my pig whistles.

Equal goes it loose. Lübke lebt, jawoll!

Aber sag mal, wie du dir das mit deinen Fltervorschlägen weiter oben 
gedacht hast. Ich schätze, daß bei derartigen Konstruktionen die Phase 
im Durchlaßbereich munter Purzelbäume schlägt. Mag sein, daß sowas für 
Audio egal ist, aber aus meiner Sicht (I/Q-Radio-Empfang) wäre sowas 
tödlich. Da bleibt eben nur der volle Aufwand für ein lückenloses FIR 
Filter. Siehe angehängtes Bild.

W.S.

von svedisk ficklampa (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> daß bei derartigen Konstruktionen die Phase
> im Durchlaßbereich munter Purzelbäume schlägt.
> Mag sein, daß sowas für Audio egal ist

Ein durchgeruehrter Phasengang wird schon bei einigen
hintereinandergeschalteten analogen Sallen-Key-Filtern
unangenehm hoerbar.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Wenn ich nur FIRs mit symmetrischen Koeffizienten in Kette schalte, 
wieso sollte da die Phase irgendwelche Faxen machen?

Gruss
WK

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Wenn ich nur FIRs mit symmetrischen Koeffizienten in Kette schalte,
> wieso sollte da die Phase irgendwelche Faxen machen?

Dergute W. schrieb:
> Also so z.B.:f1=(firls(20,[0 0.1125*4 0.125*4 1],[1 1 0 0]));
> uf1=upsample(f1,4,0);
>
> f2=(firls(20,[0 0.1125 0.5-0.1125 1],[1 1 0 0]));
>
> freqz(conv(uf1,f2));

Also, das was du da an Programm hast, hab ich nicht (wohl Matlab) und 
kenne ich auch nicht inwendig. Ebenso kenne ich keine der tausend dort 
eingebauten Funktionen. Allerdings sieht es mir beim Draufschauen auf 
deine Quellzeilen tatsächlich unsymmetrisch aus - du scheinst ja nur 
positive N, positive Taps und Nullstellen zu haben. Also ein extrem 
unsymmetrisches FIR (falls es eines sein sollte...).

Das ist im übrigen ein Ärgernis: Bis auf einige Leute, die Matlab 
entweder in der Firma haben oder sonstwie dran gekommen sind (...) kann 
keiner mit dem Zeugs was anfangen. Entweder sollte man da besser seine 
Algorithmen mathematisch formulieren oder in Pascal ausdrücken (weil das 
einfach zu lesen ist und deshalb jeder von selbst versteht). Alternativ 
als Struktogramm.

W.S.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ich hab' auch kein Matlab. Aber GNU Octave mit dem "signal" package von 
octaveforge.

Gruss
WK

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sieht aber genauso unverständlich aus.

W.S.

von Bernd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Sieht aber genauso unverständlich aus.
Tja, das Leben ist eben kein Ponyhof.

W.S. schrieb:
> Das ist im übrigen ein Ärgernis: Bis auf einige Leute, die Matlab
> entweder in der Firma haben oder sonstwie dran gekommen sind (...) kann
> keiner mit dem Zeugs was anfangen.
Was Du nicht sagst. Ich würde sagen: Bullsh*t!

> Entweder sollte man da besser seine
> Algorithmen mathematisch formulieren oder in Pascal ausdrücken (weil das
> einfach zu lesen ist und deshalb jeder von selbst versteht). Alternativ
> als Struktogramm.
Pascal ist tot, Mathematik und Struktogramm findest Du in entsprechenden 
Lehrbüchern.

Ich kann Python mit SciPy und Matplotlib für solche Dinge empfehlen:
https://docs.scipy.org/doc/scipy/reference/tutorial/signal.html#filter-design

Für Matlab hat es bei mir nämlich auch nicht gereicht...

von Markus K. (markus-)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> Das ist im übrigen ein Ärgernis: Bis auf einige Leute, die Matlab
> entweder in der Firma haben oder sonstwie dran gekommen sind (...)

Matlab kostet für Privat 120€ + 35€ pro Toolbox. Es ist allerdings nicht 
upgradefähig, d.h. wer dann nächstes Jahr die neue Version will, der 
muss dann alles neu kaufen.

Ich sehe allerdings bei der Arbeit, dass die Kollegen, die frisch von 
der Uni kommen, eher Python machen (ganz allgemein, nicht auf 
Filterdesign bezogen).

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Matlab kostet für Privat 120€ + 35€ pro Toolbox. Es ist allerdings nicht
>upgradefähig, d.h. wer dann nächstes Jahr die neue Version will, der
>muss dann alles neu kaufen.

Deshalb nutze ich schon seit Jahren Gnu-Octave. Das ist zu Matlab 
ziemlich kompatibel und mit der Signal-Processing Toolbox lässt sich 
auch viel Signalverarbeitung machen.

>Ich sehe allerdings bei der Arbeit, dass die Kollegen, die frisch von
>der Uni kommen, eher Python machen (ganz allgemein, nicht auf
>Filterdesign bezogen).

So ist es. Allerdings finde ich die Umsetzung von Matlab ( NumPy, 
Matplotlib ) doch eher noch etwas umständlicher zu benutzen als 
Matlab/Octave selbst.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Hab' derweilen mal geguckt - also, das was ich hier mal urspruenglich 
meinte, heisst voellig programmiersprachenunabhaengig: IFIR oder 
"interpolated FIR".
Wird z.B. im Kap. 7.2 von "Understanding Digital Signal Processing" von 
Rick Lyons beschrieben.

Gruss
WK

von W.S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> IFIR

Hmm.. du meinst so etwa diesen Artikel - oder?

Das sieht zwar alles recht interessant aus, enthält aber mMn zu viele 
interne Entscheidungen, um sowas real in einem µC für einen Empfänger 
implementieren zu können - derart, daß man als Operator an einem Knopf 
drehen und damit zur Laufzeit die zwei Eckfrequenzen des ZF-Bandpasses 
nach Gusto einstellen kann.

Was da bleibt, wären Verwendungen, wo man das alles zuvor zur 
Entwurfszeit oder zumindest im PC zur Laufzeit ausrechnen kann. Immerhin 
sieht das ja so aus, daß die Ersparnis im Wesentlichen darauf beruht, 
daß man gezielt Taps auf Null setzt und folglich die zugehörige MAC 
ausläßt.

Aber das bedeutet im Grunde jedesmal eine Firmware-Modifikation oder 
zusätzlichen Verwaltungsaufwand, der die eingesparten MAC's wohl wieder 
auffrißt. Es ist bei sowas eben nicht mit einer simplen Neuberechnung 
des Filterkernels getan.

Nun ja, für Rick auf seinem recht hohen theoretischen Level sind das 
eher unbedeutende Details.

Ich habe weiter oben nicht ohne Grund "Pascal" geschrieben. Auch wenn 
hier jemand wegen Pascal herum motzen muß, ist es dennoch eine Notation, 
die ein Jeder sofort versteht - im Gegensatz zu den Aufrufen von 
Mathcad/Octave/etc. - und genau das war und ist die Intention.

Ein Ähnliches gilt für die mathematische Notation, wie sie z.B. Rick im 
obigen Artikel benutzt. Wer genau diesen Zweig der Mathematik nicht 
studiert hat, oder dessen Mathe-Studium zu lange her ist, der tut sich 
schwer mit dem schieren verstehenden Lesen. Das sollten die, welche 
grad frisch von der Uni kommen oder gar aktiv im Lehrbetrieb stehen, 
auch mal berücksichtigen.

Nochwas: so rund 90 dB Sperrdämpfung, wie man sie mit einem simpel 
gestrickten FIR im obigen Beispiel erreicht, habe ich bei Rick's 
Ausführungen nicht gesehen. Es ist das Thema wohl doch ein einziger 
Morast aus Kompromissen in allen Richtungen, durch den man waten muß, um 
zu seinem eigenen Ziel zu kommen.

W.S.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,
Ja - hm. Was soll ich da jetzt sagen...
Urspruenglich hat hier einer einen Tiefpass mit fixen Werten vorgegeben, 
berechnet und sich dann ueber den hohen Aufwand gewundert. Dann hab' ich 
was dazu geschrieben, wie man evtl. diesen Aufwand verringern koennte.

Jetzt kommst du an, quengelst 'rum, weils dir zu kompliziert ist und 
nicht in Pascal und ueberhaupt und Sperrdaempfung und bla. Und 
eigentlich willst du scheint's was voellig anderes als der TO - naemlich 
keinen Tiefpass mit festen Eckfrequenzen, sondern einen frei 
durchstimmbaren Bandpass.

Wenn du dich wenigstens auf eine fixe Bandbreite festlegen kannst, dann 
geht so ein durchstimmbarer Bandpass z.B. mit einem komplexen Mischer, 
danach in I und Q Zweig jeweils eines von den IFIRs oder sonst 
irgendeine Geschmacksrichtung schmalbandiger (=deine gewuenschte 
Bandbreite/2) Tiefpaesse und danach - wenn du's wieder in der 
Originallage haben willst, halt wieder per komplexem Mischer 
hochgemischt. Wenn du da unbedingt >90 dB Sperrdaempfung haben willst, 
musste auch mal gucken, mit wieviel Bit Genauigkeit die ganze 
Verarbeitung stattfinden muss. 16 koennt' da knapp werden.

Ist aber halt so, dass die Rechnerei hinter dem Ganzen nicht so 
supersimpel ist, wie du's gerne haettest. Hat schon einen Grund, warum 
man Filterentwurf, Abtastung, etc. nicht im Kindergarten als Abzaehlreim 
lernt. Auch wenn du mit'm Fuss aufstampfst und "WILL ABER!" bruellst. 
;-)

Gruss
WK

von W.S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Auch wenn du mit'm Fuss aufstampfst

Ach nee. Laß mal diese Seite. Ich sehe aber durchaus, daß es da ne 
gewaltige Lücke gibt - zwischen Leuten wie Lyon auf der einen Seite und 
Leuten wie Funkamateuren und dem TO, der "sich grad mal" mit dem 
Filterdesigner von Matlab oder so "versuchen" will. Theoretiker auf der 
einen, Bauklötzchen auf der anderen Seite.

Mir wäre durchaus daran gelegen, wenn Leute die von beiden Seiten 
genug verstehen, was schreiben und damit diese Lücke überbrücken. Fühlst 
du dich dazu in der Lage?

Eigentlich täte es not, diese Dinge mal aus ihrem Elfenbeinturm 
herauszuholen - gestandene HF-Praktiker winken nämlich ab und sagen, 
'bin zu alt dafür, werde mich damit einfach nicht mehr befassen' und 
junge Leute üben sich im Dünnbrettbohren bzw. fertigen Bauklötzchen. Das 
ist alles nicht wirklich gut für uns alle - auch wenn es mich persönlich 
nicht wirklich betrifft.

Ich hab die Sache selbst mal ein wenig von der Querseite her aufgerollt, 
aber das Thema dümpelt seit Jahren dahin. Aber da du fragtest, häng ich 
dir mal das Ganze was oben in double gerechnet war in diversen 
Integer-Ausführungen dran. Ist nicht uninteressant, wenngleich auch zu 
erwarten gewesen.

W.S.

von Analoger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
1) Ich sehe diese Diskrepanz zwischen den Theoretikern und Praktikern 
nicht. Sie ist auch nicht jung und alt zuzuordnen. Ferner ist modernes 
Bauen nicht unbedingt Bauklötzen und klassisches Bauen nicht immer 
solide oder "analog", wie man heute fälschlich gerne sagt.

2) Ich würde gerne mal wissen, wie die Baukasteneffekte in deinem 
Filterprogramm aussehen:

a) Welcher Kaiser ist das? / Welcher Blackmann? - Bei beiden gibt es 
etliche Versionen

b) Warum nimmst du ausgerechnet 201 TAPs? Das ist super grob im 
Vergleich zu dem, was die Fenster an Unterschied ausmachen können

c) Warum kommt hier Pedersen zum Einsatz? Hoffentlich nicht als 
Testsignal für den Filter????

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Analoger schrieb:
> Ich würde gerne mal wissen, wie die Baukasteneffekte in deinem
> Filterprogramm aussehen

Das Programm kann sowohl aus sich heraus Filter generieren als auch 
fertige Filterkernel laden und deren Response anzeigen. Für den 
klassischen Kaiser erscheint mir ein Beta von 9.5 am geeignetsten. Und 
der Blackman ist ebenfalls der klassische Blackman.

Das alles spielt hier aber keine Rolle, sondern hier sieht man lediglich 
den Einfluß der verschieden stark begrenzten Rechengenauigkeit bei 
ansonsten gleichbleibenden Randbedingungen.

Die 201 Taps sind mMn ein guter Kompromiß zwischen der Beurteilbarkeit 
der prinzipiellen Filtercharakteristika und der Machbarkeit in einem µC. 
Ich halte das überhaupt nicht für "supergrob". Rechne doch mal nach: bei 
"nur" 96 ksps I+Q hat man grob, ohne Waitstates bei 100 MHz Takt nur 
etwa 1000 Takte pro Sample. Da muß man zweimal je 201 Taps rechnen, 
anschließend noch demodulieren (AM+FM per Cordic) und ein Rest muß auch 
noch für alles Übrige bleiben. Mit Waitstates sieht das übler aus, 
gleiches gilt für höhere CPU-Takte wenn dort mehr Waitstates 
erforderlich sind, je nach AHB und/oder TCM-Verwendbarkeit - falls solch 
eng an die CPU gekoppelter RAM verfügbar ist UND sowohl für Daten als 
auch Code gleichzeitig benutzbar sein sollte.

Und der Pedersen dient dem gleichen generellen Zweck: Machbarkeit im µC 
unter den dortigen Restriktionen austesten. Damit wurde in allen 4 
Integer-Fällen der Filterkernel gemacht - ist ja sin(x)/x. Ich finde, 
dabei macht sich der Pedersen erstaunlich gut im Vergleich zum komplett 
in double gemachten und gerechneten Filter weiter oben.

Bedenke mal, daß man bei einem Cortex-M4F entweder mit 24 bittiger 
Mantisse in single oder mit 2 Taps pro Operation und nur 16 Bit integer 
rechnen kann. Da muß man schon abwägen, was einem welche Randbedingung 
wert ist.

Kurzum, nette Algorithmen sind das eine - die tatsächliche Realisierung 
ist etwas anderes. Und beide haben so ihre Probleme.

Ich hacke nicht ohne Grund auf der Lücke zwischen hochtrabenden Papers 
und den Niederungen der technischen Realisierung herum. Von mir aus in C 
wenn das etwa so hinkommen sollte wie Assembler - aber hier zum 
Darstellen der Algorithmen besser in pascalartige Notation, da das zum 
Verständnis dienen soll und nicht unbedingt zum tatsächlichen 
Realisieren.

W.S.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Analoger schrieb:
> Ich sehe diese Diskrepanz zwischen den Theoretikern und Praktikern
> nicht.

Daß du das nicht siehst, dafür für kann ich nicht.

> Sie ist auch nicht jung und alt zuzuordnen.

Oh doch. Die Alten haben erhebliches Wissen und Können in analoger 
Technik und die Jungen haben das nicht. Industrieller Fakt ist dabei, 
daß die rein analoge Verarbeitung nicht mehr Stand der Technik ist, 
sondern eben deren digitale Ersetzung.

Immerhin hat Hogenauer seinen CIC bereits 1981 entwickelt - zu einer 
Zeit, wo das Gros der Ingenieure gerade eben Bekanntschaft mit dem PC in 
Form des Z80 mit CP/M gemacht hatte. Da waren und sind Welten dazwischen 
- zwischen den Leuten, die mit schier unbegrenzten Mitteln für NSA und 
Konsorten Digitaltechnik entwickeln konnten/können und dem Rest der 
Ingenieurs-Welt. Eben die besagte Lücke.

Und was meinst du, wieviele Ingenieure, die am PC einen DVB-USB-Stick 
einstecken und dann ein SDR-Programm benutzen, tatsächlich über digitale 
Signalverarbeitung so gut Bescheid wissen, daß sie sowas prinzipiell 
selbst schreiben könnten?

Nein, das Wissen und Können in digitaler Signalverarbeitung ist derzeit 
noch längst nicht Allgemeingut in den Kreisen der 
Ingenieure/Informatiker/Programmierer geworden.

W.S.

von Bernd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Nein, das Wissen und Können in digitaler Signalverarbeitung ist derzeit
> noch längst nicht Allgemeingut in den Kreisen der
> Ingenieure/Informatiker/Programmierer geworden.
Und das wird es auch nicht werden.
Tatsache ist doch, wenn es etwas Fertiges gibt, was mein Problem löst 
und in die restlichen Randbedingungen passt, gibt es nur noch wenige 
Gründe etwas selbst zu entwickeln.

Daher werden Displays oder Sensoren eingesetzt, die mit fertigen 
Arduino-Bibliotheken kommen. Oder ein Raspi oder ein Zynq, wo nicht mehr 
der Netzwerkstack entwickelt werden muß, sondern die eigene Applikation 
direkt auf Linux aufsetzen kann. Oder diverse Frameworks auf 
PC-Systemen. Die Beispiele sind zahlreich.

Es gibt keinen unmittelbaren Zwang sich tief mit jeder Materie 
auseinandersetzen zu müssen. Ja, das führt natürlich zu nicht optimalen 
Lösungen im Hinblick auf Hardwareressourcen. Das spielt aber beim Hobby 
keine Rolle und in Firmen nur dann, wenn es die Konkurrenz in Summe 
besser hinbekommt.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd schrieb:
> Tatsache ist doch, wenn es etwas Fertiges gibt...

.. dann braucht man sich nicht darum zu bemühen, in seiner Sparte 
führend zu werden, zu sein, zu bleiben, innovativ zu sein, Vorsprung vor 
anderen zu haben, sich eben nicht auf den Lorbeeren vergangener 
Jahrzehnte auszuruhen.

Weißt du eigentlich, womit wir hier in Europa unseren derzeitigen 
Wohlstand in Zukunft aufrecht erhalten wollen?

Ich halte diese Denkweise für die einer im Untergang befindlichen 
Gesellschaft.

W.S.

von Mathematiker vom Dienst (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Immerhin hat Hogenauer seinen CIC bereits 1981 entwickelt

Das war jetzt aber auch eine Leistung einen Mittelwertfilter zu 
kaskadieren. Wow!

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mathematiker vom Dienst schrieb:
> Das war jetzt aber auch eine Leistung...

Sei nicht albern. Das zeigt uns, daß es in den betreffenden Kreisen 
bereits damals die zugehörige Hardware gab, von der unsereiner damals 
noch nicht mal hätte träumen können. Also lies das verstehend und 
nicht bloß, um dich drüber zu mockieren.

W.S.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.