Una delle leggi del libero mercato è che la domanda e l'offerta sono strettamente correlate tra loro, non a caso si è soliti correlarle e graficarle insieme. Ad una domanda che, ve lo garantiamo, diventa sempre più insistente da parte di tutti voi utenti, di provare e sperimentare su Raspberry Pi, allora, non ci resta che aumentare la nostra offerta.
Onestamente nelle ultime settimane ci avete davvero sommerso di richieste, non soltanto nei commenti ma anche sui social network, in privato...
La partecipazione di voi tutti al Review4U, ve lo possiamo garantire, è soltanto la parte esteriore dell'enorme desiderio che l'intera comunità sta dimostrando di provare verso l'utilizzo di questa scheda.
E allora, eccola ancora in palio.
Per chi non si è ancora proposto e per chi, invece, si propone ancora una volta con un suo progetto…
Non c'è molto da dire per presentare questa scheda, ormai la conoscete e sicuramente non volete leggere ancora l'ennesima presentazione.
E allora, passiamo alle cose importanti: rivediamo insieme il nostro regolamento.
Come ricevere GRATIS la scheda Raspberry PI?
Basta semplicemente essere Abbonato al progetto EOS-Book (se non lo sei ancora abbonati ora, costa poco più di un caffè ed avrai tantissimi vantaggi) e poi descrivere qui sotto nei commenti quale è la tua idea di applicazione per questa demoboard. L'idea più originale, ma anche verosimile, verrà premiata con la board. Te la spediamo noi a casa gratuitamente, tu dovrai soltanto..... utilizzarla e come da regolamento, inviarci uno scritto sull'utilizzo, anche semplicemente un "getting started" o "la prima messa in funzione con lampeggio di un led" insomma niente di complicato, vogliamo solo essere sicuri che il vincitore la utilizzi veramente!
Solo un breve appunto, visto che qualcuno lo ha chiesto ultimamente nei commenti: se avete un'idea, e volete riproporla anche se non avete vinto, potete tranquillamente farlo.
Potreste non aver vinto per pochi voti, e a maggior ragione tentare nuovamente potrebbe voler dire per voi che questa è la volta buona.
Potreste proporre lo stesso progetto, magari un po' modificato o migliorato, sperando che sia più appetibile o più interessante per altri utenti.
In ogni caso per vincere la scheda la cosa che conta è che sia un progetto innovativo, magari divertente, e comunque accattivante e che possa piacere a tutti coloro che partecipano.
L'importante è, comunque, che ci sia un'onesta e leale competizione.
E che vinca il migliore!
Ed ora la parola a voi: per che cosa usereste il vostro Raspberry Pi?
Buongiorno a tutti.
Sono il primo, a quanto pare… eheh
La mia idea è quella di realizzare una stazione meteo che misuri le principali grandezze: temperatura, umidità, tenga conto dell’orario e magari realizzi un file di log con lo storico delle grandezze rilevate.
In futuro tutto questo potrebbe essere caricato su un server online, per il controllo remoto dell’ambiente in cui il sistema lavora.
Come ti ho accennato l’idea non è esattamente delle più originali ma alla fine, “l’importante è partecipare” 🙂
In bocca al lupo.
Un paio di anni fa realizzai un sistema di videosorveglianza open source. Lo chiamai LiViSuX(Linux Video Surveillance). Il progetto, sotto un altro nome , è stato presentato al MIUR ed è stato approvato. LiViSuX presenta un backend in php5 per la logica di business, il frontend scritto in jquery(anche mobile). Innovazione del progetto è l’integrazione di zigbee per il controllo delle telecamere PTZ. Ovviamente come tutti i sistemi di videosorveglianza gestisco il motion detection, il salvataggio delle immagini e dei video. Sviluppai anche un modulo per la masterizzazione remota e l’architettura per il disaster ricovery… Insomma potrei provare a fare un porting grazie a raspbian. Saluti a tutti! 🙂
Ci provo, ho spesso la necessità di collegare diverse casse audio amplificate in ambienti mediamente grandi, se da un lato l’alimentazione non è mai un problema, stendere i cavi audio è sempre un impegno. Cercavo qualcosa di commerciale per trasmettere anche non in stereo una sorgente audio e riceverla in più punti sfruttando una WiFi, ma non esiste nulla. Esistono trasmettitori più o meno costosi ma avere diversi ricevitori è sempre un problema e un costo.
Volevo creare una applicazione che campioni ad almeno 48 KHz e invii via UDP dei pacchetti acquisiti di circa 20 ms, assumendo questo come delay accettabile fra Tx e Rx, e trasmettere comunque con un overlap delle acquisizioni in modo che se anche un pacchetto non arriva a destinazione, il pacchetto successivo possa conentere le informazioni necessarie, quindi in pratica i pacchetti conterranno sempre una parte ridondante del messaggio per evitare che ci siano buchi di ricezione. Ovviamente lato ricevitore ci saranno dei RaspberryPI in ricezione che fanno il reincapsulamento dei pacchetti e la conversione in analogico.
Potrebbe essere interessante comprimere loss-less oppure lavorare in modo RAW. Ho fatto qualche prova su PC usando programmi commerciali ma il ritardo è inaccettabile, il PC non riesce ad essere sufficentemente real time nella compressione e mezzo secondo di delay nel parlato si sentono parecchi. Che ne pensate? Qualcuno ha gia visto/fatto cose del genere?
Salve, la mia idea sarebbe di realizzare un termostato sfruttando l’interfaccia GPIO. Le sonde potrebbero essere dislocate anche distanti dal Raspi (forse sarebbe anche meglio perchè un minimo di calore penso lo produca) e tramite sempre l’interfaccia GPIO si potrebbe comandare il relè che attiva e disattiva la caldaia.
Volendo articolare un po’ la cosa, si potrebbe gestire anche la parte estiva e comandare il timer dell’aria condizionata ed eventualmente un timer per l’irrigazione notturna.
Il tutto verrebbe gestito tramite un’interfaccia web.
Magari esiste già qualcosa del genere però, mi fa troppo arrabbiare l’interfaccia di programmazione dei termostati classici che finisco sempre per fare pasticci, via pc credo verrebbe più comodo!
il mio proggetto sarebbe gia in fase di programmazione, ovvero la realizzazione di un controllo domotico interno vocale, estero tramite il web server o anche programmabile. il controllo di cui sto parlando riguraderebbe tutte le uscite programmabili a prova di stupido scegliendo l’utilizzo con delle opzioni preimpostate. il programma potrà cestire tapparelle elettriche sistemi d’irrigazione illuminazione nelle varie stanze, sistemi di riscaldamento, accensione e spegnimento del forno.
l’idea del mio proggetto è nata esamindando il fatto che man mano che le tecnologie si sviluppano l’uomo sta diventando sempre più pigro per tanto vorrei creare un sistema ad estremamente basso costo di automatizazione delle case, in modo che una persona possa controllare tutto cio che avviene in casa a distanza, possa eseguire comandi quotidiani con l’utilizzo di semplici comandi impostabili e personalizzabili vocalmente.
L’idea è nata anche pere tutte quelle persone magari allettate o assistite da badanti. un esempio una signora anziana si trova nel letto e non riesce ad alzarsi la badante mette il pollo nel forno ed esce per comprare un ingrediente mancante dice alla signora che tornerà in 10 minuti ma rimane bloccata nel traffico o fa un incidente. la persona anziana si potrebbe trovare in pericolo in quando inizia ad uscire il fumo ed in quel momento si ricorda del nuovo impianto del controllo vocale installato a casa pronuncia ad alta voce il comando ed il forno si spegne.
ps. domani o al massimo dopo domani mi abono alla rivista
Il tuo progetto mi incuriosisce.
Proviamo a fare 4 conti …
Campionare a 16 bit un segnale stereo a 48KHz vuol dire produrre:
2 byte (16 bit) x 48*1024 (48KHz) x 2 canali (stereo = canale dx + sx)
192Kbyte/sec (196.608 byte/sec) cioé 3.932,16 byte ogni 20 msec.
Volendo usare la rete ethernet (100mt di distanza max tra 2 punti attivi)
non ti puoi permettere pacchetti così GROSSI…
Su di una rete ethernet con protocollo IP la dimensione massima del pacchetto (tecnicamente si chiama frame) che puoi trasmettere é di 1536 byte e di questi soltanto 1500 sono a tua disposizione (tecnicamente si chiama payload).
(Per chi vuole approfondire https://en.wikipedia.org/wiki/Ethernet_frame)
Sulle reti gigabit si possono usare i Jumbo-Frame (9000 byte di payload)
ma anche questo é una possibilità che escluderei…
(Per chi vuole approfondire https://en.wikipedia.org/wiki/Jumbo_frame)
Dovresti passare da 50 pacchetti al secondo (1 ogni 20 msec => 1000msec/20msec=50) ad almeno 131,072 pacchetti al secondo (196608/1500).
Suggerire 192 (128+64=192 rimaniamo su numeri binari semplici) pacchetti al secondo cioé ad una trasmissione ogni 5,2msec circa (1000msec/192=5,2083_msec).
Il payload di ogni trasmissione é pari a 1024byte, cioé 1Kbyte (196608/192).
A questo punto ogni 5,2ms bisogna campionare il segnale audio, trasformarlo in un pacchetto ethernet e quindi trasmetterlo; bisogna fare qualche prova per capire se Raspbian sia sufficientemente real-time, ma non mi sembra un obiettivo impossibile da raggiungere, si tratta di fare qualche test e di togliere demoni/servizi linux che appesantiscono il carico dell’architettura ed eventualmente di ricompilare un kernel ad hoc; a livello computazionale l’uso della scheda audio esistente (nessuna campionatura da fare con un chip esterno) e la scarsa necessità di calcolo prevista (il segnale audio non viene compresso, ma trasmesso come un payload RAW, cioé così com’é) fanno presupporre la buona riuscita del progetto.
Alcune note a margine:
GIUSTAMENTE hai già preferito l’uso del procotollo UDP della famiglia IP al posto del TCP, questo infatti NON PREVEDE né l’handshake né tantomento la conferma dell’avvenuta ricezione del pacchetto privilegiando quindi una componente real-time della trasmissione dati su ethernet rispetto ad una trasmissione con conferma di ricezione.
La ridondanza di cui parli può essere fatta solo ri-trasmettendo l’intero pacchetto… l’idea che mi viene in mente é questa, visto che abbiamo spazio nel payload (usiamo solo 1024 byte dei 1500 a disposizione), ritrasmettiamo in ogni pacchetto anche il precedente abbassandone la qualità da 16bit a 7bit. La trasformazione da 16 a 7 bit é banale e veloce (nessun algoritmo complicato e soprattutto laborioso, semplicemente ci teniamo di ogni singolo campione a 16 bit i 7 bit più significativi) e ci permetterebbe di inviare l’intero pacchetto precedente (ad una qualità più bassa).
In sostanza se ad ogni trasmissione inviamo 1024 byte (campioni audio a 16bit) pari a 512 campioni (1024 byte / 16 bit cioé 2 byte) e a questa aggiungiamo la trama precedente a bassa qualità pari a 3584 bit (512 campioni x 7 bit) cioé 448 byte (3584/8) otteniamo un payload complessivo di 1472 byte (1024+ 448), ci stiamo (1472 < 1500)! Se l'avessimo fatto il ri-campionamento del frame precedente ad 8 bit non ci saremmo stati, infatti 1024+512 = 1536 > 1500 (512 campioni ad 8 bit equivalgono a 512 byte).
CILIEGINA SULLA TORTA:
E’ possibile trasmettere i nostri campioni a più dispositivi remoti SENZA abbassare la qualità e SENZA dover ritrasmettere a ciascun endpoint i pacchetti ?
Si, ma la risposta alla prossima puntata ops POST !
Ciao
PF
Sarai il benvenuto 🙂
Seccondo me lo dovresti fare il porting xke avrà molto successo e sopratutto é una cosa molto utile che serve a tanta gente. Ti ringrazio già da ora e spero tanto che tu lo faccia. Ciao.
Direi che il discorso è perfetto, potremmo allora pensare ad utilizzare qualche algoritmo di compressione loss-less che ci permetta di ridurre un po’ l’utilizzo di banda, e anche eventualmente limitarsi ad una trasmissione MONOFONICA, dato che il mio scopo è quello di trasmettere in streaming segnale audio che deriva principalmente dal parlato ed effettivamente, anche nei grandi concerti, si cerca di non usare audio stereofonico dato che solo una parte del pubblico riesce ad apprezzarlo, quindi si usa di fatto un sistema mono.
Ragionandoci e ripensandoci non credo che ci serva ridurre la banda, tutto sommato ne usiamo poca, 192Kbyte/sec, quando con una rete 10 Mbit/sec possiamo tranquillamente arrivare a 925-975Kbyte/sec (a 100 Mbit/sec possiamo raggiungere nel real-world 8.750-9.150Kbyte/sec.
Il nostro (già mi sento parte del progetto!) scopo é invece trasmettere un segnale audio in tempo reale (arrotondiamo a 5-6 msec) senza latenze percepibili e fastidiose.
Abbassare la qualità audio trasmettendo in monofonia ( uno solo dei due canali stereo) ridurrebbe a 96Kbyte/sec il peso dei dati da trasmettere, ma non ci aiuterebbe in nulla nell’abbassare i 5 msec di ritardo che abbiamo nell’elaborare il segnale e nel trasmetterlo.
Nell’utilizzo del mondo reale fai cenno a soluzioni mono utilizzate nei concerti, ci passi qualche nome di prodotto/azienda/soluzione utile allo scopo ?
Per quanto riguarda la compressione loss-less (senza perdita), non ho conoscenze dirette degli algoritmi esistenti in grado di fare ciò, ma immagino che le soluzioni tradizionali (lha, zip, gzip, 7zip) su di un segnale audio raw/wav non siano molto efficaci. So che flac (http://flac.sourceforge.net/), ma parlo solo per sentito dire, é un buon compressore audio e comprime anche loss-less (senza poerdite di qualità come invece fa il jpeg).
Sai dirmi quale margine di compressione media in percentuale raggiunge (ipotizzando un segnale stereo a 48KHz campionato a 16bit) ?
PS : La soluzione per raggiungere più end-point di ritrasmisisone del segnale audio consiste nell’usare il protocolla UDP in Unicast che ha il pregio di non appesantire la postazione principale (che trasmette un solo pacchetto) appoggiandosi a dei router/switch (abbastanza economici) in grado di riproporre e ridondare i pacchetti trasmessi ad N postazioni ( nel nostro caso a 10 Mbit potremmo trasmettere a 5 destinatari (975Kbyte_sec/192Kbyte_sec), a 100Mbit/sec a 45 destinatari (9150Kbyte_Sec/192Kbyte_sec).
Anch’io pensavo al FLAC, non l’ho mai usato ma immagino esistano librerie a cui appoggiarsi, il problema è al limite il tempo di conversione. Considera che i 5 ms non sono assolutamente apprezzati da un “orecchio”, le casse normalmente sono a minimo 10 metri dagli ascoltatori, e il ritardo naturale del suono è di 30 ms sono per via dei 10 metri.. pensa quando siamo a 50 o più metri dall’ascoltatore! in pratica non si avverte un ritardo se chi parla non si sente in eco con un tempo superiore ai 100 ms circa. Comunque ben vengano i 5 ms!!
Per il discorso di quanto esiste di standard, tutti usano trasmissione modulata in frequenza a banda larga (ma ci sono in giro anche schifezze in NarrowBand…) e i più sofisticati usano tecniche di trasmissione su 2 frequenze poi il ricevitore doppio sceglie quella che ha meno disturbi (diversity) oppure un solo trasmettitore e 2 ricevitori iso-frequenza da cui si prende il meglio.
Le soluzioni di questo tipo (Shennaiser, LEM e altri) hanno costi decisamente elevati.
Io per l’UDP pensavo al multicast!! Perchè fare una trasmissione 1:1 ?
Non credo ci siano controindicazioni!
Ho acquistato poco tempo fa, da un venditore eBay cinese:
– un display lcd a caratteri con tastiera integrata,
– un display lcd 320×240 di 3.2″ con touch integrato
– un DAC usb basato sul circuito PCM2704
se mi date la vostra fiducia la mia proposta è cercare le soluzioni migliori per usare queste interfacce che si possono trovare a buon mercato, insieme all’utilizzo in sessione remota, e realizzare una raccolta dettagliata.
Un progetto umile rispetto ad altri, ma che punta ad allargare l’offerta di Elettronica Open Source. Riguardo a questo argomento ho trovato diverse discussioni ed articoli, ma tutto materiale frammentario e incompleto. Un resoconto completo su una copertina di buon livello quale è Elettronica Open Source sarebbe d’aiuto ai meno esperti.
Ricordati che è importante abbonarsi per poter partecipare 😉
Voto per questo progetto … in bocca al lupo !
Ciao a tutti,
vorrei realizzare un antifurto completo di Ir, allermi magnetici, allarme ultrasuoni + combinatore telefonico + altri dati generali tipo ora, temp, umidità utilizzando un arduino mega2560 interfacciato con il Raspberry per il controllo a distanza e la gestione di una webcam con eventualmente allarme al movimento. Certo in commercio ce ne sono già fatti ma il costo è abbastanza alto strutturato così, e poi volete mettere costruirselo da soli!
Questa mi sembra sia la bozza di progetto che avevi anticipato alla fine del tuo articolo su APC VIA, vero? 😉
In bocca al lupo!
Se non si fosse capito il mio voto per questo progetto di remotizzazione del segnale audio …
Signori, ricordo a tutti che questa settimana, come da regolamento, è utile solo per esprimere voti e non per proporre altre idee di progetto.
Buona votazione a tutti.
Voto questo progetto, interessa molto anche a me
FLAC, qualche nota a margine.
Innanzitutto é bene notare che questo compressore, specifico per il formato audio, é di tipo losslessy (=senza degrado) ed é capace mediamente di comprimere del 50% il segnale ricevuto in ingresso; in questo modo é possibile archiviare la propria raccolta musicale da CD a file .flac senza che nulla venga perduto, potendo all’occasione rimasterizzare un file .flac in una traccia audio equivalente all’originale; per contro, il ben noto formato MP3 é in grado di comprimere del 90% una traccia audio mantenendo una buona fedeltà del segnale originale, a patto di rinunciare alle parte del contenuto audio meno *importante* (ad esempio le frequenze audio al di sotto dei 20Hz ed al di fuori del campo udibile dell’orecchio umano, oltre a tutte quelle frequenze *deboli* che all’ascolto sarebbero oscurate da altri segnali più forti); avete mai notato come il formato dell’MP3 sia stato comunque scarsamente adottato dagli audiofili più accaniti appassionati di musica classica? Negli impianti audio più raffinati gli *artefatti* (potremmo chiamarli gli ‘arrotondamenti’ !) effettuati dal formato MP3 sono percepibili, soprattutto se il segnale originale é molto *ricco* (ad es: orchestra sinfonica con molti strumenti diversi).
Torniamo a noi; Flac é un compressore specifico per l’audio ed é per questo che, con file .wav/.aiff, é in grado di essere molto più efficiente di compressori generici multipurpose (es: zip, bzip, 7zip …).
Ma come fa? Principalmente adotta 2 tecniche :
1) INTER-CHANNEL DECORRELATION [Mi aiutate a tradurlo ?]
I canali stereo (sx e dx) vengono trasformati in un canale centrale (sx+dx)/2 ed uno laterale (sx-dx), questo é un processo reversibile (si riesce sempre a tornare al segnale originale) ed i due canali così ottenuti sono meno ‘variabili’ (le differenze si evidenziano, le uguaglianze o similitudine si azzerano) consentendo una più efficiente compressione.
2) MODELING [anche qui chiedo aiuto al team di traduzione ita-eng]
Tramite una funzione matematica si cerca di approssimare la forma d’onda del segnale audio, in questo modo si dovrà codificare NON l’intero segnale ma solo il polinomio numerico che rappresenta la funzione generatrice della forma d’onda prossima al segnale in ingresso
3) RESIDUAL-CODING (Codifica del segnale residuo)
Viene chiamata residua la differenza tra la funzione di approssimazione ed il segnale in ingresso; quest’ultima parte di dati, essendo frutto di una differenza, sarà più piccola e quindi più facile da comprimere senza perdite (cioé lossless);
A questo punto sorge spontanea la domanda, FLAC può essere il codec adatto ai nostri scopi (compressione in tempo reale di un segnale audio per permetterne la sua trasmissione)?
La risposta purtroppo é NO, questo perché FLAC é un codec asimmetrico (http://flac.sourceforge.net/faq.html#general__asymmetry) privilegia cioé una decodifica semplice e veloce (consentendo quindi anche ad hw poco potenti di riprodurre il proprio formato) penalizzando il tempo di compressione dell’algoritmo di codifica (che deve calcolare una funzione che si avvicina il più possibile alla forma d’onda da comprimere) con ottimi risultati però sul fronte della compressione (dove riesce a raggiungere performance pari se non superiori al 50%).
In realtà la risposta é sicuramente negativa se consideriamo come hardware di compressione il RB PI, chiaramente potendo sfruttare un PC con un processore più potente e veloce e molta più ram (non più i 512 MB della nostra amata schedina, ma qualche GB …) potremmo riuscire ad effettuare la compressione in tempo reale (diciamo entro i 5 ms di tempo che avevamo calcolato) consentendoci quindi di adottare questa soluzione !
Per la decodifica non ci dovrebbero essere problemi di velocità sul RB Pi proprio perché il decoder audio flac é pensato per essere snello e veloce nella parte di compressione!
ECO
Dato che il suono viaggia a circa 340 metri/sec sappiamo che l’eco si genera quando siamo distanti da un soggetto in grado di riflettere il segnale almeno 170 metri (andata+ritorno = 340metri) che Nicola giustamente arrotonda a +100metri perché già prima di raggiungere la soglia (170 metri) si nota un certo fastidio e disturbo.
Le soluzioni ‘commerciali’ indicate usano soluzioni diverse da quelle da noi ipotizzate in quanto modulano il segnale audio (che quindi rimane un segnale analogico) e lo trasmettono su di una portante (trasmessa su di un segnale radio via etere o su di un segnale elettrico tramite cavo conduttore); noi abbiamo scelto una strada ‘digitale’ in cui campionando il segnale audio in ingresso lo trasformiamo in un flusso streaming (quindi in una trasmissione dati binaria) che poi a destinazione riconvertiamo in un segnale analogico che inviamo alle casse audio; non ho idea se la nostra idea sia una soluzione valida, ma se funziona, potremmo avere un discreto successo sul mercato 🙂
Per l’UDP pensavo anch’io al multicast !
Fare una trasmissione 1:1 in unicast ci permette di provare il progetto con un unico ripetitore remoto per poi poterlo espandere ad N ripetitori remoti passando da una trasmissione UNICAST ad una trasmissione MULTICAST.
Che dici, ci proviamo?
Il primo algoritmo in pratica trasforma il segnale in monofonico, dato che l’80% del segnale è monofonico e che le frequenze sotto i 500 Hz non sono particolarmente direttive è inutile trasmetterle in stereo, poi sulla differenza fra questo segnale e il Dx – Sx calcola una nuova forma d’onda che serve per ricostruire la stereofonia.
Il segnale poi viene approssimato con una funzione numerica, e quindi si ottiene la differenza con il segnale reale come funzione d’errore.
Più o meno tutti i codec sono asimmetrici o fortemente asimmetrici, perchè nella fase di compressione occorre analizzare il segnale per capire quale è la tecnica migliore di compressione, mentre in decompressione le istruzioni sono solo da eseguire!
Ma scusa…se non ce la fa ad abbonarsi che succede?
Posso chiedere sia a te sia ad Emanuele conferma del fatto che l’abbonamento di questo utente sia pervenuto in tempo utile?
Vi ricordo che queste sono le ultime ore per esprimere le vostre preferenze 😉
Intanto confermiamo il suo abbonamento e poi vediamo 😉
Si si, s’era capito eccome 😉
Annuncio che il vincitore è Antonio Blescia. 🙂
Complimenti.
Come sempre, che il vincitore contatti Emanuele, utilizzando il modulo “Contact” per info e ulteriori dettagli.
Buon lavoro.
A tutti gli altri, non perdetevi d’animo: ci sono ancora altri Raspberry Pi in palio.
La competizione continua 😉