FAQ zum iRadio

[saarfranzose]

ich wollte mal etwas schreiben zum Thema "älteres image". Ich habe mir, vor allem wegen den Alsa-Problemen, bei meinem letzten iRadio dieses Image rausgesucht:


  older-version1.PNG (Größe: 25,45 KB / Downloads: 550)

mit dem Kernel 4.19.66-v7+

die iRadio Installation scheiterte erst mal mit dieser Meldung (auch nach mehrmaligem Durchlauf):

   

nach entsprechender Recherche konnte ich das Problem mit

autoreconf -f -i

im Ordner iRadio/bcm2835-1.68

und anschliessendem Ausführen von:

./configure
make
make check
make install

entsprechend einem alten Hinweis von Bernhard beheben.

Ich baute dann eine x11-Simulation und stellte fest dass diese extrem langsam lief. Kein Wunder, ich musste ja auch den Legacy Treiber benutzen. Mit dem KMS bzw. fake KMS läuft fbcp-ili9341 nicht, und den brauchte ich für das kleine SPI-Display. Mit KMS-Treiber meldete der HDMI Bildschirm "ausserhalb Betriebsbereich" unabhängig von der eingestellten Auflösung, das SPI-display blieb dunkel.

Ich habe dann ein rpi-update durchgeführt auf den Kernel 5.10.25+. Der Fehler blieb der gleiche.

Es erfolgte eine Neuinstallation mit dem aktuellen Raspberry OS. Es gab keine Probleme oder Abbrüche. Die x11-Simulation läuft gewohnt flüssig. Natürlich hatte ich mal wieder keinen Ton auf der Klinkenbuchse. Das konnte ich aber fixen durch Anlegen einer  /etc/asound.conf und dem Eintragen der mit aplay -l ermittelten card nr. für die Klinkenbuchse. Also die gleiche Vorgehensweise wie bei der Installation einer USB-Soundkarte.

Nach dieser Erfahrung kann ich ein älteres image speziell im Zusammenspiel mit fbcp-ili9341 nicht mehr empfehlen.

[Bernhard45]

die iRadio Installation scheiterte erst mal mit dieser Meldung (auch nach mehrmaligem Durchlauf):


nach entsprechender Recherche konnte ich das Problem mit

autoreconf -f -i

im Ordner iRadio/bcm2835-1.68

und anschliessendem Ausführen von:

./configure
make
make check
make install

entsprechend einem alten Hinweis von Bernhard beheben.

Hallo Jupp,

den entscheidenden Hinweis auf eine dem Image beiliegende, aber veraltete, aclocal hättest Du ein paar Zeilen weiter oben in deiner Consolenausgabe gehabt, somit leider nicht im Bild. Zum Compilieren der BCM2835 (siehe iRadio-Update vom 09.12.2020 ) wird eine aclocal Version 1.16 gefordert, dein ausgewähltes altes Image hat aber wohl nur noch die Unterstützung für eine 1.14 oder 5? Dann wird die BCM2835-Bibliothek nicht compiliert und es erscheint dieser Fehler! Mit einem Raspbian kurz vor dem Switch auf Pulseaudio sollte die Installation ohne zusätzliche Handarbeit aber durchlaufen, auf dem neuen Raspberry Pi OS sowieso. Alternative, checke eine Version des iRadios vor dem BCM2385 Update vom 09.12.2020 aus, die noch ältere Images unterstützt und auf diesen getestet war.

Es erfolgte eine Neuinstallation mit dem aktuellen Raspberry OS. Es gab keine Probleme oder Abbrüche. Die x11-Simulation läuft gewohnt flüssig. Natürlich hatte ich mal wieder keinen Ton auf der Klinkenbuchse. Das konnte ich aber fixen durch Anlegen einer  /etc/asound.conf und dem Eintragen der mit aplay -l ermittelten card nr. für die Klinkenbuchse. Also die gleiche Vorgehensweise wie bei der Installation einer USB-Soundkarte.

Schaue mal hier, andere nervt der Pulseaudio-Switch auch, deshalb schmeißen viele Pulseaudio so wieder runter.

https://boffinpanda.wordpress.com/2020/0...ulseaudio/

Ob das wirklich zuverlässig funktioniert habe ich noch nicht getestet, aber an vielen Stellen im Netz wird das als erfolgreich beschrieben. Ob das nach einem händischen dist-upgrade dann immer noch so ist? Sollte eigentlich.

Nach dieser Erfahrung kann ich ein älteres image speziell im Zusammenspiel mit fbcp-ili9341 nicht mehr empfehlen.

Hast Du fbcp-ili9341 direkt aus den Quellen compiliert?

https://github.com/kpishere/fbcp-ili9341
https://github.com/juj/fbcp-ili9341

Wenn ja, welche Build-Optionen wurden gewählt, da gibt es einiges zu beachten!

PHP-Code:

Specifying display speed
To get good performance out of the displays, you will drive the displays far out above the rated speed specs (the rated specs yield about ~10fps depending on display). Due to this, you will need to explicitly configure the target speed you want to drive the display at, because due to manufacturing variances each display copy reaches a different maximum speed. There is no "default speed" that fbcp-ili9341 would use. Setting the speed is done via the option

