Gnuradio Verständnisfrage

[Erwin U. (erwin_u)]

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!

[Rick (rick)]

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?

[Erwin U. (erwin_u)]

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.

[Erwin U. (erwin_u)]

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?

[Erwin U. (erwin_u)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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?

[Erwin U. (erwin_u)]

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.

[R. M. (n_a_n)]

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.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Hp M. (nachtmix)]

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.

[Erwin U. (erwin_u)]

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.