Cohiradia-Player unter GNU Radio

Hallo Hermann,

ein herzliches Willkommen im Forum!

Quote from hscharfetter

Hallo Bernhard,

Wenn ich das richtig lese, kannst Du so ein Executable für die Commandline kompilieren, ist das korrekt, oder misinterpretiere ich das ?

Das ist genau das was man mit GR machen kann! Du kannst entweder eine Konsolenversion oder eine GUI Version deiner Signalverarbeitung grafisch erstellen und bekommst je nach Einstellung im Options Block ein Python oder C/C++ Programm.

Bei Python wird nur eine .py Datei erzeugt und C/C++ ein ganzer Ordner mit c,cpp,h und Makefiles. Die Erzeugung von C/C++ Programmen ist allerdings daran gebunden, daß jeder Block in der Signalverarbeitung diese Sprache unterstützen muss, bei Python ist dies wohl immer der Fall, mir ist jedenfalls noch kein C/C++ only Block in einer Standard GR Installation begegnet.

Mit Hilfe des Parameterblocks kannst Du die Befehlszeilenparameter der Programme festlegen hinsichtlich Namen/Typs.

Parameter - GNU Radio

Damit kann man dann Daten zwischen verschiedenen Programmen oder mehreren Programmteilen von GR oder Nutzern austauschen. Das funktioniert auch unter Windows!

Man kann somit schnell einen Wrapper für sämtliche SDR-Sender bauen, für die es in GR Treibersupport oder Sinks (USRP Sink) gibt. Auch ein Resampler mit Pipes ist kein Problem, dank der Parameterbausteine frei konfigurierbar und mit den so übergebenen Werten kannst du im GR Programm natürlich auch Berechnungen anstellen.

Einen Pferdefuß im Zusammenspiel mit Fl2k hat das allerdings, flk2 und seine Programme akzeptieren nicht jede beliebige Samplerate.

Möchte man zum Beispiel eine Signalausgabe mit 5 MS/s und ruft man fl2k_tcp -s 5000000 auf, kommt als Ergebnis heraus

Requested sample rate 5000000 not possible, using 7777777.000000, error is 2777777.000000

Man muss eine Samplerate von 7.7... MS/s nutzen, 5 MS/s gehen nicht. Weitere Beispiele für Samplerates unter 10 MS/s

Requested sample rate 8000000 not possible, using 8032786.000000, error is 32786.000000

Requested sample rate 8000000 not possible, using 8032786.000000, error is 32786.000000

10; 11; 12 MS/s ... wieder okay, bei 16 MS: Requested sample rate 16000000 not possible, using 15999998.000000, error is -2.000000

Aber dann gehts hier bei mir in 1 MS bzw. ab 20 MS/s auch in 10 MS-Schritten weiter bis der USB3 Controller seine Leistungsgrenze erreicht hat oder der genutzte PC vorher die Daten nicht mehr Live streamen kann. Gepuffert wird bei der FL2k Lösung rein gar nichts, also muss der PC die Daten in Echtzeit berechnen und transferieren können.

Viele Grüße

Bernhard

Hallo Semir

Quote from Semir

Um drei Kanäle auszugeben wäre es aber erst einmal erforderlich die Software für den fl2k anzupassen. Die Lösung in Github "fl2k rgb" (Danke für den Tip, Bernhard!) kann das zwar aber soweit ich gesehen habe nur wenn man mit einer Datei als Übergabemedium arbeitet und nicht per TCP.

siehe mein Kommentar

Quote from Bernhard45

Nach dem Kompilieren wird fl2k_file durch eine 3 Kanalversion ersetzt die auch für TCP Sinks genutzt werden kann. Keine extra _tcp Version, dafür aber ein 3Kanal Siggen als eigenständiges Programm.

Jeder Kanal kann eine eigene Portnummer zugeteilt bekommen und aus einer entsprechenden Anzahl an TCP Sinks aus GR angesprochen werden

