ARI Fidenza

IW1AYD ha scritto:

Ciao a tutti.
Confermo Stefano, ricordi bene. Il digipeater - digital repeater - aveva una serie di funzioni specifiche da ripetitore che, nell uso via un normale TNC - come il PK-232, mancano. Ma il concetto era quello.
I diversi pacchetti di codice disponibili per il digipeating avevano le loro funzioni peculiari. Bene o male nello stile, registro chi sento e imparo le strade, i circuiti, necessari per raggiungerlo. Questo alemno nelle ultime versioni più avanzate. Per contro offrivano ai gestori la possibilità di predefinire il routing, instradamento, dei pacchetti da e per certi call o altro e di bloccare, per altri o gli stessi call, l'apprendimento automatico. In altre parole permettevano attraverso altri digipeater di mappare uan serie di destinazioni e di circuiti logici necessari per raggiungerli. I digipeater, almeno nelle ultime versioni TAPR e altre più avanzate, ricordo anche FLEXNETe NETROM se non sbaglio, permettevano il connect IW1AYD da un punto dove IW1AYD non si vedeva nemmeno lontanamente. Applicando il connect iw1ayd via digipeateruno, digipeaterdue, ecc. in automatico dopo aver ricevuto una connessione, connect digipeaterzero, e una una seconda connessione semplificata, connect iw1ayd.
Nello stesso modo permettevano di scrivere a manina il path, l'instradamento.
Spero di non aver mischiato le diverse possibilità un uso per i diversi tipi di codice, ma nella media erano queste le funzioni - entro i limiti di capacità d'apprendimento: non erano tanto le stazioni finali d'utente oggetto d'apprendimento, ma altri digipeater con codice simile.

La prima forma di digipeating era però eseguibile da qualsiasi TNC, quindi il connect IK1CHE via IR1IV era ammesso da qualsiasi TNC: PK232 compreso che qui farebbe IR1IV. Mi pare che non fosse ammesso il send di pacchetti UI a mo di broadcast. Ma veramente non ricordo con precisione. Nel senso che veniva disabilità in quanto il broadcast di pacchetti UI, in un ipotesi d'uso principale della rete tra end to end connessi, rappresenta uno spreco immane d'efficenza.

APRS sfrutta i broadcast UI perchè è una rete da uno a tutti per quasi al 100%, Packet radio non lo era al 100%.
In APRS le informazioni vengono collezzionate e tabellate nel tempo, se si perde un informazione - che nemmeno si sapeva ci fosse, basta aspettare e, se c'è, prima o poi arriva. In Packet Radio lo scopo era inviare le informazioni in modo sicuro e non ripudiabile, se non ci riusciva e le richeste successive di riallineamento dello stream da entrambi i lati fallivano cadeva la connessione e basta - il resto anche se arrivava dopo era perso.

Una forma simile, ma solo in UI, Unnumbered Information, pacchetti trasmessi senza un circuito di connessione tra due entità TNC in comunicazione è funzionale a APRS. Forse UQG, ti volevi riferire a questo?
Si tratta sempre di digipeating, ma con funzioni completamente diverse da quelle di un digipeter NON per APRS. Mentre un digipeater per APRS, normalmente non conosce null'altro.

Spero di non aver mischiato troppo e di esser rimasto in tema.
In parole semplici un Digipeater APRS e un Digipeater Packet Radio sono due cose simili, ma diverse: quale dei due vuoi mettere insieme?
(Come dice IW1EYZ ...)

73 de iw1ayd Salvo

Tutti i Forum Discussioni APRS - DSTAR - DMR - MODI DIGITALI digipeter con pk232 Qui c'è:
Tutti gli utenti possono inserire NUOVE discussioni in questo forum Tutti gli utenti possono rispondere in questo forum