-DSPI_BUS_CLOCK_DIVISOR=even_number: Sets the clock divisor number which along with the Pi core_freq= option in /boot/config.txt specifies the overall speed that the display SPI communication bus is driven at. SPI_frequency = core_freq/divisor. SPI_BUS_CLOCK_DIVISOR must be an even number. Default Pi 3B and Zero W core_freq is 400MHz, and generally a value -DSPI_BUS_CLOCK_DIVISOR=6 seems to be the best that a ILI9341 display can do. Try a larger value if the display shows corrupt output, or a smaller value to get higher bandwidth. See ili9341.h and waveshare35b.h for data points on tuning the maximum SPI performance. Safe initial value could be something like -DSPI_BUS_CLOCK_DIVISOR=30.
Specifying the target Pi hardware
There are a couple of options to explicitly say which Pi board you want to target. These should be autodetected for you and generally are not needed, but e.g. if you are cross compiling for another Pi board from another system, or want to be explicit, you can try:

-DSINGLE_CORE_BOARD=ON: Pass this option if you are running on a Pi that has only one hardware thread (Pi Model A, Pi Model B, Compute Module 1, Pi Zero/Zero W). If not present, autodetected.
-DARMV6Z=ON: Pass this option to specifically optimize for ARMv6Z instruction set (Pi 1A, 1A+, 1B, 1B+, Zero, Zero W). If not present, autodetected.
-DARMV7A=ON: Pass this option to specifically optimize for ARMv7-A instruction set (Pi 2B < rev 1.2). If not present, autodetected.
-DARMV8A=ON: Pass this option to specifically optimize for ARMv8-A instruction set (Pi 2B >= rev. 1.2, 3B, 3B+, CM3 or CM3 lite). If not present, autodetected. 


schnell ist da was falsches gewählt (oder es steht etwas suboptimales im Buildscript des Treiberpakets welches dem Display mitgegeben oder bezogen wird) und auch was DMA angeht kann man viel Leistung verschenken

PHP-Code:

-DUSE_DMA_TRANSFERS=OFF: If specified, disables using DMA transfers (at great expense of lost CPU usage). Pass this directive if DMA is giving some issues, e.g. as a troubleshooting step if something is not looking right.
-DDMA_TX_CHANNEL=<num>: Specifies the DMA channel number to use for SPI send commands. Change this if you find a DMA channel conflict.
-DDMA_RX_CHANNEL=<num>: Specifies the DMA channel number to use for SPI receive commands. Change this if you find a DMA channel conflict. 


Der fbcp-ili9341 existiert ja schon länger, also auch zu Zeiten älterer Images und lief damals auch schnell. Warum sollte das jetzt nicht mehr so sein?

Gruß
Bernhard

[saarfranzose]

Hast Du fbcp-ili9341 direkt aus den Quellen compiliert?

https://github.com/kpishere/fbcp-ili9341
https://github.com/juj/fbcp-ili9341

ich benutze den 2. von dir angegbenen link und folgende Parameter:

cmake -DSPI_BUS_CLOCK_DIVISOR=40 -DWAVESHARE35B_ILI9486=ON -DUSE_DMA_TRANSFERS=OFF -DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON -DSTATISTICS=0 ..

mit aktiviertem DMA hatte ich noch kein Glück. Beim divisor dürfte auch noch Beschleunigungspotential stecken. ABER: es geht nicht um die Geschwindigkeit der Displayspiegelung, sondern erst mal um die Geschwindigkeit des zusätzlich angeklemmten (oder auch NICHT angeklemmten) HDMI-Monitors. Meine Erklärung für den Geschwindigkeitseinbruch ist der legacy-mode. Der Treiber fbcp-ili9341 kann ja nicht schneller laufen als das HDMI-Signal mit dem er gefüttert wird. Ansonsten gibt mein Bericht die live von mir gemachten Erfahrungen wieder die ich so detailliert wie möglich dokumentiert habe.

Code:

Zum Compilieren der BCM2835 (siehe iRadio-Update vom 09.12.2020 )

wo in der Welt in diesem Zeitraum über iRadio geredet wurde weiß ich nicht. Im RBF jedenfalls nicht. Ich bin froh dass es jetzt wieder ein paar Informationen gibt und ich ein bisschen was aufarbeiten kann.

Wenn ich aclocal im RBF suche sehe ich dass der Begriff heute erstmalig aufgetaucht ist. Vermutlich hätte ich github mehr im Auge behalten sollen. Okay, mein Fehler.

Soviel mal für heute.

[Bernhard45]

Guten Morgen Jupp!

Hast Du fbcp-ili9341 direkt aus den Quellen compiliert?

https://github.com/kpishere/fbcp-ili9341
https://github.com/juj/fbcp-ili9341

ich benutze den 2. von dir angegbenen link und folgende Parameter:

cmake -DSPI_BUS_CLOCK_DIVISOR=40 -DWAVESHARE35B_ILI9486=ON -DUSE_DMA_TRANSFERS=OFF -DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON -DSTATISTICS=0 ..

mit aktiviertem DMA hatte ich noch kein Glück. Beim divisor dürfte auch noch Beschleunigungspotential stecken.

Danke, das werde ich mal durchspielen und schauen wo wir hier die optimalen Leistung rauskitzeln können.

ABER: es geht nicht um die Geschwindigkeit der Displayspiegelung, sondern erst mal um die Geschwindigkeit des zusätzlich angeklemmten (oder auch NICHT angeklemmten) HDMI-Monitors.

Nein DMA hat hier auch nichts mit der Geschwindigkeit der Displayspiegelung zu tun!

Code:

Zum Compilieren der BCM2835 (siehe iRadio-Update vom 09.12.2020 )