Dort wo die Filenamen hinkommen, kann man mit nc und verschiedenen Portnummern reingehen!

Man hat sich hier einfach eine Version und Mühe erspart und den Teil, der bei der bisherigen _tcp Version den nc-Teil darstellte, weggelassen, weil nc ja sowieso im Betriebssystem vorhanden und viel flexibler ist! Man bräuchte auch in der Einkanalversion nur das fl2k_file denn beide Versionen machen im Prinzip das Gleiche. Man kann den Netzwerkteil auch problemlos wieder einbauen, bringt nur überhaupt keinen Vorteil. Man hat ja nc auch deshalb entwickelt, um unter Unix alle Konsolenanwendungen netzwerktauglich zu machen.

Ich habe auf Gerhards Grundgedanken hin, zu einem "iPod" der HF ausgibt, um das bisherige GR Cohiradia eine noch sehr einfache fltk GUI gebastelt, die auf Minidisplays so etwas wie einen Dateibrowser für einen USB Stick darstellen kann, zwei Comboxen mit gängigen Samplerates und Bandmittenfrequenzen aus den Aufzeichnungen drunter, dann ein Startknopf und alles auf einen RaspPi 4 gepackt.

Alles noch sehr provisorisch und nur den Grundgedanken folgend, aus dem sich mal ein Softwarepaket "PTS" (Pi-Transmitter-System) machen lassen könnte.

Hier läuft es noch nicht auf einem Minidisplay, sondern an einem großen HDMI Monitor und meine Webcam ist für Dunkelaufnahmen ... naja Müll könnte man sagen.

Die Quellen für die Ur-Version (0.001) eines PTS pts.zip

Inhalt

Die Osmo-fl2k Dienstprogramme als Quelle mit Anweisung zu kompilieren, hier könnten später auch weitere Treiber für einen GPIO oder USB DAC erscheinen.

build.sh baut aus cohiradiaplayer_gui mit der fltk-lib die Anwendung cohiradiaplayer_gui, im Moment das Hauptprogramm.

start_fl2k.sh und stop_fl2k.sh - Das sagt der Name, da kommt alles zum Start und zum Stoppen der Show rein, damit man für Veränderungen nicht immer aus der cpp eine neue App compilieren muss.

Das Cohiradia_fl2k Konsolen Programm für GR Version 3.8 und GR Version 3.10. Habe festgestellt das sich da einige Bausteine geändert haben zwischen den Gnu Radio Versionen, deshalb hier zwei Dateien. Je nachdem welche GR Version man hat, baut man damit einmalig das Programm Cohiradia_fl2k_console.py

Die Hauptanwendung könnte man dann direkt nach dem Betriebssystemstart starten lassen (anstelle des User-Desktops).

Wenn man mehrere Module hat (neben Cohiradia könnte man auch UKW nach MW Umsetzung, Internetradio nach MW, ...) in ein weiteres Menu packen, alles hüsch und optisch ausdesignen und das PTS wäre dann nicht weniger flexible als ein PortaHack-Shield für den HackRF. Nur deutlich güstiger.

Gruß

Bernhard

Jetzt habe ich den Player geschrumpft und ihm ein 3.5 Zoll Display verpasst.

Die Cohiradia-Dateien können über einen USB-Stick oder externe USB Platte eingespielt werden (müssen beim Systemstart gesteckt sein, später Automount). Spannungsversorgung über Akku/Powerbank (10 Ah) reicht über viele Stunden hinweg, kann aber auch gleichzeitig wieder über USB aufgeladen und gesendet werden.

Auf dem Raspberry 4 läuft ein Legacy OS https://www.raspberrypi.com/software/operating-systems/ , 32 Bit mit Basisdesktop. Ich habe diese Version genommen, weil damit das X System schon drauf ist und man weniger nachinstallieren muss.

