Hallo! Ich versuche gerade, im Gnuradio Streams und Vektoren besser zu verstehen, und habe mir dazu das Beispielprogramm (siehe Bild) gebaut. Die Streams der beiden Signale werden in einen Vektor umgewandelt, und diese wieder retour, allerdings in einen Stream, der daher ja wohl logischerweise mit der doppelten Sample-Rate Daten liefern müsste. Allerdings sehe ich hinten in der QT-Gui die Daten mit derselben Sample-Rate. Daher die Frage: wer wirft hier Daten weg? Muss ja wohl der "Vektor to Stream"-Block sein, allerdings müsste er dann immer abwechselnd den ersten und dann den zweiten Wert im Vektor ausgeben, oder der zweite Wert im Vektor kommt zeitverzögert raus. Ist meine Vermutung richtig, dass Gnuradio sozusagen mit mit der Geschwindigkeit der sample-rate getaktet, jedesmal den Flowchart durchrechnet? Oder kann mir jemand erklären, wie die Berechnung da stattfindet? Danke für die Hilfe!
:
Bearbeitet durch User
Du schickst vorne 2x 1 kHz rein und gibst das hinten auf eine FFT. Wo kannst du an der FFT die Samplerate sehen? Was passiert, wenn eine Quelle auf z.B. 1,2 kHz gedreht wird?
Hallo! Entschuldigung, ich hätte wohl gleich meine Beobachtung mitanhängen sollen. Anbei ein Screenshot des Zeitverlaufs, da sieht man, dass alle Millisekunden ein Wert vorhanden ist.
Zu deiner Frage mit den 1,2 KHz: die beiden Sinus-Signale werden mit 200 Hz bzw. 100 Hz erzeugt. Meinst du, ich soll einen der beiden auf 1,2 KHz ändern oder soll ich die Sample-Rate der Signalquellen anpassen?
Weitere Beobachtung meinerseits: wenn ich im QT Gui Sink die Bandbreite erhöhe, z.B. auf das Achtfache, dann erhalte ich in der Ausgabe die achtmalige Datenmenge, d.h. die beiden Sinussignale vorher liefern plötzlich mit einer höheren Samplerate Daten, als eigentlich bei ihnen eingestellt ist.
Erwin U. schrieb: > die beiden Sinussignale vorher liefern > plötzlich mit einer höheren Samplerate Daten, als eigentlich bei ihnen > eingestellt ist. Hast Du denn hinter beiden Sinusquelle jeweils einen Throttle-Block gesetzt?
Hallo! Nein, die Verschaltung aus dem ersten Bild ist weiterhin gültig. Ich habe nur den Parameter Bandbreite im QT GUI Sink auf 10 KHz geändert und sehe jetzt das folgende Bild. Man sieht im Zeitdisplay, dass jetzt 10 Werte pro Millisekunde angezeigt werden.
Ich habe Dein Experiment nachgebaut. Dabei untersuchte ich aber nicht den Zeitbereich, sondern habe mir das FFT-Ergebniss angeschaut. Die originalen 100/200 Hz Signale werden bei 1k Bandbreite (entspricht Samplerate der FFT) als 50/100 Hz abgebildet. Bei 2*samp_rate sind auch die 100/200 Hz Komponenten richtig. Ich bin erst seit kurzer Zeit User von gnuradio (leider) und kann nur vermuten das durch die Vector/Stream Verdrahtung die Datenmenge verdoppelt wird.
Hänge dir mal ein Oszi (QT GUI Time Sink) mit an den Ausgang. Da siehst du schon, das ein 200Hz Signal mit 1kHz Sample Rate nur aus 5 Punkten zusamengebaut wird und alles andere als ein Sinus ist. Beim Oszi schalte am besten das Control Panel mit an, damit du es sinnvoll skalieren kannst.
Erwin U. schrieb: > Bandbreite im QT GUI Sink auf 10 KHz geändert und > sehe jetzt das folgende Bild. Man sieht im Zeitdisplay, dass jetzt 10 > Werte pro Millisekunde angezeigt werden. Damit ist die Bandbreite aber nur 5kHz. Solange du am Eingang nur einen Sinus bis knapp 5kHz anliegen hast, kann man damit leben, aber wenn dein Eingangssignal Oberwellen aufweist, brauchst du vor dem ADC ein analoges(!) Filter, das alles ab 5kHz völlig abtötet. Sonst werden die Frequenzanteile oberhalb 5kHz ebenfalls im Spektrum dargestellt und zwar teilweise spiegelverkehrt. Da solch steilflankige analoge Filter schwer zu bauen sind, wählt man Eckfrequenzen und Samplingraten, die sehr weit über der maximalen Nutzfrequenz liegen, sodass oberhalb fs/2 tatsächlich nichts mehr zum ADC gelangt.
Hallo! Mein Experiment sollte ja dazu dienen, die interne Verarbeitung im Gnuradio besser zu verstehen. In der Zwischenzeit habe ich gelernt, dass der Gnuradio Scheduler anscheinend hochkomplex ist. Siehe Link http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html Ich kann derzeit die Präsentation da drinnen nicht komplett durchschauen, aber irgendwo ab Seite 27 ist der Scheduler Flow Chart beschrieben, und da gibt es die Aussage, dass jeder Block seinen eigenen Thread bekommt, und das verstehe ich so, dass es keine "generelle" Durchrechnung des Flowcharts gibt, sondern jeder Block für sich rechnet, und das mit der Geschwindigkeit seiner Vorgaben.
Bitte 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.