Il Pi Pico Rx è un ricevitore SDR open source capace di coprire le bande relative alle onde lunghe, medie e corte, dando la possibilità di ricevere segnali dalla metà del globo. Si tratta di un ricevitore SDR minimale costruito attorno al Raspberry Pi Pico. Pur non essendo un'idea completamente nuova, le caratteristiche introdotte da Pi Pico Rx non si trovano in altri design simili. Andremo a descrivere il funzionamento generale e il design hardware in questo articolo, lasciando la descrizione della parte software per un prossimo intervento.
Introduzione
Realizzare un ricevitore radio definito dal software (SDR) è un processo relativamente semplice, se si hanno un adeguato front-end radio ed i giusti convertitori analogico-digitali. Due flussi di dati separati vengono generati utilizzando due clock con uno sfasamento di 90° tra loro, e questi vengono poi passati all'elaborazione software del segnale per la demodulazione.
Il ricevitore SDR, Pi Pico Rx, presenta un'architettura standard optando per un front-end radio realizzato con un Quadrature Sampling Detector, un solo ADC integrato nell'RP2040 e l'elaborazione del segnale eseguita dalla CPU di quest'ultimo.
Le caratteristiche più importanti del ricevitore SDR, Pi Pico Rx, sono:
- copertura radio da 0 a 30 MHz
- larghezza di banda di 250 kHz
- ricezione delle modulazioni CW/SSB/FM/AM
- display OLED
- cuffie/altoparlante
- alimentato da 3 batterie AAA
- consumo di corrente inferiore a 50 mA
Funzionamento generale
La Figura 1 riporta lo schema a blocchi del ricevitore SDR, Pi Pico Rx.
Figura 1: Schema a blocchi del ricevitore SDR, Pi Pico Rx
Il segnale proveniente dall'antenna viene dato in ingresso ad un filtro passa-banda (BPF). A seguire, invece di un tradizionale mixer, il progetto sfrutta un Quadrature Sampling Detector (QSD), ovvero un rilevatore di campionamento in quadratura, implementato con il popolare circuito rilevatore Tayloe. Utilizzato in molti progetti di radio HF SDR, questo semplice circuito consente di implementare un mixer di alta qualità utilizzando un economico commutatore analogico (multiplexer).
I segnali di controllo del multiplexer si devono comportare come un oscillatore in quadratura. Per fare ciò, è stata utilizzata la funzionalità PIO dell'RP2040. Ciò ha eliminato la necessità di utilizzare un oscillatore programmabile esterno. Senza dover overclockare il dispositivo, supporta frequenze fino a circa 30 MHz, coprendo comodamente le bande delle onde corte, medie e lunghe.
L'uscita IQ dal QSD viene amplificata utilizzando un amplificatore operazionale ad alta velocità e basso rumore. I canali I e Q vengono campionati dall'ADC integrato che fornisce 250 kHz di larghezza di banda. Il processore ARM Cortex M0 dual-core implementa gli algoritmi di elaborazione del segnale digitale (DSP), demodulando AM, FM, SSB e CW per produrre un'uscita audio.
L'uscita audio viene fornita utilizzando un segnale PWM seguito da un filtro passa-basso. Per mezzo di un resistore di limitazione della corrente è possibile adattare il pin IO in modo da pilotare direttamente un paio di cuffie o persino un piccolo altoparlante senza bisogno di un amplificatore audio.
Un prototipo assemblato alla buona, dimostra che è possibile costruire un ricevitore HF SDR utilizzando un Pi Pico, un commutatore analogico, un amplificatore operazionale e una manciata di componenti discreti.
Campionamento round-robin
Una delle sfide affrontate nel progetto del ricevitore, è stata il campionamento dei segnali I e Q utilizzando un ADC in grado di campionare solo un canale alla volta. Il convertitore può essere configurato in modalità round-robin in modo da campionare i segnali I e Q in maniera alternata. Le preoccupazioni riguardanti questo approccio erano che si potesse creare uno squilibrio di fase tra i canali I e Q.
Normalmente, un segnale complesso con larghezza di banda W può essere campionato a frequenza W, questo perché ogni campione complesso sarà in realtà come due campioni reali, quindi non si infrange il criterio di Nyquist. Nel caso di questo progetto, campionando a frequenza 2W è possibile evitare lo squilibrio di fase tra I e Q. Per recuperare il segnale complesso con una larghezza di banda di 250 kHz basterà quindi campionare I e Q alternativamente a 500 kS/s.
Prima però occorre filtrare i dati I e Q con un passa-basso che lasci passare 250 kHz di larghezza di banda da -125 kHz a 125 kHz. Il rilevatore QSD stesso forma un filtro passa-basso, quindi questo può essere facilmente ottenuto selezionando valori di condensatore adatti nell'amplificatore operazionale. L'ADC è configurato per campionare I e Q alternativamente (a partire da I). Nel software, i valori "mancanti" possono essere sostituiti da zeri.
Ciò si traduce in un segnale complesso con una frequenza di campionamento di 500 KS/s. Per recuperare lo spettro originale, basta semplicemente filtrare il segnale con un passa-basso. Decimando si potrà poi ridurre la frequenza di campionamento a 250 kHz.
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2001 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.
Ti potrebbe interessare anche:
Come discriminare gli asintomatici Covid da un colpo di tosse
Firmware 2.0 #33: Aerospace & Defence – Sensors Applications
La rivoluzione delle reti LoRaWAN nelle applicazioni IoT Industriali (IIoT)
Architetture e soluzioni di edge computing
I Dispositivi Indossabili nell’Health Coaching: Tra Innovazione e Sfide
” sono 3 PCB in totale. I file Gerber per i PCB possono essere trovati qui, qui e qui.”
il primo qui non funziona , restituisce 404, il secondo e terzo qui vanno bene
Salve, a causa di aggiornamenti sono combiati i link, Ecco i nuovi link per i PCB:
https://github.com/dawsonjon/PicoRX/raw/refs/heads/master/PCB/back_panel/gerbers/back_panel.zip
https://github.com/dawsonjon/PicoRX/raw/refs/heads/master/PCB/front_panel/gerbers/front_panel.zip
https://github.com/dawsonjon/PicoRX/raw/refs/heads/master/PCB/pico_rx/gerbers/pipicorx.zip
Questo link per il firmware:
https://github.com/dawsonjon/PicoRX/releases
Grazie
purtroppo cliccando al “Il firmware caricabile tramite USB per Pi Pico può essere trovato qui.” viene dato errore 404,
Si spera che tale stato venga risolto nell’immediato
grazie
Ok grazie per il nuovo link per il firmware, grazie
Però caricando il file binario di cui allo ZIP “binaries-rp2040-pico.zip” sul raspberry pi pico, pur andando in porto l’operazione e quindi attivandosi le funzionalità visibili a display e comandabili da interfaccia utente (pulsanti ed encoder), “sembrerebbe” NON FUNZIONARE la comunicazione a 3 bit verso la commutazione dei filtri LPF di ingresso, In pratica sui tre pin 4, 5 e 6 della schedina processore e da interconnettere verso il SN74CBT3251 per comandare la commutazione, permane sempre lo stato “zero zero zero” qualunque banda si vada a selezionare a menu mentre ci si aspetterebbe, ovviamente, il variare delle combinazioni a 3 bit (8 combinazioni di zero e uno),
Al momento tali prove e verifiche le ho effettuate senza ancora interconnettere il SN74CBT3251 ed anzi non connettendo nulla ai pin 4, 5 e 6 della schedina Pico se non i puntali del tester e tali prove le ho effettuate con due diverse schedine raspberry Pico, entrambi originali e con il file binario caricato.
Sicuramente starò commettendo un errore io per cui mi sono espresso in forma dubitativa, Mi occorrerebbe quindi un aiuto in merito per poter far funzionare il tutto e capire ove sto sbagliando,
grazie infinite
OK doverosamente informo che ho capito che sbagliavo nell’utilizzo del corretto menu, Non stavo selezionando una fase attuativa, Utilizzando correttamente il menu il firmware funziona perfettamente anche per la funzione di commutazione filtri LPF.
Per concludere avrei una ultima domanda e cioè se i valori dei componenti sono corretti quelli nei file PDF o quelli sulle schema nell’articolo. Specificatamente mi sto riferendo alle resistenze R3, R4, R7 e R8 in quanto di diverso valore tra figura 2 dell’articolo con i valori riportati nel file PDF.
grazie
Salve,
Con riferimento all’ RX pico mi rivolgo all’autore della pubblicazione su “elettronica open source”, oltre per ringraziarlo degli interessanti articoli, per chiedere se ha la fruibilita’ anche del firmware dell’upgrade alle funzionalità descritte nella parte 4 della pubblicazione sul sito “101”.
Sicuramente tale possibilita’ interessante a molti di quelli che hanno letto gli articoli su “elettronica open source”.
Grazie
Salve e grazie. Riguardo alla sua richiesta mi sembra di aver capito che cerca l’upgrade al software per implementare le funzionalità del decoder SSTV. Io non ho nelle mie disponibilità il software, ma posso rimandarla a due link:
1) questo è il link alla pagina github del progetto SSTV:
https://github.com/dawsonjon/PicoSSTV
2) mentre a seguire il link per il codice del progetto:
git clone https://github.com/dawsonjon/PicoSSTV.git
Non so se era questo che chiedeva, ma spero di esserle stato di aiuto.
Buongiorno,
Sicuramente utile per l’altra applicazione.
In realta’ mi riferivo al firmware relativo all’upgrade hardware, sempre descritto nella parte 4 dello stesso articolo, che implementa, in opzione configurabile, il PLL SI5351 e prevede la funzionalita’ di impostazione del valore della IF nonche’ un nuovo layout di visualizzazione sul display TFT. Chiaramente non so o forse non avevo compreso se il firmware a cui mi riferivo venga ad essere lo stesso per ricevere la SSTV.
Grazie
Renato IU0MTL
Per quanto riguarda l’impostazione della IF leggo che:
“L’ultimo firmware offre la possibilità di ignorare l’impostazione IF predefinita, consentendo all’utente di scegliere la propria frequenza IF”
Quindi credo sia a questo indirizzo:
https://github.com/dawsonjon/PicoRX/releases
Per quanto riguarda l’oscillatore esterno SI5351, leggo che :
“Vale la pena notare che l’oscillatore esterno è un’opzione sperimentale e non è necessario per costruire il ricevitore. Il firmware è completamente retro compatibile, ma l’oscillatore interno basato su PIO rimane l’opzione più semplice e consigliata per la maggior parte degli utenti.”
Quindi il firmware aggiornato dovrebbe andare bene
Per quanto riguarda il TFT, leggo che:
“Il software precedente includeva un display TFT secondario che poteva essere utilizzato per visualizzare un oscilloscopio e un waterfall. Sono stati apportati alcuni miglioramenti visibili all’interfaccia utente, tra cui una manopola di sintonia in stile retrò e un indicatore di intensità del segnale. Dietro le quinte, il driver TFT è stato ampiamente rielaborato per migliorarne l’affidabilità e le prestazioni.”
Credo che il driver TFT sia compreso nell’aggiornamento del firmware, anche se non ci metto la mano sul fuoco.
Grazie per la chiara e rapida risposta.
Avevo chiesto in merito perché io ho gia caricato il firmware rilasciato il 5 dicembre 2024 e specificatamente il file binario uf2 che, salvo miei errori, è risultato allineato alla pubblicazione “part 3” e quindi compendia solo l’aggiunta del display secondario ma non le modifiche di interfaccia utente, né la gestione dell’SI5351 e né la configurazione del valore dell”IF nel BW 0÷9 KHz ove quest’ultimo, permetterebbe sicuramente una ottimizzazione di problematiche di Aliasing e similia. Chiarisco che sicuramente concordo che con il sistema di generazione dei due segnali di oscillatore locale a “bordo” pico si ha un progetto hardware nettamente piu’ semplice ed economico, rispetto all’utilizzo dell’SI5351 e coerente pienamente con lo spirito del progetto originale che addirittura parte da una realizzazione minimale su breadboard. Infatti l’ho gia’ realizzato su breadboard e ne sono rimasto molto soddisfatto. Pero’ adesso sono nella fase di tentativo sperimentale di implementazione di ottimizzazioni funzionali e di caratteristiche… ovviamente se possibile o se ne saro’ capace … e tra questi i punti su cui vorrei agire sono:
– aumento del filtraggio antialiasing tramite miglioramento della pendenza e stop band del filtro passa basso in BF inserendo un LPF attivo in cascata dell’amplificatore filtro BF gia’ in essere (aggiungendo un altro operazionale sul circuito Q e uno su I con resistori e capacitori rigorosamente selezionati e i due operazionali da single chip per minimizzare le differenze di sfasamento tra i due canali che verrebbero introdotte)
– possibilita’ (firmware) di configurazione del valore della frequenza IF
– riduzione del noise generato dal circuito switching del DC/DC di bordo del display OLED SSD1306 e dell’opzionale TFT (modifica hardware bordo display come effettuata e documentata, limitatamente al SSD1306, nel progetto del (tr)uSDX)
– riduzione del noise potenzialmente derivante dal DC/DC bordo board pico realizzata o tramite la rimozione dell’integrato switching e sostituzione con un DC/DC lineare oppure con alimentazione diretta e solo a 3.3 V sul pin 36 del Pico e non a 5V da pin 38.
– opzionalita’ di scelta alimentazione 3.3 volt o 5 volt degli stadi di rivelazione in quadratura e amplificatore BF da circa 60 dB in cascata e opzionalita’ di scelta tra varie soluzioni per rendere compatibile l’output di una configurazione con DC a 5 volt con le porte del Pico (max 3.3 volt o poco meno) dato che dagli schemi sul web la soluzione realizzata con il partizionamento resistivo, sicuramente efficiente per l’obiettivo di interfacciamento elettrico tra gli amp. con DC a 5 V, penso verrebbe potenzialmente ad introdurre un “abbassamento del livello del segnale” e vorrei valutare se si ha una attenuazione (max. 3 dB? non lo so e vorrei valutarlo).
– schermatura e filtraggio dei circuiti I2C e SPI (nei limiti di funzionalita’ dalla comunicazione ekettrica) per attenuare e rendere non percettibile il noise generato da tali circuiti (come pesantemente presente, come un “pump pump”, quando viene aggiornato il display, in alcuni ricevitori SDR acquistabili e che usano I2C e display OLED SSD1301 che credo gia’ eliminata o ridotta ai minimi termini dal progetto dei PCB pubblicati sul nostro “elettronica open source”)
Infatti all’uopo sto realizzando un hardware “piattaforma” per permettere tutte queste sperimentazioni con scopo di “studio” e sicuramente non di miniaturizzazione o costi .
Chiedo scusa per le mie lungaggini ma volevo condividere del perche’ sto cercando anche il firmware di cui sul sito “…101” viene data anticipazione e pubblicate delle immagini e cio’ anche se in forma sperimentale .
A me fa piacere che l’articolo risulti interessante e che ci siano persone come lei interessate alla tematica SDR. Mi dispiace non poterle essere di ulteriore aiuto.
Si veramente stimolante e devo ringraziarla sia per l’articolo che per la chiarezza e trasparenza. La tematica SDR la trovo avvincente e sicuramente per me da approfondire in ambito “home made”
Buongiorno Andrea,
Nella mia realizzazione del PI PICO ho inserito un filtro hardware antialiasing ulteriore (2° ordine in cascata a quello del 1° ordine dopo il QSD e realizzato con componentistica selezionata per assicurare uno scostamento dei valori di ciascun componente al massimo dell 1 × 1000) e funzionale bene e non inficia lo sfasamento di 90 gradi tra I e Q.
Per chiarezza io, il ricevitore, l’ ho realizzato secondo lo schema che prevede un BW di +/- 12 KHz e non secondo quello a larga banda.
Un problema che riscontro, anzi piu’ che un problema penso trattasi di funzionamento fisiologico ma magari se mi potrai confermare o spiegare diversamente (… grazie in anticipo), si rileva un significativo tempo di “mute” ad ogni step di cambio frequenza e cio’ si risente abbastanza quando si vuole fare una esplorazione di banda manualmente…. ci si deve fermare ad ogni step e attendere il ritorno dell’audio se si vuol sentire cosa c’è a quella frequenza ma che diventa fortemente incisivo se si sta cercando di sintonizzare con step piccoli ad esempio per una Isoonda in modalita’ SSB.
Io ipotizzo (ma potrei sbagliarmi) che tale tangibile tempo di mute derivi proprio dalla scelta architetturale di generare i due segnali di oscillatore locale a bordo di uno dei due “core” del Pico (stop e start di vari moduli firmware ad ogni step della sintonia) e che quindi non si possa risolvere in questa architettura ma solo passando ad un PLL esterno. Se non ho sbagliato con le mie empiriche deduzioni, non supportate da una mia reale conoscenza del firmware in questione, mi verrebbe da pensare che quanto veniva presentato nella parte 4 dell’articolo di John e che prevedeva l’uso dell’ SI5351 come PLL potesse risolvere tale problema. Chiaramente parlo di un problema che riscontro io e non vorrei (… anzi forse vorrei…) che fosse presente solo sul mio hardware (ho fatto parecchi pasticciamenti atti ad ottenere una piattaforma HW modulare plug-in con molti disaccoppiamenti EMI in maniera da poter fare una serie di prove con modifiche HW) .
Concludendo starei chiedendo se questo significativo tempo di mute lo si riscontra tutti e quindi se si ha notizia di previsione di quando sara’ rilasciata la nuova release FW che gestisca il PLL esterno con SI5351 (o magari si avesse una beta release anche in uno stato di avanzamento da debuggare).
Se non ho completamente sbagliato…. e se il problema del mute non lo abbia genersto io con le mie modifiche HW …. sicuramente con la riduzione del mute si avrebbe una ulteriore performance su questo progetto che è molto interessante e stimolante.
Grazie da IU0MTL Renato
Buongiorno Renato, devo dire che dal giorno in cui ho scritto l’articolo il progetto di John ha subito molte modifiche e miglioramenti di cui non ho seguito le evoluzioni. Da questo punto di vista lei è ormai è molto più esperto di me a tal proposito. Detto questo, da quel che ho capito, credo che l’uso del SI5351 sia per l’autore una scelta di pura sperimentazione e che il progetto dovrebbe funzionare bene con l’oscillatore locale implementato su uno dei core del Pico.
Su due piedi quindi mi sentirei di consigliare di rivedere la sua implementazione hardware, visto che lei stesso dici di aver aggiunto elementi per ottenere “una piattaforma HW modulare plug-in con molti disaccoppiamenti EMI in maniera da poter fare una serie di prove con modifiche HW”.
Mi piacerebbe poterle dare una risposta esaustiva, ma data la complessità del progetto non riesco a poter essere più utile di così.
Grazie Andrea. Quindi ipotizzando di rivedere gli upgrade HW stiamo assumendo che il progetto originale di john non ha tempo eccessivo di mute?
Se ne è sicuro ok altrimenti ci metto poco e realizzo su Bread board esattamente il progetto originale per vedere se senza alcuna minima modifica questo tempo di mute persiste…. io personalmente pur non escludendo miei eventuali pasticci…
non mi sento di poter escludere che ad ogni step di sintonia il firmware reinizializzi i moduli firmware inerenti e quindi interrompa anche la processazi9ne del segnale e il PWM dell’audio. Secondo me prima di metterci mano pesantemente conviene che faccio un test con copia esatta di quanto previsto su bread board ..
Cosa che sto gia’ facendo e presto magari scriverò i risultati ,
Grazie e buona giornata,
Buongiorno e buona domenica,
Ho realizzato un esemplare su bread board rigorosamente cone da progetto originale con alimentazione a 5.0 vdc per l’ FST3253 (da datasheet tensione minima 4 Vdc) e quindi con partitore resistivo input all’ADC per rendere compatibile il range di tensioni.
Risultato purtroppo che quanto si presentava sulla mia rielaborazione hardware (avevo fatto tante piccole modifiche atte a, …. teoricamente …,, abbattere potenziali fenomeni di aliasing etc etc ) si è riscontrato precisamente anche secondo progetto originale. Quindi in soldoni:
– tempo di mute significativo ad ogni step di tuning
– impallamento e necessita’ di reboot durante un uso del tuning manuale .
Quindi vorrei chiederei se il problema al secondo punto qui sopra e quindi “l’impallamento” lo avete riscontrato anche sul vostro prototipo?
Chiedo cio’ dato che spero che sia sempre qualche problema che derivi dalle mie realizzazioni anche se credo che questa volta la mia qualita’ tecnica non sia la responsabile.
Grazie
Renato IU0MTL