Nachinstalliert habe ich gnuradio, fltk Bibliotheken und cmake. Die fl2k-tools habe ich aus den Quellen im PTS.zip gebaut, Anleitung ist drin, denn die von Raspberry bereitsgestellte osmo-fl2k, die über apt-get installiert werden kann, läuft bei mir nicht.

SSH ist installiert um bequem von draußen ranzukommen, Desktop wurde über raspi-config abgestellt, dafür Autologin auf console. In der /etc/rc.local wurde startx mit der cohiradiaplayer_gui angegeben, damit dieses Programm gleich und als einziges grafisches Programm nach dem Start auf dem Display erscheint. Das Display ist leider kein HDMI, sondern eines mit 3.5 Zoll Header zum Aufstecken auf die GPIOs, die damit leider verdeckt sind. Ich muss nachschauen welche Pins da überhaupt benutzt werden! Der Treiber fürs Display ist hier zu finden. https://github.com/goodtft/LCD-show

Installation

sudo ./LCD35_show

und die Displayrotation einmalig mit ./rotate 270 eingestellt, danach reboot.

Damit die V0.002 des PTS

pts_0_002.zip

Falls die Ausführungsrechte nach dem Entpacken icht mehr enthalten sind, ausführbar müssen sein die Dateien:

build.sh

cohiradiaplayer_gui (sollte nach dem Compilieren mit build.sh aber vom Compiler schon gemacht worden sein)

start_fl2k.sh

stop_fl2k.sh

Cohiradia_fl2k_console.py (falls nicht vorher nochmal die passende Version mit GR erstellt wurde)

Ausführbar gemacht werden kann mit chmod +x ...Liste der Dateien...

Eine weitere Verbesserung wäre es wenn man direkt nach dem Anklicken einer Datei deren Dateinnamen nach Parametern wie Samplerate und Bandmittenfrequenz durchsucht und die Werte als Vorschlag übernimmt. Leider gibts im Netz einen Haufen Mitschnitte wo diese Daten nicht im Dateinamen stehen und zum Teil nicht einmal auf der Downloadseite. Da muss man sich durchtesten, bei der Samplerate ist das so als würde man eine Kassette langsamer oder schneller laufen lassen, das hört man, bei der Mittenfrequenz ist man leider variable wenn diese nicht irgendwo angegeben ist, kann man das Band ja sonst wo hinschieben.

Grüße Bernhard

Hallo Hermann,

alles was du an Vorteilen/Nachteilen nennst kann ich voll unterschreiben. Ich bin leider kein Python Liebhaber geworden! In einem anderen Projekt habe ich gesehen wie verschwenderisch Python mit den Ressourcen umgeht und wie schnell C/C++ Code läuft. Da sind bei der gleichen Aufgabe schon Faktoren zwischen 20x bis 100x drin. Dennoch sehe ich im Netz das man selbst mit Python heute Signalverarbeitung macht (und was mich immer wieder wundert, auch brauchbar funktioniert), aber bei den heutigen PCs kann man wohl so mit den Ressourcen umgehen.

GNU Radio wurde hier gewählt, weil wir im Forum das Tool schon zur Erzeugung mehrerer Sender nutzen, ähnlich deines Cohiradia-Synthesizers zum Beispiel. Über Copy/Paste der Blöcke hat man schnell die gewünschte Senderanzahl, die man im Endsignal drin haben möchte, man kann sich der Simulationsbausteine bedienen, die den Ausbreitungsweg des Signals nachahmen, Störungen hinzufügen und so weiter. Auch verschiedenen Sendenormen wurden hier wieder zum Leben erweckt mit, zum Beispiel DSR oder DAB oder DRM, HDRadio und bald ISDB-T. Es wurden AM-Stereo Sender gebaut, die nach unterschiedlichen historischen Verfahren arbeiten. Echtzeitumsetzer mehrere Internetradiostationen oder UKW auf Mittelwelle. Alles nur mit Mausklicks, wahnsinnig schnell im Prototyping, funktionierend, aber eben nicht mit maximal machbarer Performance auf einem Rechner. Man hat das Problem halt mit massiver Rechenleistung gemeistert und geschlagen. GNU Radio ist hier halt so ein bisschen zum Lieblingstools der Leute geworden, die mit SDRs und speziell Fl2k, LimeSDR, Adalm Pluto, ... experimentieren. Stichwort Machbarkeitsprüfung, Fast-Prototyping. Dafür ist es ja auch da und wird in der Forschung / Industrie so eingesetzt.

