BayCom è una celeberrima linea di prodotti per gestire le comunicazioni in Packet Radio, dal modem ultraeconomico quasi interamente basato sul software al controllore multiporta ad alta velocità, che ha dato origine ad una serie di programmi similari. Questa serie esamina le diverse opzioni possibili per costruire una stazione Packet
Tra i programmi di Packet Radio, il BayCom è sicuramente il più famoso ed amato, poiché ha permesso a moltissimi di entrare nel mondo del Packet senza investire cifre elevate. Ripercorriamo la sua storia, confrontandolo con i suoi emuli, ed intanto scopriamo molti segreti della trasmissione in Packet Radio.
Correva l'anno 1991, e per chi li ricorda ancora (!), regnavano i processori di classe 386; allora, per operare in Packet Radio, occorreva necessariamente munirsi di un TNC, una sorta di incrocio tra un modem ed un piccolo sistema telematico, dal costo di svariati biglietti da centomila che ne scoraggiava l'acquisto ai più. L'alternativa era di passare ad un computer di progettazione più recente, come Amiga o MacIntosh: certo possibile, ma che costo, e che smacco per la piattaforma più amata dai radioamatori, che si costruivano le schede con stagno e saldatore...
Potrà sembrare strano, ma per quanto potenti i PC fino ad allora non erano in grado di sopperire alla ben inferiore potenza di calcolo dei TNC, che erano però nati esclusivamente con lo scopo di fare Packet.
Ma ormai i tempi erano maturi; e come nella storia, quando arriva il suo momento la stessa scoperta scientifica avviene in più posti ad opera di persone che non sanno nulla del reciproco lavoro, così nel mondo nel Packet cominciarono a fiorire i programmi che staccavano "il cordone ombelicale" tra TNC e Packet Radio. Erano nati i primi emulatori di TNC, in grado di abbassare il costo di accesso al mondo del Packet Radio a poche migliaia di lire...
È una storia breve ma piena di genialità, quella del Packet a basso costo, che arriva fino ai giorni nostri.
GLI ALBORI
Il primo programma che aboliva il TNC in favore di un semplicissimo modem a basso costo, privo di intelligenza, si chiamava PMP, ovvero "Poor Men's Packet", il Packet della povera gente... Sebbene un terremoto nel suo campo, questo progenitore - completamente gratuito - fu abbandonato abbastanza presto in favore di programmi più supportati. Esso era nato infatti quasi per scherzo, e l'autore non ne rilasciò versioni più aggiornate.
Pochi mesi dopo, ad opera di un gruppo di radioamatori tedeschi, appare il BayCom, destinato ad n grandissimo successo, tanto da identificarsi con il "Packet senza TNC"; segue a breve distanza il Packet Monitor, un decodificatore per la sola ricezione del Packet che richiede un hardware ancora più striminzito.
Passa ancora qualche mese ed un prodotto Packet commerciale molto curato, dal nome Eskay Packet, inizia a supportare i dispositivi modem virtuali.
Da allora il Packet "economico" ha fatto molta strada sul PC, tanto che questo è diventato la piattaforma preferita per gli "smanettoni" con poche risorse economiche. L'adozione di una struttura software "a strati", infatti, ne consente l'impiego anche con molti programmi nati per l'abbinamento con un TNC. La prossima barriera è quella dei sistemi operativi poco "real time", come Windows, che pongono un serio problema a questo tipo di programmi. Ma l'uomo è un animale geniale, ed il radioamatore a maggior ragione, dunque anche questo problema sarà certamente superato...
SINCRONO O ASINCRONO
Sicuramente vi starete chiedendo quale sarà questa misteriosa difficoltà che rende un PC così inadatto al Packet rispetto ad un TNC od un altro tipo di computer, quando lo stesso PC riesce a fare cose sbalorditive e magari a parlare contemporaneamente con un modem a velocità vertiginosa.
Il problema di base sta nel modo in cui i dati vengono trasmessi. L'unica modalità nota ad una classica seriale di PC è la cosiddetta "asincrona". In questa modalità ogni byte da trasmettere - trattandosi di una trasmissione seriale - viene trasmesso un bit alla volta, preceduto da un bit iniziale (di valore fisso) ed uno finale. Non esiste alcun vincolo temporale tra un byte e l'altro, a parte ovviamente la non sovrapposizione, e per questo si parla di "modo asincrono".
Il Packet invece utilizza una modalità cosiddetta "sincrona": in essa i byte sono prima raggruppati in pacchetti (da cui il nome "Packet"), a cui vengono aggiunti altri byte indicanti la sorgente e la destinazione dei dati stessi, quindi altre informazioni per la correzione degli errori, ed il tutto viene infine trasmesso in blocco, senza pausa tra un byte e l'altro fino alla fine dei dati stessi; per inciso, questo è lo stesso modo usato dalle schede Ethernet.
Il pacchetto, che può contenere un certo numero massimo di byte, ha ovviamente una struttura ben più complessa di una normale trasmissione asincrona, ed è quindi comprensibile che nel primo PC non fosse fornita un'interfaccia seriale sincrona oltre a quella asincrona.
Chiariamo meglio cosa sia un'interfaccia. Il PC, "dentro", è formato, come ormai tutti sanno (vero?) di un microprocessore e di una serie di memorie, con un contorno di "gestori di periferiche" che liberano il microprocessore da una parte dei compiti di basso livello, consentendogli di far girare più velocemente i programmi.
Un esempio di questi compiti a basso livello è quello svolto dalla classica seriale del PC, che, dicevamo, è in grado di trasmettere in forma seriale un byte alla volta. Pensate ora a cosa significa inviare un byte alla volta su una seriale "classica", quella asincrona, a livello microscopico: il microprocessore carica un byte all'interno della periferica che controlla la seriale, e le dice "inizia la trasmissione". Il gestore o controllore seriale trasmette per prima cosa il bit di inizio, quindi - uno alla volta - i bit di dati, quindi il o i bit di stop, e solamente a questo punto è richiesto un intervento del microprocessore, che nel frattempo è stato occupato a fare altre cose.
Se si usa un gestore di periferica "seriale sincrona", le cose sono ancora più semplici: il processore segnala dove e quanti sono i dati da trasmettere, e l'apposito gestore si occupa di generare tutti i codici di correzione d'errore, le identificazioni del mittente e del destinatario, e tutto ciò che occorre per la gestione del pacchetto. Il processore nel frattempo può fare veramente di tutto, avendo a disposizione un tempo enorme (informaticamente parlando...).
Ora, il problema nasce quando si vuole effettuare una trasmissione sincrona anche senza il controllore apposito, che, come abbiamo detto, nel PC originale non esiste.
COME RINUNCIARE AD UN GESTORE E SOPRAVVIVERE (FELICI?)
In questo caso non c'è molto da fare; ci salviamo solo grazie al fatto che il processore ha la possibilità di "scavalcare" il controllore seriale e cambiare lui stesso lo stato d'uscita della porta seriale, nonché verificare lo stato dell'ingresso. Purtroppo però ora deve fare tutto da solo, non potendo contare sull'aiuto di nessuno: deve generare i codici d'inizio e di fine, quindi calcolare ed aggiungere tutte le informazioni aggiuntive che formano la trama completa, ed infine trasmettere tutti i bit uno alla volta, con pazienza certosina. Trasmettere un byte in questo modo equivale - come carico per il processore - a trasmetterne dieci con una seriale asincrona, o migliaia con un controllore sincrono. In ricezione la situazione è ancora più infernale: il microprocessore deve collezionare un bit alla volta, da questi ricostruire i vari byte componenti, quindi ancora estrarre i dati da tutte le informazioni di controllo; ma c'è di peggio: data la lunga sequenza di bit, occorre compensare i piccoli spostamenti apparenti dell'inizio di ogni bit, e questo può essere ottenuto solo verificando lo stato dell'ingresso con una frequenza molto maggiore (da 16 a 32 volte). Un compito se non proibitivo quantomeno molto pesante. Questo spiega perché un componente elettronico molto usato per la trasmissione seriale sincrona - ed anche in molte schede Packet professionali - è l'8530, un oggetto dalla complessità paragonabile ad un microprocessore degli anni '80.
Ecco anche spiegato perché si è dovuto attendere la disponibilità di processori come i '286 veloci per assistere alla diffusione di questo tipo di programmi.
73 de Mario
Le immagini non sono più disponibili... mi dispiace!)
Fig. 1: Gli stessi dati ("byte" di quattro bit...) trasmessi in modalità seriale asincrona (sopra) e sincrona (sotto). La modalità sincrona non è supportata dalla seriale standard del PC, ma programmi come il BayCom riescono ugualmente ad emularla.
No, non si tratta di una persona, ma pur sempre di un amico per tanti radioamatori che hanno effettuato collegamenti in tutto il mondo grazie ad esso. La sua fine, prevista per la fine dell'anno per il decadimento dell'orbita e l'eccessivo riscaldamento dovuto all'attrito con l'atmosfera, è puntualmente avvenuta: la telemetria indicava nei giorni 16/17 temperature di oltre 60° per i pannelli solari. Qualche giorno di fiato sospeso, poi il giorno 23 novembre alle 11.40 UTC, il pannello solare 3 ha smesso di funzionare. Al perigeo successivo (quando cioè il satellite era più vicino alla Terra, nel momento di massimo riscaldamento), anche i pannelli 1, 2, 4 e 6 hanno ceduto, ed è sopravvissuto solo il numero 5. Per risparmiare energia, i trasponder sono stati spenti da Graham VK5AGR, del team di controllo, alle 23.14 UTC. Durante l'orbita successiva, è continuata solo la telemetria del beacon. AO-13 è sopravvissuto al perigeo delle 4.32 UTC del giorno 24, mentre i dati della telemetria (perigeo a soli 107 km. dalla Terra) venivano raccolti da molti insonni di tutta Europa. La tensione della batteria era stabile sugli 11.8 volt, molto inferiore alla classica di 14.5. VK5AGR ha poi monitorato il resto dell'orbita, ma il pannello superstite si è dimostrato insufficiente per sostenere l'elettronica di bordo, ed il beacon ha cessato le trasmissioni alle 5.38 UTC (6.38 ora italiana) del 24 novembre. I comandi di reset, che avrebbero generato un segnale continuo non modulato, non hanno avuto effetto. Dopo alcune ore di tentativi, i membri del gruppo di controllo hanno dichiarato ufficialmente la perdita del satellite.
Oscar-13 (AO-13) è stato lanciato nel 1988, ed era il più sofisticato satellite radioamatoriale in orbita, disponendo di un sistema di motori per la correzione dell'orbita, che non erano a razzo, ma a spinta magnetica. Una serie di bobine, infatti, attivate con corrente elettrica ricevevano spinta dal campo magnetico terrestre.
Il sistema di controllo era costruito attorno ad un microprocessore RCA 1802 con appena 32 KByte di RAM, su cui girava un software denominato IPS, Interpreter for Process Structures, un sistema operativo multiprocesso molto simile al Forth. Scritto dal Dr. Karl Meinzer, DJ4ZC, l'IPS è stato impiegato a bordo di altri satelliti radioamatoriali, come l'AO-10, lanciato del 1983 e tuttora in funzione. A bordo era presente anche un sistema di posta elettronica denominato "RUDAK-1" costruito attorno ad una CPU 65SC02.
BayCom, nel mondo dei radioamatori, ha rappresentato ben più di un semplice programma; esso infatti è stato il primo terminale Packet Radio a bassissimo costo che offriva prestazioni e caratteristiche tali da non dover rimpiangere una attrezzatura tradizionale. In questa puntata vedremo perché, anzi, per certi versi il BayCom è un programma all'avanguardia.
Se avete digerito, magari con l'aiuto di un po' di bicarbonato, la scorsa puntata, in cui abbiamo visto in maniera molto tecnica dove sia la difficoltà nell'usare una periferica seriale di un PC per operare in Packet Radio, potete cominciare a riprendervi: è il momento di cominciare a vedere seriamente il programma BayCom.
Il "pacchetto" BayCom è formato essenzialmente da due programmi rigorosamente DOS, l'L2 e l'SCC. Il primo è un programma residente che si occupa degli strati più bassi della comunicazione: gestisce l'interfaccia seriale come se fosse di tipo sincrono, si occupa della spedizione e della ricezione dei pacchetti, ed arriva a svolgere la funzione di "digipeater" ossia il funzionamento da "ponte" digitale per i pacchetti; gli altri radioamatori infatti possono utilizzare la vostra stazione come "ponte" per rilanciare i propri pacchetti oltre la propria area di copertura.
L2, come abbiamo detto, è un programma residente; questo consentiva, ai tempi in cui sul PC imperava il DOS, di avere la stazione Packet operativa anche mentre si impiegava il computer per altri scopi, anche se solo per operazioni di basso livello, come per il "digiponte" dei pacchetti e per l'emissione del segnale identificativo periodico o "beacon".
L'attivazione del programma L2 è segnalata da un quadratino lampeggiante in alto a destra sullo schermo. Non tutti i programmi DOS sopportano il carico di interruzioni generate dalla presenza dell'L2, che come abbiamo detto si occupa di decodificare esclusivamente da software i pacchetti trasmessi in modalità sincrona, aggirando la porta asincrona del PC, con un conseguente grosso appesantimento del carico sul processore centrale.
Una particolare "applicazione DOS" come è il vecchio Windows 3, poi, crea dei problemi di coesistenza gravissimi...
Tuttavia sono documentati casi, su elaboratori particolarmente veloci, in cui è stato possibile caricare l'L2 con Windows (anche 95), facendo funzionare il tutto! L'unica avvertenza è quella di caricare L2 prima di Windows, quindi lanciare il programma di terminale da Windows come applicazione DOS. Vale la pena di provare.
IL TERMINALE PACKET DI BAYCOM
Il programma di terminale, come abbiamo detto, si chiama SCC e fornisce l'interfaccia utente alle comunicazioni Packet.
Esso offre il pieno controllo dello stato delle comunicazioni, molto più di quanto faccia un programma di terminale che utilizzi un TNC tradizionale. D'altr'onde è ovvio: poiché tutte le funzioni di ricezione e trasmissione vengono adesso svolte dentro al PC stesso, è possibile "spiarne" l'andamento in modo molto approfondito.
Lo schermo del terminale Packet è diviso in tre zone, separate da due barre di stato. La zona in alto è quella di immissione; in essa si inseriscono sia i comandi, sia il testo da inviare alla stazione collegata.
La seconda zona è quella di ricezione. In questa zona appaiono tutte le risposte ai comandi dati, ed anche le informazioni ricevute dalla stazione collegata.
La terza zona, la più in basso, è la finestra "monitor", che visualizza tutti i pacchetti in transito sul canale, visualizzandone tipo, provenienza, destinazione e contenuto. A prima vista le informazioni in essa visualizzate sono incomprensibili; tuttavia, esaminandone il susseguirsi dei pacchetti potrete arrivare a scoprire come funziona il protocollo Packet stesso.
Se ad esempio inviate un comando di connessione ad un'altra stazione (es. digitate C IW0CHN - cioè "Connect IW0CHN"), appena premuto Invio - sempre che in quel momento non ci sia nessun altro a trasmettere sul vostro canale - , vedrete apparire sulla finestra monitor: "T:31 18:17 IW0CDT>IW0CHN>SABM,P", seguito, sempre che nessuno si inserisca nel frattempo, da un altro pacchetto "T:31 18:17 IW0CHN>IW0CDT>UA,F".
Questi messaggi, scritti in un linguaggio che diventa chiaro appena si conosce il protocollo AX.25 usato in Packet, possono essere i primi passi nel mondo dei protocolli a pacchetto: il primo, infatti, è un pacchetto di richiesta di connessione - SABM significa "Set Asynchronous Bilateral Mode, ossia "imposta modo asincrono bilaterale". In parole povere, IW0CDT ha richiesto a IW0CHN (origine e destinazione sono sempre visibili nell'intestazione) l'apertura di un canale virtuale bidirezionale per lo scambio di informazioni. Su esso le informazioni viaggeranno senza subire disturbi da parte di nessun'altra comunicazione in corso.
La risposta UA - che significa Unnumbered Acknowledge, ossia "conferma non numerata", da IW0CHN a IW0CDT, conferma l'apertura del canale richiesto (la conferma è l'unica "non numerata"; tutti successivi pacchetti di scambio dati saranno numerati, per garantire che nessuna informazione vada persa). La ",P" finale sta per "Poll", ossia "richiesta", ed indica che l'origine sollecita una risposta da parte del destinatario: ovviamente, se stiamo cercando di connetterci vorremmo per prima cosa sapere se dall'altra parte c'è disponibilità alla connessione. La ",F", invece, sta per "Final", e indica che non si richiede risposta; da questo momento in poi, stabilito il canale virtuale, solo chi avrà bisogno di spedire informazioni effettuerà altre trasmissioni, evitando di occupare inutilmente il canale.
La cosa simpatica della finestra monitor è che essa è disponibile sempre, anche durante le connessioni ad un'altra stazione; con essa è possibile "vedere" il traffico che si svolge sul nostro canale condiviso tra varie comunicazioni, permettendo di rendersi subito conto di chi e quando stia comunicando con altri.
I CANALI MULTIPLI
Ma fin qui non abbiamo fatto altro che vedere un solo terminale virtuale: BayCom, infatti, ne offre ben sette, corrispondenti a sette diversi canali, selezionabili con i tasti da F1 a (ovviamente) F7; su ciascuna di questi canali è possibile collegarsi ad una stazione diversa e svolgere una diversa conversazione, in modo del tutto indipendente l'uno dall'altro. Ad aiutarci in questo "zapping" da una conversazione all'altra ci pensa la barra di stato in basso: essa ci indica, evidenziandola in viola, il canale su cui ci troviamo, e la stazione a cui esso è connesso. La presenza di nuove informazioni sul canale viene rivelati dal lampeggiare dell'indicazione corrispondente; in questo modo è possibile conversare con più radioamatori contemporaneamente saltando solo là dove serve. Esiste poi un canale particolare canale, corrispondente a F10; selezionandolo solo il traffico "monitor" è visualizzato, mentre l'area centrale, quella di ricezione, è collassata. Tutto ciò che scriviamo su questo canale viene trasmesso come pacchetto non numerato, e cioè destinato a tutte le stazioni in ascolto.
LO SCAMBIO DI FILE
BayCom consente sia di registrare le proprie sessioni su un file, che di ricevere e trasmettere file, siano essi di testo che binari; per questi ultimi ci sono però alcune difficoltà, dovute al fatto che BayCom non supporta il protocollo YAPP, il protocollo per i trasferimenti binari in Packet molto diffuso in Francia ed in Italia ma che, evidentemente, non altrettanto in Germania, la patria di BayCom. Ma il radioamatore è un animale molto ingegnoso, e questo problema è stato aggirato, in modo macchinoso ma efficace, sfruttando le caratteristiche di unidirezionalità del protocollo YAPP: si attiva il trasferimento YAPP imbrogliando il BBS o la stazione collegata, spedendo una serie di caratteri di controllo; la cosa è particolarmente semplice se essi sono memorizzati come macro in un tasto, possibilità offerta da BayCom. Si avvia quindi il salvataggio su file.
Una volta terminato il trasferimento, esistono ormai parecchi programmi che trattano il file ricevuto, eliminando tutti i caratteri di controllo aggiunti dal protocollo YAPP, e ricavano così il file originale. Sembrerà strano e complicato, ma funziona...
Un'altra caratteristica simpatica di BayCom è quella di permettere di far eseguire a distanza dei comandi. Così, è possibile consentire alle stazioni che si collegano a noi di visualizzare l'elenco delle stazioni collegate, quelle ricevute, o i file che è possibile prelevare, e così via. Trattandosi di una funzionalità piuttosto delicata in termini di sicurezza, è possibile abilitare e disabilitare uno ad uno tutti i comandi remoti, in base alle proprie preoccupazioni.
I COLLEGAMENTI AL MODEM
Come abbiamo detto la scorsa volta, BayCom elimina parecchie necessità in fatto di hardware, poiché nell'L2 vengono svolte moltissime funzioni proprie di un TNC. Per questo, è possibile dotarsi di un semplice modem a 1200 BPS che può essere realizzato o con un semplice circuito integrato XR2211, oppure con un AM7910 o 7911. Il primo è un componente dalle prestazioni un po' peggiori, ma è molto compatto, tanto da poter essere montato all'interno della stessa presa che si collega all'uscita RS-232 del PC; grazie al ridotto consumo, non è necessaria nemmeno un'alimentazione esterna. Si tratta della soluzione ideale per il Packet mobile: un PC portatile, un modem compatto, una radio, e via.
Chi desideri le prestazioni migliori, può invece realizzarsi un modem tramite un AM7910, o il suo miglioramento AM7911; sono componenti molto più costosi e dal maggior consumo, ma dalle prestazioni decisamente eccellenti.
La versione ultima del BayCom, la 1.60, supporta anche la velocità di 9600 BPS, che in Packet è ragguardevole; anche qui non si richiede un TNC, ma un particolare convertitore analogico/digitale da collegare alla porta parallela del computer.
Tutti questi modem per la radio possono essere acquistati, a prezzo "non commerciale", direttamente dal team BayCom, che li fornisce anche in diverse versioni. Il team può essere contattato anche sull'immancabile Internet, all'indirizzo http://www.baycom.de. Basta un messaggio di posta elettronica.
Nel caso vogliate costruirlo da voi, tenete presente che dovrete collegare i fili della seriale in un modo abbastanza atipico; a causa dei vincoli citati più volte, i dati non escono dal classico piedino di "Tx Data", ne ricevuti sull' "Rx Data".
73 de Mario
(Le immagini non sono più disponibili... mi dispiace)
Fig.1: La finestra del terminale BayCom, appena aperta. Sono visibili le tre zone per l'immissione dei comandi e dei messaggi da spedire (in alto), dei messaggi ricevuti (al centro), del monitor del traffico sul canale (in basso). In quest'ultima appaiono i messaggi spediti in Packet per effettuare la conversazione che appare nelle prime due.
È molto evidente anche la barra che consente di commutare e tenere sotto controllo le sette conversazioni possibili contemporaneamente.
Fig. 2: Il programma BayCom consente all'utente remoto di dare comandi sulla stazione locale, precedendoli con "//". Con "//cstatus" appare l'elenco delle connessioni attive in quel momento: possono essere fino a sette, una per ogni canale virtuale.
È stato presentato in sordina dal Ministero delle Poste e Telegrafi un nuovo regolamento di attuazione per il settore dei radioamatori. Purtroppo in esso si devono rilevare notevoli approssimazioni, leggerezze e perfino errori formali e sostanziali, nonché la tendenza a ridurre notevolmente lo spazio per la sperimentazione permessa ai radioamatori. Se è vero che il settore soffre di notevoli carenze - peraltro in parte dovute proprio all'assenza di una regolamentazione chiara - ci pare che se dovesse prevalere questa linea repressiva si sarà persa una grande occasione di sfruttare il grande patrimonio di esperienza e di abnegazione costituiti dalla gran parte dei radioamatori che credono nell'utilità del loro hobby.
In particolare, i due punti che suscitano i maggiori dissensi sono:
Vi sono poi altre gravi incongruenze, sia formali che sostanziali. Tra esse, spicca il fatto che questo regolamento d'attuazione è previsto dal D.P.R. nr. 156 del 29 Marzo 1973; mentre ragione vorrebbe che il regolamento venga emanato in 6 o 12 mesi dopo l'approvazione della legge, siamo qui in presenza di un regolamento emanato con ben 280 mesi di ritardo. Per questo motivo già un precedente tentativo in questo senso fu rigettato dal Consiglio di Stato.
Tutto questo ignorando inoltre che esiste da anni un Disegno di Legge già discusso dalle associazioni di categoria, che vorrebbe garantire ai radioamatori italiani lo stesso trattamento dei loro colleghi europei e non solo; i radioamatori italiani infatti non sono penalizzati solo dalla ridotta quantità di frequenze loro assegnate, ma anche dall'incertezza giuridica circa l'installazione di ponti radio e stazioni Packet; e perfino l'attuale licenza "speciale" non è prevista dalla vecchia legge, rimasta praticamente immutata dal 1936 (!).
Con questo regolamento inoltre si continua a perpetuare il concetto di servizio di Radioamatore come "concessione" dello Stato, in luogo di "autorizzazione". È una pretesa sorprendente, poiché per parlare di "concessione" si deve ammettere che l'unico in Italia ad avere il diritto di fare il radioamatore è lo Stato stesso, che "concede" ai radioamatori il compito di farlo in sua vece o per suo conto. Bisognerebbe invece parlare di "autorizzazione", con cui lo Stato riconosce a ciascun cittadino il diritto di esercitare la libertà di espressione garantitagli dalla Costituzione, anche attraverso la radio.
Sorvoliamo infine sulla questione economica (il regolamento dovrebbe portare un adeguamento dei canoni da pagare per l'esercizio della stazione), ripetendo la ormai annosa considerazione che i radioamatori sarebbero ben felici di pagare di più degli anacronistici canoni, mai rivisti dal dopoguerra, a patto di avere una maggior sorveglianza ed attenzione da parte dello Stato.
In questi giorni stanno pervenendo da parte di singoli radioamatori e delle loro associazioni (tra cui si è distinta per fermezza e responsabilità la CISAR) le proteste per il contenuto del regolamento e le proposte alternative per mettere definitivamente chiarezza in un settore che l'attende da anni. Speriamo che l'inefficienza di qualche burocrate non spenga la possibilità per il nostro paese di usufruire di un apporto tecnico di tutto rilievo, quale quello dei radioamatori, a cui tutto il resto del mondo attinge andandone giustamente orgoglioso.
Alcuni "acciacchi" di vecchiaia per l'UoSAT-2 (UO-11); è stato recentemente osservato infatti che il suo periodo di rotazione non era quello nominale. La stazione di controllo da terra ha quindi effettuato un controllo manuale della funzionalità dei motori magnetici, usati per controllare l'orientamento del satellite. Per il controllo dell'assetto, infatti, l'Oscar-11 non fa uso di tradizionali razzi, ma di bobine magnetiche che, interagendo col campo magnetico terrestre, forniscono una spinta rotazionale.
Mentre i motori degli assi X e Z risultavano funzionare regolarmente, quello dell'asse Y ha evidenziato un problema. Si tratta proprio di quello usato per mantenere il periodo di rotazione a circa 5 minuti; il guasto ha impedito al computer di bordo di mantenere questo periodo costante.
Il motore magnetico dell'UoSat-2 funziona attraverso corrente elettrica, ed è azionato da un relè; ma quando ciò avviene per l'asse Y, si osserva dalla telemetria solo un piccolo aumento di consumo dalle batterie; questo aumento è probabilmente dovuto al relè stesso, per cui si immagina che si sia verificato un guasto ai contatti del relè, oppure la bobina magnetica del motore si è interrotta.
Per questo, durante il pomeriggio del 22 dicembre, durante i passaggi dell'UoSAT sulla stazione terrestre, è stato caricato sul computer di bordo il nuovo software di controllo che usa il motore dell'asse X per controllare la velocità di rotazione, invece di quello dell'asse Y. La stazione di controllo nel Surrey ha quindi continuato a sorvegliare l'assetto del satellite per alcuni giorni, per assicurarsi che il nuovo software abbia risolto il problema.
È interessante notare che, mentre è possibile controllare ancora l'assetto di un satellite con due motori, è stato dimostrato che non esiste alcun modo di farlo usandone uno solo; nel caso di rottura di un altro motore, dunque, il satellite risulterebbe non più controllabile.
L'UoSAT-2 è stato lanciato dalla base aeronautica di Vandenburg negli USA nel marzo 1984, ed è quindi in funzione da quasi 13 anni, avendo completato 68.000 orbite intorno alla Terra.
[Informazioni da Chris Jackson, G7UPN / ZL2TPO via AMSAT News Service]
Fig. 1: Il grafico della temperatura dei pannelli dell'UoSAT-2 nel mese di Novembre. La notevole alterazione di questo grafico durante il mese di Dicembre ha fatto sospettare un problema di controllo di assetto del satellite.
Dopo l’interruzione non voluta dello scorso mese, riprendiamo il nostro consueto appuntamento con il mondo dei radioamatori in abbinamento con il PC.
Il BayCom, il cui nome deriva dall’omonimo gruppo di radioamatori bavaresi che lo hanno creato (Bayern è la Baviera in tedesco), è giunto alla versione 1.60; a causa della sua grande versatilità, si è diffuso a macchia d’olio negli ultimi anni, tanto che qualcuno, un po’ disinvoltamente, ha pensato di distribuire il programma in abbinamento con un modem in kit per l’autocostruzione o addirittura già montato (un po’ un controsenso per chi si dichiara radioamatore, ma tant’è...). Il gruppo BayCom si è comprensibilmente un po’ risentito del fatto che altri si siano appropriati della sua "creatura", guadagnando su di essa; e così ha deciso di imporre alcune restrizioni sulla politica di distribuzione del programma. E come al solito, i tanti corretti ci hanno rimesso per la colpa di pochi. Così, oggi BayCom resta sempre gratuito, ma la sua distribuzione non è più totalmente libera. In particolare, non è permesso distribuire il programma su reti di qualsiasi genere, su BBS e su CD-ROM, nè in abbinamento con qualsiasi oggetto commerciale. È invece possibile copiare e distribuire "di persona" il programma; in sostanza, ogni forma di distribuzione diretta a più persone è sgradita al gruppo BayCom. Misure sicuramente impopolari, ma che possono essere facilmente comprese; e se proprio non conoscete nessuno che possa darvi il BayCom, non dovete fare altro che richiederne una copia al gruppo BayCom, tramite posta tradizionale o elettronica, pagando i quindici marchi richiesti per il disturbo.
IL PROGRAMMA L2
Il BayCom, come abbiamo detto, è composto da due "strati" di software, ovvero l’L2 e l’SCC, ovvero il "gestore" di basso livello o emulatore di TNC, ed il programma di terminale vero e proprio. La scorsa volta abbiamo esaminato, sebbene abbastanza a "volo d’uccello", il programma di terminale; stavolta occupiamoci più da vicino del gestore di basso livello, l’L2. Il nome di tale programma annuncia che si tratta di colui che si occupa dei primi due livelli del protocollo AX.25, quelli più bassi. Il massimo che l’L2 riesce a fare da solo, infatti, è rispondere alle richieste di connessione che riceve con un messaggio che avverte che il terminale non è attivo (ricorda molto un telefono cellulare, lo so!).
Per configurare correttamente il programma L2 esiste un apposito file di configurazione, che si chiama SCC.INI; questo file di testo viene generato automaticamente dal programma di installazione, che nella versione 1.60 è stato notevolmente migliorato. Si occupa infatti di generare non solo i parametri per la ricetrasmissione (che comunque vanno ottimizzati a mano), ma anche i messaggi che vengono emessi alla connessione di altre stazioni, alla disconnessione, ed altre situazioni.
Il gruppo BayCom, infatti, si è accorto che, in molti casi, nella fretta di "andare in aria" e provare questo sorprendente programma, molti radioamatori si dimenticavano di personalizzare i vari messaggi; così, collegandovi a gran parte delle stazioni che usano BayCom, si riceve sempre lo stesso messaggio predefinito. Per questo, il programma di installazione adesso si preoccupa di inserire il vostro nominativo e qualche frase personalizzata nelle configurazioni. Tutte le impostazioni dei messaggi di stazione sono in un’apposita sezione dell’SCC.INI; in altre sezioni troviamo, oltre alle scontate impostazioni dei colori e dello schermo, anche una serie di parametri di comunicazione: ritardi di trasmissione, velocità, porte di comunicazione, memoria tampone, ...
L’interfacciamento con la radio può essere realizzato in diversi modi: con modem seriali a 300 o 1200 baud, con modem per porta parallela a 9600 baud, o con schede SCC (vedi riquadro) che permettono di avere più radio collegate contemporaneamente al PC, ed anche TNC in modalità KISS. Quest’ultima modalità è comoda per chi ha un TNC tradizionale, ma non vuole rinunciare ad usarlo con il programma BayCom.
Il file SCC.INI non viene letto dai programmi L2 e SCC così com’è, ma va compilato grazie all’apposito programma Para.exe; esso genera un altro file, SCC.PAR, e solo con esso possiamo lanciare il pacchetto BayCom.
9600 BAUD VIA RADIO
Uno dei vantaggi del BayCom è la possibilità di infrangere, ad un prezzo molto ridotto, la barriera dei 1200 baud. Purtroppo, però, a differenza del caso telefonico, collegare un modem a 9600 baud ad una radio è una faccenda tutt’altro che facile, e questo costituisce il principale freno alla diffusione di questa nuova velocità. La colpa è da ricercarsi nelle forti distorsioni e non linearità dei vari stadi di amplificazione interni alla radio: il segnale da trasmettere viene talmente distorto che non è possibile ricostruirlo in ricezione. Con l’AFSK a 1200 baud, questo tipo di problemi era molto più ridotto.
Così, occorre quasi sempre armarsi di saldatore, ed aprire la radio per saldare i fili di trasmissione e ricezione direttamente sul modulatore e sul discriminatore per operare con un segnale veramente pulito; non sapete nemmeno di cosa sto parlando? Niente paura, siete in buona compagnia; ed adesso avete capito perché i 9600 baud in packet non sono ancora così affermati. Ma per fortuna sul mercato si trovano oggi trasmettitori già predisposti per l’uso a queste velocità.
I prodotti del gruppo BayCom
Il catalogo BayCom, che contiene tutte le realizzazioni offerte dal gruppo, merita senz’altro di essere spulciato, poiché in esso si trovano altre realizzazioni radioamatoriali di un certo interesse, di cui è disponibile la sola basetta, il kit o la versione montata e collaudata. Il programma di terminale omonimo, che abbiamo appena visto, può operare a 1200 baud con due versioni di modem AFSK (lo standard più diffuso in assoluto in Packet): una alloggiata in una presa seriale a 25 poli e l’altro in una a 9 poli; entrambi usano l’ottimo integrato TCM3105 e traggono l’alimentazione direttamente dalla porta seriale. Troviamo poi un modem costruito attorno ad un AM7911, un componente dalle eccellenti caratteristiche compatibile anche con lo standard Packet a 300 baud usato nelle bande decametriche, sulle quali è possibile collegarsi in tutto il mondo. Questo tipo di modem però necessita di un’alimentazione esterna, consumando troppo per essere alimentato direttamente dalla seriale. I prezzi per il kit vanno da 115 a 195 marchi.
Chi non è addentro alle cose del Packet potrebbe rimanere un po’ perplesso a sentire parlare di "modem", che normalmente sono associati ad un telefono; in effetti, questi modem sono in tutto e per tutto identici ai loro colleghi telefonici, dai quali differiscono unicamente per avere l’uscita compatibile con una radio ricetrasmittente anziché col la linea telefonica. In altre parole, ciò che differenza un modem via radio da uno telefonico è esclusivamente la presa di collegamento e pochi componenti attorno ad essa.
Tra gli ultimi prodotti sviluppati dal team c’è una serie di modem a 9600 baud (finalmente un po’ più veloci!) compatibili con il protocollo sviluppato ormai dieci anni fa da G3RUH James Miller, in assoluto il più diffuso sulle bande radioamatoriali per velocità oltre i 1200 baud.
Di modem a 9600 baud ne esistono due modelli: il PAR96, da collegarsi alla porta parallela del PC e misurante circa 10x10 cm., ed il PICPAR, ultimo uscito, più piccolo e più flessibile, che si alimenta direttamente dalla porta parallela; prezzi rispettivamente 175 e 139 marchi. Con poche modifiche ai valori di alcuni componenti ed una radio adatta è possibile arrivare fino a 19200 baud, una velocità "stratosferica" per il Packet.
Sempre tra i prodotti sviluppati dal team troviamo un TNC di tipo tradizionale, il TNC2X, che quindi permette di avere la stazione Packet funzionante anche a PC spento; il TNC può essere equipaggiato di un modem a 1200 baud AFSK tradizionale, oppure di un modem commutabile tra 1200 e 9600 baud; la possibilità di sostituire il solo modem del TNC ne garantisce l’aggiornabilità anche con nuove modulazioni digitali amatoriali che possano nascere in futuro. Il TNC2X costa in kit 199 marchi, i modem 59 e 89 marchi.
Tra i prodotti più noti del gruppo BayCom troviamo le schede per PC USCC>4 e USCC>8. Si tratta di schede interne per PC, perfettamente integrate con il programma BayCom, che consentono di gestire fino a 4 o 8 diversi canali, collegabili ad altrettante radio. Si tratta di schede adatte per grossi nodi multicanale, che scambiano pacchetti su varie frequenze e bande tra quelle amatoriali (HF, VHF, UHF). Su ogni scheda è possibile montare più tipi di modem a 300, 1200 e 9600 baud. Una USCC>8 in kit costa solo 265 marchi, ed un modem a 9600/1200 baud per un canale 99 marchi. Si possono montare fino a otto USCC>8 in un mobile rack da 19 pollici, ottenendo un "supernodo" da 64 canali, una vera e propria "centrale telefonica" dell’etere.
Un’altra versione di scheda, sempre per PC, incorpora il modem ed un trasmettitore UHF; si tratta della 9k6-USCC-Slotcard; con essa si evita ogni problema di interfacciamento tra la radio ed il modem a 9600 baud. Il kit costa 539 marchi, comprensivo dei quarzi per la ricetrasmissione sul canale desiderato; l’alloggiamento per un secondo modem consente di realizzare facilmente un nodo a due canali.
Infine, sul catalogo BayCom troviamo un’intera linea di prodotti per il beneamato Commodore 64: sì, proprio lui, che si è guadagnato una imperitura fama tra i radioamatori grazie alla possibilità di operare in Packet con una semplicissima schedina, esattamente come il BayCom; il programma che permetteva questo si chiamava (e si chiama tuttora) Digicom; si tratta dell’antenato del BayCom, sviluppato dallo stesso gruppo di radioamatori. Bene, tutti i prodotti per l’interfacciamento del C64 sono ancora disponibili, inclusi modem a 9600 e 1200 baud, ed un controllore a due porte.
Informazioni e cataloghi possono essere richiesti via Internet all’indirizzo http://www.baycom.de o scrivendo a baycom@baycom.de, o ancora telefonando allo 0049/5105585050, o inviando un fax allo 0049 5101 585060.
(Le immagini non sono più disponibili... mi dispiace)
Fig. 1: Con il modem PICPAR, compatibile con il programma BayCom, è possibile operare in Packet Radio a 9600 baud: una velocità molto elevata per le strette bande amatoriali...
Il programma BayCom ha dato origine ad una serie di utilità con esso "compatibili", che ci danno la libertà di impiegare indifferentemente un modem o un TNC con gli stessi programmi.
Il Baycom ha avuto il merito di portare al successo il modem omonimo; trattandosi di un'alternativa economica ma efficiente ad un ben più costoso e più raffinato apparato di controllo del nodo, il TNC, è facile capire perché molti abbiano provato ad usare lo stesso hardware con altri programmi di terminale.
Dapprima sono nati programmi con la stessa struttura del BayCom (un gestore del dispositivo seriale ed un programma di terminale); più avanti è nata l'idea di emulare direttamente l'intero TNC da software. Questo stratagemma consente di utilizzare il modem BayCom con qualsiasi programma di terminale desiderato, poiché esso non noterà alcuna differenza con un TNC vero.
VERSO LA VIRTUALIZZAZIONE
Ecco quindi che diventa possibile comporre la propria stazione Packet combinando in vario modo l'hardware ed il software; tutto grazie alla scelta tra vari "mattoni" che, composti uno sopra l'altro, ottengono il risultato della massima flessibilità ed indipendenza dall'hardware. Possiamo così risparmiare usando il BayCom, per poi spendere un po' di più con un TNC che garantisce la nostra presenza "in aria" anche a TNC spento.
Ci possono essere diversi motivi per utilizzare un altro terminale che non sia il BayCom: perché intendete utilizzare la raccolta automatica delle intestazioni dei messaggi ("broadcast") offerta dalla BBS Packet a cui vi collegate; o perché trovate troppo macchinoso il modo in cui BayCom gestisce il trasferimento dei file in protocollo YAPP (normalmente usati in Italia); o, semplicemente, siete già affezionati ad un certo programma di terminale Packet, tanto da non volerlo cambiare con quello BayCom.
Se siete in una di queste situazioni, potete utilizzare uno dei diversi gestori del modem BayCom. Essi sono in grado di interporsi tra il programma di terminale e l'hardware, virtualizzandolo, ossia svincolandolo dalla sua effettiva natura. In questo modo, il programma di terminale potrà comandare indifferentemente un TNC, un modem BayCom, o una scheda multiseriale come quelle presentate nella scorsa puntata.
L'unica difficoltà sta nel fatto che il gestore non è ovviamente in grado di emulare direttamente l'hardware della seriale; molti terminali viceversa pretendono di gestire direttamente l'hardware per la necessità di aggirare le pesantissime limitazioni del sistema operativo (si tratta di un retaggio del primo PC IBM mai completamente superato...).
È quindi giocoforza l'utilizzo di terminali che nascano predisposti all'utilizzo di un gestore esterno. Per nostra fortuna, la maggior parte è ormai così, grazie proprio alla diffusione prorompente del BayCom: è sufficiente configurarli per scambiare dati usando, anziché l'hardware, un'interruzione (interrupt) software.
I GESTORI BAYCOM, OVVERO I "TNC VIRTUALI"
Quali gestori è possibile allora utilizzare? La prima scelta cadrebbe sull'L2 del BayCom stesso; esso però non ha avuto alcun successo come gestore di dispositivo, per mancanza di documentazione o per le restrizioni di distribuzione a cui è sottoposto.
In genere, come potete vedere in tabella, è molto diffuso il TFPCX (l'acronimo sta per l'altrettanto criptico "The Firmware PC Extended"); esso, molto simile all'L2, è in pratica un'estensione del BIOS del PC che fa da gestore per l'interfaccia "modem BayCom".
Lanciando il TFPCX con gli oppurtuni parametri (porta COM da utilizzare, velocità, ecc.), esso si installa in memoria agganciandosi ad un vettore d'interruzione software. Ora tramite esso tutti i programmi DOS possono inviare e ricevere dati in formato Packet sull'interfaccia BayCom. Il TFPCX si occupa di aprire, mantenere e chiudere i canali virtuali, e di gestire ricezione e trasmissione, nonché la correzione automatica.
Altro programma che svolge la funzione di gestore è il BPQAX25. Esso funziona allo stesso modo del TFPCX, con la differenza di essere compatibile con BPQ, un gestore che supporta anche le funzionalità di nodo multiporta (è usato su molti BBS per gestire le varie porte - o frequenze - su cui gli utenti possono collegarsi, e per rilanciare i pacchetti da una porta all'altra).
Infine l'AX25DRV è un "Packet Driver" ovvero un gestore che fa vedere la seriale a tutti gli effetti come una scheda di rete. Su esso potete installare - ad esempio - il TCP/IP od un qualsiasi protocollo di rete che supporti il "packet driver", e realizzare una rete ethernet via radio!
Per quest'ultima utilizzazione è molto diffuso un "terminale" (in realtà è più un sistema operativo) che gestisce il protocollo TCP/IP sotto DOS: il celebre NOS di KA9Q. In alternativa potete installare il sistema operativo Linux, un vero e proprio Unix con supporto nativo della rete via radio, per il quale esistono i relativi gestori per modem BayCom.
I PROGRAMMI DI TERMINALE
Che programmi di terminale si possono usare con questi gestori? Ad esempio il celebre TPK, di cui abbiamo parlato qualche mese fa; esso però ha bisogno di un piccolo programma residente "adattatore" (una specie di "zeppa") che si chiama "TNCDED" per interfacciarsi con TFPCX. I due programmi TFPCX e TNCDED sono forniti in un unico archivio TPK-BCOM.ZIP incluso nelle nuove versioni di TPK, che quindi ormai supporta ufficialmente il modem BayCom. Lo stesso TPK tuttavia può usare altri programmi, per "girare" su un nodo BPQ (fare sempre riferimento alla tabella) che utilizza modem BayCom.
Altri programmi, come gli ottimi TSTHost e Graphic Packet, pilotano senza alcuna difficoltà direttamente il TFPCX.
Insomma come potete vedere, oggi è possibile utilizzare il modem BayCom con i più noti programmi di terminale, esattamente come se si trattasse di un TNC, ed addirittura è possibile farlo in protocollo TCP/IP.
Nuove frontiere che affronteremo nei prossimi appuntamenti.
73 de Mario
(4. fine)
Le diverse architetture per usare il modem BayCom con i più noti programmi di terminale per il Packet Radio
| Programma di terminale usato ->
Driver |
BayCom | TPK | Eskay Packet (prg. commerciale) |
Graphic Packet / TSTHost | KA9Q NOS | |
| Eventuale programma adattatore ("zeppa") | L2 | BPQHTNC2 | TNCDED | TFPCX | TFPCX | AX25DRV |
| Gestore di nodo (per sistemi a più canali -multiseriale) | BPQCODE | |||||
| Gestore di seriale | BPQAX25 | TFPCX | ||||
| HARDWARE (Seriale standard collegata a modem BayCom) | ||||||
AVVISO: Per completezza abbiamo incluso i programmi "Eskay Packet" (un software commerciale) Graphic Packet e TSTHost, ancora non presentati in questa rubrica; esse saranno oggetto di prossime puntate.
È una domanda non troppo provocatoria, questa, visto i recenti episodi di mancanza di raccordo tra essi ed il Ministero delle Poste. Dapprima la presentazione del nuovo regolamento che conteneva delle palesi incongruenze e inutili limitazioni; per fortuna sembra che il deciso intervento delle associazioni di categoria presso il Ministero abbia orientato quest’ultimo su misure più sensate. Adesso, però, una nuova ed incomprensibile novità: sempre il Ministero ha deciso di autorizzare la banda da 433.050 a 434.790 per nuovi apparati di radiocomunicazione denominati "LPD", dalla potenza massima di 10 milliwatt. Per utilizzare uno di questi apparati è sufficiente una domanda in carta da bollo ed un versamento di 15.000 lire l’anno.
La banda radioamatoriale da 430 a 440 MHz è stata assegnata dalla Conferenza Mondiale delle Telecomunicazioni (WRC) del 1979 al servizio di radioamatore, decisione recepita in Italia con un DPR del 1981; nel 1983 il Ministero PPTT restringeva tale banda a 432-438, con uno strascico di dubbi sul fatto che potesse farlo senza l’autorizzazione del Governo. Nel 1986 il Ministero ha dichiarato la banda 433-434 MHz in uso ai radioamatori come servizio secondario, in promiscuità con altri servizi pubblici (es. pubblica sicurezza); poi nel 1992 ha cominciato ad assegnare autorizzazioni ai telecomandi industriali nella porzione 433.050-434.790. Infine la nuova destinazione, che rischia di permettere agli LPD, in mano a persone senza conoscenze tecniche, di andare a disturbare Polizia, Vigili del Fuoco, e ingressi di ponti ripetitori radioamatoriali (tra 433.600 e 433.800), che ritrasmetterebbero il loro "debole segnale" in tutta Italia…