Ich entwickle ein Web-Frontend für eine GNU Radio-Anwendung, die von einem Kollegen entwickelt wurde.GnuRadio tcp_sink Datenwerte sind verstümmelt
Ich habe einen TCP-Client mit der Ausgabe von zwei TCP Sink Blöcke verbinden, und die Datencodierung ist nicht so, wie ich es erwarte.
Ein TCP Sink sendet komplexe Daten und der andere sendet Float-Daten.
Ich entziffere die Daten auf dem Client, indem ich jeden 4-Byte-Chunk als float32-Wert lese. Der Server und der Client sind beide Little-Endian-Systeme, aber ich versuchte auch Byte-Swapping (mit dem GNU-Funk Endian Swap Block und auch manuell auf dem Client), und die Daten sind immer noch nicht richtig. Eigentlich ist es viel schlimmer, wenn man bestätigt, dass es keine Byte-Reihenfolge gibt.
Wenn ich das Flussdiagramm in GNU Radio Companion mit entsprechenden GUI-Elementen ausführe, sehen die Diagramme korrekt aus. Die Datenwerte werden erwartungsgemäß zwischen 0 und 10 angezeigt.
Die Werte, die am Client dekodiert werden, liegen jedoch im Allgemeinen bei 0,00xxxxx, und die Grafik sieht eher wie Rauschen aus als einen einfachen Ton wie in GNU Radio. Wenn ich die Daten manuell durch Multiplikation mit 1000 skaliere, sieht es immer noch wie Rauschen aus.
Ich werde den Pre-Pfad in GNU Radio beschreiben, da es kürzer ist, aber ich sehe das gleiche Problem auf dem Post-Pfad, wo ein WBFM Receive und ein Rational Resampler hinzugefügt werden, gefolgt von einem Throttle Block und dann einem TCP Sink Block sendet Float-Daten.
File Source (Output Type: complex, vector length: 1) =>
Throttle (vector length: 1) =>
Low Pass Filter (FIR Type: Complex->Complex (Decimating)) =>
Throttle (vector length: 1) =>
TCP Sink (input type: complex, vector length: 1).
Dies scheint der richtige Weg zu sein, um die Stream-Parameter zu spezifizieren (und in der Tat Companion zeigt Fehler, wenn ich Änderungen vornehmen, die den Strom Artikel Mismatch), aber ich kann keinen Weg finden, um die Daten korrekt auf der anderen Seite zu dekodieren Ende des Streams.
Warum verwenden Sie 'Drossel'-Blöcke, und warum sogar zwei von ihnen? Throttle tut genau * nichts * zu deinem Signal. Es verlangsamt nur die Verarbeitung. Sie sollten nie zwei davon im selben Beispielpfad haben. –
Also: schlechte Nachrichten zuerst: GNU Radio bereitet sich auf die Version 3.8 vor, und die TCP-Senken sind veraltet und werden entfernt. Also könntest du diese überhaupt vermeiden, besonders, weil sie in vielerlei Hinsicht ziemlich schrecklich sind (ich kann es erklären, wenn du die Mailingliste von discuss-gnuradio verschickst). –
Aber: Ich glaube nicht, dass das hier das Problem ist. Was ist dein Dezimierungsfaktor? –