Was die Inkompatibilitäten zwischen verschiedenen Pythonversionen und wie ich wiedereinmal festgestellt habe auch zwischen den GR Versionen angeht, eindeutig, das NERVT!

Gerade bei GR wurde mit 3.7 über .8 .9 zur .10 wahnsinnig viel verändert, modernisiert. Meist Kleinigkeiten in den Bausteinen, die einen aber dann in die Suppe spucken. Ich hoffe das da ab 3.10/11 wieder eine Stabilität und Kompatibilität an der Tagesordnung ist, habe aber (noch) Zweifel auch wenn man hört das es besser werden soll.

Quote

Daher wäre mir lieber ein kompiliertes, parametriertes Executable, das ich als Kommandozeilenaufruf über 'subprocess' ausführe, sowas wie z.B.:

Code

Code

convert_IQ_fl2kstream -i inputfile.wav -s <startposition> -lo <LO-Frequency> -o <source_samplingrate> -r <target-samplingrate>

Das Ding soll das Ergebnis als 8-Bit-Binärfile für fl2k auf stdout schreiben. Das könnte ich über eine Ringbuffer-Queue einlesen und an den TCP-Sendeprozess weiterleiten. So brauche ich die gnuradio-Library gar nicht zu importieren.

Nun habe ich dafür mit GRC 2 Möglichkeiten (bitte korrigiere mich, falls das falsch ist):

(1) Den aus GRC exportierten Python Python-Code über pyinstaller in executables umsetzen.

VT: Simpel, kann ich.

NT: Nicht effizienter als direkter Python-Code, da ja da nur die Interpreterumgebung mit reingepackt wird. Das ist erfahrungsgemäß dann unter Windows nicht wesentlich schneller als gleich in Python (unter LINUX gehts bei mir etwas besser).

(2) Aus GRC C++-Code exportieren und nach Anpassungen kompilieren.

VT: vermutlich sehr effizient

NT: Ich habe keine Erfahrung mit C++. Kann ich also (noch) nicht.

Fazit: Mein Favorit ist (2), also mit C++ und kompilieren. Ich brauch aber lediglich eine Kommandozeilen-executable, kein sonstiges Schnickschnak drum herum. Kannst Du mir da irgendwie helfen, z.B. so ein executable erzeugen ?

Display More

