Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Hallo Walter,
ich denke der CohiradiaStreamer wird sich mit der CohiWiz Software beißen. Die Ur-Hardware des CohiWiz aus dem Radiomuseum spricht mit dem SD-Karten Image für das Stemlab eine anderes Protokoll. Ich habe Google gefagt und den Code analysieren lassen. Dort meinte man das man ein kleines Programm als Übersetzer für das STEMLAB schreiben oder ein anderes Image verwenden sollte, da der SCPI Server nicht von CohiradiaStreamer genutzt wird.
Für einen Test mit dem angesprochenen FL2000 gibt es aber eine Lösung die auf der Seite genannt wird. Man muss einen zusätzlichen Befehl eingeben
Dieser socat-Befehl ist ein genialer, kleiner Trick. Kurz gesagt: Er baut eine unidirektionale Netzwerk-Brücke (einen Rendezvous-Punkt) zwischen zwei Programmen, die beide eigentlich "Clients" sein wollen und nicht selbst auf Verbindungen lauschen können.
Hier ist die exakte Zerlegung des Befehls und warum er für den FL2k-VGA-Dongle gebraucht wird: Die Parameter im Detail
-u (Unidirectional): Schaltet socat in den Einweg-Modus. Daten fließen strikt nur von links (Quelle) nach rechts (Ziel). Das verhindert, dass Müll oder Bestätigungspakete der Hardware zurück in die DSP-Engine gefüttert werden.
TCP4-LISTEN:1234,reuseaddr (Die Quelle): socat öffnet einen TCP-Server auf Port 1234. Hier verbindet sich das Qt-Programm (CohiStreamer) hin und pumpt den fertigen HF-Datenstrom hinein.
TCP4-LISTEN:1235,reuseaddr (Das Ziel): Jetzt kommt der Clou: socat öffnet gleichzeitig einen zweiten TCP-Server auf Port 1235. Hier wartet es darauf, dass sich das Programm verbindet, das die Daten an den FL2k-Stick weitergeben soll.
reuseaddr: Das sorgt dafür, dass die Ports nach einem Abbruch oder Neustart des Streamings sofort wieder freigegeben werden. Ohne diesen Parameter müsstest du nach jedem "Stop" in der GUI oft ein paar Minuten warten, weil das Betriebssystem den Port blockiert (Address already in use).
Warum macht man das so kompliziert mit zwei "LISTEN"-Ports?
Das Standard-Tool für den FL2k-Stick (fl2k_file und fl2k_tcp) hat überhaupt keinen eingebauten Netzwerk-Stack – es kann standardmäßig nur aus einer Datei oder direkt von der Standardeingabe (stdin) lesen.
Um die Brücke von der Netzwerk-GUI zum FL2k-Stick zu schlagen, sieht die Kette im System normalerweise so aus:
CohiStreamer verbindet sich als Client mit Port 1234 und sendet die HF-Daten.
socat nimmt die Daten auf Port 1234 an und hält sie im RAM bereit.
Auf der Konsole startest du (oder ein Skript) einen zweiten Befehl, der die Daten von Port 1235 abholt und in das FL2k-Tool einspeist, zum Beispiel so: Bash
fl2k_tcp -s 10000000 -p 1235
Ich habe es getestet. Es läuft, aber man muss im CohiradiaStreamer unbedingt den richtigen Port von socat verwenden, die Samplerate muss auf 10 MSPS und die Bitbreite auf 8 Bit nativ eingestellt werden.
Bei den neuen SDRs die die im Elektor verlinkt haben und von denen ich bereits zwei nachgebaut habe läuft die Aussendung direkt über das Netzwerk ohne irgendwelche Zusatzeingaben. IP des SDRs im Netzwerk und gewünschte Bitbreite auswählen reicht. Für das im Elektor genannte Update für FPGA DUC / DDC wird ein Iceboard empfohlen. Ich habe mal angefragt und als Antwort die Empfehlung für das iCE40HX8K bekommen was dort bereits umfangreiche Test absolviert hat.
Vor einiger Zeit habe ich bei Elektor das Max1000 Lehrbuch Bundle gekauft weil ich mich damit beschäftigen wollte. Leider hat dieses Board keinen passenden Anschluss für die SDRs und man muss einen Adapter entwickeln. Es geht wohl auch für den Zweck, aber ich hebe es für die anderen Elektorprojekte auf die auch sehr interessant sind und von der gleichen Cohiradia-Gruppe entwickelt wurden. AM Modulator on Legacy FPGA Silicon https://www.elektormagazine.it/labs/am-m...cy-fpga-silicon Aber die Lehrkurve ist sehr steil und ich kann dort nur durch Ausprobieren vorankommen.
!!!
Fotos, Grafiken nur über die
Upload-Option des Forums, KEINE FREMD-LINKS auf externe Fotos.
!!! Keine
Komplett-Schaltbilder, keine Fotos, keine Grafiken, auf denen
Urheberrechte Anderer (auch WEB-Seiten oder Foren) liegen! Solche Uploads werden wegen der Rechtslage kommentarlos gelöscht!
Keine Fotos, auf denen Personen erkennbar sind, ohne deren schriftliche Zustimmung.
Den Beitrag-Betreff bei Antworten auf Threads nicht verändern!
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Hallo Roland,
ob sich Cohiwizard und Cohiradiastreamer "beissen" kann ich nicht beurteilen, weil ich das Programm nicht programmiert habe.
Ich kann aber sagen, dass Hermann versuchen wird, Kernteile von Bernhards Codes in den COHIWizard einzubauen, da er die extrem effiziente liquiddsp Library nutzt. Das wird aber nicht vor Ende der HamRadio passieren, an der Cohiradia auf dem Stand der GFGF vertreten sein wird.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Hallo Walter,
von Herrn Dünk wurde mir mitgeteilt das zur Zeit nicht beabsichtigt wird das SCPI Protokoll des RedPitaya zu implementieren, da man nur einen kleinen Teil davon benötigen würde und man mit einem eigenen Steuerkanal für smiSDR und parlioSDR über Port 5000 schneller wäre und dieser ausreichend ist.
Herr Dünk hat auch mitgeteilt das man die liquiddsp nicht weiter benutzen wird, da sie in der rückwärtigen Betrachtung für einige Anwendungen nicht schnell genug ist. Seit einem Versionsupdate kann man die DSP-Engine im Streamer auf das neue experimentelle Rechenprinzip umstellen und vergleichen.
In meinem Experimentierfeld läuft die INT32 DSP Engine um einiges schneller als mit der liquiddsp Engine. Nach Herrn Dünk wird nur noch die Filterung angepasst und später dann die liquiddsp aus der Software verschwinden. In einem anderen Projekt dieser Gruppe sieht man den Gewinn sehr deutlich.
Nach meinem Test mit der von der Gruppe angebotenem Livesystem sind die Unterschiede noch viel größer als beim CohiradiaStreamer. Auf der Webseite steht das es die neuen Funktionen für smiSDR und parlioSDR, die Gewittersimulation auch nur noch in der liquiddsp-losen INT32 Version geben wird.
Im Beschreibungscode für die FPGA Erweiterung der SDRs wird auch nur diese Ganzzahlmethodik für die NCO und Mischerbausteine angewendet.
Ob die Umstellung auch den cohiplayer_smi betreffen wird ist mir nicht bekannt, auf der Seite steht nichts davon. https://github.com/radiolab81/cohiplayer_smi Vorstellbar wäre es, da ein direkt auf dem SDR installierbarer Player bestimmt sehr von solchen Rechnungsoptimierungen profitieren würde.
Mein nächstes ereichbares Wunschziel wäre den CohiMini Player von Claus Peter Gallenmiller installiert zu bekommen. Ist dir bekannt wo das Image von dem auf cohiradia.org gesprochen wird, runterzuladen ist? Ich finde keinen Downloadlink.
Wenn die Software von Herrn Gallenmiller so effizient läuft wie der cohiplayer_smi, wäre es sehr gut wenn man die Ausgabe in den localhost port 1234 umleiten könnte wie bei CohiradiaStreamer. Dort würde das smiSDR Programm smi_tcp_streaming_dac es aufnehmen können und über eine selbstgebaute DAC-Platine aussenden. Die Software von Hr. Gallenmiller hat die Nutzeroberfläche für ein Touchdisplay welches ich benutzen möchte, der cohiplayer_smi mit seiner DOS-artigen Minimaloberfläche funktioniert damit nicht.
Vermutlich wird auch der Syntheziser im Wizard deutlich zulegen wenn Herr Scharfetter die Software umgestellt hat. Bei meinem bisherigen Versuch mit dem Wizard dauert es mehrere Stunden um eine Stunde Archivdatei zu berechnen. Bei den gleichen Einstellungen mit unterschiedlichen Signalquellen, Modulation von Datei und Modulation von Internetradio, geht es mit dem AMWaveSynth in Echtzeit. Eine Stunde Programmaufzeichnung braucht eine Stunde Berechnung und man kann am Radio das ganze Band live überwachen.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Hallo Roland,
interessante Infos. Der Miniplayer des Herrn Gallenmiller wird demnächst auch auf der Cohiradia-Webseite vorgestellt werden. Die Webseite ist gerade erst entstanden, und alles braucht seine Zeit, zumal einige Leute ja auch noch ihrem Job nachgehen müssen. Wie ich erfuhr wird auch Gallenmiller auf der HamRadio sein.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Vielen Dank für diese Hintergrundinformation Walter.
Ich habe die letzten Bürotage wetterbedingt nutzen können um vor meinem Urlaub noch etwas am Cohiradia-SDR zu experimentieren. Im Elektor wird neben dem smisdr auch das parliosdr als Alternativsystem genannt. <Link unten>
Dabei kann man günstige ESP32P4 Systeme als Grundlage für einen Cohiradiasender und Aufzeichner nehmen. Das gleiche System wird auch vom Elektor für einen mehrkanaligen Heimsender vorgeschlagen. In Kombination kann das eine Alternative für die CohiradiaWizard Synthese angesehen werden.
Für diese Idee habe ich ein parliosdr Grundboard bestellt und ein sehr günstiges FPGA Board mit dem EP4CE6 Cyclone IV. Dieses FPGA System gibt es bei Amazon und eBay und anderen schon für etwas über 10 Euro. Es passt nach meinem Dafürhalten genau in die Sparte die Elektor als Legacy Hardware nennt, hat sogar noch etwas mehr Spielraum als die Cohiradialeute für ihren Minimalismusversuch im Projekt nennen.
Das Cyclone IV Board kommt ohne Schnörkel und Dokumentation, ganz im Gegensatz zu dem Elektor Lernbundle oder den Kits der Firma Trenz. Das ist jedoch nicht so wild, da diese Minimalsysteme genauso oder sogar noch besser im Internet auf breiter Front dokumentiert werden.
Ich habe also wie für das Max1000 Elektor-Trenz-System ein neues Quartus Projekt erstellt und als Device den EP4CE6E22C8 dieses Minimalsystems auf meinem Foto ausgewählt. Den Verilogcode von der im Elektorartikel verlinkten Seite eingefügt wobei man beachten muss das die Cohiradialeute dort mehrere Versionen aufzeigen, die wohl evolutionär oder selbst als Lehrsystem zu verstehen sind. Das Hauptprojekt im Stammverzeichnis zeigt einen Lang-Mittelwellen-Generator für 10 Sender. Die Unterverzeichnisse zeigen modernere Techniken, die wie im Elektorartikel beschrieben bis 40 Kanäle auf Langwelle und Mittelwelle in Echtzeit auf einem Cyclone II erzeugen.
Im Topmodul habe ich die Bitauflösung meines DAC übernommen. Wie im verlinkten Dokument gezeigt, kann das Pinassignment, das Zuweisen welcher FPGA Pin welche Funktion haben soll, in einer TCL Datei erfolgen. Diese kann man in Quartus laden und erspart sich das mühevolle Zuweisen im grafischen Pin-Planer.
Bei der Synthese des im Elektor gezeigten TDM-Model für 40 Kanäle meldete Quartus das es die M4K Speicherblöcke nicht übersetzen kann.
Assertion warning: Device family Cyclone IV E does not have M4K blocks -- using available memory blocks
Im Legacy Hardwareartikel nimmt die Gruppe eine viel ältere Cyclone II Serie, die Serie IV hat diese kleinen Blöcke nicht. Ich habe zur Sicherheit neben dem Quartushandbuch auch noch einmal die KI von Google gefragt.
Quartus akzeptiert das Attribut (* ramstyle = "M4K" *) beim Kompilieren für den Cyclone IV (EP4CE6) problemlos.
Die Synthesesoftware ist abwärtskompatibel implementiert und fängt diesen Fall wie folgt ab:
Was Quartus im Hintergrund tut 1. Automatisches Mapping: Wenn Sie für einen Cyclone IV kompilieren und das Attribut "M4K" angeben, erkennt Quartus Ihre Absicht, den Code in dedizierten Speicherblöcken zu platzieren. Es mappt das Attribut automatisch auf die im Cyclone IV physisch vorhandenen M9K-Blöcke um.
2. Keine Fehlermeldung: Es gibt keinen Compiler-Fehler. Höchstens eine dezente Warnung (Warning) im Synthese-Log, dass das ältere Architektur- Attribut auf die neue Struktur angepasst wurde.
Quartus nutzt eine Option die dem ramstyle auto gleichkommt. Andere Synthesetools oder wenn keine RAM Blöcke frei wären würden in letzter Instanz versuchen den Speicher über normale LUTs darzustellen.
Auf meinem Board läuft die Synthese aber vollständig und dennoch erfolgreich ab wie der Compilation Report zeigt.
Family Cyclone IV E Device EP4CE6E22C8 Total logic elements 4,382 / 6,272 ( 70 % ) Total combinational functions 3,574 / 6,272 ( 57 % ) Dedicated logic registers 2,909 / 6,272 ( 46 % ) Total registers 2909 Total pins 20 / 92 ( 22 % ) Total virtual pins 0 Total memory bits 35,328 / 276,480 ( 13 % ) Embedded Multiplier 9-bit elements 20 / 30 ( 67 % ) Total PLLs 1 / 2 ( 50 % )
Die PLL ist im diesem Fall nötig und sollte bei eigenen Versuchen gegen die auf dem Board verbauten Quartzgeber geprüft werden damit die Geschwindigkeit zum DAC mit 10 MS/s und alle anderen Takte der Pipeline erhalten bleiben. Die Cohiradialeute haben hier ein Zeitschlitzverfahren umgesetzt um Ressourcen einzusparen. Sie benutzen immer wieder das gleiche Rechenwerk für die Trägererzeugung, zeitlich aufgeteilt. Im zum Artikel verlinkten Code erzeugt der Oszillator vier Trägerfrequenzen auf einmal, durch die Verteilung auf 10 Zeitschlitze bei 100 MHz PLL Takt kommen so die 40 AM Send
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Die Forensoftware bricht im Text ab, ich muss deshalb hier neu anfangen.
Bei der Cyclone IV Serie habe ich laut Quartus die Möglichkeit bei Speedgrade C8 auch PLLWerte von 150 oder 200 MHz stabil zu erreichen. Würde man diese Idee von Herrn Kirchner und Müller weiter verfolgen, wären unter Beibehaltung der 10 MS für den DAC gar 15 oder 20 Zeitschlitze mit dann 60 oder 80 Kanälen im Synthesizer möglich.
Ich habe es bei meinem Versuch aber bei dem Elektorprojekt mit 40 Kanälen belassen auch um keine Änderungen am Code vornehmen zu müssen was mich mit Sicherheit überfordern würde! Um den Heimsender ansprechen zu können muss man nur noch die Verbindung zum Steuerprozessor herstellen. Im verlinkten Projekt auf der Elektorseite wird die Firmware direkt mit gegeben. Ich konnte sie mit dem Espressifstudio in das ESP32P4 Board einspielen. Das Kommunikationsprotokoll zwischen den Steuerprozessor und FPGA Modulator hat mir Herr Dünk als Link zugeschickt.
Ich habe mir damit eine Datei aufgebaut und konnte so alle Kanäle initialisieren und mit verschiedenen Sendestärken versehen, so wie das die Software von Herrn Scharfetter auch vorsieht.
Zur Erstellung einer Cohiradiadatei kann man jetzt den DAC Ausgang aufzeichnen. In meinem Kopf geht die Vorstellung herum das es noch einfacher ist, direkt die Bussignale zum DAC in umgekehrter Richtung durch ein als Empfänger konfigurierten parliosdr oder smisdr BUS direkt aufzunehmen.
Herr Dünk meinte in der Gruppe sei es geplant, die Richtung und den Übertragungsmodus einmal per Port 5000 einstellbar zu machen. Man behält also den HF Modus wie gehabt bei, kann für I/Q Prozessing in Software oder auf FPGA HAT über Steuerbefehl an Port 5000 umschalten weil nicht jedes SDR für I/Q Modus bereit ist und dieser Modus nur als Erweiterung angedacht sei. Ich fände es toll wenn man in der Firmware noch die Option des Synthesizers aufnehmen könnte. Über ein Steuerkommando könnte dann vom normalen SDR für alle Sende und Empfangsanwendungen wie zum Beispiel Cohiradia, der FPGA Aufsatz zum Cohiradiasynthesizer werden. Die unterschiedlichen Module im FPGA könnten durch ein zusätzliches Enable-Signal von Aufwärts/Abwärtsmischung der I/Q Signale in den Generatormodus wechseln. Oder man kann nach gewählten Modus verschiedene Bitstreams in den FPGA senden oder aus verschiedenen Speicherbereichen des Konfigurationsspeichers laden lassen.
VG Roland
* Ich habe für von mir genutze Hardware oben Links eingefügt. Diese sind beispielhaft als Produktinformation und nicht als Kaufinformation zu verstehen, ich pflege keine Geschäftsbeziehungen zu diesen Händlern. Es gibt mehrere Händler die dieses und vergleichbare Produkte anbieten. Die Preise variieren. Es gibt teilweise günstigere Angebote mit längeren oder kürzeren Lieferzeiten unter 10 Euro. Da die Links nicht anklickbar sind hoffe ich diese Produktangaben für die Administration so in Ordnung gehen. *
<Link zu Elektor aus meinem vorherigen Beitrag> h**ps://www.elektormagazine.de/labs/historischer-rundfunk-zum-budget-preis-der-cohiradiastreamer h**ps://www.elektormagazine.de/labs/am-modulator-on-legacy-fpga-silicon
Die Heimnetzwerkadesse des genutzten parliosdr Boads welches mit dem ESP32P4 aufgebaut wurde ist die 192.168.3.56. Über den Port 5000 nimmt dieses eine Frequenzliste an. Nach dem Protokoll von Herrn Dünk liest sich das entsprechend wie folgt.
Erzeuge Träger auf 153 kHz mit Modulationseingang Port 1234 Erzeuge Träger auf 531 kHz mit Modulationseingang Port 1235 Erzeuge Träger auf 603 kHz mit Modulationseingang Port 1236
Die Obergrenze der erzeugbaren Kanäle bestimmt das synthetisierte Design. Wie ich gestern schrieb habe ich diese bei meinem Nachbau auf 40 Kanäle belassen. Ich benutze in diesem Test zur Modulation das Onlinearchiv rias1.de mit alten Mitschnitten. Die Modulationszuführung erfolgt live über das Internet an die festgelegten Portadressen. Ich benutze die im Steuerprogramm gezeigte Beispielbefehlssequenz, die IP des parliosdr Boards habe ich bei jedem Modulationssignal hinzugefügt.
In diesem Moment bekommt das Cohiradia SDR Board die Daten in Echtzeit von rias1.de , die Tonqualität wird primär durch die Ausgangsqualität des Modulationsmaterials bestimmt, eine gesonderte oder dynamische Trägersteuerung über den dafür vorgesehenen Steuerport habe ich nicht genutzt. Zur Übersetzung in ein analoges Signal habe ich dem Cyclone IV ein Digilent DAC Board mit PMOD Interface angesteckt.
Die Erzeugung der Cohiradiadatei wäre jetzt mit der Software von Herrn Scharfetter möglich, ohne auf die Berechnungen des Wizard warten zu müssen. An der direkten Rücklesung und Generierung der Datei über den ESP32 und FPGA scheint nach letzten Informationen eine Arbeitsgruppe bereits zu sitzen. Auf der Projektseite wird von Aufnahmemöglichkeiten auf SD Karte und USB Massenmedium gesprochen.
DIe Software des Forums hat oben leider etwas von den letzten Befehlen abgeschnitten. Das Prinzip der Modulationszuführung bleibt aber erkennbar.
Re: Historische Breitbandaufzeichnungen von AM-Bändern (Projekt Cohiradia)
Da heute nicht viel zu tun war, habe ich die Elektorartikel tiefgehender betrachtet und versucht das auf meinen Sender gedanklich und praktisch umzusetzen.
Im ursprünglichen System ist der DAC direkt mit dem Host-Board verbunden, ich habe die KI des Betriebssystem für die Erstellung der Bilder genutzt.
Das folgende Diagramm zeigt diese einfache Architektur. Der Host (links) sendet Daten über einen parallelen Bus direkt an den DAC (rechts). Der DAC ist vollständig von den Timing- und Datenraten des Hosts abhängig.
Um Platz für das neue Herzstück, den FPGA, zu schaffen, muss die direkte Verbindung aufgetrennt werden.
Das nächste Diagramm visualisiert diesen Schritt. Der parallele Bus zwischen Host und DAC ist physisch unterbrochen (gekennzeichnet durch die roten 'X' und die Lücke). Die Datenübertragung ist gestoppt, das System ist inoperabel. An dieser Stelle wird die neue Hardware eingefügt.
Jetzt wird der FPGA in die entstandene Lücke platziert.
Das dritte Diagramm zeigt die geänderte Topologie. Der Host ist nun über den Bus (links) mit dem FPGA verbunden. Der FPGA wiederum ist über einen separaten, parallelen Bus (rechts) mit dem DAC verbunden. Dort übernimmt die interne Logik des FPGAs die Verarbeitung der IQ-Daten vom Host und generiert die hochfrequenten Signale für den DAC. Der FPGA ist jetzt der Master für das Timing des DACs.
Um den FPGA an den Host und an den DAC anzuschließen muss jetzt wie beim WaveSynth eine Pin-Datei geschrieben werden.
Bei den Cyclone Chips wird die Intel Quartus Prime Software genutzt.Hier wird eine .tcl (Tool Command Language) Datei benötigt. Beim GoWin ist das eine cst-Datei.
Anmelden