wo in der Welt in diesem Zeitraum über iRadio geredet wurde weiß ich nicht. Im RBF jedenfalls nicht. Ich bin froh dass es jetzt wieder ein paar Informationen gibt und ich ein bisschen was aufarbeiten kann.

Wenn ich aclocal im RBF suche sehe ich dass der Begriff heute erstmalig aufgetaucht ist. Vermutlich hätte ich github mehr im Auge behalten sollen. Okay, mein Fehler.

Ja Jupp, einige Leute des iRadios sind nicht im RBF, sondern in anderen Foren unterwegs. Deshalb erscheinen hier auch nicht immer alle Änderungen! Ausschlaggebend ist die Webseite des iRadios.

   

dadurch ergibt sich

   


Bei der Version vor dem 09.12.2020 war die BCM2835 noch in der Version 1.57 vertreten und die konnte man noch mit einer älteren Version von aclocal bauen. So gesehen gibt es auf dem Github nicht nur eine Version des iRadios, sondern mehrere zeitliche Versionen, die man auch alle einzeln auschecken kann. Sollte man das nochmal ausführlich erwähnen und wie es geht?

Bitte probiere auch nochmal aus ob Du auf dem neuen Raspberry Pi OS Pulseaudio so zurückbauen kannst:

$ sudo apt-get remove pulseaudio

$ sudo apt autoremove

$ sudo /etc/init.d/alsa-utils reset

$ sudo reboot

bei mir hat es jetzt auf einem 4er sehr gut funktioniert und man bekommt über HDMI sofort das Audio wieder auf Klinke. Könnte man ja schnell in ein Script packen...

Gruß und einen schönen Tag
Bernhard

[saarfranzose]

nach Ausführen dieser Anweisungen:

$ sudo apt-get remove pulseaudio

$ sudo apt autoremove

$ sudo /etc/init.d/alsa-utils reset

$ sudo reboot

und dem Löschen der /etc/asound.conf

hatte ich kein Bild mehr auf dem SPI-Display. Ich musste fbcp-ili9343 neu bauen, dann war das Bild wieder da. Die Klinkenbuchse lieferte keinen Ton mehr, auch nicht nach Aktivierung mit raspi-config. Erst nachdem ich die asound.conf wieder einspielte.

[mdat69]

Hallo,

ich brauche mal wieder eure Hilfe. Ich versuche gerade ein Nooelec NESDR SMArt v4  für den DAB Empfang zu installieren.
Aber irgendwie bekomme ich kein Signal. Das Scripts install_dabservices.sh habe ich durchlaufen lassen auch build.sh ebenfalls.
Die erzeugte dabd bleibt die jetzt in den Ordner /home/pi/iRadio/Tuner/DABplus  oder muss die auch in /usr/bin kopiert werden?

Mfg

[Bernhard45]

Hallo,

Hallo!

ich brauche mal wieder eure Hilfe. Ich versuche gerade ein Nooelec NESDR SMArt v4  für den DAB Empfang zu installieren.
Aber irgendwie bekomme ich kein Signal.

1. Treiber für das SDR installiert?
2. Bandpassfilter für VHF-Band III installieren! Wichtig!
3. halbwegs brauchbare Antenne für VHF-Band III, die üblicherweise mitgelieferten Stummelantennen sind praktisch nur im Nahbereich (<5km) zum Sender brauchbar.

Bei diesen einfachen SDRs immer dran denken das hier mit nur 8 Bit digitalisiert wird. Entsprechend niedrig ist der Dynamikbereich!

Das Scripts install_dabservices.sh habe ich durchlaufen lassen auch build.sh ebenfalls.
Die erzeugte dabd bleibt die jetzt in den Ordner /home/pi/iRadio/Tuner/DABplus 

ja!

oder muss die auch in /usr/bin kopiert werden?

nein!


Gruß
Bernhard

[mdat69]

Hallo Bernhard,

danke für deine Rückmeldung.
Nach der Treiberinstallation wurden ein paar Sender gefunden, also scheint der RTL-SDR Stick zu funktionieren.
Allerdings nicht so gut wie mit dem DABplayer über die Windows.
Mit dem Bandpassfilter für VHF Band III meintest du hardwaremäßig oder ist der softwaremäßig zu installieren?
Ich kenne mich leider in der Materie nicht wirklich aus und bin zufällig über Google auf dieses Projekt gestoßen, daher
auch meine vielen Fragen.
Da meine Grundkonfiguration wegen Platzgründen aus RPi, HiFibeery amp, zwei Drehencodern für Senderwechsel und die Lautstärke sowie
einem LCD 20x4 Display besteht, komme ich mit der Drehendcodesteuerung um DAB Radio einzubinden nicht wirklich zurecht.
Dazu fehlen mir einfach die Programmierkenntnisse. Läßt sich die stb_rotary.c aus der LorenzC2 Scalensimulation einfach umbauen um
das DAB Radio mit einzubinden?

Gruß Mike

[Bernhard45]

Nach der Treiberinstallation wurden ein paar Sender gefunden, also scheint der RTL-SDR Stick zu funktionieren.
Allerdings nicht so gut wie mit dem DABplayer über die Windows.

Was Du bei deinem Selbstbauradio natürlich auch beachten musst wenn Du über Antenne empfängst, dass Du deine Störstrahlung des Hauptprozessorboards so in den Griff bekommst, dass überhaupt die Grundlagen für ein brauchbares SNR hergestellt werden. Ein nackter Raspberry und Laptop/PC sind da zwei Paar unterschiedliche Schuhe! An der Antenne soll ja der DAB+ Sender und nicht deine CPU hörbar sein! Es ist überhaupt kein Problem mit einem nackten Raspberry ein LMK/UKW/DAB+ Radio in einem Meter Entfernung empfangsmäßig außer Betrieb zu setzen!

