Posts by Bernhard45

    Wiedermal ein neuer Versuch die nun schon mehrfach aktualisierte COHIWizard Software von Hermann mit fl2k Unterstützung unter Linux zu starten.

    Was hat sich verändert? Wie geht es jetzt?

    Als Ausgangsbasis wieder ein frisches Debian12 (mit installierter fl2k Unterstützung).

    Dieses OS wird mit Python 3.11 ausgeliefert, deshalb musste beim 1. Versuch auch ein wenig der Quellcode zurückportiert werden, Hermann schreibt aber das seine Software im Branch 2.0 (also mit fl2k-Unterstützung) ein Python 3.13 will.

    GitHub - hermy-sf/COHIWizard at cohiwizard_v2.0
    Software for COHIRADIA. Contribute to hermy-sf/COHIWizard development by creating an account on GitHub.
    github.com

    install Python v3.13.0 on your PC; the COHIWIzard may fail with other versions

    Ich bin diesmal den Weg über pipx und uv gegangen, das sind Tools welche erlauben mehrere Pythonversionen bequem (und meist ohne Gefahr) parallel im System zu halten. Die Installation von pipx in Debian geht mit

    sudo apt install pipx

    Jetzt kann man mit pipx noch uv installieren.

    pipx install uv

    Um den Wunsch von Hermann (und seiner Software) nachzukommen, installiere ich jetzt eine virtuelle Python 3.13 Umgebung.

    uv venv --python 3.13

    Python in der angegeben Version wird automatisch aus dem Netz geholt, man muss nichts weiter machen, als im Nachgang der Installation die virtuelle Python 3.13 Umgebung zu aktivieren.

    source .venv/bin/activate

    In dieser Umgebung gehe ich jetzt nach Hermanns Anleitung weiter vor:

    python3.13 –m venv venv

    source venv/bin/activate

    pip install -r requirements.txt (dauert eine Weile !!!)

    cd sources

    python3.13 COHIWizard.py

    fertig

    Diesmal braucht man keine Codeanpassungen an eine eventuell verschiedene Pythonversion zu machen.

    Das war der einmalig auszuführende Installationsweg mit Erststart. Bei allen weiteren Programmstarts reicht es aus in das Programmverzeichnis von COHIWizard zu wechseln und dort zunächst die virtuelle Umgebung zu starten,

    source venv/bin/activate und danach das Programm selbst

    python3.13 COHIWizard.py


    Bei Bedarf kann ich eine kleine Live Cohiradia Linux Distribution erstellen, wo bereits alles installiert und aufrufbereit ist. Dieses ISO-Abbild könnte auf einen USB Stick "gebrannt" werden und kommt ohne Installation auf einem PC aus. Reinstecken -> Booten -> Cohiradia senden.

    Schöne Osterfeiertage

    Bernhard

    mir fehlen noch die Fähigkeiten.

    Die kommen von ganz allein! Einfach in die verschiedenen Projekte mal reinriechen, Democode anschauen und so wachsen die Fähigkeiten Stück für Stück. An einem Punkt angekommen, macht dir das Verknüpfen unterschiedlicher Libs (und dann auch der VS1053) keine Probleme mehr. Oder du nimmst eines der vielen Internetradioprojekte da draußen, die neben dem Softwarecodec auch auf den VS1053 "umschalten" können. Da gab es in der Vergangenheit ja auch einiges was Einsteigerfreundlich (in der Regel also wohl mit Arduino IDE) zu bezeichnen ist. Plattform I/O oder direkt das ESP-IDF/ADF + FreeRTOS wie bei unserem iRadio für ESP32 ist da schon wesentlich komplexer in der Einrichtung und natürlich auch im Verstehen/Abändern des Codes.

    Zum VS1053 gab es hier im Forum schon einiges, auch kleine Testprogramme mit denen man schon Internetradio hören kann! Da kann man ansetzen, dann ein Display mit eigener GUI dran, dann eine bessere Senderverwaltung dran, ... und so entsteht Stück für Stück dein eigenes Internetradioprojekt, frei vom Ballast den viele andere Projekte und Baukästen mitbringen (müssen) um möglichst viele Anwendungsgebiete abdecken zu können.

    Bleibe dran Günter und hier im Forum findest Du bestimmt auch genug Support wenn mal etwas umgeschrieben werden muss oder wenn man Code lesen muss.

    Ein Display mit Core0 ist kein gute Idee und wird den Fehler noch verschlimmbessern. Dieser kümmert sich unter anderem um die WiFi Geschichten

    Der Core0 hat natürlich diese "Spezialaufgabe" und man muss aufpassen das man dort nicht diese Aufgabe blockiert.

    Das allgemein kein Display auf Core0 laufen kann oder das das keine gute Idee ist, ist jedoch so allgemein verfasst nicht richtig! Der Core0 hat noch genügend Spielraum für ziemlich viele Aufgaben und auch kleine nicht ganz so aufwendigere GUIs und Bedienkonzepte. Das kommt natürlich ganz auf die Implementierung dieser Aufgabe an (wieviele fps reichen zum Beispiel aus)! Aber eine aufwendige Skalensimulation oder Cassettensimulation mit 20+ fps wie bei den iRadios möglich, kann schon schiefgehen, muss aber nicht, wie auch schon bewiesen! Hier im Fall ist aber kein grafisch aufwendiges Konzept zu sehen, sondern eher was 0815-mäßiges. Ob und wie gut/schlecht das im verwendeten Code umgesetzt wurde, wie (unnötig) schnell das Display beschrieben wird, muss man sehen. Wahrscheinlich wurde sowieso alles auf Core0 geklatscht und wenn man dort die technisch rechenintensivste Aufgabe (den Codec) wegnimmt, macht WiFi/Display/Bedienung nicht mehr, sondern erstmal weniger Probleme. Ein Refactoring und Entmüllen ist also natürlich immer gut! Die 320k und viel mehr schafft das WiFi grundsätzlich erstmal auch, ob das aber in jedem Fall (also auch auf einem komplett leergeräumten Core) immer durch jeden Softwarecodec/dekoder geht, steht auf einem anderen Blatt! Da gibt es ziemliche Unterschiede in den Benchmarks. Manche Umsetzungen liegen bei 192 kBit schon an der Grenze, während andere mit höhreren Datenraten auf der gleichen HW keine Probleme haben, zum Teil unterscheidet sich das schon bei verschiedene Versionen eines Softwarecodecs. Da muss man pro-aktiv selbst mal ran und prüfen / testen, optimieren bis man ein geeignetes Setup hat.

    Hallo Günter,

    da kann man verschiedene Sachen und Problemlösungen betrachten.

    Wenn es rein um die Datenrate des Streams geht, muss man schauen was der verwendete Softwaredekoder überhaupt kann.

    Ich glaube das ist die Audiolib von https://github.com/earlephilhower/ESP8266Audio die da verwendet wird? Viele Softwaredekoder sind da halt nach oben hin etwas limitiert. Eventuell kann ein anderer Softwaredekoder optimaler arbeiten und bekommt auf dem ESP32 bessere Datenraten hin, dann kann man den Dekoder tauschen.

    Man muss auch mal schauen wie der ESP32 initialisiert wird. Vielleicht wurde sein Clock nur auf 160 MHz statt 240 MHz gesetzt? Dann kann man dort noch die Taktrate hochsetzen.

    Der ESP32 ist auch ein Dualcore, aber die meisten Sketches da draußen nutzen das nicht und lassen alles nur auf einem Core laufen! Hier kann man händisch im Programm aufräumen und sagen Core0 macht alles mit Netzwerk und vielleicht Display, Tastenabfrage usw. und Core1 bekommt den Softwaredekoder der von Core0 mit den Daten über einen Puffer gefüttert wird, oder man denkt sich eine andere Aufteilung auf die die Last besser verteilt. Es macht keinen Sinn, wie bei vielen Sketches aber umgesetzt, alles nur auf Core0 laufen zu lassen und ein Kern hat gar nichts zu tun. Nutzt man schon beide Cores kann man dennoch händisch sortieren und Tasks fest an bestimmte Cores binden.

    Was am Besten bei hohen Datenraten funktioniert, ist aber ein kleiner externer Hardwaredekoder (eigener DSP mit hochoptimierten Dekodern im ROM des ICs) wie VS1053b oder seine Nachfolger. Dann muss man im Quellcode des Radios statt der Datenweiterleitung an den Softwaredekoder nur eine Umleitung auf eine VS1053-Lib machen (sind mit Buffer füllen/senden nur wenige Zeilen Code, genug Beispiele im Netz und hier im Forum). Das dekodierte Audio kann dann Analog vom VS1053 abgenommen werden oder über I2S einen externen DAC/Amp durchgereicht werden.

    Viele Grüße

    Evtl hat ja jemand etwas detailierteres darüber.

    Was genau denn?

    Hinsichtlich der verbauten Hardware (Si4732, den man heute auch in vielen sehr günstigen bis mittelpreisigen Radios/Weltempfänger findet, hier aber durch Software gepatched/aufgebohrt wurde) oder wo die oder alternative Firmware herkommt bzw. was die kann?

    Welcher Dekoder was macht und wo man passende Aussendungen findet?

    Ich habe das Ding in den Verkaufsplattformen auch drin, biete es aber auch im im Forum an.

    Verkaufe also ein Starlink UFO ("Dishy") der Version 1, komplett , Router, Kabel usw. in Originalverpackung. Vom Umfang wie das Ding die heiligen Hallen von Musk verlassen hat. Das Set ist von meinem Vertrag entregistriert und kann sofort nach Erhalt auf einen neuen Vertrag registriert werden.

    Die Tarife könnt Ihr direkt auf starlink.com einsehen und dort auch monatsweise buchen. Ich verkaufe die V1 ( technisch in Ordnung), weil ich auf die neuste Miniantenne gegangen bin, die in meinem Alter doch wesentlich einfacher zu transportieren ist und der Datendurchsatz von gut 100 MBit/s mir damit absolut ausreicht. Die großen Antennen schaffen mehr Durchsatz, sind aber auch schwerer und verbrauchen mehr Strom. Testweise kann ich sagen das beide Systeme auch noch knapp unter einer GFK Abdeckung (Boot, Wohnmobildecke) funktionieren. Ansonsten auf die Terasse oder Wiese legen und loslegen.

    Im Forum etwas günstiger, ich würde 70 Euro inklusive DHL Paketversand haben wollen. Zahlung mit Paypal und nur an Leute die hier nicht gerade frisch registriert sind und als Kaufanfrage gleich ihren ersten Beitrag schreiben.

    Schickt mir bitte direkt eine Mail falls Interesse besteht.


    <hat sich bereits erledigt>

    Das habe ich gelesen, er schreibt aber auch das die DTMF gar nicht zum Einsatz kommen soll, da Festfrequenzen über eine Schalter ausgewählt werden. Also hat er gar keine CPU Probleme, die deinen vorgeschlagenen Umbau auf R2R rechtfertigen oder gar zu ultimativen Performancesteigerungen führen würden!

    Wenn er die DTMF Erkennung einbaut, müsste man nur mal schauen wo und wie unglücklich beide "Tasks" miteinander verschachtelt sind damit die gegenseitig blockierende Wirkung den Piloten frequenzmäßig nicht (auf 5Hz!!!) absinken lässt. Das Problem hätte er dann nämlich auch beim R2R auf dem Port, also keine Vorteile bei deinem gemachten Vorschlag. Auf der anderen Seite, wenn einem die Trennung beider Tasks zu viel Mühe macht, ist es auch kein Problem wenn der Pilot für die Zeit der Frequenzumstellung ausfällt oder deaktiviert wird und nach Neueinstellung durch DTMF wieder angeworfen wird. Bei dauerhaft möglicher Frequenzänderung durch DTMF könnte man in einen weniger fordernden "Detektormodus" wechseln und erst dadurch eine DTMF Dekodierung triggern.

    Einzig der Rechteckweg (also ganz ohne DAC) bringt da viel weniger Verbrauch und Kontextwechsel, ob die Dekoderlib mit dem Interrupt klar kommt müsste sowieso untersucht werden!

    Ich denke also das ist weniger ein Problem der DAC-Art der Erzeugung der "popeligen" 25 Hz, da alle hier umgesetzen und genannten Wege möglich sind und CPU mäßig fast das gleiche kosten, sondern eher wie man die Aufgaben sauber getrennt und sich nicht gegenseitig beeinflussend in einen Core bekommt! Man kann auch locker zwei so simple LED-Blinkeraufgaben (eine LED alle 1s die andere alle 500ms) so blöd miteinander verschachteln, das zum Schluss alles rauskommt, nur nicht ein Blinken einer LED alle 1s und die andere alle 500ms! ;) Und so ein 8Bit AVR kann mehr machen als sich manche vorstellen. Jedenfalls sollte er nicht bei den in Semirs Projekt gestellten Aufgaben (auch mit dauerhafter DTMF + egal mit welchem DAC 25 Hz Pilot erzeugt wird) scheitern, wenn er auch viel aufwendigere Signalverarbeitung als SDR Basisbandprozessor hinbekommt.

    Semir wie ich sehe erzeugt Dein Arduino auch noch das PWM Signal für den Piloton. Das ist nicht die beste Idee. Es sind genug Anschlüsse frei. So könnte man sich die Anschlüsse D0 bis D7 frei machen und als ganzen Port digital ansprechen. Außen dann über Widerstände ein D/A Wandler machen.

    Dann hat man einen 8 bit Sinus ohne große Prozessorlast und ohne den Datensalat, den PWM erzeugt.

    Macht Semirs Implementierung denn eine Software-PWM? Ansonsten läuft die PWM doch sowieso mit einem Hardwarecountermodul der erstmal ohne Prozessorlast auskommt. Wenn der Prozessor jetzt mit mehreren MHz getaktet ist, braucht er bei 25 Hz Pilot gefühlt nur alle Ewigkeiten mal einen LUT-Wert in ein Register schreiben um einen sehr fein aufgelösten Sinus mit per Software einstellbaren Pegel zu bekommen. Beim R2R DAC über 8 Ausgänge, muss er im gleichen Abstand auch nur einen Wert in das Portregister schreiben.

    Also PWM zu R2R DAC , beides mal ein Registertransfer eines LUT-Wertes. Da wird man keinen großen Unterschied in der Prozessorlast haben. Auf der anderen Seite, wenn ich mir Semirs verlinktes Projekt anschaue, nach dem Init des DDS, hin- und wieder mal schauen welche Sendefrequenz eingestellt werden soll (selbst wenn man das 10 x die Sekunde macht), was fällt denn da für große Last im Controller an? Für den Piloten alle paar tausend Takte ein Registertransfer. Der Käfer macht doch die meiste Zeit sonst nichts anderes als NOP.

    Mein Hauptproblem bleibt aber noch die 'zerhackte' Wiedergabe einiger Sender (Buffer-Problem?). Hat hier noch jemand eine Idee?

    Beste Grüße, Günter

    Wenn das ziemlich gleichförmige, regelmäßige Aussetzer sind, können das auch nicht vollständig entfernte Metadatenchunks sein, die der Server sendet um zum Beispiel Sendernamen und Titel des aktuellen Stücks zu übertragen.

    Deine Fotos zeigen ja das die Funktion im Radio vorhanden ist, also fragt dein Radio beim Server mit einer Option an, die den Antwortdatenstrom fragmentiert. Der Audiodatenstrom wird also immer mal wieder mit Metadaten gespickt und die dürfen nicht auf den eigentlichen Codec kommen, sondern müssen vorher entfernt werden. Es reicht aus wenn ein oder zwei Bytes eines solchen Metadatenchunks durchkommen, vielleicht weil eine falsche Länge des Chunks ermittelt wurde oder deine Software nur eine Untermenge von Tags erkennt und andere nicht, die dann zum Codec durchlaufen weil sie nicht entfernt wurden.

    Im Forum wird das an verschiedenen Stellen genauer beschrieben, Suchfunktion liefert zum Beispiel das.


    Man kann den Header der Anfrage einfach dahingehend verändern, daß der Server die Anweisung bekommt, keine Metadatenchunks mitzusenden sondern nur den reinen Audiostream. Dann aber bekommt man auch keine Infos zur aktuell gesendeten Musik. Im anderen Fall muss man die genutzte Software erweitern, daß die auslösenden Chunks erkannt und vor dem Audiodekoder entfernt werden.

    Du kannst über die Serielle Schnittstelle eines ESP32 sowohl den Request mit vollständigem Header, also auch die Serverantwort live mitschneiden lassen und mit einem Terminalprogramm auf einem PC in eine Datei schreiben lassen. Wenn das Problem auftritt, kannst du die Aufzeichnung abbrechen und mit einem Hexeditor alles nach diesen Chunks untersuchen und beheben.

    Servus Jens,

    die Modulationsstufe kann ich aber noch nicht entdecken - oder habe ich Tomaten auf den Augen?

    Grüße vom Günter

    Das ist bei dem 9833 natürlich unglücklich, der kann die Modulation nur extern.

    Mit dem 32/35 (34 glaube auch), den 50/51 kannst Du über einen Pin des Chips auch eine sehr gute AM Modulation direkt im Chip machen lassen.

    Da die DDS Family nur ganz geringe Unterschiede in der Ansteuerung hat, könnte man im Controller gleich die Ansteuerung für die ganze Familie unterbringen und dann über ein Setupmenü den passenden DDS-Chip auswählen, den man ranhängen möchte.

    hm….weiß nicht…da ist doch ein 2Mhz DDS Modul viel flexibler? Nur des Sinus wegen? Das kann jedes 30 Euro DDS Modul und das sogar recht gut. Da braucht man auch nix programmieren, 5Volt und schon läuft das Teil wie hulle!

    Hmm, 2MHz DDS Modul? Warum für sowas 30 Euro ausgeben? Die ganze 98xx Family ist als Chip spukebillig, eine Typen als Sample sogar kostenlos bei Hersteller beziehbar, können weit mehr als 2 MHz fmax, meist mehrere Signalformen und auch interen Modulation und Programme dafür gibts fertig so das man - wenn man nicht programmieren kann - auch nicht muss.


    , aber falls man die Schaltung für einen Empfänger nutzen möchte,

    Als Lo für den Empfängerbau oder die Umrüstung auf genaue digitale Abstimmung sind diese Module sehr gut brauchbar, allerdings ist das hier nur die halbe Miete. Man sollte im Controller noch eine Abstimmspannung (die dann extern auch auf größere Werte gezogen werden kann) für den Vorkreis vorsehen, um damit eine Varicap anzusteuern. Alternativ geht auch eine Schrittmotorsteuerung (mit Erfassung der Endpositionen) für eine Drehkoabstimmung, Beispielsweise wie im Grundig Satellit. So oder so wird dann aber entweder auch noch ein Kalibriermodus nötig:

    from Bandanfang to Bandende with Schrittweite___

    Lo einstellen,

    Vorkreis auf max Empfindlichkeit,

    speichern

    Alternativ kann man auch eine Automatik einbauen, aber dann muss man wieder einen Pegel messen.


    In der Ausbaustufe wie es jetzt ist, ist es als BFO brauchbar.

    PiFM Projekt und das läuft ganz gut, allerdings FM und AM simuliert der Pi wie eine Katze.

    Das kommt sicher ganz darauf an, welche Methode man im Pi verwendet und mit welcher Methode man moduliert und wie die Signalrekonstruktion und mit welchem Filteraufwand erfolgt.


    Grüße

    Bernhard

    Um mehr Bits zu bekommen und einen weiteren fl2k Ersatz zu haben, könnten einige dieser Boards hilfreich sein, schaut mal.

    Ich habe gerade fast 3 Wochen Gartenarbeit mit 4 Mitarbeitern einer Gartenbaufirma hinter mir um meinen kleinen Park hinter dem Haus wieder auf Vordermann zu bringen. Das habe ich gut 2 Jahre schleifen lassen, früher hatte meine Frau ein Auge drauf gehabt. Jetzt ist noch der Springbrunnen und die Bewässerungstechnik dran und nach der Schlafenszeit waren natürlich die Pumpen und Ventile arbeitsscheu und leider will die S7 auch nicht mehr, so daß ich kurzerhand ein solches Board dafür hernehme um das wieder zu automatisieren und die alte Siemens kommt raus.

    Durch die Datenblätter motiviert habe ich mal einen kleinen Durchsatztest gemacht und der 100 MBit-Ethernetport scheint gut für Cohiradia zu funktionieren. Man könnte auch USB2 nehmen, was wohl mehr Bandbreite bietet, aber dann muss man wieder ein Zwischenprogramm mit libusb haben. So kann man direkt an eine IP streamen, fertig, das gefällt mit mehr.

    Mit dem verbauten ADC würde man, bei vielleicht 5 MSPS direkt aus GNU Radio oder dem Wizzard rausgehen können, was für MW ausreicht. Und das Schöne ist, man könnte den Datenfluss auch umdrehen, dort also mit 12 Bit digitalisieren, hätte also einen Empfänger um die MW breitbandig aufzeichnen zu können.

    Also 12 Bit Wiedergabe und Recording auf einem Board.

    Die Preise sind, ich habe mal bei Mouser den Filter für diese Nucleo-Klasse gesetzt, auch akzeptabel denke ich. Jetzt das aber, es gibt zwar einen Arduino Core für die STM32 aber der ist wohl nicht für alle Boards komplett umgesetzt, man müsste die Programmierung über die CubeIDE machen, so wie ich das jetzt für meine Automatisierung schon erledige. Die IDE ist aber ein anderes Kaliber als die Arduino IDE und ich habe keine Ahnung wie attraktiv das dann noch für die Radiobastlergemeinde ist.

    Man könnte auch für verschiedenen Boards fertige Images machen, aber die Programmierung geht halt auch wieder ein bisschen anders und macht die Sache vielleicht wieder für die Hobbygemeinde uninteressant.

    Die Mehrkanalvariante braucht mehr CPU/RAM/alles.

    Wird halt nicht nur ein 10 MSPS Buffer übertragen, sondern gleich 2 oder 3 davon. Vergleichbar mit zwei fl2k-Dongeln (bekommen am USB dann unterschiedliche Devicenummern) und zwei separat gestarteten fl2k-Einkanalversionen der Datenübertragungsprogrammen.

    Da wird aus 80 MBit/s dann schnell 160 oder 240 MBit/s in der Generierung und im Transfer. Das muss der PC und die Schnittstelle in Echtzeit schaffen, sonst klappt es nicht.

    Der Pi sampelt, meine ich, nur bis 192khz. Egal was du da auf den Gpio steckst. Aber, da wäre das PiFM Projekt und ich müsste mal schauen wie weit es runter geht.

    Über Hardware (die PiFM oder rpitx nutzt), geht der Frequenzbreich 5 kHz bis 1500 MHz und das mit einem maximal 250 kHz breiten Signal. Das kann also ein schmaler Träger sein, über FM oder auch Schmalband DTV (DVB) oder was man sich ausdenkt.

    Und nur über ausgewählte GPIO.

    Über die restlichen GPIOs kann man Bitbanging bis in einen zweistelligen MHz Bereich machen. So ging halt auch ein R2R DAC für Cohiradia wie ich ihn im Forum neulich gezeigt habe.

    Wenn der das macht dann wäre ja alles gut. Das machen aber die meisten Frequenzzähler nicht.

    Da habe ich bei den verbreiteten Modulen eigentlich genau das 100% ige Gegenteil erlebt!

    Irgendwie konnte man immer, entweder per Drahtbrücke oder über eine 1-Taster Bedienung eine vorprogrammiert ZF oder ein externes Testsignal als ZF +/- reinmorsen / programmieren. Die Funktion (oder das Menü) mag oft nicht dokumentiert sein, oder nicht in allen übersetzten Anleitungen enthalten, aber eine Suche im Netz zeigte in den Fällen dann doch die Lösung.

    Das NF Signal kommt aus einem PCM5122 der brav auf einem Pi sitzt. Das lässt sich dann auch über einen digitalen Limiter gut begrenzen. Das analoge Signal ist bei mir ein Abfallprodukt und da wäre die Möglichkeit einer Spiegelung von einem Sender auf einem alten AM Empfänger zwecks Demonstration super.

    Also lass das nicht zu weit ausufern. Ich wollte doch nur wissen, ob man auf einem kurzen Dienstweg das Teil auch mit einem Quarz ausbauen könnte.

    Klar geht das Klaus mit dem Quarz. Wenn da aber sowieso ein Pi davor hängt, kann der Pi auch den "Quarz" direkt spielen oder simulieren und sogar abstimmbar sein. NF-Signal kommt dann aus PCM5122.

    Wenn der Gedanke etwas weiter geht und man mehr will und der PCM5122 die komplette Samplingbandbreite von 384 kHz zulässt, könnte man ein schmales Basisbandstückchen mit mehreren AM Sendern durch den PCM5122 erzeugen und über den oben gezeigten Sender/Mischer aus deinem Eingangspost in den Mittelwellenbereich verschieben. Die Verschiebefrequenz bzw. der Lokaloszillator wird hier wieder durch den Pi selbst bereitgestellt. Du hast also schon ein richtig kleines universelles AM-Senderchen, welcher neben deinem Vorhaben dann später, wenn man will und der Anspruch wächst, leicht 5 bis 6 AM Sender bzw. Programme im Mittelwellenbereich erzeugen könnte. :thumbs_up: Wenn der Pi eine V4 ist, ginge sogar Cohiradia. Dann aber nicht mehr mit PCM5122, sondern mit einem anderen DAC.

    Das kann sein Günter, das ist der Preis für die Flexibiliät. Wenn jedoch das Sendematerial sowieso auf einem Rechner vorliegt, ist das kein Hinderungsgrund. Beim den DDS-ICs braucht man nur einmal einen Rechner, nämlich zum Überspielen der fertigen Programme in einen Controller, danach kann auch die alte Tonbandmaschine am Sender hängen und nichts anderes.