Differenze tra le versioni di "Web radio"
m (→Configurazione di IceS) |
(→TODO: allarme malfunzionamento) |
||
Riga 464: | Riga 464: | ||
== TODO == | == TODO == | ||
* bottoni virtuali per comandare le macchine da remoto | * bottoni virtuali per comandare le macchine da remoto | ||
+ | * scrivere un programmino da far girare su una macchina indipendente che mandi un messaggio di allarme (e-mail, per esempio) non appena qualcosa smette di funzionare correttamente; dalla versione 2.4.0 di Icecast è disponibile un'[http://icecast.org/docs/icecast-2.4.1/changes.html API JSON] che potrebbe tornare comoda | ||
* [http://www.savagehomeautomation.com/projects/raspberry-pi-rs232-serial-interface-options-revisit.html interfaccia seriale] (vedi anche [http://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/ qui], [http://www.trainelectronics.com/RaspberryPi/ qui] in basso, [http://www.fasttech.com/product/1247400-jy-mcu-mini-rs232-to-ttl-converter-module-board-35 qui] e [https://blogs.oracle.com/speakjava/entry/serial_communications_with_a_raspberry qui]) | * [http://www.savagehomeautomation.com/projects/raspberry-pi-rs232-serial-interface-options-revisit.html interfaccia seriale] (vedi anche [http://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/ qui], [http://www.trainelectronics.com/RaspberryPi/ qui] in basso, [http://www.fasttech.com/product/1247400-jy-mcu-mini-rs232-to-ttl-converter-module-board-35 qui] e [https://blogs.oracle.com/speakjava/entry/serial_communications_with_a_raspberry qui]) | ||
* [http://www.plcforum.it/f/topic/145470-alimentare-raspberry-tramite-gpio-5v/ alimentazione] | * [http://www.plcforum.it/f/topic/145470-alimentare-raspberry-tramite-gpio-5v/ alimentazione] |
Versione delle 17:32, 4 mar 2015
Con questo progetto si è realizzata la web radio della Comunità pastorale di Missaglia (LC).
Il sistema prevede il collegamento audio via Internet tra le chiese parrocchiali di Maresso e Missaglia, in modo tale da poter ascoltare presso la chiesa locale eventi che si svolgano nell'altra chiesa; quanto viene diffuso attraverso l'impianto audio della chiesa viene inoltre trasmesso via etere ai parrocchiani dotati di un particolare apparecchio radio.
In un secondo tempo si renderà disponibile una playlist di brani da trasmettersi in automatico nel caso saltasse il collegamento ad Internet.
In futuro si valuterà se rendere fruibile al pubblico lo stream della web radio.
Il sistema è modulare, per far sì che si possano aggiungere in futuro nuove stazioni ricetrasmittenti e mettere così in comunicazione un maggior numero di chiese tra loro.
Indice
Prerequisiti
- connessione ad Internet (ADSL o superiore)
- impianti audio con almeno un ingresso e un'uscita liberi (possibilmente bilanciati)
Hardware
Per ogni stazione ricetrasmittente:
- 1 Banana Pi [A]
- 1 ATXRaspi [L]
- 1 JY-MCU Mini RS232 to TTL Converter Module Board [F]
- 1 scheda SD SanDisk Ultra SDHC 8 GB [A]
- 1 scheda audio USB EDIROL UA-25 [ME]
- alcuni metri di cavo microfonico Cordial CMK 222 [T]
- a seconda del tipo di impianto audio:
- connettori XLR maschi Neutrik NC3MXX [T]
- connettori XLR femmine Neutrik NC3FXX [T]
- connettori RCA REAN NYS373-0 [T]
- connettori jack 1/4" tripolari Neutrik NP3X [T]
- connettori jack 1/4" bipolari Neutrik NP2X [T]
- 1 case rack 19"/1U Adam Hall 87407V [T]
Fornitori:
- [A] Amazon.it
- [F] FastTech
- [L] LowPowerLab Store
- [ME] Mercatino Musicale
- [MO] Mouser Electronics
- [T] Thomann
Pannelli
Per la progettazione dei pannelli dell'unità rack, una valida metodologia di lavoro potrebbe essere questa (seguendo anche questi consigli). Purtroppo non è possibile al momento adattarla al mondo del software libero, a causa della indisponibilità di strumenti CAD adeguati.
Per questo progetto abbiamo dunque preferito attendere l'arrivo di tutti i pezzi da montare sui pannelli, posizionandoli manualmente sui pannelli smontati in una disposizione indicativa, e prendere le misure con metro e calibro.
Le misure reali del pannello frontale da 1U da noi acquistato sono 482,6 mm × 44,3 mm; quelle del pannello posteriore sono 400 mm × 41 mm.
Console port
Il Banana Pi dispone di un'interfaccia seriale via GPIO, già configurata su Bananian [VERIFICARE] per funzionare come console seriale. Abbiamo quindi deciso di sfruttare questa potenzialità per poter facilmente accedere al sistema operativo in caso di malfunzionamento.
Occorre collegare i pin GPIO ad una scheda costituita da un integrato (MAX3232) e da cinque condensatori. Questa scheda, facilmente costruibile anche in casa, fornisce un'interfaccia RS-232 standard, a 5 V; il MAX3232 invece funziona anche a tensioni più basse, come quella del Banana Pi (3,3 V).
Noi abbiamo optato per l'acquisto di una scheda già pronta; esistono prodotti dotati di connettore saldato, ma abbiamo preferito acquistarne uno sprovvisto, per poter posizionare la scheda liberamente all'interno dell'unità rack.
Per questioni estetiche abbiamo deciso di evitare di posizionare un connettore D-sub sul pannello frontale; ci siamo quindi inventati una nostra soluzione proprietaria, che trae ispirazione dalla console port di Cisco.
PIN | BCM | |
---|---|---|
TX | 8 | 14 |
RX | 10 | 15 |
Bottone di accensione
La procedura è spiegata chiaramente sul sito ufficiale della scheda ATXRaspi. In sintesi abbiamo alimentato la scheda saldando direttamente due fili all'alimentatore; abbiamo attaccato un bottone e un LED saldando i fili del primo direttamente, e interponendo una resistenza adeguata per il LED; abbiamo attaccato i 4 cavi diretti alla scheda ATXRaspi (alimentazione sui pin laterali e controllo in mezzo, GPIO28 a IN e GPIO30 ad OUT) all'header J12 del Banana Pi che corrisponde al P5 del Raspberry Pi (la fila più vicina all'header P1).
PIN | BCM |
---|---|
J12-P03 | 28 |
J12-P05 | 30 |
Abbiamo riscritto lo script shutdowncheck.py
da zero, in Python, ponendolo nella directory /root/
e dandogli i permessi di esecuzione da parte del proprietario (l'utente root
):
#!/usr/bin/env python3 import RPi.GPIO as GPIO import time import subprocess GPIO.setwarnings(False) # set up GPIO using BCM numbering GPIO.setmode(GPIO.BCM) GPIO.setup(28, GPIO.IN) GPIO.setup(30, GPIO.OUT) GPIO.output(30, True) # detect button pushes GPIO.add_event_detect(28, GPIO.RISING, bouncetime=500) if __name__ == '__main__': while True: if GPIO.event_detected(28): print('PIN 28 requested a SYSTEM HALT!') p = subprocess.Popen('shutdown -h now'.split()) time.sleep(0.5)
Infine abbiamo aggiunto a /etc/rc.local
la seguente riga, giusto prima di exit 0
:
exec /root/shutdowncheck.py &
Bottoni
N° | PIN | BCM |
---|---|---|
1 | 11 | 17 |
2 | 15 | 22 |
3 | 12 | 18 |
4 | 24 | 8 |
5 | 26 | 7 |
LED
N° | PIN | BCM |
---|---|---|
1 | 19 | 10 |
2 | 16 | 23 |
3 | 18 | 24 |
4 | 21 | 9 |
5 | 23 | 11 |
Software
Sistema operativo
Seguire le istruzioni presenti qui per ottenere una versione recente di Bananian e copiarla sulla scheda SD.
Inserire la scheda SD nel Banana Pi; collegare il cavo di rete al dispositivo, possibilmente un monitor HDMI e una tastiera, e alimentarlo.
Effettuare il login (username: root
; password: pi
) e lanciare bananian-config
.
Per comodità installare vim:
# aptitude update # aptitude install vim # aptitude purge vim-tiny
Installare infine i programmi usati per questo progetto:
# aptitude install alsa-base ices2 vlc-nox hexedit python3-dev gcc unzip
Installare python3-rpi.gpio
:
# wget https://github.com/LeMaker/RPi.GPIO_BP/archive/bananapi.zip # unzip bananapi.zip # cd RPi.GPIO_BP-bananapi/ # python3 setup.py install # cd .. # rm -r RPi.GPIO_BP-bananapi bananapi.zip
Impostare l'indirizzo IP come fisso, modificando il file /etc/network/interfaces
ed, eventualmente, /etc/resolv.conf
; nel nostro caso abbiamo scelto come indirizzo 192.168.0.40
in un caso, e 192.168.1.40
in un altro. Potrebbe essere necessario ridurre il range gestito dal server DHCP (ad esempio configurando adeguatamente il router) in modo tale da non avere conflitti con questi indirizzi.
Per impostare la scheda audio esterna come dispositivo di default, verificare che il file /etc/asound.conf
presenti il seguente contenuto:
pcm.!default { type hw card 1 } ctl.!default { type hw card 1 }
DNS dinamico
La condizione ideale sarebbe quella di disporre di un indirizzo IP statico per ogni ricetrasmittente. Purtroppo è molto più probabile che il provider fornisca un indirizzo IP dinamico. Per rendere sempre raggiungibili i diversi host occorre quindi ricorrere ad un servizio di DNS dinamico.
Per questo progetto si è deciso di sfruttare OpenNIC. Occorre creare un account sul sito e poi registrare un dominio .dyn
per ogni stazione ricetrasmittente.
Per ogni dominio, una volta preso nota dell'URI messo a disposizione da OpenNIC per aggiornare l'indirizzo IP, è sufficiente scrivere sulla macchina che vogliamo raggiungere da Internet uno script (che chiameremo /root/ddns.sh
) analogo al seguente, sostituendovi l'URI precedentemente appuntato:
#!/bin/sh wget -qO- "http://api.opennicproject.org/ddns/example.dyn?user=myUserName&auth=myAuthCode" > /dev/null
Una volta datogli i permessi di esecuzione, creeremo un crobjob da lanciarsi ogni 10 minuti:
# crontab -e
# m h dom mon dow command */10 * * * * /root/ddns.sh
Bisogna infine pazientare il tempo necessario affinché i nuovi domini da noi registrati si propaghino per tutta la rete (in genere bastano pochi minuti). Si può verificare che sia tutto a posto lato DNS lanciando questo comando da una macchina che sfrutti i DNS OpenNIC:
$ dig mio_dominio.dyn
Configurazione di IceS
Copiare il file /usr/share/doc/ices2/examples/ices-alsa.xml
in /root/
e modificare le righe evidenziate in grassetto:
<?xml version="1.0"?> <ices> <background>0</background> <logpath>/var/log/ices</logpath> <logfile>ices.log</logfile> <logsize>2048</logsize> <loglevel>4</loglevel> <consolelog>0</consolelog> <stream> <metadata> <name>Radio[Nome]</name> <genre>Catholic</genre> <description>Parish Radio from [...] (Brianza, Italy)</description> <url>http://reginamartiri.it</url> </metadata> <input> <module>alsa</module> <param name="rate">44100</param> <param name="channels">2</param> <param name="device">hw:1,0</param> <param name="metadata">1</param> <param name="metadatafilename">test</param> </input> <instance> <hostname>indirizzo_IP_corretto</hostname> <port>8000</port> <password>password_corretta</password> <mount>/nome_stream.ogg</mount> <yp>0</yp> <encode> <quality>0</quality> <samplerate>44100</samplerate> <channels>1</channels> </encode> <downmix>1</downmix> ' </instance> </stream> </ices>
Creare la directory per i log:
# mkdir /var/log/ices
VLC
VLC, così come è compilato nel pacchetto fornito, non consente di essere eseguito dall'utente root
. Per evitare di ricompilare tutto il programma è sufficiente sostituire la stringa "geteuid" con "getppid" usando un editor esadecimale:
# hexedit /usr/bin/vlc
Premere TAB per passare alla modalità ASCII; cercare la stringa con CTRL+S; posizionarsi sui caratteri da sostituire; digitare i caratteri; premere CTRL+X per salvare e uscire.
Radio Mater mette a disposizione lo stream in quattro formati, pensati per quattro player multimendiali:
- iTunes, mono, codifica MPEG Audio layer 1/2/3 (mpga), campionamento 24000 Hz, bitrate 32 kb/s
- Windows Media Player, stereo, codifica Windows Media Audio 2 (WMA2), campionamento 32000 Hz (32 bit per campione), bitrate variabile attorno ai 32 kb/s
- RealPlayer, mono, codifica MPEG Audio layer 1/2/3 (mpga), campionamento 24000 Hz, bitrate 32 kb/s
- QuickTime, VLC 2.1.2 non lo supporta
Icecast
Icecast va installato su un server con banda sufficiente a permettere il download a tutti gli utenti che dovessero collegarsi.
Per installarlo su un server Debian:
# aptitude install icecast2
Rispondere "No" alla proposta di configurazione.
Per configurarlo, modificare il file /etc/icecast.xml
riducendo il numero di client che si possono connettere da 100 a 5 e impostando le 3 password (source, relay e admin). Mettere anche ENABLE=true
in /etc/default/icecast2
, in modo che parta automaticamente.
Ricordarsi di aprire la porta 8000 nel caso in cui il server Icecast riceva da Internet i flussi da ritrasmettere.
Programmazione bottoni
Ecco lo script buttoncontroller.py
, posto nella directory /root/
con i permessi di esecuzione da parte del proprietario (l'utente root
):
#!/usr/bin/env python3 import RPi.GPIO as GPIO import time import subprocess GPIO.setwarnings(False) # set up GPIO using BCM numbering GPIO.setmode(GPIO.BCM) # mapping buttons and LEDs buttons = {1: 17, 2: 22, 3: 18, 4: 8, 5: 7} leds = {1: 10, 2: 23, 3: 24, 4: 9, 5: 11} # set buttons as GPIO input for button in buttons.values(): GPIO.setup(button, GPIO.IN) # set LEDs as GPIO output for led in leds.values(): GPIO.setup(led, GPIO.OUT) # detect button pushes for button in buttons.values(): GPIO.add_event_detect(button, GPIO.RISING, bouncetime=500) # test leds for led in leds.values(): GPIO.output(led, True) time.sleep(0.2) GPIO.output(led, False) if __name__ == '__main__': p = False while True: if GPIO.event_detected(buttons[1]): for led in leds.values(): GPIO.output(led, False) if p: p.terminate() GPIO.output(leds[1], True) p = subprocess.Popen(['ices2', '/root/ices-alsa.xml']) if GPIO.event_detected(buttons[2]): for led in leds.values(): GPIO.output(led, False) if p: p.terminate() GPIO.output(leds[2], True) p = subprocess.Popen(['cvlc', 'http://URL:8000/FILE.ogg']) if GPIO.event_detected(buttons[5]): for led in leds.values(): GPIO.output(led, False) if p: p.terminate() GPIO.output(leds[5], True) time.sleep(0.2) GPIO.output(leds[5], False) time.sleep(0.1)
sostituendo URL
e FILE
adeguatamente.
Come ultimo passo abbiamo aggiunto a /etc/rc.local
la seguente riga, giusto prima di exit 0
:
exec /root/buttoncontroller.py &
Test
Abbiamo messo a punto una serie di test per verificare rigorosamente l'affidabilità hardware e software del prototipo. Nel caso in cui un punto fallisse, si trovi una soluzione e si ripeta quel punto.
- Collegare ad un PC la scheda audio modificata, un impianto audio all'ingresso della scheda e realizzare una trasmissione della durata minima di 2 ore, senza interruzioni.
- Utilizzare la scheda audio per ricevere uno stream dal server Icecast per almeno un'ora senza interruzioni, verificando il corretto funzionamento di entrambe le uscite.
- Partendo da un'installazione minimale del sistema operativo, con i soli collegamenti strettamente indispensabili, installare il software di streaming e ripetere il primo punto usando questa volta il Banana Pi per effettuare la trasmissione.
- Con i soli collegamenti strettamente indispensabili, installare il player multimediale e ripetere il secondo punto usando questa volta il Banana Pi per effettuare la ricezione.
- Realizzare i collegamenti minimali sia per la ricezione che per la trasmissione e ripetere i due punti precedenti.
- Collegare man mano tutti i fili, ripetendo ogni volta il punto precedente usando però come interfaccia uomo-macchina quella definitiva (led e bottoni).
- Simulare l'interruzione del collegamento ad Internet.
Problemi
Bottone di accensione (Missaglia)
Il bottone di accensione a Missaglia non funziona; trovare la causa e porvi rimedio.
1/3/2015: collegamento fallito
Si sanno 3 cose:
- il primo marzo 2015 si è manifestato un problema che ha reso impossibile il collegamento tra la chiesa di Missaglia a quella di Maresso;
- il problema è stato localizzato a Missaglia;
- il problema si manifestava con l'impossibilità da parte di IceS di collegarsi al server Icecast (collocato in Oregon), facendo quindi fallire la trasmissione.
Tutto ciò è stato dedotto da numerosi test e dall'analisi del log di IceS svolti la sera stessa collegandoci via SSH dalla chiesa di Maresso alla macchina di Missaglia.
Purtroppo non è stato possibile individuare la causa del problema, in quanto quando ci siamo recati sul posto il pomeriggio successivo, tutto è tornato a funzionare perfettamente.
TODO
- bottoni virtuali per comandare le macchine da remoto
- scrivere un programmino da far girare su una macchina indipendente che mandi un messaggio di allarme (e-mail, per esempio) non appena qualcosa smette di funzionare correttamente; dalla versione 2.4.0 di Icecast è disponibile un'API JSON che potrebbe tornare comoda
- interfaccia seriale (vedi anche qui, qui in basso, qui e qui)
- alimentazione
- valutare se migrare il VPS su Haphost
- reset
- testare il codec Opus con DarkIce
- documentare circuiti
- test
Possibili evoluzioni
Le macchine realizzate sono sostanzialmente dei prototipi. Chi volesse perfezionarli ed eventualmente portarli ad una scala industriale troverà qui alcuni spunti:
- disegno e stampa dei frontali
- sostituzione di Banana Pi + scheda audio con una scheda progettata ad hoc