IW0FKO 1

IW0FKO 1
... le mie esperienze, la mia passione ....

giovedì 26 marzo 2026

SISMA

L'idea di geolocalizzare un evento sismico sul circuito A.P.R.S. non è farina del mio sacco, si tratta di un servizio che dalla fine degli anni 90 fino alla prima decade (circa) del ventunesimo secolo era gestito via RF (se non ricordo male) da un sysop dell'area 3. L'idea era quella di riprendere questa preziosa idea e riproporla affinchè potesse essere inserita in un quadro emergenziale ed usata come supporto alla logistica  di quegli operatori che in caso di calamità sono chiamati a supporto della Protezione Civile.

Dagli anni 90 l'A.P.R.S. ha subito enormi mutazioni, questo ha posto durante lo sviluppo di quessto progetto parecchi ostacoli, infatti la mia idea era quella di veicolare queste informazioni via RF, cosa che all'epoca, con il vecchio paradigma, trovava terreno fertile, mandare un messaggio dal Friuli alla Sicilia era la normalità, oggi non lo è più.

Ad ogni modo, il 24 settembre 2025, dopo un primo accenno con uno script scritto da Fabrizio IZ0ORT, ho portato questa idea all'attenzione di Biagio IT9FDP a cui devo veramente tanto; è lui che di fatto ha dato vita a questo servizio. 

I primi "vagiti" sono avvenuti comunicando le informazioni ricevute dall'INGV direttamente al server aprs.is, che poi le avrebbe geolocalizzate su mappa. Grazie a questa opportunità abbiamo avuto modo di affinare i bug che si presentavano ottimizzando e modellando il processo con gli standard che ci eravamo proposti

Primo evento notificato al server 

Il 7 ottobre iniziammo a lavorare sulla parte RF, (la vera regina di questa idea!) il sistema non aveva ancora un nome che lo identificasse, la rosa era di tre nomi; Quake, Earthquake e Sisma. Fu scelto Sisma, questo identificativo fu utilizzato anche per un indirizzo unproto fuori dagli standard WIDEn-N. Il path ufficiale sarebbe stato SISMA5-5, questo indirizzo avrebbe trasportato le informazioni trasmesse dal sistema, logicamente questo comportava anche un settaggio ad hoc da parte di quei sistemi che avrebbero dovuto ricevere e veicolare le informazioni.

Prima trsmissione ufficiale in RF del 31 Dicembre 2025

Inizialmente abbiamo attivato alcuni sistemi locali che configurammo per ricevere queste informazioni e ripeterle a loro volta in RF, l'idea era quella che queste informazioni sarebbero dovute essere ricevute da una ipotetica stazione locata in zone non coperte o laddove la rete telefonica era collassata. 

Come dicevo all'inizio, il nuovo paradigma non permette più di veicolare le informazioni oltre i 2 salti, si è pensato quindi di creare un nuovo path che desse modo a queste informazioni di raggiungere maggiori distanze dal punto di partenza, il SISMA5-5 teoricamente a questo dovrebbe  portare. Attualmente esiste un link verso tutto il Lazio, ed alcune regioni limitrofe, logicamente aggiungendo questo path all'interno di un sistema digipeater, si avrà modo di veicolare queste informazioni via RF nel caso in cui venissero in qualche modo ricevute.

I sistemi su cui abbiamo avuto modo di relizzare questo nuovo path, con successo sono UiDigi, PLXDigi, WX3 e Direwolf

Setup tipo in UiDigi
 

Configurazione tipo in PlxDigi, WX2 e WX3 Microsat

Configurazione tipo in Direwolf

Contestualmente è stata logicamente provata la geolocalizzazione su mappa con i terminali UiView, APRSIS32, APRSdroid e PinPoint. Quest'ultimo aveva un bug che non gli permetteva di visualizzare su mappa propria gli oggetti generati e ricevuti da altri sistemi (Object beacon), ho così scritto all'autore Frank Watervoort  il quale tempestivamente, lavorando su un aggiornamento del software ha risolto il problema rendendo PinPoint efficace nell'utilizzo in queste condizioni. Oggi si può scaricare il suo aggiornamento a questo link https://pinpointaprs.com/Pinpoint_v2.1_build_260222.msi

Il sistema è ancora in fase test, nonostente ciò il suo sviluppo di per se non è andato oltre in quanto sono stati raggiunti tutti gli obbiettivi che ci eravamo proposti, le informazioni ricevute da INGV oggi viaggiano ogni 30 minuti e per due giorni dall'evento sia su server aprs.is che in RF sulle bande A.P.R.S. 144.800MHz e 432.500MHz, gli eventi ricevuti sono circoscritti ai soli confini nazionali, questo per non creare conflitti con altre realtà simili sparse per il mondo, non avrebbe senso sovrapporsi al lavoro di altri.

Ringrazio Fabrizio IZ0ORT ed il grande Biagio il cui lavoro è stato determinante alla realizzazione dell'intero progetto. Doverosi ringraziamenti vanno anche ai colleghi che si sono prestati ai primi test in RF quali IK0JJX, IK0BVM, IU0REK, IW0FZP, IZ8FAV, IZ0CWW, IW0REF e IT9ELT, non ultimo Frank AB0WV per aver messo mano al bug sul suo PinPoint.


mercoledì 11 marzo 2026

Messaggi verso WhatsApp da client via RF

 

Come già avviene con l'inoltro di E-mail o SMS da client APRS (vedi post ottobre 2022), è possibile inviare anche un testo con un massimo di 50 caratteri verso un gateway che veicola poi le informazioni inviate sull'applicazione WhatsApp all'utente finale, destinatario del messaggio. Il server è attivo da qualche anno, ma è in costante sviluppo da parte dell'autore che lavora nelle sue migliorie.

Lavorando con il client UiView (ma può essere usato qualunque sistema terminale che abbia la funzione messaggi), operando all'interno della sessione "messaggi" , preparo il testo da inviare seguendo la seguente sintassi:

Campo to : WTSAPP 

Campo testo: @+prefissointernazionale_numeroutente messaggio  

Questa è la notifica giunta sul mio smartphone in WhatsApp  
  

Questo è invece il testo del messaggio presente al suo interno

Questa è invece la risposta che ho inoltrato al mittente tramite WhatsApp utilizzando la seguente sintassi:

Campo messaggio: @call (che è lo stesso del mittente) 

Ed infine questo è il risultato; la risposta consegnata sul mio dispositivo terminale via RF dalla rete dei sistemi APRS