Tweet
3 - L'hardware
Parliamo adesso di quello che sicuramente interessa un po tutti: cosa usare per remotizzare.
Ho letto le cose più assurde nel tempo. Da guide pubblicate su nostre riviste le quali consigliavano il desktop remoto "senza password così non c'è pericolo che ve la scordiate"
a combinazioni di più software che mentre arrivava l'audio della stazione remota a casa vostra vi era passato sopra il mondo intero nel pile up.
Ci sono due scuole di pensiero: con PC o con dispositivi custom. Analizziamo le strutture e poi ognuno deciderà come meglio crede.
Alla fine tutte le remotizzazioni si riducono a: 1)flusso audio 2)flusso CAT 3)flusso seriale per dispositivi vari ed eventuali (rotori, sensori, PA, antenne) 4) flusso video per telecamere di monitoring delle apparecchiature.
Remotizzare con i PC è la soluzione più economica che esista. Si mette in piedi hamradiodeluxe o altro (io andavo con mixw dal divano alla radio), si installa skype (ma ci sono tanti altri software voip peer-to-peer che sono adatti allo scopo), per i più pigri HRD in desktop remoto, e si è operativi con qualsiasi radio che supporti il CAT in un baleno. Programmi di terze parti controlleranno il rotore, il PA è gestibile in band switch tramite un duplicatore di CAT.. fatto!
Diciamo di si.
Windows ha in media 57 processi in esecuzione. Ognuno è una potenziale mina vagante per quanto riguarda blocchi e malfunzionamenti del sistema operativo. In più, abbiamo un hard disk che come tutte le cose meccaniche, non è eterno. Potremmo inoltre avere una mancanza di energia elettrica che nonostante l'UPS, potrebbe spegnerci il PC magari quando è in fase di R/W sull'hard disk, con conseguente impossibilità di avvio alla prossima accensione. O una banalissima batteria CR2032 che si scarica, complice il troppo freddo, e ci presenta la schermata nota al bios "date and time are not set. Press F1 to enter setup F2 to continue". E come lo premiamo F1 o F2 se il computer è scollegato dal mondo in quanto il BIOS è interagibile solo localmente ?
In più, va messa in conto una cosa molto, molto importante. La latenza dei driver audio di windows: "Latency can be a particular problem in audio platforms, for instance the standard Microsoft Windows audio drivers which can cause latency up to 500 ms" (wikipedia)
Un'elaborazione ADC/DAC di windows tipicamente aggiunge un centinaio di millisecondi di latenza (sono molto ottimista, 50 millisecondi per PC, locale e remoto). La tratta internet ne aggiunge una sessantina. L'elaborazione dei flussi da parte dei programmi, un'altra ventina. Totale 180-200 millisecondi.
La durata di un punto a 20 wpm è di 50 millisecondi.
Penso che ci siamo capiti
Volendo si può ovviare. Si potrebbero usare due linux, con kernel modificati (RT-kernel per prioritizzazione delle applicazioni real time) ove hamradiodeluxe girerebbe in emulazione sotto wine, oppure dei programmi nativi sotto linux (http://radio.linux.org.au/?sectpat=rigcontrol tanto per dire...)
rimangono comunque i problemi hardware legati all'utilizzo in se dei PC.
Qualcuno potrebbe dire, beh ho speso fior di soldini per un icom 7700, lo controllo con l'RS-BA1 e il PC in stazione remota non c'è più!
Ok, giusto, ma la latenza lato locale rimane sempre. E poi come controlliamo il rotore ???
Facciamoci un paio di conti a livello di larghezza di banda.
Per larghezza di banda io intendo sempre l'aggregata, ossia flusso upload+flusso download + overhead di protocollo, ossia le cavolate che il protocollo IP aggiunge ad ogni pacchetto perchè le deve aggiungere, e che comunque vengono trasportate.
Per farvi capire quanto sia importante e pesante l'overhead, il codec audio G.723.1 occupa nudo e crudo 13 Kbps aggregati, che diventano 44 Kbps lordi con l'overhead di protocollo. Ci passano altri 3 flussi! Banda sprecata...
Comunque, dicevamo:
- Desktop remoto di windows: 400 kb/s aggregati per essere "usabile"
- Codec audio, a meno di non usare skype dovete usare il G711, 180 kb/s
- Flusso CAT: 10 kb/s ottimistici
- Flusso MJPEG telecamera: 600 kb/s con qualità discreta.
- Totale: sfioriamo i 1200 kb/s
Ultima chicca: se il link remoto-locale va giù mentre siamo in trasmissione rtty, e non risale per tot tempo, key down con l'ampli, che succede ??
Ricapitolando:
- Non abbiamo la radio di fronte
- Siamo costretti a fare CW tramite un programma lato remoto che "traduca" quello che scriviamo da tastiera (cwtype, mixw, quellochecavolovipare)
- La latenza è stratosferica.
- Assenza di protezioni per caduta link
Costo totale: voglio essere buono, trovate 2 PC usati a 200 euro l'uno, completi, sono 400 euro di spesa. Diciamo che ve ne serve uno, perchè userete quello di casa. Sono 200 euro di spesa.
La seconda scuola di remotizzazione è quella tramite remoterig. Usato inizialmente da Radio Arcala, hanno pro e contro.
Cominciamo dai contro:
- costo abbastanza elevato
- necessitano di skill medi per installazione e configurazione
Pro:
- latenza audio inferiore al millisecondo: dobbiamo mettere in conto solamente la latenza della tratta internet o link diretto. Attualmente la latenza tra me e la stazione di test a IQ0WL con link wifi diretto misurata con un oscilloscopio a doppia traccia, tra il punto del keyer e l'effettiva riproduzione sull' "audio monitor" della radio (quello che udite quando fate CW), è di 2,8 millisecondi.
- tasto telegrafico reale in remoto
- con molti modelli di radio, avete la possibilità di avere la radio "di fronte"
- assenza di blocchi accidentali o di mancato avvio dovuti a failures del software
- protezioni e spegnimento radio in caso di perdita del link per più di 2 secondi.
- scelta di una vasta varietà di codec audio, indipendenti sia in RX che in TX.
- monitor CW in locale, per evitare il fastidio del ritardo sulla manipolazione
- due porte seriali remotizzabili in IP, per avere ad esempio il controller di antennadinamica o il rotore Prosistel di gianni controllabili direttamente in stazione
Banda occupata in questo caso:
- 160 kb/s aggregati per TUTTO
- 600 kb/s della solita telecamera optional che guarda lo shack.
Nel primo caso avevamo saturato l'upload tipico di una ADSL, nel secondo no.
Ciò vuol dire eliminare "scatti" nell'audio, tipici di un collegamento remoto in saturazione.
Se poi si usa un link diretto, beh, si spera che 2 mega passino
I possessori di yaesu inoltre possono usufruire della modalità "cross-CAT", ossia comandare un FT 2000/5000/9000 con un FT 857, o viceversa, come se si avesse un "frontalino" separabile.
Ora, guinness time. Il prossimo post tratterà dell'ottimizzazione del link, traffic shaping, e messa in sicurezza generica della remotizzazione.
73 via tcp/ip
Parliamo adesso di quello che sicuramente interessa un po tutti: cosa usare per remotizzare.
Ho letto le cose più assurde nel tempo. Da guide pubblicate su nostre riviste le quali consigliavano il desktop remoto "senza password così non c'è pericolo che ve la scordiate"
a combinazioni di più software che mentre arrivava l'audio della stazione remota a casa vostra vi era passato sopra il mondo intero nel pile up.Ci sono due scuole di pensiero: con PC o con dispositivi custom. Analizziamo le strutture e poi ognuno deciderà come meglio crede.
Alla fine tutte le remotizzazioni si riducono a: 1)flusso audio 2)flusso CAT 3)flusso seriale per dispositivi vari ed eventuali (rotori, sensori, PA, antenne) 4) flusso video per telecamere di monitoring delle apparecchiature.
Remotizzare con i PC è la soluzione più economica che esista. Si mette in piedi hamradiodeluxe o altro (io andavo con mixw dal divano alla radio), si installa skype (ma ci sono tanti altri software voip peer-to-peer che sono adatti allo scopo), per i più pigri HRD in desktop remoto, e si è operativi con qualsiasi radio che supporti il CAT in un baleno. Programmi di terze parti controlleranno il rotore, il PA è gestibile in band switch tramite un duplicatore di CAT.. fatto!
Diciamo di si.
Windows ha in media 57 processi in esecuzione. Ognuno è una potenziale mina vagante per quanto riguarda blocchi e malfunzionamenti del sistema operativo. In più, abbiamo un hard disk che come tutte le cose meccaniche, non è eterno. Potremmo inoltre avere una mancanza di energia elettrica che nonostante l'UPS, potrebbe spegnerci il PC magari quando è in fase di R/W sull'hard disk, con conseguente impossibilità di avvio alla prossima accensione. O una banalissima batteria CR2032 che si scarica, complice il troppo freddo, e ci presenta la schermata nota al bios "date and time are not set. Press F1 to enter setup F2 to continue". E come lo premiamo F1 o F2 se il computer è scollegato dal mondo in quanto il BIOS è interagibile solo localmente ?
In più, va messa in conto una cosa molto, molto importante. La latenza dei driver audio di windows: "Latency can be a particular problem in audio platforms, for instance the standard Microsoft Windows audio drivers which can cause latency up to 500 ms" (wikipedia)
Un'elaborazione ADC/DAC di windows tipicamente aggiunge un centinaio di millisecondi di latenza (sono molto ottimista, 50 millisecondi per PC, locale e remoto). La tratta internet ne aggiunge una sessantina. L'elaborazione dei flussi da parte dei programmi, un'altra ventina. Totale 180-200 millisecondi.
La durata di un punto a 20 wpm è di 50 millisecondi.
Penso che ci siamo capiti
Volendo si può ovviare. Si potrebbero usare due linux, con kernel modificati (RT-kernel per prioritizzazione delle applicazioni real time) ove hamradiodeluxe girerebbe in emulazione sotto wine, oppure dei programmi nativi sotto linux (http://radio.linux.org.au/?sectpat=rigcontrol tanto per dire...)
rimangono comunque i problemi hardware legati all'utilizzo in se dei PC.
Qualcuno potrebbe dire, beh ho speso fior di soldini per un icom 7700, lo controllo con l'RS-BA1 e il PC in stazione remota non c'è più!
Ok, giusto, ma la latenza lato locale rimane sempre. E poi come controlliamo il rotore ???
Facciamoci un paio di conti a livello di larghezza di banda.
Per larghezza di banda io intendo sempre l'aggregata, ossia flusso upload+flusso download + overhead di protocollo, ossia le cavolate
che il protocollo IP aggiunge ad ogni pacchetto perchè le deve aggiungere, e che comunque vengono trasportate.Per farvi capire quanto sia importante e pesante l'overhead, il codec audio G.723.1 occupa nudo e crudo 13 Kbps aggregati, che diventano 44 Kbps lordi con l'overhead di protocollo. Ci passano altri 3 flussi! Banda sprecata...
Comunque, dicevamo:
- Desktop remoto di windows: 400 kb/s aggregati per essere "usabile"
- Codec audio, a meno di non usare skype dovete usare il G711, 180 kb/s
- Flusso CAT: 10 kb/s ottimistici
- Flusso MJPEG telecamera: 600 kb/s con qualità discreta.
- Totale: sfioriamo i 1200 kb/s
Ultima chicca: se il link remoto-locale va giù mentre siamo in trasmissione rtty, e non risale per tot tempo, key down con l'ampli, che succede ??
Ricapitolando:
- Non abbiamo la radio di fronte
- Siamo costretti a fare CW tramite un programma lato remoto che "traduca" quello che scriviamo da tastiera (cwtype, mixw, quellochecavolovipare)
- La latenza è stratosferica.
- Assenza di protezioni per caduta link
Costo totale: voglio essere buono, trovate 2 PC usati a 200 euro l'uno, completi, sono 400 euro di spesa. Diciamo che ve ne serve uno, perchè userete quello di casa. Sono 200 euro di spesa.
La seconda scuola di remotizzazione è quella tramite remoterig. Usato inizialmente da Radio Arcala, hanno pro e contro.
Cominciamo dai contro:
- costo abbastanza elevato
- necessitano di skill medi per installazione e configurazione
Pro:
- latenza audio inferiore al millisecondo: dobbiamo mettere in conto solamente la latenza della tratta internet o link diretto. Attualmente la latenza tra me e la stazione di test a IQ0WL con link wifi diretto misurata con un oscilloscopio a doppia traccia, tra il punto del keyer e l'effettiva riproduzione sull' "audio monitor" della radio (quello che udite quando fate CW), è di 2,8 millisecondi.
- tasto telegrafico reale in remoto
- con molti modelli di radio, avete la possibilità di avere la radio "di fronte"
- assenza di blocchi accidentali o di mancato avvio dovuti a failures del software
- protezioni e spegnimento radio in caso di perdita del link per più di 2 secondi.
- scelta di una vasta varietà di codec audio, indipendenti sia in RX che in TX.
- monitor CW in locale, per evitare il fastidio del ritardo sulla manipolazione
- due porte seriali remotizzabili in IP, per avere ad esempio il controller di antennadinamica o il rotore Prosistel di gianni controllabili direttamente in stazione
Banda occupata in questo caso:
- 160 kb/s aggregati per TUTTO
- 600 kb/s della solita telecamera optional che guarda lo shack.
Nel primo caso avevamo saturato l'upload tipico di una ADSL, nel secondo no.
Ciò vuol dire eliminare "scatti" nell'audio, tipici di un collegamento remoto in saturazione.
Se poi si usa un link diretto, beh, si spera che 2 mega passino
I possessori di yaesu inoltre possono usufruire della modalità "cross-CAT", ossia comandare un FT 2000/5000/9000 con un FT 857, o viceversa, come se si avesse un "frontalino" separabile.
Ora, guinness time. Il prossimo post tratterà dell'ottimizzazione del link, traffic shaping, e messa in sicurezza generica della remotizzazione.
73 via tcp/ip
Commenta