@ Rossi
il tono 1750 è tipico di apparati radioamatoriali, privilegiando
l'attivazione con tale sistema resterebbero tagliati fuori gli utilizzatori
di apparati di altro genere.
Il circuito del quale parli è un COR?

Il circuito è molto più semplice di un cor, non è invasivo per la radio poiché sfrutta l'uscita audio ed è costituito da un decoder (lm567 appunto) che cambia lo stato logico nel momento in cui percepisce la frequenza per cui è tarato.
Si può pensare anche ad un decoder con Mt8870 dtmf però il solo doppio colpo di portante (a meno che non sia protetto da toni digitali dcs) è pericoloso, si rischia di esporre la radio ai disturbi qrm e di avere degli annunci abusivi non richiesti che impegnano la frequenza involontariamente.
Comunque è vero che la maggior parte delle radio radioamatoriali ha il tono a 1750hz ma anche qualche LPD di uso obbistico ... Vedi Alinco la serie DJ e djs .

Si in effetti un COR è un'esagerazione ... l'attivazione con tre colpi di portante comunque non mi sembra pericolosa. Sulla banda aeronautica starei tranquillo, dando al massimo una buona dose di squelch il problema è risolto.
Sulle altre frequenze invece concordo sull'utilizzo di toni DCS o subaudio, soluzione che già adotto su una vecchia stazione meteo.
La bella idea di Tony di portare l'input audio via USB è molto semplice e funzionale a parer mio, per esempio ho visto delle sound board USB con ingresso microfonico, molte di esse compatibili con Linux. Il modo semplice di far "entrare" l'audio nella raspberry quindi esiste, ad "uscire" via radio ci penserebbe poi il solito VOX. Il problema è farlo elaborare dal sistema. Aggiungo che, secondo una consuetudine aeronautica, i due colpi di portante vengono spesso dati dal pilota in certe fasi del volo in segno di "ok ... eseguo ... è chiaro". Il sistema dovrebbe quindi attivarsi almeno su tre o quattro colpi consecutivi di portante, non di meno.

Bisogna coordinarsi con Tony il quale ha già inquadrato il problema e che con una tale disinvoltura qualche post più su ha scritto che "... poi non sarebbe difficile in python rilevare la portante o il bip"
Sto imparando tantissimo da voi esperti ma sono ancora qualche anno luce indietro ...

Già ... portare l'audio al raspberry per poi elaborare via software le richieste di sicuro sarebbe la soluzione più elegante in tutti i sensi.
Però credo che non sia così "facile" da implementare sia a livello di sistema operativo (drivers) e sia a livello di programma.

E' invece semplice, solo con un paio di modifiche al SW SWPI, ottenere già questo tipo di funzionalità.

Mi spiego meglio.

La prima eliminare il vox (o renderlo facoltativo) tramite un comando che al momento dell'annuncio attivi un pin dell I/O del raspberry e lo spenga a fine del messaggio.
Al pin interessato basterebbe collegare un transistor e una resistenza per avere già il P.T.T. senza più dover utilizzare il VOX, rendendo più precisa e meno problematica l'attivazione della radio e si potrebbero utilizzare anche quelle sprovviste di VOX.

La seconda è quella di implementare appunto il messaggio su richiesta tramite sempre un pin in ascolto al cambiamento del livello logico,
se sente il cambiamento allora fa partire il messaggio.
Poi che lo si attivi via decoder dtmf o via tono a 1750hz oppure via colpo di portante il compito viene lasciato al circuito che viene collegato dietro.

spero di essere stato chiaro ho scritto dal cellulare ...

Rossi wrote: Già ... portare l'audio al raspberry per poi elaborare via software le richieste di sicuro sarebbe la soluzione più elegante in tutti i sensi.
Però credo che non sia così "facile" da implementare sia a livello di sistema operativo (drivers) e sia a livello di programma.

E' invece semplice, solo con un paio di modifiche al SW SWPI, ottenere già questo tipo di funzionalità.

Mi spiego meglio.