Mit dem Bandpassfilter für VHF Band III meintest du hardwaremäßig oder ist der softwaremäßig zu installieren?
Ich kenne mich leider in der Materie nicht wirklich aus und bin zufällig über Google auf dieses Projekt gestoßen, daher
auch meine vielen Fragen.

Mit dem Bandfilter musst Du dafür sorgen, dass außerhalb von 174-230 MHz sehr wenig "Signal" an deinen Eingang kommt, denn dieses Signal wird sonst ja mit digitalisiert und wenn da ein starker Sender ist (UKW, Mobilfunk, WLAN....), dann "klaut" er sich quasi seinen Anteil an der Empfindlichkeit eines solchen Sticks. Stell Dir das so vor. Dein Ohr ist dein Empfänger. In 10m Entfernung flüsstert Dir jemand zu, dass ist der DAB+ Sender. Wenn Du und der DAB+ Sender allein da sind, verstehst Du alles prima. Jetzt kommt eine dritte, vierte, fünfte Person (UKW-Sender, Mobilfunk, WLAN, Störstrahlung von ,..) hinzu. Diese Sender reden lautstark auf Dich ein. Den DAB+ Sender verstehst Du dann sehr viel schlechter oder gar nicht mehr.

Das Bandfilter soll diese Störer abschwächen, so dass Du deinen DAB+ Sender wieder besser oder überhaupt hören kannst. Das Bandfilter muss also vor dein Ohr, in Falle deines Radios also unmittelbar vor den Antenneneingang des USB-Sticks.  

Da meine Grundkonfiguration wegen Platzgründen aus RPi, HiFibeery amp, zwei Drehencodern für Senderwechsel und die Lautstärke sowie
einem LCD 20x4 Display besteht, komme ich mit der Drehendcodesteuerung um DAB Radio einzubinden nicht wirklich zurecht.
Dazu fehlen mir einfach die Programmierkenntnisse.

Das ist natürlich ein Problem!

Läßt sich die stb_rotary.c aus der LorenzC2 Scalensimulation einfach umbauen um
das DAB Radio mit einzubinden?

Einfach => mit Programmierkenntnissen ja, ohne unmöglich.

Für ein normales DAB+ Radio würde es ausreichen mit einem gpiod folgende Kommandos abzusetzen:

5. Um die DAB-Unterstützung bei jedem Start des iRadios einzuschalten, nehmen sie den Steuerdaemon dabd in ein Startscript, zum Beispiel /etc/rc.local auf. Dies geht analog der dort bereits aufgeführten Daemonen (zum Beispiel gpiod, displayd).

Der DAB-Steuerdaemon lauscht auf 127.0.0.1 Port 9914 UDP nach eingehenden Kommandos

Kommando - Bedeutung

dab0  - schaltet den DAB-Empfang ab
dab1  - schaltet den DAB-Empfang ein
next - wechselt zum nächsten Programm in den Senderlisten
prev - wechselt zum vorherigen Programm in den Senderlisten

Konsolenbeispiel:

echo "dab1" | nc -u 127.0.0.1 9914 -w 0
echo "next" | nc -u 127.0.0.1 9914 -w 0
echo "prev" | nc -u 127.0.0.1 9914 -w 0

Wenn jetzt noch andere Betriebsmodis hinzukommen, dann muss Du die Umschaltung zwischen den Modis ebenso realisieren, wie deren Ansteuerung. Dafür gibt es mit der DABgui einen, wie ich denke, guten Einstieg für eigene Benutzerkonzepte. Aber ja, elementare Programmierkenntnisse sind nötig, ebenso muss man verstehen wie die Teile des iRadios zusammenarbeiten.


Gruß
Bernhard

[mdat69]

@Bernhard

Danke für deine umfangreiche Ausführung. Da werde ich wohl noch etwas Zeit investieren müssen, aber das wird wohl erst wieder etwas im
nächsten Herbst/Winter.
Trotzdem ein schönes Projekt, ich hoffe, es wird fortgeführt.

Gruß Mike

[Bernhard45]

Hallo Mike,

du kannst uns ja dein Radio mal schematisch darstellen, also wo ist was angeschlossen und welche Komponenten werden genutzt usw.
Was ist im Endeffekt geplant, welche Funktionen soll es haben? Dann könnte man vielleicht aus der Ferne programmiertechnisch aushelfen auch ohne selbst vor dem Gerät zu sitzen. Vielleicht in einem eigenen Thread ala "Mikes Digitalradio"? Wir haben doch mit vereinten Kräften hier im Forum schon einige Radios so aus der Ferne fertigstellen können!

Gruß
Bernhard

[mdat69]

Hallo Bernhard,

danke für das Angebot, ich werde darauf zurückkommen. Leider fehlt mir in den nächsten Wochen dafür die Zeit, da im Frühjahr nun andere
Projekte in den Vordergrund rücken werden und die Zeit für das iRadio dann leider sehr eingeschränkt vorhanden sein wird.
Sobald es mir die Zeit wieder erlaubt werde ich mich hier wieder melden.

Gruß Mike

[Bernhard45]

