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?
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.
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
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.
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.
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
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 ...
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.
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.
