• Prossimamente entreranno in funzione 2 DigiP che consentiranno il traffico APRS verso il Triveneto e verso Liguria - Toscana.    La loro costruzione è di fatto terminata e l'ubicazione definitiva stabilita.  Rimangono alcuni dettagli secondari e la posa in loco.


  •  
    I
     
    • Continua purtroppo l'attività di disturbo Packet a  9600 bps  che stà di fatto isolando la nostra regione dal resto d'Italia. 

    I particolari sono ormai noti a tutti !!   Un ultimo tentativo di mediazione pare non abbia ottenuto i risultati sperati e si teme lo scontro aperto !   Ci auguriamo solamente quello verbale e non quello fisico come ormai da più parti ventilato ( anche se in fondo - in fondo sapremmo per chi tifare ! HI )

    Per ora accontentiamoci delle finestre aperte dai DigiP di IK2HNG e IK2CHZ che ci permettono di vedere un po' di "azzurro" alternato al verde delle mappe !!

    Ci auguriamo tutti che la ragione abbia il sopravvento e che nei prossimi giorni le nostre mappe si animino con le icone di chi, come noi, stà provando l'avventura APRS ! 

    BOLLETTINI DI G.A.L.  APRS Lombardia


    Bollettino N. 1
    Bollettino N. 2
    Bollettino N. 3
    Bollettino N. 4
    Bollettino N. 5
    Bollettino N. 6


    • Situazioni di emergenza e controllo sul territorio di uomini e mezzi

    • Breve messaggistica e veloci QSO

    • Utilizzo da mobile in abbinamento ad un GPS

    • Spot DX per VHF e superiori e segnalazione di particolari attivita’ radiantistiche quali ad es. la presenza di una spedizione DX

    • Segnalazione dati meteo , incidenti e similari.

    • Cosa serve

      Per "fare" APRS non necessita’ nulla di particolare se non la normale attrezzatura usata per l’attivita’ packet tradizionale a 1200 Bd e cioe’:

        una radio VHF – FM

        un TNC o modem Baycom

        un PC

        oltre naturalmente all’apposito soft.

      Per l’attivita’ da mobile, vista la ovvia scomodita’ del PC, si puo’ eliminare quest’ultimo semplicemente utilizzando una radio con protocollo APRS e TNC entrocontenuto aggiungendo l’indispensabile GPS per il costante aggiornamento delle coordinate da trasmettere.
       


      I software a disposizione sono pochi ma piu’ che sufficienti allo scopo:

      MacAPRS, APRSDos, WinAPRS e UI-VIEW.


       


      Tralasciando i primi due la cui diffusione e’ trascurabile , dei secondi possiamo dire che:


    • WinAPRS è un programma shareware (la registrazione costa circa 60 dollari) e funziona anche senza la registrazione, ma ogni volta vanno reimpostati i settaggi.
    • UI-VIEW invece, pur essendo anche esso shareware (10 sterline per la registrazione) funziona perfettamente e la registrazione comporta la sola iscrizione in una mailing list informativa.
    • A livello di gestione mappe UI-VIEW è più malleabile e consente anche l’accesso a Internet verso i server APRS sparsi nel mondo.

      Tutti i riferimenti fatti in questo scritto al "software" si riferiscono a UI-VIEW. (UI-VIEW e’ scritto da Roger Barker G4IDE.)

      Come inviare e come ripetere i beacon APRS

      Aprs e’ fondamentalmente , come gia’ accennato , uno strumento in grado di dare e ricevere dati in tempo reale finalizzato alla gestione di situazioni di emergenza.

      Queste caratteristiche richiedono che l’"occupazione temporale" del canale sia la minore possibile per dare modo al flusso di informazioni di raggiungere nel minor tempo possibile i destinatari.

      Per ottenere questo e’ indispensabile una buona configurazione da parte di tutte le stazioni , siano esse stazioni utente o digi.

      Chi ha pensato il protocollo APRS (APRS e’ un marchio registrato da WB4APR ,Bob Bruninga) ha ovviamente pensato anche a questo, vediamo quindi come tutti dovrebbero inviare il proprio beacon e come questo andrebbe ripetuto.

      Le modalita’ previste per l’invio del beacon e della sua ripetizione sono quattro divise in due livelli gerarchici.

      Queste quattro modalita’ possono essere usate singolarmente o combinate assieme.

      Le modalita’ di ripetizione sono:

      1. Trace n-n (Gerarchia superiore) 
      2. Wide n-n " " 
      3. Wide (Gerarchia inferiore) 
      4. Trace " " 
      Le modalita’ Trace n-n e Wide n-n sono le modalita’ riservate ai digi la cui portata e’ notevole e che potremmo quindi definire "a lunga distanza".

      (n-n indica quante ripetizioni in cascata, eseguite da questo tipo di digi, vogliamo che abbia il nostro beacon. Il primo numero , max 7 indica il numero di ripetizione da noi richieste , il secondo e’ il contatore che viene aggiornato automaticamente dai vari digi ad ogni ripetizione fino a zero.)

      La differenza tra Wide n-n e Trace n-n consiste nel fatto che la seconda consente di inserire, nelle ripetizioni eseguite, il proprio nominativo , la prima no.

      E’ quindi consigliabile l’adozione della modalita’ trace n-n anche se questa comporta una maggiore lunghezza dei pacchetti trasmessi.

      Le modalita’ Wide e Relay sono invece riservate alle stazioni di livello intermedio tra stazioni mobili e digi.

      La differenza tra queste due modalita’ e’ solo nel modo di applicazione trattandosi a tutti gli effetti di veri e propri alias.

      I digi che si occupano di ripetizioni a "lunga distanza" si dovrebbero configurare esclusivamente come digi Trace n-n ed inviare il proprio beacon solo a Trace n-n.

      Le stazioni che hanno un ottimo link con i digi Trace n-n (quelli a lunga distanza) ed hanno una propria buona area di copertura, si dovrebbero settare invece come digi Wide (Wide generico , non Wide n-n !) e dovrebbero inviare il proprio beacon a Trace n-n.

      Infine le stazioni che non raggiungono direttamente i digi Trace dovrebbero settarsi come digi Relay ed inviare il proprio beacon a Wide,Trace n-n.

      C’e’ pero’ ancora una categoria di stazioni che puo’ non riuscire a raggiungere ne’ i digi Wide ne’ i digi Trace n-n: sono le stazioni mobili che quindi sfrutteranno i digi Relay inviando il beacon a Relay,Wide,Trace n-n.

      Questo tipo di stazione non dovrebbe configurarsi con nessuna modalita’ di ripetizione per evitare di generare pacchetti inutili o, al limite, configurarsi solo come Relay!

      Quindi secondo questo schema e’ facile capire che il beacon inviato da una stazione mobile in questo modo:

      IK2YDM>APRS,RELAY,WIDE,TRACE7-7

      sara’ ripetuto dalla stazione Relay cosi: IK2YDM>APRS,RELAY*,WIDE,TRACE7-7

      ci sara’ poi la ripetizione della stazione Wide : IK2YDM>APRS,RELAY*,WIDE*,TRACE7-7

      infine la ripetizione del digi Tracn-n, che supponiamo sia IK2CHZ: IKYIDM>APRS,RELAY*,WIDE*,IK2CHZ,TRACE7-6

      A questo punto gli altri digi Trace n-n che riceveranno la ripetizione del primo digi Trace n-n eseguiranno a loro volta le ripetizioni scalando di un passo alla volta il contatore fino alla completa eseguzione del comando , cosi: (ad es. digi IK2ANB)

      IK2YDM>APRS,RELAY*,WIDE*,IK2CHZ,IK2ANB,TRACE7-5

      Questa catena di ripetizioni vale ovviamente per tutti i tipi di stazione che abbiamo visto,naturalmente piu’ e’ alto il livello di gerarchia nella catena, meno saranno le ripetizioni necessarie per arrivare al digi Trace n-n.

      Infatti se il beacon inviato da un digi Wide (es IK2YDM) fosse’ questo:

      IK2YDM>APRS,TRACE7-7 la ripetizione effettuata subito dal digi Trace n-n sarebbe:

      IK2YDM>APRS,IK2CHZ,TRACE7-6

      In questa situazione ideale la catena delle ripetizioni sara’ questa:
       


      I beacon cosi ripetuti pero’ non consentono a chi li riceve di capire la strada (path) che questi hanno fatto perche’ Realy e Wide possono essere chiunque.

      Ecco quindi che diventa indispensabile che le stazioni che si abilitano come digi ,di qualsiasi livello , abilitino nella propria configurazione l’inserimento del proprio alias(che deve essere il proprio nominativo) affinche’ questo venga inserito al posto del generico Relay o Wide,nel beacon da loro ripetuto.

      Ecco come sarebbe stata ripetuta la catena dei beacon dell’esempio precedente con i digi Relay(es. IK2HNG) e Wide (es. IK2YHJ) aventi abilitata la sostituzione dell’alias:

      IK2YDM>APRS,RELAY,WIDE,TRACE7-7

      IK2YDM>APRS,IK2HNG*,WIDE,TRACE7-7

      IK2YDM>APRS,IK2HNG*,IK2YHJ*,TRACE7-7

      IK2YDM>APRS,IK2HNG*,IK2YHJ*,IK2CHZ,TRACE7-6

      (Ovviamente anche i digi Trace n-n devono avere questa opzione abilitata!)

      E pure possibile indirizzare geograficamente il nostro beacon.

      Cosi facendo possiamo ad es. decidere di inviarlo solo verso sud piuttosto che a nord e cosi via.

      I comandi per ottenere questo sono campi numerici superiori a 7 da abbinare al comando di ripetizione secondo il seguente schema:


    BOLLETTINO N. 1

    1) Utilizzo delle icone

    Si raccomanda l'utilizzo delle icone piu' indicate al caso evitando di Utilizzare icone di "fantasia" che nulla centrano con la stazione che le inviano.

    In particolare viene indicata l'icona "HOME" come standard per le stazioni fisse qualunque sia il soft usato, l'icona "DIGI" per i digipeater e l'icona "WX STATION" per le stazioni meteo. (Quest'ultima e' di default abilitando WX setup con UI_View.) Si consiglia l'uso dell'icona "HOME HF" per segnalare la contemporanea attivita in HF dell'operatore. In questo caso sara' utile indicare nel beacon text banda o frequenza e modo.

    Per le stazioni fisse di sezione (qualsiasi associazione ovviamente) e' indicata l'icona "RSGB".

    Per le stazioni mobili si consiglia di adottare l'icona piu' appropiata al mezzo in questione, in caso di dubbio o tipo di mezzo non previsto utilizzare l'icona "CAR".

    L'icona "JOGGER" sara' invece usata da escursionisti a piedi e quella "HORSE" per quelli a cavallo e cosi via. In ogni caso si operi al di fuori della propia abitazione si raccomanda comunque sempre di adottare l'icona che piu' di tutte le altre "visivamente" suggerisce la collocazione o l'attivita' in corso.

    Si fa' l'esempio della stazione portatile che per diversi giorni, in Lombardia, ha utilizzato l'icona "HOSPITAL": utilizzo corretto in quanto la stazione operava dall'ospedale essendovi l'operatore......ricoverato.

    In particolare si sconsiglia l'uso delle varie icone "meteo" raffiguranti sole, pioggia etc:piuttosto e' meglio configurarsi come stazione meteo ammesso che si sia in grado di trasmettere dati validi e costantemente aggiornati.

    2) Utilizzo dei nominativi e SSID

    Si raccomanda l'utilizzo eslusivamente del propio nominativo per le stazioni fisse anche meteo (WX) senza nessun SSID.

    Per i digi si raccomanda il nominativo del sysop con l'aggiunta del SSID -11 che essendo, secondo il protocollo APRS, destinato agli aerostati non potra' essere usato in Italia per quello scopo.

    Il SSID si rende in questo caso necessario per non confendere la stazione fissa dal digi nel caso di contemporanea presenza.

    E' evidente che se il digi utilizza il nominativo di un operatore che NON SARA' MAI attivo da stazione fissa il SSID -11 potra' non essere usato.

    Sono caldamente sconsigliati per i digi nominativi con prefissi non regolari (IR1,IR2,IR3 etc) o adirittura completamente fittizzi.(IR2GPS etc).

    L' utilizzo degli altri SSID e' consigliato nel rispetto del protocollo APRS qual'ora ve ne fosse bisogno come ad es. nel caso di stazione mobile contemporaneamente attiva all'omonima stazione fissa.

    3) Creazione di oggetti

    Si ritiene che la creazione degli oggetti debba essere fatta con "parsimonia" per due motivi principali:

    A) tutti possono creare uno o piu' oggetti e se cosi fosse rischieremmo di avere piu' "object" che stazioni; oltertutto spesso gli oggetti "nascondono" la nostra o peggio l'altrui icona di stazione.

    B)La trasmissione dell'oggetto e la sua relativa ripetizione da parte dei digi "impegna", occupandolo, per un certo tempo il canale portando via spazio magari a stazioni packet tradizionali laddove il canale e' (come giusto che sia) in coabitazione con altri sistemi a 1200.

    Bisogna quindi segnalare solo cose che sono di evidente interesse generale ma nel contempo sono sconosciute ai piu' e non cose ho fatti la cui esistenza e' nota a tutti.

    4) Configurazione stazione fissa e configurazione digi

    Introducendo questo argomento e' necessario fare una premessa:

    quando vogliamo interrogare o comunicare con una stazione che ascoltiamo tramite uno o piu' digi e' necessario conoscere la "strada" (path) che fanno i pacchetti per poterli instradare correttamente in modo che arrivino a destinazione.

    E' evidente che se i digi intermedi non hanno l'"ALIAS SUBSTITUTION" abiliato non sara', nella maggior parte dei casi, possibile ricostruire la strada.(Un conto e' una stazione che "dista" solo uno o due digi ma pensate a quale sara' la difficolta' con stazioni lontane cinque, sei, o piu' digi!)

    Ecco quindi che si rende indispensabile l'uso dell' "ALIAS SUBSTITUTION" per TUTTE le stazioni (fisse e digi) e l'uso del TRACEn-n anziche' del WIDEn-n per far si che nelle varie ripetizioni venga inserito anche il nominativo di chi, appunto, ripete.

    Da contatti in corso con la zona 6 e zero risulta che tra breve (mancano 2 digi di prossima attivazione) sara' possibile arrivare in Lazio con solo 5 o 6 digi (forse anche meno!) non serve quindi inserire nel propio "unproto address" sfilze interminabili di comandi.

    Molte e e senz'altro valide sono le configurazioni utilizzabili ma e' evidente che una certa uniformita' consentira' di otimizzare il sistema facendo arrivare i nostri beacon il piu' lontano possibile con il minor numero possibile di ripetizioni.

    Ecco che e' quindi indispensabile che le stazioni fisse e le mobili abilitino si il digi ma NON abilitino il WIDEn-n ED il TRACEn-n lasciando ai digi queste funzioni evitando cosi di "bruciare" delle ripetizioni che rimarrebbero in ambito locale.

    Cosi facendo inoltre le stazioni fisse garantirebbero la prima ripetizione alle stazioni mobili consentendo loro di arrivare al primo digi nel caso direttamente non vi riuscissero.

    Quindi le stazioni fisse dovranno scrivere nel loro "UNPROTO ADDRESS":

    APRS,RELAY,TRACE7-7

    (Nel momento in cuila rete sara' nazionale o piu' grande ancora bastera' aggiungere un altro TRACE7-7.)

    Invece nel "DIGIPEATER SETUP" scriveremo:

    enable digi : SI
    ui-only : NO
    alias substitution : SI
    wide n-n : NO
    trace n-n : NO
    alias(es) : il propio call,RELAY
    sub alias : il propio call
    dupe secs : 15
    Analogamente i digi avranno lo stesso "unproto address" delle stazioni fisse ma in digipeater setup abiliteranno in piu' il solo campo TRACEn-n.

    E' importante che i digi ripetano solo RELAY e modalita' TRACEn-n perche' cosi facendo "obbligano" le stazioni fisse a "mandare" tramite TRACEn-n consentendo cosi a tutti di ricostruire i vari path!!

    Il "DUPE SECS" dei digi deve essere tanto piu' elevato quanti piu digi esso stesso riceve, questo per evitare ripetizioni dello stesso pacchetto piu' di una volta da parte dello stesso beacon.
     
     Inizio Pagina

    BOLLETTINO N. 2
     


    SFRUTTIAMO LE CARATTERISTICHE NON INTRUISVE DELL'APRS


     


    La caratteristica fondamentale dell'APRS è quella di lavorare senza connessioni sfruttando le trame beacon "UI". 

    Il vantaggio in termini di limitata "occupazione temporale" del canale è indiscutibile anche nel caso di veri e propri "QSO" tra due o più stazioni: non solo non si avranno tutti i pacchetti necessari alla "creazione" della connessione stessa (con i relativi logo e msg. di benvenuto) ma , nei momenti di pausa, non si avranno neppure i pacchetti di verifica della connessione stessa. Stesso discorso vale per i pacchetti di disconnessione. (Il tutto moltiplicato per due perché ci sono poi le trasmissioni degli ACK operate dalla stazione destinataria.) 

    In altre parole per inviare ad una altra stazione una breve frase, con APRS, utilizzo un solo pacchetto più un pacchetto di conferma (ACK) di ritorno. 

    Per inviare la stessa frase con il Packet tradizionale servirebbero invece un numero imprecisato di pacchetti dovuti a: connessione (tanti più pacchetti quante più sono le info di benvenuto del sistema remoto), invio msg, disconnessione. (Il tutto sempre con l'aggiunta dei pacchetti di conferma!). 

    Questa non "intrusività" è senza dubbio l'argomento da portare a conoscenza di quei sysop di sistemi tradizionali a 1200Bd operanti a 144.800 che si vedono "minacciati" dall'arrivo sulla medesima frequenza da questo nuovo sistema. 

    La convivenza sulla stessa frequenza di questi due modi di fare Packet a 1200Bd è senz'altro indolore per entrambi a patto pero' che gli operatori APRS settino bene i loro sistemi, non creino "object" inutili e utilizzino i vari comandi (query , ping, dx, aprsd, aprsh, etc. etc.) con giustificato motivo e non tanto per fare. 

    Anche i sysop dei digi devono prestare attenzione ad un importantissimo parametro: il "dupe secs", o comando corrispondente a seconda del soft che si usa. (Idem per UIDIGI!) 

    Se questo valore è troppo basso i beacon di tipo WIDEn-n e TRACEn-n ricevuti rischiano di essere ripetuti a scalare "rimbalzando" sempre tra gli stessi due digi. 

    Questo produce due risultati negativi: 

    1) Il beacon inviato da una qualsiasi stazione non viene "propagato" a dovere rimanendo nell'area di copertura dei due digi che se lo rimpallano. 

    2) Si occupa inutilmente la frequenza per il tempo necessario alle ripetizioni inutili (Magari 7 se Wide7-7 o Trace7-7) alla faccia della non intrusività 

    In particolare abbiamo osservato questo problema in zona 3 e zona 1. 

    (Questa vuole essere una segnalazione agli interessati, NON una critica!!) 

    Concludendo: una buona configurazione delle stazioni fisse e dei digi oltre che rendere più efficiente il sistema stesso a vantaggio di tutti, consente la perfetta (tecnicamente) e civile (educata) convivenza con bbs tradizionali. 
     
      Inizio Pagina

    BOLLETTINO N. 3

    Che cos’è APRS.

    L’APRS viene presentato ne 1992 in occasione della "Conferenza sulle comunicazioni digitali" dell’ARRL/TAPR da parte dell’ideatore di tale protocollo WB4APR Bob Bruninga.

    Tale protocollo e’ stato pensato per un tipo di diffusione "broadcast" da tutti verso tutti con lo scopo di diffondere dati (meteo,notizie di interesse generale,segnalazioni particolari etc.) in tempo reale.

    Oltre a questo sono possibili comunque semplici comunicazioni fra le stazioni (due o piu contemporaneamente) e sono disponibili una serie di comandi che permettono di interrogare le altrui stazioni dando modo all’operatore di valutare le condizioni propagative del momento sulla frequenza usata. (144.800 MHz per VHF e 14.105 MHz per HF.)

    La fondamentale differenza tra APRS e packet tradizionale consiste nel fatto che questo sistema non necessita di connessioni ma utilizza le trame beacon UI per inviare a tutti i propri pacchetti.

    Inoltre a video si ha la rappresentazione grafica delle aree geografiche che vogliamo visualizzare sulle quali verranno automaticamente sovraimpresse delle icone indicanti stazioni utente, stazioni meteo, stazioni digi, stazioni mobili, oggetti.

    Per le stazioni mobili e’ previsto l’utilizzo in abbinamento ad un GPS che consente l’aggiornamento automatico delle proprie coordinate consentendo cosi il continuo aggiornamento della posizione sulla mappa.

    Oltre a questo ,e’ possibile l’utilizzo di digipeater dedicati che consentono ,sempre senza connessione, la ripetizione del proprio beacon e dei propi pacchetti in diversi,sofisticati modi.

    Senza dubbio uno, se non il maggiore, campo di applicazione dell’APRS e’ la situazione di emergenza che si viene a creare in caso di calamita’ naturale o di incidenti che per le loro particolari conseguenze richiedono l’impiego e l’intervento degli organi di protezione civile.

    APRS consente infatti con un solo "colpo d’occhio" di "vedere" dove sono dislocati uomini e mezzi, di sapere le esatte condizioni meteo di aree ristrette e tutte queste informazioni saranno disponibili non solo ad un ipotetico supervisore ma a tutte le stazioni contemporaneamente.

    Il protocollo APRS prevede anche la possibilita’ di utilizzare TNC multiporta consentendo quindi la realizzazione di gateway VHF-HF con relativo scambio di traffico tra le due porte.

    Le modalita’ di questo scambio sono selezionabli in diversi modi: si puo’ fare uno scambio totale tra le due porte (cio’ che e’ ascoltato in VHF viene ripetuto in HF e viceversa) oppure si puo’ decidere che lo scambio sia monodirezionale e cioe’ che solo una delle due porte ripeta cio’ che viene ascoltato sull’altra.

    Non manca ovviamente la possibilita’ di collegarsi ad un server internet dal quale prelevare in tempo reale il traffico di altre parti del mondo.

    Utilizzi dell’APRS

    Con APRS vedremo quindi visualizzate sulla nostra mappa le icone rappresentanti le altre stazioni esattamente collocate nel luogo ove esse si trovano.

    L’approssimazione sara’ dovuta alla correttezza delle coordinate inserite dall’operatore nella propria configurazione e dalla precisione della mappa che utilizziamo.

    Ovviamente durante l’utilizzo di mappe regionali o ancor piu’ grandi la precisione richiesta e’ minima mentre se si utilizzano mappe "cittadine" o ancor piu’ dettagliate, anche solo poche decine di metri di errore possono mostrare la nostra o l’altrui icona magari nel mezzo di un fiume anziche’ sulla sua sponda.

    L’icona cosi ricevuta contiene una serie di informazioni sulla stazione che l’ha inviata e se si tratta di una stazione meteo sara’ possibile leggere i dati che l’operatore avra’ deciso di inserire o manualmente oppure abbinando al sistema PC–radio anche una stazione meteo automatica che autonomamente aggiornera’ i dati da trasmettere.

    E’ inoltre possibile dialogare con altre stazioni , anche in gruppo,perche’ tutti vedono i pachetti di tutti e non essendoci connessioni il traffico avviene in maniera piuttosto veloce.

    Volendo si ha anche la possibilita’ di inviare bollettini che verranno ripetuti automaticamente ad intervalli di tempo prestabiliti.

    Punto di forza del’APRS sono gli "oggetti" che consistono in particolari icone che chiunque puo’ creare e che servono ad indicare in qualsiasi punto della mappa avvenimenti ed eventi di particolare interesse quali ad es. incidenti , incendi, allagamenti etc. oppure "cose" quali campi base, ospedali da campo,punti di ritrovo,infrastrutture di vario tipo etc.

    L’uso degli oggetti e’ quindi molto indicato in situazioni di emergenza.

    Gli oggetti si possono creare per segnalare qualsiasi cosa ma considerando che la loro trasmissione, con le relative ripetizioni , "occupa" tempo ,sarebbe bene farne un uso "parsimonioso" segnalando solo cose di particolare interesse che giustificano la creazione dell’oggetto stesso.

    Oltre a questo va considerato che gli oggetti che creiamo potrebbero andare a coprire le icone di stazione di altri operatori che non sarebbero certo contenti della cosa.

    Riepilogando, APRS serve per :

    WIDE8 = nord

    WIDE10 = est

    WIDE11 = ovest

    WIDE9 = sud

    Sono anche possibili una serie di istruzioni "cumulative" secondo lo schema che segue:

    WIDE 12 = NORD PIU’ UN WIDE

    WIDE 13 = SUD PIU’ UN WIDE

    WIDE 14 = EST PIU’ WIDE

    WIDE 15 = SUD PIU’ WIDE

    Scrivendo ad es. IK2YDM>APRS,WIDE12,WIDE7-7 avremo una ripetizione WIDE a nord piu’ una WIDE generica e poi sette WIDE a scalare

    Questa descritta fino ad ora e’ la situazione "ideale" nella quale una ordinata applicazione delle regole fin qui’ viste consentirebbe una ottimizzazione (quasi) perfetta del traffico ed un ridotto tempo di occupazione del canale.

    Purtroppo la situazione attuale lombarda (ma non solo) si discosta di molto da questa "idealita’" per due motivi principali:

    1) Le problematiche (per altro in via di soluzione) relative al traffico a 9600Bd presente sul canale obbligano tutte le stazioni ha tenere il tempo di intervallo tra l’invio si un beacon ed il successivo, molto breve per avere la certezza che esso riesca a "bucare" facendosi ricevere cosi da tutti.

    Per lo stesso motivo e’ necessario anche che il beacon sia inviato da "tutti a tutti" (tramite Relay) a "tappeto".

    Questo causa un notevole aumento dei tempi di occupazione del canale e di fatto, in alcuni momenti di quiete, provoca una "ridda" di pacchetti.

    2) Altro motivo , questo di natura tecnica , e’ che i digi 24h/24h attualmente attivi in Lombardia posti principalmente verso est non sono , ad esclusione del digi di Cremona e parzialmente quello di Crema, digi Trace n-n.

    Vi sono due tipi di digi: digi "intelligente" e digi "stupido" (l’aggettivo non si riferisce ai sysop , ovviamente. HI).

    Il digi intelligente e’ un digi gestito ,ad es. , da UI-VIEW o da un TNC2 con eprom dedicata e sono quindi interrogabili dagli utenti (ping,query,dx) ma sopratutto hanno la possibilita’ di funzionare in modalita’ Trace n-n.

    Il digi "stupido" e’ invece un TNC che ripete solo la modalita’ generica Relay o Wide tramite l’alias ma non e’ interrogabile e soprattutto non ha la possibilita’ di funzionare in modalita’ Trace n-n.

    La quasi totalita’ dei digi lombardi sono digi "stupidi" che ripetono in modalita’ Relay o Wide (Relay prevalentemente) obbligando cosi tutte le stazioni che tramite loro vogliono transitare verso est , ad inviare il proprio beacon anche a Relay.

    Ecco quindi la situazione attuale in Lombardia , dove tutti inviano necessariamente a Relay o Wide per poter raggiungere i digi Trace n-n:
     



     


    E’ evidente che una volta risolte le problematiche relative al traffico a 9600 Bd ed introdotti digi "intelligenti" si dovra’ rivedere la filosofia delle configurazioni cercando quanto pu’ possibile di avvicinarsi alla situazione "ideale" precedentemente descritta.

    A breve, grazie ad UGO I2SDD, verra’ attivato un digi "intelligente" in una zona "strategica" che garantira’ il link costante verso il Veneto.

    In considerazione di cio’ e del fatto che esistono gia’ tra zona tre – quattro, sei e zero dei link stabili questo ci portera’, finalmente, a "vedere" le altre regioni oltre che al solo essere visti.

    L’attivazione di questo nuovo digi Trace n-n sara’ l’occasione per iniziare, secondo la logica prima esposta, una prima riorganizzazione delle modalita’ di ripetizione dei digi attualmente attivi e delle modalita’ di invio dei beacon. beacon.
     
     

    Da un bollettino originale di Flavio IK2XYU a SYSOP@ILOM.

    PERCHE' L'APRS

    Ciao, dopo che ho notato che molti non hanno capito cosa sia APRS e dopo che qualcuno mi ha spinto a scrivere, ecco che mando a voi sysop, le motivazioni del perchè occorre sostenere APRS.
    Perchè a voi sysop ? Perchè qualcuno di voi si è mostrato poco interessato ... e con alcuni messaggi (non mi riferisco a quelli inviati a me, ma altri che mi hanno girato in copia) hanno mostrato poco interesse.

    Questo messaggio non vuole essere fonte di discussione sulle frequenze da usarsi o da chi le impegna ... come qualcuno potrebbe aspettarsi sia, ma una sola fonte di informazione che mi auguro venga condivisa.

    Innazitutto diciamo cosa è APRS. APRS significa Automatic Position reporting System, è un sistema sviluppato in USA dal 1992 e che ormai a macchia d'olio, da quando cioè è stato terminato il primo manuale sul protocollo, si è diffuso ovunque nel mondo.

    E' un sistema che utilizzando i soli frame UI dei pacchetti permette di gestire un software apposito (ne esistono freeware, shareware e da registrare secondo i gusti di ciascuno) per lo scambio di informazioni brevi (tipo SMS dei cellulari), sfruttando però la grafica per conoscere la posizione delle stazioni a livello geografico. Permette inoltre di "spottare" eventi mostrati per mezzo di una icona grafica quali ad esempio informazioni meteo, di traffico stradale, ospedali, aeroporti, o comunque è usato per segnalare la posizione anche di mezzi mobili (auto private, auto di soccorso,etc.)

    Ecco quindi che si capisce che tale sistema, che non usa connessioni permette l'utilizzo durante situazioni di emergenza per localizzare mezzi di soccorso, campi di emergenza, punti di gestione emergenza, etc. senza che questi sia connessi in rete, ma con la semplice accensione di un interruttore. L' uso a 1200 Baud derivato dal fatto che i frame UI inviati sono di dimensioni piccolissime, permette di avere un sistema robusto e l'uso di radio "As Is" (senza modifica alcuna).

    E' evidente che nell'uso normale quotidiano APRS diviene quasi un gioco, ma è da considerare che è di notevole aiuto per chi si trova su mezzi in movimento (in sostituzione dei sistema di navigazione anche se in alcuni casi resta limitato) e comunque può essere sfruttato quale packet cluster, meteo info, etc. Chi non ha chiaro l'etc. mi contatti e spiego altri esempi più pratici ed esperienze personali, che ora non cito per non dilungarmi.

    Attualmente APRS è stato presentato in due province (Bergamo e Cremona) che ne hanno subito apprezzato le funzionalità.  In un caso è stata chiesta collaborazione per la gestione delle posizioni ambulanze.

    Ecco quindi che serve, in un periodo di instabilità del nostro regolamento e della nostra tassa ... che i radioamatori tornino ad essere un punto di riferimento.

    In una situazione di emergenza le altre nostre attività radiantistiche, se non quelle in fonia nel caso di blackout della rete telefonica cellulare non sono più richieste .... APRS può invece divenire qualcosa di interessante.

    In USA ormai non manca occasione di mostrare tale sistema al pubblico a tutte le occasioni. Non so chi di voi abbia avuto occasioni di partecipare a eventi negli States (fiere, maratone, regate, etc.), ma si sarà sicuramente accorto che APRS è ben utilizzato ....

    Insomma APRS non deve essere visto come un qualcosa di tecnologicamente obsoleto, non in grado di sostituire gli attuali sistemi packet, ma come un mezzo di riscatto verso chi abbiamo sopra che come tale deve essere supportato.
     

    Ringrazio per l'attenzione, grazie per il supporto che ci date con i BBS.

        IK2XYU also KF6EEZ

              Per il G.A.L. Gruppo APRS Lombardia ha trascritto IK2YDM

    Inizio Pagina

    BOLLETTINO N. 4
     

    Fisionomia della rete APRS secondo il protocollo.

    Bene , come discusso a Novegro e come da più parti sollecitato è  il momento, visto l'alto numero di stazioni che giornalmente sono attive in APRS e visto il numero di operatori che si configurano come digi,di iniziare ha dare una fisionomia ben precisa alla rete APRS.
    Il modo di determinare ciò è quello di agire sulle configurazioni dell'unproto e del digi setup cercando per quanto più possibile di renderle aderenti a quanto previsto dal protocollo.
    E' bene ricordare che il protocollo stesso prevede la suddivisione  delle modalità di ripetizione in due ordini gerarchici : superiore ed  inferiore.
    Del livello superiore fanno parte le modalità WIDEn-n e TRACEn-n che sono quelle riservate ai digi "a lunga distanza" in grado cioè di
    assicurare il link con altri digi di analoga gerarchia posti a notevole distanza.
    Riteniamo di utilizzare la modalità TRACEn-n e non la WIDEn-n per il noto motivo che la prima consente l'inserimento dell'alias nella stringa ripetuta mentre la seconda no. 
    Nel livello inferiore troviamo invece la modalità RELAY e WIDE.
    La modalità relay è quella che consente alle stazioni mobili e  portatili di arrivare alle gerachie superiori mentre la modalità WIDE è quella che lo consente alle stazioni "normali".
    Per stazione normale si intende una stazione la cui area di copertura NON è notevole o, pur essendola non è attiva 24 ore su 24.
    Vediamo nel dettaglio la classificazione delle stazioni:

    DIGI TRACEn-n = stazioni attive 24 ore su 24 con notevole portata in grado di assicurare i collegamenti interregionali.
    Queste stazioni invieranno il proprio beacon solo a TRACE7-7.

    DIGI WIDE (non widen-n) = stazioni attive 24 ore su 24 con una buona copertura regionale o dedicate alla raccolta del traffico di aree specifiche. Queste stazioni devono avere un ottimo link con le stazioni di gerarchia superiore ed invieranno il proprio beacon solo a TRACE7-7.

    DIGI RELAY = tutte le stazioni che non rispondono alle precedenti caratteristiche andranno configurate come digi relay e invieranno il 
    proprio beacon a WIDE,TRACE7-7.

    NESSUN DIGI = le stazioni mobili è bene che non si attivino con nessuna modalità di ripetizione per evitare , nella maggior parte dei casi, di aumentare solo il traffico senza scopo , esse invieranno il prorio beacon a RELAY,WIDE,TRACE7-7.

    Per capire bene il perchè di tutto ciò vediamo il seguente schema:
     

    stazione mobile o portatile(non ripete nessuna modalità ed invia il beacon  a RELAY,WIDE,TRACE7-7) 
    |
    |
    tutte le staz.  (ripete la modalita' RELAY ed invia il propio  beacon a WIDE,TRACE7-7)
    | |
    | |
    digi 24 ore "regionali"  (ripete la modalita' WIDE ed invia il  proprio beacon a TRACE7-7)
    | | | 
    | | |
    digi 24 ore "interregionali" (ripete la modalita' TRACEn-n ed invia   il proprio beacon a TRACE7-7)
    | | | |
    | | | |
    V V V V
    verso altri digi TRACEn-n 
    "interregionali"

    Una volta "assimilato" questo concetto di ripetizioni gerarchiche è facilmente intuibile come divenga necessario darsi un minimo di organizzazione affinchè il traffico venga allegerito ed ottimizzato. Le configurazioni fino ad oggi consigliate (relay,trace7-7 o relay,relay, trace7-7) sono comunque valide in tutte quelle zone dove il traffico scarseggia.

    Invitiamo quindi tutti gli operatori APRS ad adottare questo nuovo tipo di configurazione ed in particolare ,come G.A.L. riferendomi alla situazione lombarda, invitiamo tutti i sysop di digi attivi 24 ore su 24 o che hanno intenzione di attivarsi come tali a discutere, attraverso il nostro riferimento, le soluzioni migliori. (Wide o Tracen-n a seconda della posizione e dei link.)

    Attualmete collaborano i seguenti digi:

     IK2ANB,IW3FN-11,IK2CHZ,IK2HNG,IW2MIN-11,IK2YHJ-11

     che a breve, dopo aver valutato la situazione, setteranno le nuove modalità di ripetizione. 

    P.S. Sono/siamo a disposizione per chiarimenti ed approfondimenti.

    Per il G.A.L. Gruppo APRS Lombardia ha scritto IK2YDM
     
    Inizio Pagina

    BOLLETTINO N. 5       28.06.2000

    Digi e funghi.
     

    Digi e funghi??
    Cosa c' entrano i funghi vi chiederete!
    I funghi c' entrano nel senso che ultimamente , non solo in Lombardia , stanno spuntando digi aprs come....funghi appunto.
    Premesso e ribadito che chiunque se vuole può attivare un digi APRS e nessuno può ledere questo diritto altrui, bisogna però fare alcune considerazioni.
    Quando si parla di APRS bisogna fare lo sforzo di dimenticare le idee ed i concetti che utilizziamo per il packet tradizionale.
    Un digi APRS è "un' arma" molto potente ,se usata bene, ma è un' arma che
    ci scoppia tra le mani se usata male.
    Troppi digi servono soltanto a fare ripetizioni dello stesso beacon nella stessa area accorciandone la distanza massima che esso stesso potrà coprire e "saturando" al contempo il canale impedendoci magari di ricevere i segnali più lontani e deboli.
    In poche parole è inutile installare un digi n-n a metà strada tra due digi n-n che già tra loro SI VEDONO: facciamo "scalare" inutilmente una ripetizione e occupiamo tempo.
    Il discorso ovviamente è esattamente all'opposto se installiamo un digi n-n in mezzo a due digi n-n che tra loro NON SI VEDONO:in questo modo permettiamo il passaggio dei beacon da un digi all'altro svolgendo una azione utile.
    Possono però verificarsi casi , specialmete al di fuori delle grandi pianure e quindi nelle zone collinari e montagnose, dove tra due digi n-n che tra loro SI VEDONO esistano delle zone dove, pur arrivando il loro segnale , quello di eventuali stazioni ivi presenti non arrivi a loro.
    Ecco che si sarebbe portati a pensare che in questo caso l'installazione di un altro digi n-n posto in mezzo ai due, per garantire il traffico alle stazioni nella zona in ombra, sia utile e positivo.
    In realtà sarà si utile ma poco positivo perchè se da un lato darà il servizio alle stazioni in ombra, dall'altro farebbe "scalare" una ripetizione ai beacon di tutti gli altri.
    In questo caso è indicata si l'installazione di un digi, ma che NON sia un
    digi n-n bensi un digi che ripeta le sole modalità GENERICHE e cioè RELAY
    e WIDE (non WIDEn-n).
    In questo modo le stazioni in ombra raggiungeranno i digi n-n inviando il loro beacon tramite "APRS,WIDE,TRACE7-7" mentre i beacon in transito tra i due digi n-n non subiranno ulteriori inutili ripetizioni.
    Quest'ultimo tipo di digi non è "meno importante" di un digi n-n ma è invece fondamentale per una corretta copertura del territorio e una corretta ripetizione dei segnali.
    Oltretutto questo tipo di digi non richiede un TNC2 e UIDIGI ma può essere
    un qualsiasi tnc con la funzione digi abilitata e con WIDE come alias!

    In conclusione:

    1) Non attiviamo digi solo perchè abbiamo a disposizione un tnc ed una radio
    che ci avanzano.

    2) Se attiviamo un digi facciamo si che sia in una zona dove realmente serve.

    3) Valutiamo bene le modalità di ripetizione che questo digi deve avere non considerandolo un digi di serie "B" se non deve ripetere le modalità n-n.

    4) Se abbiamo già attivato un digi prendiamo in considerazione l'idea di spegnerlo se qualc'un altro ne attiva uno in zona con area di copertura maggiore.

    5) Curiamo attentamente i settaggi.
     

    P.S. Questo blt. è inteso in senso generale e non ha alcuna attinenza specifica con eventuali attivazione di digi operate in questi giorni.
     
    Inizio Pagina

    BOLLETTINO N. 6           01.07.2000

    Mi è stato chiesto ,da parte di alcuni operatori APRS che leggono i vari blt. concernenti le configurazioni di UI-VIEW , come mai il G.A.L., nella persona di IK2NBV ,scriva cose diverse da quelle precedentemente da mè indicate.
    Questi colleghi non hanno prestato attenzione al fatto che NBV non si firma G.A.L. (non facendone parte) e che parla quindi a titolo personale.   Partendo dal presupposto che ogni idea ha pari dignità e pari diritto di essere discussa, vi illustro su cosa non siamo d'accordo con le configurazioni da Lui proposte.
    Fondamentalmente la differenza consiste nell'uso del "WIDE" generico (quello che si scrive nel campo "unproto address e non il widen-n per intenderci).
    Le configurazioni da NBV proposte ignorano completamente questa modalità che invece, se ben usata, evita ripetizioni multiple nel caso di beacon inviati inutilmente a relay e garantisce a tutti il miglior risultato.
    Concordiamo su questo: i digi con grande area di copertura invieranno il proprio beacon solo a TRACE7-7 (Per UI-VIEW: unproto address APRS,TRACE7-7) 
    (Per UIDIGI : beacon1 path TRACE7-7) 
    mentre abiliteranno il prorio digi così:
    Per UI-VIEW: ENABLE DIGI: si
    UI Only : no (altrimenti non si ripetono le stazioni che non usano UI-VIEW)
    Alias subs.: si
    Widen-n : si
    Tracen-n : si
    Alias : nominativo,relay,wide
    sub alias : nominativo
    dupe secs : consigliato maggiore di 25 inferiore di 45

    Per UIDIGI17:digipeaterAlias : nominativo
    beacondestination : APZ17
    uifloodCall : wide
    uitraceCall : trace
    duplicatesuppression : ottimi risultati ottenuti con "45"
    loopSuppression : 7

    NBV non considera questa seguente categoria di digi:
    digi con una area di copertura ridotta rispetto a quelli visti prima o che servono zone particolari dove il segnale dei DIGIn-n arriva ma dalle quali,per le stazioni "normali", è difficile od impossibile farsi sentire.
    Questi digi, che chiameremo digi wide/relay, DEVONO avere un buon link con almeno un DIGIn-n.
    Essi invieranno il proprio beacon esattamente come i digi visti sopra.
    Dovranno invece essere cosi settati come digi:
    Per UI-VIEW: ENABLE DIGI : si
    UI Only : no
    alias subs. : si
    Widen-n : no
    Tracen-n : no
    Alias : nominativo,relay,wide
    sub alias : nominativo
    dupe secs : consigliato maggiore di 25 inferiore di 45

    Per UIDIGI17:digipeaterAlias : nominativo
    beacondestination : APZ17
    uifloodCall : omettere questo campo!!
    uitraceCall : omettere questo campo!!
    duplicatesuppression : ottimi risultati ottenuti con "45"
    loopSuppression : 7

    Questo tipo di digi può essere realizzato anche con TNC normali senza UIDIGI semplicemente settando nel campo alias WIDE e RELAY e abilitando la funzione digipeater ma ATTENZIONE: essi non gestiscono il controllo sulle doppie ripetizioni dello stesso beacon!!

    Infine ci sono le stazioni "normali" per le quali non si può a priori stabilire quale configurazione esse debbano adottare perchè questo dipende dal link diretto oppure no che esse hanno con i digi n-n .   Se la stazione linka direttamente un digi n-n , dovrà inviare il suo beacon così:
     unproto address "APRS,TRACE7-7".
    Se invece NON collega direttamente un digi n-n allora avrà a disposizione due possibilità:
    1) nel caso vi sia un digi di tipo wide/relay allora invierà il proprio beacon a "APRS,WIDE,TRACE7-7" (RICORDIAMOCI CHE IL DIGI WIDE/RELAY DEVE VEDERE ALMENO UN DIGI n-n) cosi facendo il digi wide/relay eseguirà la prima ripetizione generica consentendo al beacon di arrivare al digi n-n che inizierà ad eseguire le ripetizioni a "scalare". 
    Quindi con una sola e SICURA ripetizione (wide) il mio beacon arriverà al digi n-n!!
    2) nel caso invece che non vi siano digi di tipo wide/relay tramite i quali inviare il beacon allora esso andrà inviato a "APRS,RELAY,TRACE7-7"
    SE SONO SICURO CHE IL RELAY CHE MI RIPETERA' HA UN LINK CON UN DIGI n-n se invece sò che c'è la possibilità che il "relay" che mi ripete non veda direttamente il digi n-n ma veda invece un digi wide/relay allora dovrò inviare il beacon a "APRS,RELAY,WIDE,TRACE7-7.
    In questo modo con due ripetizioni sicure arriverò al digi n-n.
    Questa ultima configurazione è inoltre quella che dovrebbero adottare le stazioni mobili per avere la (quasi) certezza di far arrivare il propio beacon ai digi n-n.
    Le stazioni "normali" dovranno abilitarsi come digi nella sola modalità RELAY per garantire una copertura a "tappeto" utile alle stazioni mobili e portatili, cosi:

    enable digi : si
    ui only : no
    alias subs. : si
    widen-n : no
    tracen-n : no
    alias : nominativo,relay
    sub alias : nominativo
    dupe secs : consigliato maggiore di 25 inferiore di 45

    Ovviamente , come giustamente consigliato da Luigi IW2FUS, alcune stazioni "normali" potranno non abilitarsi come digi relay se nelle loro vicinanze vi è già una stazione con migliori "prestazioni" o meglio ancora se nelle vicinanze di qualche digi.
    In altre parole se l'area di copertura della nostra stazione è perfettamente servita (anche come ricezione) da parte di stazioni messe meglio di noi , è inutile che pretendiamo , magari spinti da buone intenzioni, di essere noi a ripetere mezzi mobili e portatili quando qualc' un altro lo può fare meglio di noi!
    Infine le stazioni mobili dovrebbero disabilitare tutte le modalità di ripetizione.
    ---------------------------
    E' deleterio inviare il beacon ad es. a "APRS,RELAY,RELAY,TRACE7-7" perchè cosi facendo si provocano una serie di ripetizioni locali che ,oltre a  causare l'intasamento del canale, non si garantisce che il mio beacon arrivi al digi n-n perchè tutti i "relay" che mi ripetono potrebbero non vedere direttamente il digi n-n.

    Chi avrà avuto la pazienza di leggere il tutto avrà visto che le diferenze tra le configurazioni proposte sono minime ma..... sostanziali.
     

    P.S. E' anche possibile inserire nell' unproto address dopo trace7-7 anche wide7-7. Al momento questo tipo di istruzione è del tutto inutile perchè, data l'estensione della rete attuale, con 7 "salti" si e' in grado di arrivare fin dove c'è attività APRS in Italia. (ne avanza anche). Dare quindi istruzioni per fare 7+7=14 "salti" significa solo far fare delle ripetizioni inutili quando si incontrano digi settati male!!
     

    Per il G.A.L. Gruppo APRS Lombardia ha scritto IK2YDM

    >>>>>   FINE  BOLLETTINI