Da nach unserem gestrigen Update https://radio-bastler.de/forum/showthrea...#pid210249 gleich die Frage an mich gestellt wurde, wie man auf einer Taste zwei oder mehrere Funktionen unterbringt, also zum Beispiel kurz gedrückt "Funktion der Taste wird angesagt", lange gedrückt wird die Funktion ausgeführt, will ich das hier kurz nochmal für alle (die es interessiert) zeigen.

Wir haben solche Doppel- und Mehrfachbelegungen einer Taste schon an mehreren Orten im iRadio gebraucht. Beispielsweise im gpiod von Skalensimulationen oder grafischen Nutzeroberflächen. Am Beispiel des gpiod für die im iRadio enthaltene DAB/Internetradio GUI (hier einsehbar https://github.com/BM45/iRadio/blob/mast...ui/gpiod.c) will ich das nochmal demonstrieren.


Der Codeteil ist hier für uns interessant:

Code:

void rotarySW(void) {
  if (!digitalRead(RoSWPin)) {
 time_ms_by10++;
  } else {

      // zwischen 10ms und 1000ms
      if ((time_ms_by10>1) && (time_ms_by10<100)) {
        system("echo \"entr\" | nc -u 127.0.0.1 6030 -w 0");
      }
 
     // zwischen 2000ms und 5000ms
     if ((time_ms_by10>200) && (time_ms_by10<500)) {
       system("echo \"menu\" | nc -u 127.0.0.1 6030 -w 0");
     }
 
     // länger als 6000ms
     if (time_ms_by10>600) {
       system("echo \"menu\" | nc -u 127.0.0.1 6030 -w 0");
       system("echo \"stby\" | nc -u 127.0.0.1 6030 -w 0");
     }

     time_ms_by10=0;
  }
}

Ich will das mal kurz erklären. Sobald der Taster, der am Pin "RoSWPin" angeschlossen ist, gedrückt wird, wird eine Zählvariable hochgezählt. Das passiert ungefähr alle 10ms, da wir weiter unten im Code der Datei die Routine "rotarySW" alle 10ms aufrufen. Lassen wir den Taster los, geht die Auswertung los. Wir schauen nach, wie hoch die Zählvariable gezählt wurde. Das passiert in den drei if-Zweigen, worin dann auch definiert wird, was passiert wenn die Taste nach einer bestimmten Zeitspanne losgelassen wird. Ganz zum Schluss setzen wir die Zählvariable zurück. Viel komplexer braucht die Auswertung für unseren Zweck gar nicht zu sein um praxistauglich zu funktionieren.

Wie sieht dieser entscheidende Codeteil nun für eine Taste aus, die zum Beispiel auf den nächsten Sender in der Programmliste springen soll? Na zum Beispiel so:

Code:

void rotarySW(void) {
  if (!digitalRead(RoSWPin)) {
 time_ms_by10++;
  } else {

      // zwischen 10ms und 1000ms
      if ((time_ms_by10>1) && (time_ms_by10<100)) {
        system("pico2wave --lang=de-DE -w /tmp/pico.wav \"Schalte auf nächstes Programm\" | aplay");
      }
 
     // zwischen 2000ms und 5000ms
      if ((time_ms_by10>200) && (time_ms_by10<500)) {
       system("echo \"next\" | nc 127.0.0.1 9294 -N");
      }
 
     time_ms_by10=0;
  }
}

Drücken wir die Taste kurz, wird das iRadio nur folgendes aussprechen: "Schalte auf nächstes Programm".
Drücken wir die Taste länger, wird das iRadio tatsächlich auf das nächste Programm umschalten, da der Umschaltbefehl "next" an vlc (also unsere Wiedergabesoftware) gesendet wird, welche auf Port 9294 nach eingehenden Steuerkommandos lauscht.

Das kann nun mit jeder Taste am selbstgebauten Radio gemacht werden. Also Programmumschaltung, Lautstärkeeinstellung, Menütasten, .... Taste für Ansage der Uhr oder Weckzeit usw. ...

Einfach, oder?


Gruß
Bernhard

[Bernhard45]

Hallo zusammen,

auf eine "technische Schwierigkeit" möchte ich beim sprechenden iRadio hinweisen und zwar im Zusammenhang beim Einsatz von speakingd bei einem Displaydaemon displayd.

Der displayd hat im iRadio ja die Aufgabe, zyklisch bei der Wiedergabesoftware vlc/cvlc nachzufragen, welche technischen Informationen der aktuell empfangenen Stream hat, also zum Beispiel Sendername, was gerade gespielt wird, Bitrate, ... und diese Daten für ein Display/Skalensimulation aufzubereiten und per Schnittstelle (I2C, SPI, HDMI ...) zum Display zu übertragen. Was bietet sich näher an, als das der displayd bei der Programmumschaltung den neuen Sendernamen des eingestellten Programms ausplaudert?  Hier liegt der Hund begraben.

Die Umschaltung des Programms in unserer Wiedergabesoftware geht augenblicklich. Der Sendername wird dabei sofort durch die Internetadresse aus der Playlist ersetzt. Also zum Beispiel http://......    erst nach wenigen Augenblicken wird diese Internetadresse durch den "richtigen" Sendernamen ersetzt und zwar sobald vlc diese von der Internetradiostation empfangen hat.  Das klappt auch fast immer, aber einige Sender trödeln bei der Übertragung dieser Senderkennung so rum (oder lassen es ganz sein!), dass unser speakingd letztendlich als Senderkennung nur die URL vorlesen kann. Das klingt natürlich unschön.

Hier könnte man im displayd vielleicht solange warten, bis in der Senderkennung kein http oder https mehr vorkommt. Das filtert schon ein paar Irrläufer raus, aber nicht diese, die gar keine Senderkennung übertragen! Auch wenn Sender solche Senderkennungen mit Sonderzeichen zurückliefern: ndr_1_ns , oder schlimmer. Da frage ich mich, welcher Techniker beim Sender hat das so konfiguriert?
Ihr könnt Euch ja vorstellen was eine synthetische Sprachausgabe aus so etwas macht.  Man müsste jetzt mit einer KI und einer Zeichenersetzung ran um da noch etwas zu retten, was nicht immer gelingen wird. Die einfachere Alternative ist, man sucht sich einen Stream des Senders, der eine ordentliche Senderkennung zurückliefert (wenn es einen solchen gibt), oder man muss der Streamadresse eine händische (selbst erdachte) Kennung direkt in der playlist.m3u zuweisen! Dann hat man das Problem (mit viel Handarbeit an der Senderliste) entschärft, auf Kosten anderer Nachteile.

Ein anderes Problem ist die Sprache mit der man einen Sendernamen vorliest! Im Democode ist de-DE eingestellt, damit klingen deutsche Sendernamen (sofern sie richtig übertragen werden) am Besten. Was ist aber mit ausländischen Sendernamen? Beispiel "Radio Caroline".
-
Das iRadio würde bei dem Parameter de-DE so etwas sagen: "Radio Karolin". Erst mit dem Parameter en-US würde sich der Sendername so anhören, wie die Moderatoren Ihn auch aussprechen würden, halt mit englischem Stil. Andersrum würde sich ein Sendername wie "Deutschlandfunk" oder "Antenne Brandenburg" von einem US-Sprecher (also Parameter en-US) wohl an hören, als hätte Kennedy sein berühmtes "Isch bin ain Bäärlinär" losgelassen.

So eine richtige technische Lösung dafür fällt mir (im Moment) dazu noch nicht ein. Zwar ist es kein Problem dynamisch den Sprecher und seinen Dialekt auszutauschen, geht ja über den Aufrufparameter, aber wie kommt man an die Info das der Sendername deutsch, englisch , französisch, ... ausgesprochen werden soll?  

Eine richtige Länderkennung übertragen die Radiosender ja nicht. In den URLs nach .de .com .us .fr usw. nachzuschauen ist auch nicht wirklich zielführend, da nicht immer treffsicher -  bei .com .fm .net wird es arg schwierig und diese Endungen benutzen viele Sender (auch in Deutschland).

Vielleicht über eine IP-Datenbank, sprich GeoIP ... Also mit solchen Techniken mit dem Fernsehsender zum Beispiel ausländische Zuschauer von Ihrem Programmangebot aussperren, weil sie keine Rechte dafür erworben haben.  Man schaut also auf die IP vom antwortenden Sender, prüft auf dessen Herkunft und versucht das dann einem Sprachpaket der Sprachausgabe zuzuordnen. Vielleicht der vielversprechendste Ansatz. Ich bin sicher da wird eine Lösung im iRadio kommen.

Gruß
Bernhard

[Bernhard45]

Ich bin sicher da wird eine Lösung im iRadio kommen.

Hallo,

eine solche Lösung ist jetzt in der aktuellen Version des iRadios auf https://github.com/BM45/iRadio eingecheckt.

Technisch basiert die Sprachbestimmung auf dem Konsolenprogramm geoiplookup, siehe https://linux.die.net/man/1/geoiplookup


Über ein kleines selbstgeschriebenes Tool (https://github.com/BM45/iRadio/blob/mast...nguage.cpp) erhalten wir nach Rückfrage bei unserer Abspielsoftware vlc einen "Vorschlag" für ein zu benutzendes Sprachpaket, also zum Beispiel de-DE, en-US und so weiter.

Wird kein entsprechendes Land in der vorgegeben Liste gefunden, wird die Sprache zurückgegeben, die unter #define DEFAULT_LANG "en-US" angegeben wird. In diesem Fall also ein Englisch mit amerikanischen Dialekt, das kann aber jeder so einstellen wie er will.

Der Code des sprechenden Displayd (https://github.com/BM45/iRadio/blob/mast...splayd.cpp) wurde für die Verwendung des "Sprachbestimmungstools" angepasst. Gebaut und installiert wird alles über das schon bekannte Skript install_Speaking_Displayd.sh, welches mit Rootrechten ausgeführt werden muss.

Ich habe die ganze Sache mit vielen Internetradiosender aus DACH, sowie GB, USA, Frankreich, Italien getestet. Liefern die Sender eine ordentliche Senderkennung zurück, wird der Sendername in der entsprechenden Landessprache ausgesprochen. Radio Caroline klingt also wirklich wie Caroline und nicht wie Karolin (bei de-DE), usw.   Aber: liefern die Radiosender keine Senderkennung, nur Ihre URL selbst als Kennung oder "Schrott" zurück, dann wird das halt ebenfalls in dieser Landessprache vorgelesen. Anderes Problem: Sendet eine deutsche Radiostation zum Beispiel nun über einen US-Server bzw. über eine IP die zum Beispiel geografisch einem "fernen" Gebiet zugeordnet wird, so wird die Senderkennung nicht in Deutsch, sondern in der dem Server zugeordneten Sprache vorgelesen. Dafür können wir aber nichts und sind gewissermaßen auch machtlos dagegen. Hier kann man nur durch sorgfältige Erstellung der playlist.m3u entgegenwirken!

Gruß
Bernhard

[Bernhard45]

Hallo Bastler,

da unser iRadio nun auch sprechen kann, kam eine Anfrage wie genau man mittels Programmcode die Uhrzeit auf Knopfdruck im Radioprogramm ansagen lassen kann.

Ich will dies hier einmal anhand einer Codemodifikation eines gpiod für Tastenansteuerung zeigen.

Zunächst brauchen wir eine Funktion, die bei Aufruf uns die Uhrzeit vom System holt und daraus ein Kommando für die Sprachausgabe zusammensetzt.
Nennen wir die Funktion einfach whatTime. Der Code sähe dann zum Beispiel so aus

PHP-Code:

void whatTime() {

  //get current date/time based on current system
  char cmd[255] = "\0";
  char hour[3] = "\0";
  char min[3] = "\0";

  time_t now = time(0);
  struct tm *ltm = localtime(&now);
  sprintf(hour,"%d",ltm->tm_hour);
  sprintf(min,"%d",ltm->tm_min);

  // build speaking command
  strcat(cmd,"pico2wave --lang=de-DE -w /tmp/pico.wav \"Es ist jetzt ");
  strcat(cmd,hour);
  strcat(cmd," Uhr und ");
  strcat(cmd,min);
  strcat(cmd," spät.\" | aplay \0");

  // say time
  system(cmd);
} 


Diese Funktion benötigt wegen der Zeitfunktion noch ein zusätzliches Headerfile, welches wir mit #include <time.h> weiter oben im gpiod.c laden.

Als nächsten können wir die Funktion whatTime() ganz einfach da aufrufen, wo wir im gpiod-Code schon auf Tastendruck reagieren. Also zum Beispiel so:

PHP-Code:

     if (val_prg_weiter == 0)
                //system("echo \"play\" | nc 127.0.0.1 9294 -N");
                whatTime(); 


Wir ersetzen hier einfach das Kommando an vlc durch den Aufruf unserer Funktion whatTime(); Jedesmal wenn diese Taste gedrückt wird, wird nun unsere Zeit im Radioprogramm angesagt.

Hier nochmal der ganze modifizierte Code des Standard gpiod.c als Datei.


  gpiod.c (Größe: 2,73 KB / Downloads: 2)

Compiliert wird der gpiod.c so wie es im Installerscript install_Tastensteuerung.sh im iRadio-Basisverzeichnis steht. Ich denke mit diesem Beispiel kann jeder eine gesprochene Zeitansage so und dort implementieren, wo er es gern für sein Radio hätte?


Gruß
Bernhard

[Bernhard45]

Hallo nochmals, hier jetzt zu deinem Post:

Hallo an alle und besonders natürlich an Bernhard, der diese wundervolle Software erschaffen hat. Vielen Dank dafür!!!

Vielen Dank dafür das Du das iRadio benutzt.

Mir ist der recht gut erhaltene Derby Commander meiner verstorbenen Schwiegereltern in die Hände gefallen und ich dachte, es würde meiner Frau gefallen, ihn weiter zu benutzen. Vorausgesetzt er würde heutigen Ansprüchen genügen. Dadurch bin ich auf diesen Thread gestoßen und bin sehr begeistert über die Möglichkeiten, die sich mir auftun.
Das Derbygehäuse ist neu lackiert, die Chromknöpfe poliert, eine neue Antenne liegt auf dem Tisch und ein alter Raspberry Zero lag auch noch rum.

Der Umbau würde mich interessieren. Kannst Du Bilder machen und deinen Umbau bisher hier vorstellen?

Ein erster Test mit dem verfügbaren iRadio Image ließ den Zero recht behäbig werden. Mit dem aktuellen Buster Lite läuft meine Playlist aber recht flott. Ich bin soweit zufrieden.

Ja der kleinste Raspberry, also der Zero, hat schon begrenzte Rechenleistung. Da muss man Einschränkungen hinnehmen und auch das "verzögerte" Antwortverhalten des Systems akzeptieren. Damals mit der ursprünglichen Software vom Pimoroni Pirate Radio  (https://shop.pimoroni.com/products/pirat...roject-kit) lief das alles noch wesentlich langsamer, als mit dem iRadio jetzt. Warum? Pimoroni hat viele Systemkomponenten in Python programmiert, einer Interpretersprache. Ein solcher Programmcode läuft auf einer Art virtuellen Maschine, dem Interpreter, und braucht deshalb noch zig mal mehr Rechenleistung, als ein Programm das nativ in C oder C++ geschrieben ist. Eigentlich zuviel für den kleinen Zero und natürlich erst Recht für einen Ur-Raspberry. Das war die Geburtsstunde des iRadio, wo wir uns auf C/C++ und nicht auf Python konzentriert haben, Ergebnis: auch mit den kleinen (alten) Raspberrys kann man interessante Internetradios bauen. PS: Für Leute die einen Raspberry im Zero-Format brauchen und noch keinen gekauft haben: Hier der leistungsfähigere Zero2 https://www.raspberrypi.com/products/ras...-zero-2-w/

Um den Lautsprecher des Derby ansteuern zu können, habe ich einen Pimoroni 3W Amp angeschafft. Das sollte ausreichend sein. Nun besitzt dieses recht preisgünstige Teil sogar noch ein Farb-LCD onboard, welches ich auch gerne nutzen würde.

Dieses hier? https://shop.pimoroni.com/products/pirat...stereo-amp

Ich habe den Start dieses Threads so verstanden, dass die wohl  vorher benutzte Software von Pimoroni zu viele Ressourcen  benötigen würde und habe nun Skrupel, diese (https://github.com/pimoroni/pirate-audio) für mein Board zu benutzten.

Richtig, wie gerade schon zur "Geburtsstunde" des iRadio geschrieben! 
Ich habe mir auch schon den Code von https://github.com/pimoroni/pirate-audio angeschaut. Wieder praktisch eine Python-Umsetzung. Keine Ahnung was Pimoroni daran so toll findet, diese kleinen Zeros mit so etwas zu quälen. Sicher kann man den Audio HAT auch auf einen "großen" Pi setzen und fabelhaft diese Python-Implementierung nutzen, aber das Format der Platine scheint doch eher für einen Zero zu sprechen den man da im Auge hat.

Jetzt kannst Du diesen Code von Pimoroni schon als Grundlage für ein iRadio nutzen, jedoch musst Du dann noch einen Display-Daemon displayd dafür schreiben.

Dieser displayd holt sich zyklisch die Daten (Sendername, Titel, ...) von vlc und schickt das dann zu deinem Display. Für die Tasten (wenn diese genutzt werden sollen) sollte  ein gpiod geschrieben werden. Wir haben da Beispielcode im iRadio, hier für ein artverwandtes Display https://github.com/BM45/iRadio/blob/mast...displayd.c aber halt in C/C++. Dennoch sieht man wie man an Daten von vlc rankommt und kann dies nach Python umsetzen. ABER: Es ist dann wieder alles schnarchlangsam, weil - richtig - Python!

Mein Vorschlag: Wir (oder ich) suchen nach einen passenden ST7789 Treiber in C/C++. Mit diesem Treiber bauen wir ein displayd mit der Pinbelegung deines Pimoroni-Audio-HAT. Dafür brauche ich aber deine Unterstützung, denn ich habe diese Platine mit dem Display nicht. Du müsstest dann, nach meinen Ratschlägen, die Sache mal auf deinem System umsetzen und testen ob es läuft.

Ich vermute mal du willst bei dem Derby Commander sicher die Tasten oder das Drehrad für die Sendereinstellung + Lautstärke nutzen? Welche Pläne hast Du, welche Bedienelemente des Commander sollen wie in das iRadio integriert werden? Läuft da schon etwas ? Lass und an deinem Umbau teilhaben und wir können die Probleme und Programmierung sicher gemeinsam angehen. Auch Jupp ist ein sehr talentierter Radio(um)bauer und hat schon viele iRadios und iTVs gebaut und wird softwaremäßig und auch bei der Adaption von Bedienelementen viel Wissen und Tipps einbringen können!

Benutzt vielleicht jemand schon diesen Pimoroni mit aktivem LCD?
Kann ich die Treiber von Pimoroni einfach installieren und läuft dann iRadio damit?

Wie geschrieben, ich habe dieses Board von Pimoroni noch nicht in der Hand gehabt, Jupp du? Aber ja, wenn man das "Geschwindigkeitsproblem" mit Python vernachlässigt, kann man den "Treiber" als Grundlage für ein iRadio nutzen. Man muß halt nur einen passenden displayd dafür stricken.

Gruß
Bernhard

[kaloschke]

Ups. Das ging ja schnell :-)  Grossartig.
Der Derby ist eigentlich (noch) nicht umgebaut. Ich weiß auch noch nicht so genau, was ich will. Evtl. bleibt die Hardware wie sie ist und ich nutze nur eine Taste, um den Derby auf den Zero umzuschalten. Wahrscheinlich möchte ich die vorhandenen Tasten aber zur Senderwahl nutzen, um eine intuitive Bedienung zu ermöglichen.  Der Lautsprecher ist aktuell ausgebaut und hängt zu Testzwecken am Pimoroni. Er könnte gegebenenfalls über ein Relais zwischen diesem und dem Original umgeschaltet werden. Das Display unter der Skala anzubringen erscheint mir zu aufwendig. Ich würde es auf der Geräteseite unterbringen, zusammen mit dem Gestensensor, den es hier ja tollerweise auch gibt. Für die Küche ideal, wenn die Hände gerade dreckig sind. Wenn es später fertig ist, will ich gerne ein paar Fotos schicken. Für die für das iRadio genutzten GPIOs habe ich mich hier https://de.pinout.xyz/pinout/pirate_audio_speaker orientiert.
 
Zu den Treibern: Es wäre großartig, wenn Du den Treiber und den Daemon auf die Beine stellen könntest. So etwas traue ich mir nicht zu, auch wenn sich auf Github etliches dazu findet. Testen allerdings schon :-)

Bin sehr gespannt.

[kaloschke]

Ach ja, es ist das von Dir genannte Pimoroniboard

[saarfranzose]

Bernhard, danke für die Blumen! Der 3W-amp ist mir in der Adafruit-Variante wohlbekannt. Ich weise darauf hin dass der MAX98357 einen I2S-DAC beinhaltet. Deshalb würde ich vorschlagen das Gesamtkonzept nochmal zu überdenken. Ich würde eine ESP32-Lösung mit einem Monobaustein MAX98357 für diesen speziellen Einsatz bevorzugen. Und dann ein Display benutzen welches zur ausgewählten software passt. Es sei denn du, Bernhard, willst wirklich iRadio an das Pirate-Modul anpassen. Eine I2S-Unterstützung würde iRadio nochmal entschieden aufwerten.