Hallo Gemeinde ich möchte einen einfachen Spektrumanalyzer realisieren. Dazu soll mit einem ADC das Eingangssignal abgetastet und einer FFT unterworfen werden. Mich interessieren nur Frequenzen bis ca. 1 MHz, also könnte man doch mit 2 MSamples/s abtasten. Wenn man das ganze noch mit einem DDS-Chip koppeln würde, dann könnte man evtl. sogar noch eine Art Mitlaufgenerator bauen. Zuerst wollte ich das mit einem STM32 realisieren, aber da ich gerne ein grosses Display mit GUI möchte, scheint mir das doch keine so gute Idee. Für solche Sachen wäre ein Raspberry Pi ja eigentlich ganz toll! Ich frage mich, was für Möglichkeiten es gibt, einen schnellen ADC an den Pi anzubinden. Was denkt ihr? Schlussendlich möchte ich gern die Start- und Stop-Frequenz, sowie die Anzahl der Punkte usw. über das GUI eingeben. Das sollte zu schaffen sein. Sorge bereitet mir aber wie gesagt die Datenerfassung. Was gibts da für Möglichkeiten?
Beitrag #5305427 wurde von einem Moderator gelöscht.
Harald schrieb: > Was denkt ihr? Dass Google bei dir kaputt ist. Einen ADC mit SPI an einen Raspberry PI anzuschließen ist z.B. hier beschrieben: http://www.hertaville.com/interfacing-an-spi-adc-mcp3008-chip-to-the-raspberry-pi-using-c.html Der MCP3008 hat zwar nur 200 ksps, wenn ich mich recht entsinne, aber einen ADC mit mindestens 2 MegSps stattdessen einzusetzen sollte ja nicht die Schwierigkeit darstellen. Wenn du also schon einen Pi hast oder Erfahrungen damit würde ich an deiner Stelle genau diesen Weg gehen.
M. K. schrieb: > Der MCP3008 hat zwar nur 200 ksps, wenn ich mich recht entsinne, aber > einen ADC mit mindestens 2 MegSps stattdessen einzusetzen sollte ja > nicht die Schwierigkeit darstellen. Auf einem Rpi oder ähnlichen Frickel-Embedded-Linuxen SPI-ADCs abrissfrei und in Echtzeit auszulesen erfordert rechte Klimmzüge und tieferes Wissen betr. Kerneltreiber und DMA. Das klassische SPI Subsystem von Linux ist nicht wirklich für sowas geeignet.
Martin S. schrieb: > Auf einem Rpi oder ähnlichen Frickel-Embedded-Linuxen SPI-ADCs > abrissfrei und in Echtzeit auszulesen erfordert rechte Klimmzüge und > tieferes Wissen betr. Kerneltreiber und DMA. Das klassische SPI > Subsystem von Linux ist nicht wirklich für sowas geeignet. Naja, der TE will 1 MHz-Signal abtasten und darauf eine FFT loslassen, das ist auch nix für "mal eben zwischendruch", ich geh da schon mal von aus, dass sich der TE da tiefer ins Gebiet einarbeiten wird oder besser: einarbeiten werden muss. Mit 2 MSPS ist er da auch nur akademisch dabei, ich würd ja eher auf 10 oder mehr MSPS ADCs setzen.
M. K. schrieb: > ich geh da schon mal von > aus, dass sich der TE da tiefer ins Gebiet einarbeiten wird oder besser: > einarbeiten werden muss strubi hat es genau richtig beschrieben: der RaspPi ist einfach eine schlechte Basis, um in einem festen Zeitraster im µs-Bereich ADCs auszulesen. Auch dann wenn man bereit ist, "sich tiefer einzuarbeiten". Um die FFT zu rechnen ist er prima, aber die zeitgenaue Abtastung und ADC-Ansteuerung erledigt man besser mit anderer Hardware. Selbst in dem von dir oben verlinkten Projekt (http://www.hertaville.com/interfacing-an-spi-adc-mcp3008-chip-to-the-raspberry-pi-using-c.html) schreibt der Autor: "This solution is meant for applications where real-time constraints such as sampling speed requirements are very modest or even non-existent."
Einen Vorschlag hatte strubi ja schon vor deinem Beitrag gemacht. Wobei ich mal vermute, dass in dem Teil 8-Bit ADCs stecken, was für die Amplitudendynamik nicht berauschend ist. Auch die erste Idee von Harald, einen "nackten" µC (ohne ein nicht realtime Betriebssystem) zu nuten, würde für die ADC-Ansteuerung gut passen. Für seine GUI und Grafik-Display-Wünsche wäre das aber natürlich unkomfortabel. Er könnte aber weiterhin die Datenerfassung und Pufferung auf einem nackten µC fahren, die FFT-Berechnung und grafische Darstellung auf einem damit verbunden RaspPi. Ebenso möglich sind diverses Datenerfassungsmodule mit eigener Taktung für die Abtastung, die über ein Interface mit ausreichend Bandbreite an den RaspPi angebunden sind.
Wäre es zu abwegig, einen DVB-T-Stick dafür zu missbrauchen? Und mit GNU-Radio auch noch einen prall gefüllten Koffer an Signalverarbeitung.
Marek N. schrieb: > Wäre es zu abwegig, einen DVB-T-Stick dafür zu missbrauchen? Der TO will von DC bis 1MHz messen. Können das die DVB-T-Sticks? Oder wäre der Vorschlag, das Signal "hinter einer Mischerstufe" einzuspeisen?
Kann der rPI eigentlich mittlerweile hardwarebeschleunigtes X? Oder muss der ARM dort immer noch nachhelfen? Also Dinge wie: - BitBLT - Solid Line Drawing und - Rectangular Solid Color Fill
Die Brüder B. haben auf dem Discovery F429 ein kleines Oszilloskop gemacht, das auch eine FFT drin hat. Das kann man sich als Vorlage ja mal anschauen: http://mikrocontroller.bplaced.net/wordpress/?page_id=752
Aaronia verwendet TMS320F28er. Da gibt es auch Exemplare mit schnellen ADCs. Damit macht man bestimmt nichts falsch.
Du kriegst realistisch keinen > 2 MSa/s an das Pi, der unterbrechungs- und verlustfrei sampelt (was du für hochauflösende FFT brauchst). Das musst du anders machen.
Andere Möglichkeit: Beaglebone Black Echtzeit-Applikation auf einer der PRUs laufen lassen, den Rest wie GUI unter Linux. -branadic-
Ich würde das mit einem µC lösen. Ein PIC32 oder ARM mit externem ADC mit 10MSPS (parallel, wahrscheinlich - SPI eher nicht). Die Samples sammelt man im RAM (idealerweise mit DMA), zieht das gewünschte Fenster drüber und rechnet die FFT. Integer-Arithmetik vorausgesetzt sollte man damit recht ordentliche Ergebnisse bekommen. Anzeigen kann man das entweder auf einem Grafikdisplay oder man gibt das einem PC weiter. Mit 8 oder 16Bit- µC brauchst du aber nicht anzurücken. Einen halbwegs potenten 32-Bitter mit ordentlich RAM ist schon sinnvoll, viel kostet das eh nicht. Ähnliche Geschichten habe ich mal mit einem PIC32MX370 gemacht, das ging sehr gut. Wenn du einen ARM haben willst, kannst du einen STM32F4 verwenden, hier ginge das Discovery-Board, wenn du dir die Hardwarebastelei schenken willst.
Hm, du hast mit dem 120 MHz uC 10 MByte/s fouriertransformiert? Echt, das geht? Wenn du es ausprobiert hast bin ich erstaunt, wenn nicht behaupte ich das haut niemals hin. Die CPU ist viel zu lahm.
Sven B. schrieb: > Hm, du hast mit dem 120 MHz uC 10 MByte/s fouriertransformiert? > Echt, > das geht? Wenn du es ausprobiert hast bin ich erstaunt, wenn nicht > behaupte ich das haut niemals hin. Die CPU ist viel zu lahm. Die CPU ist völlig nebensächlich. Die FFT muss ja nicht für jedes Messwertpaket ausgeführt werden.
Harald schrieb: > Mich interessieren nur Frequenzen bis ca. 1 MHz, also könnte man > doch mit 2 MSamples/s abtasten. Wenn du dann noch ein Tiefpassfilter davor schaltest, was Frequenzen ab 1MHz rechteckförmig abschneidet, könnte das klappen. Sonst bekommst du Energie aus höheren Frequenzen in deinen Nutzbereich reingespiegelt.
Warum das Rad neu erfinden. Fast jedes vernünftige Oszi kann das. z.B. hier: https://www.picotech.com/oscilloscope/5000/flexible-resolution-oscilloscope https://www.picotech.com/library/picoapp/frequency-response-analyzer-with-bode-plots Gruß Anja
avr schrieb: > Sven B. schrieb: >> Hm, du hast mit dem 120 MHz uC 10 MByte/s fouriertransformiert? >> Echt, >> das geht? Wenn du es ausprobiert hast bin ich erstaunt, wenn nicht >> behaupte ich das haut niemals hin. Die CPU ist viel zu lahm. > > Die CPU ist völlig nebensächlich. Die FFT muss ja nicht für jedes > Messwertpaket ausgeführt werden. Hm naja, wenn es dir egal ist dass dein SNR viel viel schlechter ist als es sein könnte, kannst du das natürlich machen ...
Sven B. schrieb: > Hm naja, wenn es dir egal ist dass dein SNR viel viel schlechter ist als > es sein könnte, kannst du das natürlich machen ... Was hat das mit dem SNR der FFT zu tun? Wenn ich N Messwerte transformiere, dann hab ich eben das Frequenzspektrum dieser Reihe. SNR hängt dabei hauptsächlich von der Genauigkeit des ADCs ab. Glaubst du allen Ernstes ein Oszilloskop mit 1 GSps macht für jede Messwertreihe eine FFT?
Sven B. schrieb: > Hm, du hast mit dem 120 MHz uC 10 MByte/s fouriertransformiert? Echt, > das geht? Wenn du es ausprobiert hast bin ich erstaunt, wenn nicht > behaupte ich das haut niemals hin. Die CPU ist viel zu lahm. Nein, das geht natürlich nicht, und das habe ich auch nicht behauptet. Aber man muss ja nicht alle Samples erwischen, sondern nur z.B. einen Bereich von 10ms oder so, je nachdem welches Spektrum man sehen will. Wenn du eine FFT mit einem DSO machst, egal wie teuer das ist, erwischt du auch nur ein bestimmtes Zeitfenster. Kein Oszilloskop ist schnell genug, um ALLE hereinkommenden Samples zu verarbeiten und anzuzeigen. Das nimmt auch nur X (ist recht groß...) Samples über einen Zeitraum Y, legt ein Fenster drüber und wirft das Spektrum aus. Was sowieso klar sein muss: Ein 32-Bit-µC ist kein Ersatz für ein DSO oder einen echten Spektrumanalyzer. In Punkto Rechenleistung und Speichertiefe spielt schon das billigste Rigol in einer ganz anderen Größenordnung. Aber - so war mein Verständniss der Intention des Projektes - es ging hier um eine Bastelei zwecks Interesse and dem Thema.
Harald schrieb: > Schlussendlich möchte ich gern die Start- und Stop-Frequenz, sowie die > Anzahl der Punkte usw. über das GUI eingeben. Ach ja! Der normale Weg geht anders: Da wird ein Ausschnitt aus dem Frequenzspektrum rein analog auf Null transponiert (per Superhet, also I/Q-Mischer) und dieser Bereich dann per FFT fein auseinander genommen. Als ADC nimmt man dann lieber einen 24 Bit Audio-ADC. Tja und die Analogtechnik davor ist dann deine Sache. W.S.
avr schrieb: > Sven B. schrieb: >> Hm naja, wenn es dir egal ist dass dein SNR viel viel schlechter ist als >> es sein könnte, kannst du das natürlich machen ... > > Was hat das mit dem SNR der FFT zu tun? Wenn ich N Messwerte > transformiere, dann hab ich eben das Frequenzspektrum dieser Reihe. SNR > hängt dabei hauptsächlich von der Genauigkeit des ADCs ab. > > Glaubst du allen Ernstes ein Oszilloskop mit 1 GSps macht für jede > Messwertreihe eine FFT? Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben willst :D Es verwirft halt fast alle Werte. Klar, geht, und du siehst irgendwas, aber halt mit viel schlechterem SNR als wenn du tatsächlich alle Werte nehmen würdest und immer über 200ms die Beträge der FFTs mitteln.
Sven B. schrieb: > Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben > willst :D Es verwirft halt fast alle Werte. Klar, geht, und du siehst > irgendwas, aber halt mit viel schlechterem SNR als wenn du tatsächlich > alle Werte nehmen würdest und immer über 200ms die Beträge der FFTs > mitteln. 1. gilt das nur für periodische Signale 2. Mitteln kann man auch im Zeitbereich 3. die FFT hat immer noch nichts mit dem SNR zu tun
Wolfgang schrieb: > Wenn du dann noch ein Tiefpassfilter davor schaltest, was Frequenzen ab > 1MHz rechteckförmig abschneidet, könnte das klappen. Sonst bekommst du > Energie aus höheren Frequenzen in deinen Nutzbereich reingespiegelt. Bei ner FFT muss man eh immer Filtern, du kannst sonst nicht sagen ob der Peak im Spektrum bei fa/2 wirklich zur Frequenz fa/2 oder 3*fa/2 gehört.
avr schrieb: > Sven B. schrieb: >> Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben >> willst :D Es verwirft halt fast alle Werte. Klar, geht, und du siehst >> irgendwas, aber halt mit viel schlechterem SNR als wenn du tatsächlich >> alle Werte nehmen würdest und immer über 200ms die Beträge der FFTs >> mitteln. > > 1. gilt das nur für periodische Signale Nö. Wieso sollte das so sein. Das macht in der wissenschaftlichen Datenverarbeitung jeder immer so. > 2. Mitteln kann man auch im Zeitbereich Nein, kann man nicht. Im Zeitbereich ist die Phase mit drin und dann mittelt sich alles raus. Du musst erst die FFT rechnen und dann den Betrag und dann kannst du mitteln. Außer du hast ein periodisches Signal phasenrichtig gesampelt, aber das kommt quasi nie vor (weil es sehr viel Wissen über das zu analysierende Signal voraussetzt). > 3. die FFT hat immer noch nichts mit dem SNR zu tun Hä, wovon redest du. Das Ergebnis der FFT, nämlich das Spektrum, hat selbst ein SNR, das Verhältnis von Signal was ich darin sehe zu Rauschuntergrund der mich stört. Das interessiert mich wenn ich das Spektrum ankucke. Das wird besser wenn ich mehrere FFTs mittle.
Sven B. schrieb: >> 1. gilt das nur für periodische Signale > > Nö. Wieso sollte das so sein. Das macht in der wissenschaftlichen > Datenverarbeitung jeder immer so. Und das soll immer so gut funktionieren? Da wäre ich mir in Bezug auf den Leckeffekt nicht sicher. >> 2. Mitteln kann man auch im Zeitbereich > > Nein, kann man nicht. Im Zeitbereich ist die Phase mit drin und dann > mittelt sich alles raus. Du musst erst die FFT rechnen und dann den > Betrag und dann kannst du mitteln. Außer du hast ein periodisches > Signal phasenrichtig gesampelt, aber das kommt quasi nie vor (weil es > sehr viel Wissen über das zu analysierende Signal voraussetzt). Naja, das lässt sich je nach Komplexität könnte man das schon machen. >> 3. die FFT hat immer noch nichts mit dem SNR zu tun > > Hä, wovon redest du. Das Ergebnis der FFT, nämlich das Spektrum, hat > selbst ein SNR, das Verhältnis von Signal was ich darin sehe zu > Rauschuntergrund der mich stört. Das interessiert mich wenn ich das > Spektrum ankucke. Das wird besser wenn ich mehrere FFTs mittle. Das SNR kommt aber von dem Signal. Natürlich kann man sowohl im Zeitbereich als auch im Frequenzbereich durch Mittelung dieses Verbessern. Mit einer FFT hat das aber nichts zu tun.
avr schrieb: > Sven B. schrieb: >>> 1. gilt das nur für periodische Signale >> >> Nö. Wieso sollte das so sein. Das macht in der wissenschaftlichen >> Datenverarbeitung jeder immer so. > > Und das soll immer so gut funktionieren? Da wäre ich mir in Bezug auf > den Leckeffekt nicht sicher. Ich sehe da keinen Zusammenhang. Der Leckeffekt kommt von der Mehrdeutigkeit bei nicht-periodischen Signalen (und quasi alle Signale sind nicht-periodisch außer du hast wirklich irgendwie die Samplerate phaselocked auf das Signal), der addiert sich einfach genauso auf wie jeder andere Signalanteil. > Naja, das lässt sich je nach Komplexität könnte man das schon machen. Nein, weil du einfach die Informationen über das Signal nicht hast. Überhaupt sind Signale halt auch nicht periodisch. Gibt's effektiv einfach außerhalb synthetischer, konstruierter Fälle nicht. > Das SNR kommt aber von dem Signal. Natürlich kann man sowohl im > Zeitbereich als auch im Frequenzbereich durch Mittelung dieses > Verbessern. Mit einer FFT hat das aber nichts zu tun. Aber im Zeitbereich kannst du nicht mitteln, weil dein Signal nicht periodisch ist. Du musst immer einen Ausschnitt darstellen. Wenn du das Spektrum sehen willst, kannst du in ganz vielen Fällen mitteln, und das ist genau das was das Oszi nicht macht, und genau deshalb ist es nicht ideal für diese Anwendung.
Sven B. schrieb: > Das wird besser wenn ich mehrere FFTs mittle. Ach so, du meinst in Grund gar nicht den unmittelbaren SNR des Spektrums sondern die Frage "wie schnell kann ich mitteln, um den SNR etwas zu verbessern". Ok, dem kann ich zustimmen. Mit geringer Rechenleistung brauche ich länger, um gleich oft FFTs zu berechnen und zu mitteln, als wenn ich hohe Rechenleistung habe. Für stationäre Eingangssignale ergibt dies im Kern aber keinen Unterschied im erreichbaren SNR, sondern nur in der Zeit die ich brauche, um durch Mitteln auf diesen SNR zu kommen. Mit 10% der Rechenleistung muss ich halt 10 mal so lange messen (bzw. rechnen). Dass bei instationären Messsignalen dann tatsächlich ein Unterschied im erreichbaren SNR entsteht (weil nur eine begrenzte Zeit zum Mitteln zur Verfügung steht): ja, das stimmt. Sven B. schrieb: > Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben > willst :D Es verwirft halt fast alle Werte. Auch das trifft imho wieder nicht den Kern der Sache. Es gibt durchaus auch Oszi mit sehr hoher Rechenleistung (also vielen potentiellen FFT-Berechnungen pro Zeit), die trotzdem miserable Spektren liefern. Die Grundproblematik bei FFT aus Oszis ist, dass dafür meist 8Bit ADCs verwendet werden. Deren Quantisierungsrauschen begrenzt tatsächlich unmittelbar das SNR des digitalisierten Signals und dominert im Normalfall den noisefloor des Spektrums. Ausnahmen (wie die oben von Anja empfohlenen picoscopes) bestätigen die Regel ;-) Die sind in meinen Augen auch eher ein Mischding zwischen Oszi und hochauflösender Datenerfassungskarte. Im hochauflösenden Modus (der schöne Spektren liefert) geht ihre Abtastrate auf Werte runter, die man von "echten Oszis" nicht gewohnt ist. Inzwischen haben zwar diverse Hersteller auch Oszis mit etwas höherauflösenden ADCs im Programm. Aber für die lineare Darstellung der Spannung im Zeitbereich (dem Hauptjob des Oszis) ist alles, was über 9-10 Bit hinausgeht, erst mal verschenkter Aufwand (und bei den benötigten Abtastraten auch richtig teuer). Dedizierte FFT-Spektrumanalyzer arbeiten praktisch immer mit höherer ADC-Auflösung und haben damit einen direkten Vorteil beim SNR - auch ganz ohne Mittelung.
Achim S. schrieb: > Für stationäre Eingangssignale ergibt dies im Kern aber keinen > Unterschied im erreichbaren SNR, sondern nur in der Zeit die ich > brauche, um durch Mitteln auf diesen SNR zu kommen. Mit 10% der > Rechenleistung muss ich halt 10 mal so lange messen (bzw. rechnen). Ok, ja, in Fällen wo dir das egal ist, ist das richtig. Ich finde es meist nicht egal, aber ist natürlich ein valider Anwendungsfall. > Sven B. schrieb: >> Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben >> willst :D Es verwirft halt fast alle Werte. > > Auch das trifft imho wieder nicht den Kern der Sache. Es gibt durchaus > auch Oszi mit sehr hoher Rechenleistung (also vielen potentiellen > FFT-Berechnungen pro Zeit), die trotzdem miserable Spektren liefern. > > Die Grundproblematik bei FFT aus Oszis ist, dass dafür meist 8Bit ADCs > verwendet werden. Deren Quantisierungsrauschen begrenzt tatsächlich > unmittelbar das SNR des digitalisierten Signals und dominert im > Normalfall den noisefloor des Spektrums. Hmm. Ich hab eine Weile nachgedacht aber nein, das ist m.E. nicht ganz der Punkt. Was die 8 bit im Spektrum tun ist, sie limitieren den Signal-zu-Rauschabstand für ein einzelnes aus einer FFT berechnetes Spektrum auf 46 dB. Angenommen es gibt einen Peak auf weißem Rauschen, wird der Peak also höchstens 46 dB über dem Rauschuntergrund sein. Die Sache ist aber komplizierter. Wenn ich nämlich ein stationäres Signal habe, kann ich mehrere FFTs mitteln. Der Signal-zu-Rauschabstand im Sinne von "Energiedichte im Signalpeak durch Energiedichte im Rauschuntergrund" wird dadurch nicht besser. Allerdings wird die Varianz des Rauschuntergrunds kleiner. Das ermöglicht mir, den Rauschuntergrund von dem Spektrum zu subtrahieren und dann ist mein SNR tatsächlich besser. Mehr als 8 bit helfen mir deshalb nur, wenn ich schon in einer einzelnen FFT Peaks habe, die mehr als 46 dB über dem Untergrund liegen. Das sind schon recht spezielle Signale, und vor allem sollten 46 dB für die Extraktion der meisten relevanten Informationen eigentlich ausreichend sein. Die 8 bit Tiefe sind also für die allermeisten Anwendungen völlig ausreichend und mehr lohnt sich nur für den speziellen Fall von Signalen mit sehr starken, schmalen Peaks. Deshalb machen das wohl auch die professionellen Messgeräte so, weil könnte ja sein dass man so ein Signal dransteckt. Das meiste was man so an FFTs macht würde aber mit 3 bit genauso gut gehen. Oder mal von einer anderen Richtung gedacht: wenn dein Signal nicht die Qualität hat, dass man mehr als eine 256-QAM damit machen kann, brauchst du auch nicht mehr als 8 bit FFT zum analysieren. Meines Erachtens ist der Punkt eher, dass einzelne FFTs, wie auf dem Oszi, prinzipbedingt immer verrauscht aussehen. Wenn man ein "ruhigeres" Spektrum haben will, muss man entweder mehrere nebeneinander liegende Kanäle mitteln, oder mehrere FFTs rechnen und die mitteln (was ziemlich genau auf dasselbe herauskommt). Als Beispiel verweise ich frech mal auf meine alte Bachelorarbeit [1] Seite 37; die in blau gemalten Spektren dort sind aus dem Signal eines 2-Bit-ADCs berechnet (der hat also nur 4 mögliche Werte). _________ [1] http://files.svenbrauch.de/arbeit.pdf
:
Bearbeitet durch User
Angehängte Dateien:
-
8Bit_ADC.png
4,9 KB -
16Bit_ADC.png
4,5 KB
Sven B. schrieb: > Allerdings wird die Varianz > des Rauschuntergrunds kleiner. Das mag sein, aber SNR ist halt als Verhältnis von Signal zu Gesamtrauschen definiert (nicht als "wie gleichmäßig ist der Noisefloor und wie gut kann ich ihn subtrahieren"). Sven B. schrieb: > Mehr als 8 bit helfen mir deshalb nur, wenn ich schon in einer > einzelnen FFT Peaks habe, die mehr als 46 dB über dem Untergrund liegen. Würde ich nicht so sehen. Daher mal im Anhang eine LabVIEW-Simulation von FFT-Spektren mit unterschiedliche aufgelöstem Messsignal. Das Signal ist in beiden Fällen ein "schiefer full scale Sinus" (schief, damit man ein paar Harmonische unterschiedlicher Höhe erhält. Darunter auch welche, die nicht 46dB über dem noisefloor liegen). Die Auflösung der Signalwerte wurde vor der FFT-Berechnung künstlich auf 16Bit bzw. 8 Bit runtergerechnet. Abtastung ist mit 20kS/s und 2^14 Messwerten, Frequenz des Signals ist 102Hz.
Achim S. schrieb: > Sven B. schrieb: >> Allerdings wird die Varianz >> des Rauschuntergrunds kleiner. > > Das mag sein, aber SNR ist halt als Verhältnis von Signal zu > Gesamtrauschen definiert (nicht als "wie gleichmäßig ist der Noisefloor > und wie gut kann ich ihn subtrahieren"). SNR ist ein total undefinierter Begriff, und man muss das immer so festlegen, dass es das ausdrückt was gerade wichtig ist. Wenn ich Peaks in einem Spektrum mit einer bestimmten Sicherheit identifizieren will, ist ist "Peakhöhe gegen Varianz des Noisefloors" eine sehr sinnvolle Definition, "Peakhöhe gegen Höhe des Noisefloors" hingegen überhaupt nicht. Letzteres nimmt z.B. auch ab, wenn man bei einem Spectrum Analyzer die Resolution Bandwidth erhöht, obwohl das relevante SNR (sprich, wie sichere Aussagen kann ich über Eigenschaften des Signals treffen) für spektral breite Signale dadurch zunimmt. > Sven B. schrieb: >> Mehr als 8 bit helfen mir deshalb nur, wenn ich schon in einer >> einzelnen FFT Peaks habe, die mehr als 46 dB über dem Untergrund liegen. > > Würde ich nicht so sehen. Daher mal im Anhang eine LabVIEW-Simulation > von FFT-Spektren mit unterschiedliche aufgelöstem Messsignal. Das Signal > ist in beiden Fällen ein "schiefer full scale Sinus" (schief, damit man > ein paar Harmonische unterschiedlicher Höhe erhält. Darunter auch > welche, die nicht 46dB über dem noisefloor liegen). > > Die Auflösung der Signalwerte wurde vor der FFT-Berechnung künstlich auf > 16Bit bzw. 8 Bit runtergerechnet. Abtastung ist mit 20kS/s und 2^14 > Messwerten, Frequenz des Signals ist 102Hz. Und hier liegt der Grund für das Ergebnis: du hast es so gepegelt, dass der größte Peak noch im Dynamikumfang drin ist, dann sind natürlich alle, die mehr als 46 dB kleiner sind als der größte für eine Einzel-FFT im Noisefloor verschwunden (wenn du mittelst, tauchen sie allerdings wieder auf!). Du hast deshalb den Fall, den ich genannt habe, gebaut. Du hast Recht, in diesem Fall helfen dir mehr als 8 bit. Ich meine ja nur, dieser Fall kommt in der Praxis viel seltener vor als man gemeinhin so denkt. Weil, deine Peaks sind ja auch extrem schmal, schon wenn du ein bisschen Phasenrauschen hinzufügst werden die viel viel niedriger ...
:
Bearbeitet durch User
Angehängte Dateien:
Sven B. schrieb: > Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben > willst :D Es verwirft halt fast alle Werte. Klar, geht, und du siehst > irgendwas, aber halt mit viel schlechterem SNR als wenn du tatsächlich > alle Werte nehmen würdest und immer über 200ms die Beträge der FFTs > mitteln. Hallo, kann ja sein daß es so bei Deinem Oszi ist. Ich behaupte mal: jedes vernünftige Oszi (mit genügend segmentiertem Speicher) kann die Ausgangswerte der FFT mitteln. Du solltest dich mal am aktuellen Stand der Technik orientieren. Und Ja: wenn man eine entsprechende Anzahl FFTs mit realen Signalen mittelt reduziert man den noise floor erheblich. Gruß Anja
Anja schrieb: > Sven B. schrieb: >> Deshalb ist das Oszi ja auch scheiße, wenn du eine vernünftige FFT haben >> willst :D Es verwirft halt fast alle Werte. Klar, geht, und du siehst >> irgendwas, aber halt mit viel schlechterem SNR als wenn du tatsächlich >> alle Werte nehmen würdest und immer über 200ms die Beträge der FFTs >> mitteln. > kann ja sein daß es so bei Deinem Oszi ist. > Ich behaupte mal: jedes vernünftige Oszi (mit genügend segmentiertem > Speicher) kann die Ausgangswerte der FFT mitteln. > Du solltest dich mal am aktuellen Stand der Technik orientieren. Naja, die Picoscopes können so Zeug relativ gut, weil die halt so PC-Software haben. Mein Rigol DS2202 kann das nicht, und wenn ich mich richtig erinnere können es die 10k€ Tek-Scopes die ich in letzter Zeit benutzt habe auch nicht. Und selbst wenn sie es können hilft das nicht so viel: es werden trotzdem nur vergleichsweise wenige der tatsächlich vorhandenen Daten erfasst und noch viel weniger davon verarbeitet. Das gilt insbesondere für das Picoscope, das wahrscheinlich über 10 Wfms/s nicht hinauskommt. Ist halt einfach von der Qualität an Spektrum, die im Prinzip machbar wäre, sehr sehr weit weg. Wenn man sowas "so gut wie möglich" machen wollte, müsste man sich so einen 1 GSa/s PCIe-Digitizer nehmen, und mit einer ordentlichen CPU alles fouriertransofmieren was an Daten reinkommt. Professionelle Anwendungen, wo man tatsächlich was messen will und nicht "nur so'n bisschen kucken", machen das auch so oder so ähnlich.
:
Bearbeitet durch User
Sven B. schrieb: > wahrscheinlich über 10 Wfms/s nicht hinauskommt. Wahrscheinlich hast Du die Spezifikation nicht gelesen die ich oben verlinkt habe. Außerdem ist Wfms/s für mich eine reines "marketing buzz word" so in etwa wie 1000 PMPO bei einem Brüllwürfel mit USB-Steckernetzteil. Wenn ich bei einer FFT eine Auflösung im Bereich von 1 Hz haben will brauche ich so um die 1 Aufzeichnung/Sekunde. Da nützen mir die >100000 Wfms/s überhaupt nichts. Das einzige was wirklich hilft ist Speichertiefe. (aber die kostet ja Geld). Ansonsten: der TE sprach von 2 MSamples/s bei 12 Bit A/D-Wandler. Eine USB-Schnittstelle schafft weitaus mehr (Streaming in Echtzeit).
Anja schrieb: > Sven B. schrieb: >> wahrscheinlich über 10 Wfms/s nicht hinauskommt. > > Wahrscheinlich hast Du die Spezifikation nicht gelesen die ich oben > verlinkt habe. Ne, in der Tat nicht ;) Ich hab auch glaub ich eine etwas irrationale Abneigung gegen die Dinger, weil ich die paar die ich bisher in der Hand hatte immer furchtbar fand. > Außerdem ist Wfms/s für mich eine reines "marketing buzz word" so in > etwa wie 1000 PMPO bei einem Brüllwürfel mit USB-Steckernetzteil. Naja, ich finde es gibt schon Fälle in denen es eine Rolle spielt. Aber du hast Recht, gerade bei z.B. Keysight fühlt sich das sehr überbetont an. Mir ging es auch weniger um die Wfms/s und mehr um das Tastverhältnis, mit dem du tatsächlich auswertbare Daten bekommst. > Das einzige was wirklich hilft ist Speichertiefe. (aber die kostet ja > Geld). Dem stimme ich zu. Oder halt schnelle Datenverarbeitung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.