Nein der Weg über pyinstaller bringt gar nichts, der richtige Weg wäre hier (2) und gar nicht schwer umsetzbar, da man zum Beispiel auf TCP Sinks verzichten kann, die sich nicht nach C/C++ Code wandeln lassen. Bevor man das aber angeht, möchte ich, auch wenn es hier im Thread ja über Cohiradia unter GNU Radio geht, den Blick von GNU Radio weg und auf eine andere Lösung leiten. Es gibt ein reines Kommandozeilen-Pendant zu GNU Radio, welches in C geschrieben ist und sehr flott Signalverabeitung umsetzen kann. Es handelt sich dabei um CSDR (https://github.com/ha7ilm/csdr) a command line tool to carry out DSP tasks for Software Defined Radio.

Hier gibt es analog zu GNU Radio Bausteine, jedes für sich ist aber ein Konsolenprogramm. Durch Pipen der "Bausteinprogramme" bekommt man dann die gewünschte Signalverarbeitung verschaltet. Kein hübsch anzusehendes Mausschubsen und Wires zeichnen, dafür aber die volle Flexibilität der Konsole! Für das Einlesen/Datenkonvertierung von Cohiradiafiles wäre man hier gut aufgehoben

Regarding csdr, it can convert a real/complex stream from one data format to another, to interface it with other SDR tools and the sound card. The following commands are available:

• csdr convert_u8_f
• csdr convert_f_u8
• csdr convert_s8_f
• csdr convert_f_s8
• csdr convert_s16_f
• csdr convert_f_s16
• csdr convert_s24_f [--bigendian]
• csdr convert_f_s24 [--bigendian]

Es gibt Resamplers

rational_resampler_ff

Syntax:

csdr rational_resampler_ff <interpolation> <decimation> [transition_bw [window]]

It is a resampler that takes integer values of interpolation and decimation. The output sample rate will be interpolation / decimation × input_sample_rate.

transition_bw and window are the parameters of the filter.

Es gibt Mischer bzw. Shifter, Filter aller Art und AGCs für die perfekte Aussteuerung des DAC. Alles Einzelprogramme die pipebar sind und hinten kommt dann mit Übergabe an ein File, Fifo, Named Pipe, netcat , ... das gewünschte Signal raus. Bitte schaue dir das mal an Hermann! Von Flexibilität und Performance eigentlich das was man sich wünscht und wenn ich den Cohiradia Player von GNU Radio auf CSDR abändere wird es vielleicht sogar mit kleinere Single Board Computer noch gut laufen (Ziel Raspberry 3 und wenn möglich noch weniger *ich träume*). Ich werde das auf jeden Fall mal ausproberen und beide Lösungen vergleichen (in einem neuen Thread "Cohiradia-Player unter CSDR"). Überlege mal ob sich sowas wie csdr nicht auch für dein Projekt eignet. Die C/C++ Version aus GNU Radio erzeuge ich in den nächsten Tagen und lade sie dann hoch. Zur Zeit mal wieder einen Haufen Projekte und nur 24h am Tag.

Grüße

Bernhard

Zur GNU Radio Cpp Übersetzung.

Ich habe jetzt aus dem PTS das GRC File für Version 3.10 als Grundlage genommen und solange umgebaut, bis nur noch Bausteine drin sind, die eine Cpp Übersetzung zulassen. Cohiradia_fl2k_console_cpp.grc.txt

Da musste nur der TCP Sink Baustein dran glauben. QT hätte drin bleiben können, wenn es sich sowieso nicht nur um ein Komandozeilenprogramm handeln sollte. Was allerdings aufgefallen ist, der Konverterbaustein IShortToComplex macht im GCC den Scale Factor nicht (hat also das Verhalten aus der Pythonversion des GR 3.8), deshalb die Skalierung dahinert mit der Multiplikation.

Damit sind alle Bausteine c++ Übersetzungsfähig und man kann auf das <Code erzeugen> Symbol klicken, was auch die Generierung des py-Files angestoßen hat. Nur bekommt man jetzt kein py-File sondern ein Projektverzeichnis für den C/C++ Compiler.

Header, cpp eine CMake (und das build muss man sich wegdenken, das stammt aus einem vorherigen Compilieraufruf).

Wie übersetzt man eine frische Codegenerierung?

mkdir build

cd build

cmake ..

-> jetzt wird das Makefile für make erzeugt

make

-> Programm wird gebaut, oder auch nicht. Letzteres ist der Fall da GR keinen 100% fehlerfreien Code erzeugt hat, aber das sind nur Kleinigkeiten die wir uns jetzt anschauen, wir berichtigen also die Fehlermeldungen des Compilers.

In der Headerdatei werden zum Beispiel zwei Standardzuweisungswerte aus den Parameterbausteinen falsch generiert.

// Parameters:
    int center_frequency = 198000;
    std::string inputfile = '0';
    std::string outputfile = '0';
    int sample_rate_inputfile = 250000;
abändern in 
// Parameters:
    int center_frequency = 198000;
    std::string inputfile = "\0";
    std::string outputfile = "\0";
    int sample_rate_inputfile = 250000;

Die gleichen Sachen findet man auch noch einmal im C++ File

int main (int argc, char **argv) {
    int center_frequency = 198000;
    std::string inputfile = '0';
    std::string outputfile = '0';
    int sample_rate_inputfile = 250000;
abändern in 
int main (int argc, char **argv) {
    int center_frequency = 198000;
    std::string inputfile = "\0";
    std::string outputfile = "\0";
    int sample_rate_inputfile = 250000;

Dann wird eine Variable nochmal definiert

// Blocks:
            std::vector<float> taps = {};
        this->rational_resampler_xxx_1 = gr::filter::rational_resampler_fff::make(
            int(10000000/(sample_rate_inputfile*4)),
            1,
            taps,
            0);
            std::vector<gr_complex> taps = {};
        this->rational_resampler_xxx_0 = gr::filter::rational_resampler_ccc::make(
            4,
            1,
            taps,
            0);
abändern in 
          std::vector<gr_complex> taps2 = {};
        this->rational_resampler_xxx_0 = gr::filter::rational_resampler_ccc::make(
            4,
            1,
            taps2,
            0);

Wir nennen die zweite Variable einfach von taps nach taps2 um und verwenden taps2 im darauf folgenden Baustein.

Dann gibt es zwei Stellen, da möchten die Funktionen für die File-I/O Blöcke einen char* und keinen String.

       this->blocks_file_source_0 =blocks::file_source::make(sizeof(short)*1, inputfile, true, 0, 0);
        this->blocks_file_sink_0 = blocks::file_sink::make(sizeof(char)*1, outputfile, false);
abändern in 
        this->blocks_file_source_0 =blocks::file_source::make(sizeof(short)*1, inputfile.c_str(), true, 0, 0);
        this->blocks_file_sink_0 = blocks::file_sink::make(sizeof(char)*1, outputfile.c_str(), false);

Weiter unten nochmal und man hat "True" statt true generiert.

void Cohiradia_fl2k_console_cpp::set_inputfile (std::string inputfile) {
    this->inputfile = inputfile;
    this->blocks_file_source_0->open(this->inputfile, True);
}
void Cohiradia_fl2k_console_cpp::set_outputfile (std::string outputfile) {
    this->outputfile = outputfile;
    this->blocks_file_sink_0->open(this->outputfile);
}
abändern in 
void Cohiradia_fl2k_console_cpp::set_inputfile (std::string inputfile) {
    this->inputfile = inputfile;
    this->blocks_file_source_0->open(this->inputfile.c_str(), true);
}
void Cohiradia_fl2k_console_cpp::set_outputfile (std::string outputfile) {
    this->outputfile = outputfile;
    this→blocks_file_sink_0→open(this→outputfile.c_str());
}

Das war es aber auch schon, die händischen Korrekturen sind in ein paar Sekunden erledigt. Danach mit make übersetzen und man erhält ein natives Konsolenprogramm.

~/Cohiradia/Cohiradia_fl2k_console_cpp/build$ make Consolidate compiler generated dependencies of target Cohiradia_fl2k_console_cpp [ 50%] Building CXX object CMakeFiles/Cohiradia_fl2k_console_cpp.dir/Cohiradia_fl2k_console_cpp.cpp.o [100%] Linking CXX executable Cohiradia_fl2k_console_cpp [100%]

Built target Cohiradia_fl2k_console_cpp

Ich benutze für die Ausgabe ein File Sink, kann mit dem Programm also in eine Datei wie auch in eine Pipe schreiben.

Der Dateifall ist logisch

./Cohiradia_fl2k_console_cpp --inputfile /home/weiner/Cohiradia/AM1_1250kHz_1_20240512_100854_1250kHz.wav --sample_rate_inputfile 1250000 --center_frequency 1250000 –outputfile a_file.out

fl2k_file -s 10000000 a_file.out

Ohne Festplattenplatz in Anspruch zu nehmen schreibe ich nun in eine Pipe (mkfifo a_named_pipe)

./Cohiradia_fl2k_console_cpp --inputfile /home/weiner/Cohiradia/AM1_1250kHz_1_20240512_100854_1250kHz.wav --sample_rate_inputfile 1250000 --center_frequency 1250000 --outputfile a_named_pipe

fl2k_tcp -s 10000000 -p 1234

Und das Pipe kommt auf Port 1234: nc -k -l 1234 < a_named_pipe

Pipes gibt es ja auf allen Unix/Linux Rechnern genauso auch auf Windows, das Prinzip ist also portabel.

Das Konsolenprogramm kann man auf Rechnern ausführen die kein GNU Radio installiert haben, wenn man die entsprechenden libgnuradio Libs mit deployed (dynamisch oder statisch gelinkt) und man kann das Programm als Binärversionen zu einem Cohiradia Release dazupacken (Linux ARM, Linux x86/64, Win32/64.) Man muss im Pythoncode von Cohiradia nur erkennen auf welchem OS man läuft und dann eine der Binärversionen auswählen. Ebenso könnte man fix und fertige Versionen von fl2k_tcp mitschleppen und dann die passende starten. Das ist aber ein großer Testaufwand mit vielen verschiedenen Installationen, ich für meine Zwecke ziehe immer einen Bau aus dem Quellcode vor. Das schreckt mich nicht ab, ich bin in der typischen Radiobastlergemeinschaft sicher kein gewöhnlicher PC-Nutzer.

Hallo Semir,

von GR (TCP) auf fl2k_file ist ja das was ich oben im Zusammenhang mit der 3 Kanal Version des fl2k_files angesprochen habe, man kann sich also eine Netzwerkversion sparen und muss nur ein Transferprogramm pflegen. Wenn du für jeden Kanal eine eigene named_pipe hast und diese an der Stelle der Dateilnamen in der 3 Kanalversion angibst, kannst du aus GR über 3 unterschiedliche Ports synchron (!) heraus die Kanäle bestreamen.

Es geht auch direkt von 3 x File Sink auf 3 x named pipes! Damit hast du im letzten Teil wohl noch ein Problem. Hast geschaut was GR im Debugfenster ausgibt? Findet das Sink denn die Pipe? Findet fl2k_file die Pipe?

Du musst bedenken, wenn du in einer Konsole ein Pipe mit mkfifo anlegst, dann ist es direkt mit seinem Namen auch nur in diesem Verzeichnis erreichbar, auch nach einen Reboot ist es noch dort. Du legt ja eine 0-byte Datei an, kannst du prüfen mit ls -la

Löschen kannst du die Pipe wie eine Datei mit rm .

Wenn aber das GR Programm nicht im gleichen Verzeichnis ist, wie das named_pipe musst du im Sink den vollen Pfad zur Pipe angeben! Da unter Unix alles als Datei behandelt wird, auch Geräte, I/Os, ... wird das vom Betriebssystem immer mit den gleichen Schreib- und Leseroutinen geöffnet und bedient wie eine richtige Datei, nur das das Ziel nicht die Festplatte, sondern das RAM oder ein Controller irgendwo am Bussystem ist!

Da gleiche Funktionen wie Dateien, muss der Pfad zum Pipe natürlich auch vollständig drin sein, wenn Programm und Pipe nicht im gleichen Verzeichnis liegen.

Nach dem Eröffnungspost sollte die Cohiradia Sache eigentlich nur ein weiterer Zubringer (neben UKW über RTLSDR, KiwiSDR) für einen Lokaloszillator-gesteuerten Sender sein, eine Erweiterung der Idee aus iRadio und mit Frequenzzählersensoren mit WLAN von verschiedenen Radios aus der Sammlung kontrollierbar.

Es macht jetzt aber sicher auch keinen Sinn noch weiter in die Tiefe zu gehen und viele weitere Möglichkeiten aufzuzeigen wie man Basisbanddateien mischt und irgendwie auf einen DAC streamt. Its so simple! Man muss nur wissen, Daten kann man zu DACs senden und wenn die schnell genug sind, gibts Cohiradia, gibts in 10-20 Jahren nach der UKW Abschaltung vielleicht mal Cohiradia-UKW mit 20 MHz Basisbandfiles, gibts (heute schon) old-school DSR und andere.

Wenn jemand einen Sender dafür bauen will und Hilfe benötigt oder eine andere Umsetzung sucht, kann er sich ja im Forum melden. Wichtiger als das simple Aussenden finde ich die nicht mehr so leicht gegebene Möglichkeit Aufzeichnungen remote anzufertigen! Mittelwelle geht in 1 bis 2 Jahren auch in Japan ins off und ich kann nicht zu bestimmten Ereignissen immer rüberfliegen, auch wenn ich wollte! Wir brauchen also Methoden und Programme die diesen kleinen Mittelwellenbereich über bestehende SDRs (eventuell Streifenweise) aufzeichnen oder wir müssen ein Netz von Leuten aufbauen, die genau das für uns vor Ort machen und dann brauchen wir eine gute Verfügbarkeit der Aufzeichnungen und unabhänig von nur einem zentralen Server wie rm.org.

Ich warte mal ab was Hermann jetzt plant. Vielleicht kann die "offizielle" Playersoftware des Projekts mit einem Kommandozeilenschalter in eine Mini-GUI zurückfallen die für Display 320x240, 480x320 geeignet ist. Dann kann man die Software direkt auf einen Kleincomputer mit Ansteckdisplay bringen, dann braucht man keine weitere "PTS-Software". Obs dafür Bedarf gibt wird sich dann zeigen, wenn Leute ihre Senderaufbauten vorstellen oder anfragen.

Als nächstes Semir muss ich mich um meine Mitbringseltechnik kümmern. Ich habe noch ein AM Stereo taugliches Radio gekauft und ein Sony XDR 64TV welches man hier sehr schwer/gar nicht bekommt. Nachdem ich endlich mal OneSeg in Echt ausprobieren durfte, möchte ich ISDB_T für mich mal selbst erzeugen und testen. Und irgendwann will ich mal CDR probieren. Bisher habe ich über dieses IBOC System nur (wenig) gelesen.

Grüße
Bernhard

Hallo Gerald,

das start und stop Shellskript wird von der grafischen Nutzeroberfläche aufgerufen und mit Parametern bestückt, nicht vom Nutzer über die Konsole.

Schaut so aus als fehlten dir außerdem die Rechte zum Öffnen des USB-Gerätes, lass die GUI mal mit sudo starten. Diese Rechte hat sie dann auch wenn sie beim Systemstart aus der /etc/rc.local gestartet wird.

Das ad hoc Zusammenfügen mehrerer Teildateien zu einer einzigen kann in einer späteren Version automatisch erfolgen.

Gruß

Bernhard

Hallo Gerald,

Genauso wie auf dem Mini-PC ist richtig! Da im PTS ja das gleiche GNU Radio Konsolenprogramme drin ist. funktioniert das auch ohne GUI.

Da die Temperaturen beim Raspberry 4 schnell in die Höhe gehen, denke an eine gute Kühlung, sonst gibt es Aussetzer. Ich denke solch Alukühlkörpergehäuse ( ganze Gehäuse ist ein Kühlkörper) eignet sich am Besten und dürfte ohne zusätzlichen aktiven Lüfter die Temperaturen im grünen Bereich halten.

FREI Gehäuse für Raspberry Pi 4, Alu, schwarz | Gehäuse günstig kaufen | reichelt elektronik

Man könnte auch mehrere Cohiradia Dateien auf einen Stick machen und per Taster <up/down> an den IOs umschalten, ohne Display. Oder man schließt wie bei einem iRadio ein kleines OLED oder LCD Display an, welches den gerade gespielten Dateinamen anzeigt. Vielleicht ist das abwechslungsreicher als die Dauerwiedergabe einer Datei?