La prima eliminare il vox (o renderlo facoltativo) tramite un comando che al momento dell'annuncio attivi un pin dell I/O del raspberry e lo spenga a fine del messaggio.
Al pin interessato basterebbe collegare un transistor e una resistenza per avere già il P.T.T. senza più dover utilizzare il VOX, rendendo più precisa e meno problematica l'attivazione della radio e si potrebbero utilizzare anche quelle sprovviste di VOX.

La seconda è quella di implementare appunto il messaggio su richiesta tramite sempre un pin in ascolto al cambiamento del livello logico,
se sente il cambiamento allora fa partire il messaggio.
Poi che lo si attivi via decoder dtmf o via tono a 1750hz oppure via colpo di portante il compito viene lasciato al circuito che viene collegato dietro.

spero di essere stato chiaro ho scritto dal cellulare ...

Scusa la domanda, è molto difficile creare un circuito che collegato alla Bf della radio possa cambiare lo stato logico con 3 colpi ti portante ?

No.
Non lo è affatto. Però se si vuol aggiungere un minimo di sicurezza, è meglio farlo bene, cioè con una base di tempi in relazione ai colpi di portante.
In più bisogna vedere come far rilevare la portante, se con un semplice squelch oppure mediante subaudio, oppure penso alla spia sulla radio che si accende in caso di segnale rilevato.
Cercavo invece di `svincolarmi` dal tipo di radio e rendere La funzione universale.
Comunque ci si può ragionare.

Buonasera amici, leggo ora che è possibile permettere invio di messaggi radio. Questo vuol dire che in qualche modo dall'uscita audio laterale è possibile far venir fuori dei messaggi mp3. Vorrei sapere come è possibile attivarli. Essendo radioamatore, la cosa mi interessa alquanto. sempre grazie.

attivandoli semplicemente dalla pagina di configurazione!

Grazie per la risposta.
Dunque immagino ci sia un file in cui si trovano i file audio..
Posso chiedere come raggiungere questa directory? Si possono inviare messaggi solo per il vento?
Perdonatemi per le numerose domande ma questo swpi è fantastico ma purtroppo ho gravi mancanze in materia linux e quindi non ho dimestichezza..
chiedo scusa per il disturbo.

Sono una serie di files che compongono una frase in base alle condizioni meteo del momento.

Si, swpi nasce proprio con il messaggio solo per il vento, poi è stato implementato il resto ed è possibile la scelta attraverso sempre la pagina di configurazione.

