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.