- Benvenuto su Rogerk.
forum per Radioamatori, cb e amanti della radio.
News:
Telegram uffciale di rogerk @rogerk
Messaggi recenti
#1
antenne per CB / Re: Sirio Vector 4000
Ultimo messaggio di Pan56 - 26 Aprile 2025, 02:33:09Uajù vi prego non vi appiccicate, siete due risorse, due colossi, due colonne portanti del forum, non è cosa piacevole vedervi dialogare in questo modo. E poi, senza alcuna offesa perché io da voi due non posso fare altro che imparare (solo imparare) ma tu Andrè, forte del fatto che vorresti dare risposte il più accurate possibili effettivamente tutti quei link che mandi potrebbero indurre in confusione, tu non lo fai con cattiveria ma con grande spirito di altruismo per, ribadisco, fornire all'utente scrivente, una risposta bella carica di contenuti ma purtroppo non tutti noi godiamo del piacere e dell'opportunità di comprendere le tue gesta. Chiaritevi per carità ma lasciate sempre che la "critica" sia un punto di partenza per migliorare e diventare persone migliori.
Sotto questo macabro cielo, noi, amanti di questa nobile Arte dobbiamo cercare di distinguerci, per lo meno in termini di signorilità. Vi prego non vi litigate, fatelo per una persona che se al giorno d'oggi riesce ad accroccare quattro fili e metterli nelle condizioni di farli funzionare come "antenna" il merito è solo il vostro e di questo foro. Non dimenticate l'eredita morale che nel corso di lunghi anni avete seminato.
'73 di cuore a entrambi.
Sotto questo macabro cielo, noi, amanti di questa nobile Arte dobbiamo cercare di distinguerci, per lo meno in termini di signorilità. Vi prego non vi litigate, fatelo per una persona che se al giorno d'oggi riesce ad accroccare quattro fili e metterli nelle condizioni di farli funzionare come "antenna" il merito è solo il vostro e di questo foro. Non dimenticate l'eredita morale che nel corso di lunghi anni avete seminato.
'73 di cuore a entrambi.
#2
antenne per CB / Re: Sirio Vector 4000
Ultimo messaggio di r5000 - 25 Aprile 2025, 23:59:25Citazione di: AZ6108 il 25 Aprile 2025, 23:28:00ma si, tira pure in ballo gli 80m, la discussione alla quale fai riferimento verteva sugli 11 metri e gli alti angoli di radiazione...73 a tutti, vai a rileggere con calma e attenzione tutto quanto avevo scritto e vedrai che i collegamenti dalla macchina a 28 mhz tra i palazzi e nel fondo valle ( che vuol dire il punto più basso di una valle chiusa da montagne alte, tipicamente dove il fiume, strade e paesi) della val seriana e val brembana e valli minori che frequento hanno dislivelli variabili tra i 300 e i 1500 mt con più montagne che ostacolano la portata ottica che è possibile solo in cima e se vuoi simulare con qualche software metti pure San Pellegrino, Gazzaniga , Ponte nossa come posizione di partenza e Bergamo , Crema e Cassano d'adda che sono tra i collegamenti che ricordo al volo, ma ho fatto anche Fiorenzuola, Modena, Savona ecc... se provi vedrai che non c'è portata ottica e nemmeno rifrazione perchè ci sono più montagne in fila...
per il resto continua pure a blaterare e comunque quel riferimento al "ban" era e resta una minaccia altro che storie
p.s. "fondo valle" è un'indicazione troppo generica
#3
antenne radioamatoriali / Re: Un'antenna al volo per i 4...
Ultimo messaggio di r5000 - 25 Aprile 2025, 23:30:3073 a tutti, per queste frequenze si possono fare antenne di tutti i tipi, le dimensioni permettono anche antenne direttive con buon guadagno, poi se giustamente si vuole cominciare con qualcosa di semplice e omnidirezionale una gp è una buona base di partenza, ad esempio una gp per i 6 mt è già utilizzabile in ricezione sia per i 4 mt che gli 8 mt, quando ci butto un'occhio con la discone (ho anche quella, giusto per non tenerla nel sotto tetto...) e poi provo con la gp dei 6 mt i segnali ricevuti sono simili, aumentano solo se ci collego la direttiva risonante ma di solito con le aperture sporadiche i segnali sono robusti e si ricevono anche con la gp dei 2 mt, però se si vuole costruire un'antenna bibanda per trasmettere con ros contenuto e semplicità costruttiva mi viene in mente il dipolo multibanda e se messo in verticale assomiglia a quanto simulato da 1vr005, se si usano tubi o canne da pesca i due stili superiori e inferiori saranno simmetrici e prenderanno la forma di una X con il cavo di discesa orizzontale al terreno per almeno un paio di metri, ad esempio un palo a sbalzo sul balcone e il choke nel punto di alimentazione del dipolo, avere antenne con polarizzazione diversa aiuta sempre, mi è capitato di ascoltare in simultanea segnali differenti a seconda della polarizzazione, per la precisione in orizzontale avevo la svezia e in verticale la francia...
#4
antenne per CB / Re: Sirio Vector 4000
Ultimo messaggio di AZ6108 - 25 Aprile 2025, 23:28:00ma si, tira pure in ballo gli 80m, la discussione alla quale fai riferimento verteva sugli 11 metri e gli alti angoli di radiazione...
per il resto continua pure a blaterare e comunque quel riferimento al "ban" era e resta una minaccia altro che storie
p.s. "fondo valle" è un'indicazione troppo generica
per il resto continua pure a blaterare e comunque quel riferimento al "ban" era e resta una minaccia altro che storie
p.s. "fondo valle" è un'indicazione troppo generica
#5
antenne per CB / Re: Sirio Vector 4000
Ultimo messaggio di r5000 - 25 Aprile 2025, 23:01:23Citazione di: AZ6108 il 25 Aprile 2025, 22:15:35interessante e paradossale73 a tutti, io affermo che ho fatto e faccio i collegamenti nel fondo valle o in mezzo ai palazzi, in 80 mt si fanno in nvis, in 10 mt si fanno per altri modi ma tu non lo sai spiegare e pensi solo all'nvis quando c'è un sacco di collegamenti fatti e che si faranno ancora, se poi sei convinto che nel fondo valle i collegamenti si fanno con le antenne a basso angolo di radiazione passando attraverso le montagne o per magia pazienza, c'è chi è convinto che la terra è piatta... però se finalmente lo spieghi in modo comprensibile e non con link a raffica che non c'entrano nulla con i collegamenti dal fondo valle in banda 10 mt posso cambiare la mia opignone nei tuo confronti, se non lo spieghi non sei credibile come esperto di antenne, non è una minaccia ma una constatazione...
TU affermi di fare regolari collegamenti NVIS in 27MHz e poi pretendi che IO che non ci credo debba spiegare il perché e per di più mi minacci
credo che la cosa si commenti da sola
#6
discussione libera / Re: SSM2167 speech processor
Ultimo messaggio di r5000 - 25 Aprile 2025, 22:39:0873 a tutti, la circuitazione antirimbalzo da usare con i flip flop "dovrebbe" escludere false commutazioni ma se il progetto è semplificato o poco schermato ecc... capita che il microfono di marca fà scherzi e trasmette da solo o interrompe la trasmissione proprio mentre colleghi la spedizione, mi è capitato di riparare ( si fà per dire perchè non c'è nulla di rotto...) un microfono che andava in tx da solo quando il proprietario trasmetteva in vhf con un'altra radio e si interrompeva quando lo usava in hf, il mobile plastico e la vicinanza delle antenne (3 mt scarsi tra la scrivania e le antenne sul balcone) sono il problema perchè da me il microfono funzionava perfettamente, per scrupolo abbiamo misurato le cmc e l'intensità di campo vicino al microfono e il microfono e non c'erano cmc significative e anche l'intensità di campo con i 100 watt dell'apparato era ben poca cosa, morale della storia il microfono adonis è stato sostituito con un zetagi che ha la leva che blocca il pulsante...
#7
discussione libera / Re: 📡 LoRa e Meshtastic, Mesh...
Ultimo messaggio di Marcello - 25 Aprile 2025, 22:32:45Sto provando entrambi questi firmware/protocolli LORA, posto qui il risultato delle mie ricerche specificando come funzionano le due diverse architetture della rete che creano.
MeshCore e Meshtastic sono entrambi firmware/protocolli per reti mesh su radio LoRa, ma adottano architetture differenti riguardo al ruolo di client e server nella formazione e nel mantenimento della rete. In MeshCore, a differenza di Meshtastic, i dispositivi client (nodi utente) non inoltrano i messaggi degli altri nodi nella mesh; solo dispositivi dedicati (i server della rete, come i repeater e i room server) si occupano del relay multi-hop dei pacchetti. Di seguito spieghiamo in dettaglio questa differenza, il ruolo specifico dei client in MeshCore e il concetto di "room server" (talvolta chiamato impropriamente "server room").
MeshCore: solo repeater (server) instradano il traffico mesh
In MeshCore la rete mesh è gestita da nodi con funzioni specializzate. I dispositivi possono essere configurati con ruoli distinti – ad esempio repeater, client o room server – ciascuno con firmware dedicato. Questa separazione permette di ottimizzare ogni ruolo: ad esempio, il firmware repeater è ridotto all'essenziale e si limita a ritrasmettere pacchetti, garantendo stabilità e usando poche risorse hardware.
I nodi client invece non fungono mai da ripetitori nella mesh: un dispositivo configurato come client non inoltra i pacchetti provenienti da altri, in linea con la filosofia "messaging-first" di MeshCore che evita il flooding indiscriminato sulla rete.
In altre parole, solo i repeater (e i room server opportunamente configurati) instradano i messaggi multi-hop nella rete MeshCore.
Questo significa che se un utente porta con sé un nodo MeshCore in tasca come client, tale nodo non ripeterà i messaggi altrui – evitando di "sprecare" hop attraverso dispositivi mobili che potrebbero essere spenti o fuori copertura – e il compito di rilanciare i pacchetti è demandato unicamente ai nodi infrastrutturali fissi (i repeater). Questa scelta architetturale riduce le collisioni radio e aumenta l'affidabilità del recapito dei messaggi, privilegiando la semplicità e robustezza della messaggistica rispetto alla massima estensione della maglia.
In Meshtastic, l'approccio è più decentralizzato: tipicamente ogni nodo può partecipare al relay dei messaggi nella mesh. Di default, i dispositivi Meshtastic operano in modalità client e ripetono automaticamente i pacchetti necessari a instradare i messaggi su più hop.
In pratica, se due nodi Meshtastic non sono a portata diretta, altri nodi intermedi (anche se sono normali client) possono ritrasmettere i messaggi e fungere da "ponti" per estendere la copertura. È possibile configurare manualmente un nodo Meshtastic in modalità "CLIENT_MUTE" per disattivare la ritrasmissione (ad esempio su dispositivi personali in aree coperte da altri router), ma per impostazione predefinita i client Meshtastic "inoltrano e instradano pacchetti secondo necessità".
Questo design a maglia completamente distribuita massimizza la connettività peer-to-peer, ma può portare a maggiore traffico di rete e rischi di collisioni radio se troppi nodi rilanciano messaggi in una rete densa. (Le ultime versioni di Meshtastic hanno introdotto ruoli come ROUTER o REPEATER per nodi fissi, e meccanismi per limitare il flooding, ma resta il fatto che in Meshtastic qualunque nodo può svolgere funzioni di relay a meno che non sia esplicitamente impostato per non farlo.)
Dato quanto sopra, il ruolo dei client in MeshCore è puramente quello di endpoint utente.
Un dispositivo client MeshCore invia i propri messaggi e riceve quelli a lui destinati, ma non aiuta a inoltrare i messaggi altrui sulla rete. Quando un client MeshCore trasmette un messaggio, questo viene affidato alla rete di repeater: i ripetitori troveranno il percorso migliore per far arrivare il messaggio al destinatario finale, eventualmente attraversando più hop. Allo stesso modo, un client riceve messaggi attraverso uno o più repeater intermedi senza che il client stesso debba ripetere nulla.
In pratica i client MeshCore si connettono alla mesh come nodi foglia: possono essere dispositivi portatili (ad esempio una scheda LoRa con display, o un nodo collegato via Bluetooth/USB allo smartphone tramite l'app MeshCore), usati dall'utente per chattare, ma delegano tutta la logica di rete ai nodi infrastrutturali.
Questa strategia consente ai client di risparmiare energia (importante per dispositivi a batteria) e mantiene il protocollo semplificato dal lato utente. Se un client si sposta fuori portata, i repeater cercheranno automaticamente nuovi percorsi; MeshCore utilizza infatti un routing ibrido: inizialmente un messaggio può essere diffuso (flood) attraverso la rete per scoprirne il percorso, dopodiché il percorso ottimale (la sequenza di repeater) viene memorizzato e usato per inoltri diretti successivi.
In sintesi, in MeshCore i client usufruiscono della mesh ma non la estendono: la creazione e il mantenimento dei collegamenti multi-hop è responsabilità esclusiva dei repeater (o dei server dedicati), mentre i client si concentrano sulla comunicazione dell'utente finale.
MeshCore introduce anche una figura particolare di server chiamato room server (a volte tradotto alla buona come "server room", ma il termine corretto è room server, cioè "server di stanza/canale"). Un room server è un dispositivo che funge da bacheca messaggi condivisa per un gruppo definito (una "room", analoga a un canale o chat di gruppo). In pratica, il room server memorizza la cronologia dei messaggi inviati in quella stanza e la conserva per gli utenti che non erano online al momento.
Quando un client si collega a un room server, riceve infatti i messaggi arretrati (fino a un certo limite) che non aveva ancora visto.
Questo consente, ad esempio, di non perdere comunicazioni se il proprio dispositivo era fuori portata o spento: al ritorno in rete, il client "recupera" i messaggi persi dal room server. Si tratta di una soluzione tipo BBS (Bulletin Board System) semplificato, paragonabile a un piccolo server email: i messaggi vengono immagazzinati sul server e consegnati ai destinatari quando questi tornano disponibili.
Diversamente dalla normale modalità canale pubblico (dove se un nodo non è in ascolto al momento dell'invio di un messaggio quel messaggio viene perso), la stanza gestita da un room server garantisce store-and-forward dei messaggi per quel gruppo.
È importante notare che i room server sono pensati per gruppi ristretti o reti locali e non sostituiscono i canali pubblici mesh tradizionali: ogni MeshCore può operare anche con canali "live" pubblici o privati in cui i messaggi vengono trasmessi in tempo reale via flood, mentre le room server offrono un'opzione aggiuntiva per messaggi asincroni in comunità più piccole.
Dal punto di vista della rete, un room server può anche svolgere il ruolo di repeater se configurato: l'admin può abilitare l'opzione di instradamento.
Spesso però i room server vengono implementati su nodi fissi e alimentati (ad esempio un dispositivo Heltec o T-Echo dedicato) che contestualmente fungono da repeater per estendere la copertura locale.
In sintesi, MeshCore adotta un'architettura mesh ibrida: nodi dedicati (repeater e/o room server) creano e instradano la rete, mentre i client vi si agganciano solo per scambiare messaggi senza partecipare al relay.
Meshtastic invece permette a qualsiasi dispositivo di fungere da nodo mesh attivo, con tutti i vantaggi di una maglia completamente distribuita ma anche le complessità correlate.
Questa differenza progettuale fa sì che MeshCore sia ottimizzato per una messaggistica affidabile e a basso carico (evitando loop di ritrasmissioni inutili), mentre Meshtastic punta sulla massima connettività ad hoc. La scelta tra i due dipende dai casi d'uso: MeshCore privilegia reti con pochi nodi infrastrutturali ben posizionati e client leggeri, Meshtastic offre flessibilità ad hoc a costo di maggiore gestione del traffico. Entrambi i sistemi mirano a fornire comunicazioni off-grid su lunghe distanze, ma con filosofie di routing diverse.
Riferimenti: Le informazioni sono tratte dalla documentazione ufficiale e discussioni degli sviluppatori di entrambi i progetti. In particolare, la FAQ di MeshCore conferma esplicitamente che "i client MeshCore non ripetono" (ovvero non instradano pacchetti per altri nodi) e che solo i repeater (o un room server con repeat attivo) inoltrano i messaggi nella rete.
D'altro canto, la documentazione Meshtastic evidenzia che in configurazione predefinita i client inoltrano e instradano i pacchetti in maniera cooperativa, salvo mettere un nodo in modalità mute per escluderlo dal relay.
Inoltre, la natura e lo scopo dei room server di MeshCore sono spiegati nei documenti MeshCore (come un sistema di store-and-forward tipo BBS/email) e in interventi della community (sottolineando che tali server sono destinati a gruppi locali e non rimpiazzano i canali mesh tradizionali).
Infine, le stesse FAQ di MeshCore descrivono come un room server possa essere configurato anche come repeater per contribuire al mesh networking oltre che all'archiviazione dei messaggi.
Queste caratteristiche distinguono nettamente MeshCore da Meshtastic in termini di partecipazione dei client alla rete mesh e responsabilità dei nodi server nella comunicazione multi-hop.
Saluti
Marcello
MeshCore e Meshtastic sono entrambi firmware/protocolli per reti mesh su radio LoRa, ma adottano architetture differenti riguardo al ruolo di client e server nella formazione e nel mantenimento della rete. In MeshCore, a differenza di Meshtastic, i dispositivi client (nodi utente) non inoltrano i messaggi degli altri nodi nella mesh; solo dispositivi dedicati (i server della rete, come i repeater e i room server) si occupano del relay multi-hop dei pacchetti. Di seguito spieghiamo in dettaglio questa differenza, il ruolo specifico dei client in MeshCore e il concetto di "room server" (talvolta chiamato impropriamente "server room").
MeshCore: solo repeater (server) instradano il traffico mesh
In MeshCore la rete mesh è gestita da nodi con funzioni specializzate. I dispositivi possono essere configurati con ruoli distinti – ad esempio repeater, client o room server – ciascuno con firmware dedicato. Questa separazione permette di ottimizzare ogni ruolo: ad esempio, il firmware repeater è ridotto all'essenziale e si limita a ritrasmettere pacchetti, garantendo stabilità e usando poche risorse hardware.
I nodi client invece non fungono mai da ripetitori nella mesh: un dispositivo configurato come client non inoltra i pacchetti provenienti da altri, in linea con la filosofia "messaging-first" di MeshCore che evita il flooding indiscriminato sulla rete.
In altre parole, solo i repeater (e i room server opportunamente configurati) instradano i messaggi multi-hop nella rete MeshCore.
Questo significa che se un utente porta con sé un nodo MeshCore in tasca come client, tale nodo non ripeterà i messaggi altrui – evitando di "sprecare" hop attraverso dispositivi mobili che potrebbero essere spenti o fuori copertura – e il compito di rilanciare i pacchetti è demandato unicamente ai nodi infrastrutturali fissi (i repeater). Questa scelta architetturale riduce le collisioni radio e aumenta l'affidabilità del recapito dei messaggi, privilegiando la semplicità e robustezza della messaggistica rispetto alla massima estensione della maglia.
In Meshtastic, l'approccio è più decentralizzato: tipicamente ogni nodo può partecipare al relay dei messaggi nella mesh. Di default, i dispositivi Meshtastic operano in modalità client e ripetono automaticamente i pacchetti necessari a instradare i messaggi su più hop.
In pratica, se due nodi Meshtastic non sono a portata diretta, altri nodi intermedi (anche se sono normali client) possono ritrasmettere i messaggi e fungere da "ponti" per estendere la copertura. È possibile configurare manualmente un nodo Meshtastic in modalità "CLIENT_MUTE" per disattivare la ritrasmissione (ad esempio su dispositivi personali in aree coperte da altri router), ma per impostazione predefinita i client Meshtastic "inoltrano e instradano pacchetti secondo necessità".
Questo design a maglia completamente distribuita massimizza la connettività peer-to-peer, ma può portare a maggiore traffico di rete e rischi di collisioni radio se troppi nodi rilanciano messaggi in una rete densa. (Le ultime versioni di Meshtastic hanno introdotto ruoli come ROUTER o REPEATER per nodi fissi, e meccanismi per limitare il flooding, ma resta il fatto che in Meshtastic qualunque nodo può svolgere funzioni di relay a meno che non sia esplicitamente impostato per non farlo.)
Dato quanto sopra, il ruolo dei client in MeshCore è puramente quello di endpoint utente.
Un dispositivo client MeshCore invia i propri messaggi e riceve quelli a lui destinati, ma non aiuta a inoltrare i messaggi altrui sulla rete. Quando un client MeshCore trasmette un messaggio, questo viene affidato alla rete di repeater: i ripetitori troveranno il percorso migliore per far arrivare il messaggio al destinatario finale, eventualmente attraversando più hop. Allo stesso modo, un client riceve messaggi attraverso uno o più repeater intermedi senza che il client stesso debba ripetere nulla.
In pratica i client MeshCore si connettono alla mesh come nodi foglia: possono essere dispositivi portatili (ad esempio una scheda LoRa con display, o un nodo collegato via Bluetooth/USB allo smartphone tramite l'app MeshCore), usati dall'utente per chattare, ma delegano tutta la logica di rete ai nodi infrastrutturali.
Questa strategia consente ai client di risparmiare energia (importante per dispositivi a batteria) e mantiene il protocollo semplificato dal lato utente. Se un client si sposta fuori portata, i repeater cercheranno automaticamente nuovi percorsi; MeshCore utilizza infatti un routing ibrido: inizialmente un messaggio può essere diffuso (flood) attraverso la rete per scoprirne il percorso, dopodiché il percorso ottimale (la sequenza di repeater) viene memorizzato e usato per inoltri diretti successivi.
In sintesi, in MeshCore i client usufruiscono della mesh ma non la estendono: la creazione e il mantenimento dei collegamenti multi-hop è responsabilità esclusiva dei repeater (o dei server dedicati), mentre i client si concentrano sulla comunicazione dell'utente finale.
MeshCore introduce anche una figura particolare di server chiamato room server (a volte tradotto alla buona come "server room", ma il termine corretto è room server, cioè "server di stanza/canale"). Un room server è un dispositivo che funge da bacheca messaggi condivisa per un gruppo definito (una "room", analoga a un canale o chat di gruppo). In pratica, il room server memorizza la cronologia dei messaggi inviati in quella stanza e la conserva per gli utenti che non erano online al momento.
Quando un client si collega a un room server, riceve infatti i messaggi arretrati (fino a un certo limite) che non aveva ancora visto.
Questo consente, ad esempio, di non perdere comunicazioni se il proprio dispositivo era fuori portata o spento: al ritorno in rete, il client "recupera" i messaggi persi dal room server. Si tratta di una soluzione tipo BBS (Bulletin Board System) semplificato, paragonabile a un piccolo server email: i messaggi vengono immagazzinati sul server e consegnati ai destinatari quando questi tornano disponibili.
Diversamente dalla normale modalità canale pubblico (dove se un nodo non è in ascolto al momento dell'invio di un messaggio quel messaggio viene perso), la stanza gestita da un room server garantisce store-and-forward dei messaggi per quel gruppo.
È importante notare che i room server sono pensati per gruppi ristretti o reti locali e non sostituiscono i canali pubblici mesh tradizionali: ogni MeshCore può operare anche con canali "live" pubblici o privati in cui i messaggi vengono trasmessi in tempo reale via flood, mentre le room server offrono un'opzione aggiuntiva per messaggi asincroni in comunità più piccole.
Dal punto di vista della rete, un room server può anche svolgere il ruolo di repeater se configurato: l'admin può abilitare l'opzione di instradamento.
Spesso però i room server vengono implementati su nodi fissi e alimentati (ad esempio un dispositivo Heltec o T-Echo dedicato) che contestualmente fungono da repeater per estendere la copertura locale.
In sintesi, MeshCore adotta un'architettura mesh ibrida: nodi dedicati (repeater e/o room server) creano e instradano la rete, mentre i client vi si agganciano solo per scambiare messaggi senza partecipare al relay.
Meshtastic invece permette a qualsiasi dispositivo di fungere da nodo mesh attivo, con tutti i vantaggi di una maglia completamente distribuita ma anche le complessità correlate.
Questa differenza progettuale fa sì che MeshCore sia ottimizzato per una messaggistica affidabile e a basso carico (evitando loop di ritrasmissioni inutili), mentre Meshtastic punta sulla massima connettività ad hoc. La scelta tra i due dipende dai casi d'uso: MeshCore privilegia reti con pochi nodi infrastrutturali ben posizionati e client leggeri, Meshtastic offre flessibilità ad hoc a costo di maggiore gestione del traffico. Entrambi i sistemi mirano a fornire comunicazioni off-grid su lunghe distanze, ma con filosofie di routing diverse.
Riferimenti: Le informazioni sono tratte dalla documentazione ufficiale e discussioni degli sviluppatori di entrambi i progetti. In particolare, la FAQ di MeshCore conferma esplicitamente che "i client MeshCore non ripetono" (ovvero non instradano pacchetti per altri nodi) e che solo i repeater (o un room server con repeat attivo) inoltrano i messaggi nella rete.
D'altro canto, la documentazione Meshtastic evidenzia che in configurazione predefinita i client inoltrano e instradano i pacchetti in maniera cooperativa, salvo mettere un nodo in modalità mute per escluderlo dal relay.
Inoltre, la natura e lo scopo dei room server di MeshCore sono spiegati nei documenti MeshCore (come un sistema di store-and-forward tipo BBS/email) e in interventi della community (sottolineando che tali server sono destinati a gruppi locali e non rimpiazzano i canali mesh tradizionali).
Infine, le stesse FAQ di MeshCore descrivono come un room server possa essere configurato anche come repeater per contribuire al mesh networking oltre che all'archiviazione dei messaggi.
Queste caratteristiche distinguono nettamente MeshCore da Meshtastic in termini di partecipazione dei client alla rete mesh e responsabilità dei nodi server nella comunicazione multi-hop.
Saluti
Marcello
#8
antenne per CB / Re: Sirio Vector 4000
Ultimo messaggio di AZ6108 - 25 Aprile 2025, 22:15:35Citazione di: r5000 il 25 Aprile 2025, 22:11:4573 a tutti, non ti è bastato un mese di sospensione? non hai ancora spiegato come mai si fanno i collegamenti e insisti, o sei masochista o proprio non ci arrivi...
interessante e paradossale
TU affermi di fare regolari collegamenti NVIS in 27MHz e poi pretendi che IO che non ci credo debba spiegare il perché e per di più mi minacci
credo che la cosa si commenti da sola
#9
antenne per CB / Re: Sirio Vector 4000
Ultimo messaggio di r5000 - 25 Aprile 2025, 22:11:45Citazione di: AZ6108 il 25 Aprile 2025, 17:08:13a scanso di equivoci e prima che qualcuno si metta a blaterare di NVIS in 27MHz73 a tutti, non ti è bastato un mese di sospensione? non hai ancora spiegato come mai si fanno i collegamenti e insisti, o sei masochista o proprio non ci arrivi...
https://practicalantennas.com/applications/nvis/
dimostrando di non sapere ciò di cui parla
#10
Ricetrasmettitori banda Civile / Re: info, soft e quanto altro ...
Ultimo messaggio di Giuseppe60 - 25 Aprile 2025, 21:45:02Di seguito le corrispondente per la programmazione delle vhisper o parrot dal connettore posteriore:
1 prg/run
2 txd
5 gnd
7 rxd
Saluti Giuseppe
1 prg/run
2 txd
5 gnd
7 rxd
Saluti Giuseppe