@iw7eex
ciao, il messaggio audio si compone di una serie di file audio contenuti nelle cartelle audio. La cartella mp3 contiene i file destinati alla sintesi vocale via radio.
Nell'ordine, prima di tutto devi aprire il file swpi.cfg (il comando è "nano swpi.cfg" e nella parte [Radio], alla voce useradio = dovrai mettere valore "True", alla voce radiointerval = metterai il numero di secondi trascorsi i quali il messaggio radio sarà trasmesso via radio, io per esempio ho impostato useradio = 900 valore pari a 15 minuti.
Alla voce radio_verbosity = hai tre possibilità, a seconda del tipo di messaggio che vuoi.
Se scegli "only_wind" avrai un messaggio composto dai soli dati del vento, cioè direzione e velocità.
Se scegli il valore "all" avrai quasi tutti i dati che SWPI è in grado di elaborare: direzione e velocità del vento, temperatura, pressione atmosferica, umidità e base cumulo.
Scegliendo invece valore "motor" avrai un tipo di messaggio vicino alle esigenze di chi vola, con la denominazione aeronautica di alcuni dei dati. Avrai quindi: direzione e velocità del vento, temperatura, dewpoint (temperatura di rugiada), QNH (pressione atmosferica relativa, ovvero riferita al livello del mare), QFE (pressione atmosferica assoluta ovvero quella rilevata nel posto in cui è installata la tua stazione, umidità e base cumulo.
A SWPI puoi fare dire quello che vuoi e nell'ordine in cui lo preferisci.

Una volta settato swpi.cfg ti serve una radio con la funzione VOX attivata. Collegherai quindi con uno spinotto audio da 3,5mm l'uscita audio di raspberry all'ingresso microfono della radio e non dovrai fare altro che aspettare che trascorrano i minuti da te settati per sentire il messaggio audio.
Ciao

grazie mille per le info. sì in effetti ho visto i settaggi anche tramite interfaccia web. però sto riscontrando un problema. Mentre la gentile Jessica elenca i dati, sullo schermo della swpi leggo erro file not found : ./audio/mp3/message.mp3 addirittura spesso dice che non riconosce il format del file e riavvia tutto. dice something wrong in radio.. e riavvia..

Grazie tony. Purtroppo continuo a riscontrare errori che addirittura fanno riavviare raspberry. Dice MODULE FORMAT NOT RECOGNISED. Allego foto per essere più preciso

Dunque nella finestra RADIO ho ovviamente true 200 all.

Non so se può centrare la finestra RFM01 comunque mai toccata e compare: 315 - 0 - 134 - 97

Grazie.

only wind funge bene. Quando metto all. Il caos.

ma questa stringa

pygame.mixer.music.load(soundfile)

è giusta o bisogna indicare qualcosa al posto di soundfile tra le parentesi?

Ok credo comunque che dipenda dal fatto che ci siano ancora stringhe con .raw in radio.py.

Ma se io per eccesso di zelo in caso di pioggia volessi aggiungere lo speech che elenca il dato preciso della pioggia dovrei compilare in questo modo e creare il relativo mp3?

if( globalvars.meteo_data.rain_rate_1h != None and globalvars.meteo_data.rain_rate_1h = 0.100 ):
listOfMessages.append("./audio/mp3/raining_100.mp3")

---

f( globalvars.meteo_data.rain_rate_1h != None and globalvars.meteo_data.rain_rate_1h = 0.200 ):
listOfMessages.append("./audio/mp3/raining_200.mp3")

---

e così via fino ad un massimo che si decide magari chiudendo con una stringa del genere

f( globalvars.meteo_data.rain_rate_1h != None and globalvars.meteo_data.rain_rate_1h >= 10.000 ):
listOfMessages.append("./audio/mp3/raining_over.mp3")

in cui il file mp3 magari dice : precipitazione superiore ai 10 mm.

vorrei fare qualche prova e magari sottoporla al tuo esame. In caso affermativo metterlo come aggiornamento.

spero di essere utile.

Qualcuno gentilmente potrebbe darmi qualche link dove vi sono dei circuiti per rilevare la portante con squelch.... senza toni sub audio o simili..
Grazie in anticipo....

Ciao Tony,
facendo uno dei miei soliti aggiustamenti del messaggio radio ho notato una differenza tra file swpi.py e radio.py. Dove swpi.py dice cfg.wind_trend_limit, radio.py dice invece self.cfg.wind_trend_limit. Deve esserci differenza tra i due file?

swpi.py

if ( globalvars.meteo_data.wind_trend != None ):
if ( globalvars.meteo_data.wind_trend < - cfg.wind_trend_limit) :
listOfMessages.append("./audio/winddown.raw")
if ( globalvars.meteo_data.wind_trend > cfg.wind_trend_limit) :
listOfMessages.append("./audio/windup.raw")


radio.py

if ( globalvars.meteo_data.wind_trend != None ):
if ( globalvars.meteo_data.wind_trend < - self.cfg.wind_trend_limit) :
listOfMessages.append("./audio/mp3/winddown.mp3")
if ( globalvars.meteo_data.wind_trend > self.cfg.wind_trend_limit) :
listOfMessages.append("./audio/mp3/windup.mp3")

Ciao Tony,
vedo che nel file swpi.cfg viene ora fatto riferimento alla scelta PTT. E' già implementata tale funzione?
Grazie
Pietro

Ciao Tony,
vedo che nel file swpi.cfg nella parte RADIO viene ora fatto riferimento alla scelta PTT. E' già implementata tale funzione?
Grazie
Pietro