Reticulum gør det muligt at bygge datanetværk på tværs af forskellige forbindelsestyper. LoRa kan være én af dem, men Reticulum er hverken en bestemt radio eller ét verdensomspændende netværk, som automatisk er tilgængeligt, når et board tændes. Du vælger forbindelser og applikationer; stakken leverer mekanismer til adressering, krypteret kommunikation og transport.

Det er interessant til lokale forsøg, fælles infrastruktur og netværk, der blander langsomme radioforbindelser med hurtigere forbindelser. Men vælger du et “Reticulum-board” uden at beslutte, hvad der skal køre på værtsenheden, kan halvdelen af systemet mangle.

Adskil applikation, netværksstak og radio

I en almindelig LoRa-opsætning kører applikation og Reticulum på en telefon eller computer, mens en tilsluttet RNode leverer radiointerfacet. Integrerede produkter kan samle delene, men et understøttet radioboard er ikke nødvendigvis en komplet beskedenhed. Startvejledningen introducerer programmerne, og hardwarekapitlet beskriver forbindelserne.

Destinationer og ruter er anderledes end IP

Applikationer kommunikerer gennem destinationer frem for den velkendte kombination af IP-adresse og port. En destination hører til et applikationsendepunkt. Kryptografisk identitet indgår i identifikationen af almindelige single-destinationer. En identitet og et programs beskedadresse er beslægtede begreber, men udveksl den adresse, programmet faktisk beder om.

Announces gør destinationer og oplysninger om deres offentlige nøgler kendte. Transportnoder kan føre trafik over flere hop. Mekanismerne erstatter ikke de fysiske forbindelser: et utilgængeligt radiosegment er stadig utilgængeligt. Begynd med to endepunkter, før du bygger transportinfrastruktur. Arkitekturkapitlet forklarer destinations- og forbindelsestyperne.

RNode-understøttelse er konkret

RNode er et radiointerface med firmware til understøttet hardware. En LoRa-chip eller ESP32 i produktnavnet er ikke dokumentation for kompatibilitet. Kontrollér boardversion, radiochip, frekvensvariant og den præcise firmwaremålplatform. Muligheder for USB, Bluetooth og andre forbindelser afhænger også af implementering og værtsenhed.

Installerer du RNode-firmware oven på Meshtastic-firmware, ændrer enheden rolle. Det får ikke protokollerne til at forstå hinanden, og begge stakke kan ikke forventes at dele én almindelig firmwareinstallation. Gem relevante indstillinger, og følg den korrekte vejledning til installation og gendannelse. Brug RNode-firmwareprojektet som reference, ikke et foto af et board, der ligner.

Begynd uden radio, og tilføj den bagefter

En effektiv første test adskiller softwareproblemer fra radioproblemer. Installer et understøttet program på to egnede enheder, og brug et dokumenteret lokalnetværksinterface. Udveksl programmets adresser, send en besked begge veje, og find leveringsstatus. Så ved du, at programmer og identiteter fungerer, før antenner og serielle porte kommer ind i billedet.

Tilføj derefter to kompatible RNodes med passende antenner, dataforbindelser og stabil strøm. Konfigurér ens radioparametre efter den aktuelle interfacevejledning. Følg regionale vilkår; en eksempelfrekvens i en manual er ikke automatisk tilladelse til at sende. Notér de fungerende parametre og forbindelsen mellem vært og radio.

Isolér til sidst radiostrækningen. Slå andre Reticulum-interfaces fra, hvis de ellers kunne transportere testbeskeden. Behold naturligvis den lokale forbindelse, værten bruger til sin RNode. Send en ny besked i begge retninger. En besked mellem computere, som også deler et IP-netværk, beviser ikke, at den gik over LoRa.

LXMF og offlinelevering er ikke det samme som routing

LXMF er en beskedprotokol oven på Reticulum. Den understøtter blandt andet direkte levering og propagation, hvor en passende konfigureret propagation-node kan opbevare beskeder til senere afhentning. Det er nyttigt, når endepunkter ikke altid er online, men betyder ikke, at alle radioer automatisk gemmer beskeder.

En Reticulum-transportnode og en LXMF-propagation-node løser forskellige opgaver. Den ene flytter netværkstrafik; den anden understøtter levering på applikationsniveau. Beslut, om du har brug for én, begge eller ingen. En offline modtager kræver en tilgængelig leveringsordning og senere mulighed for at hente beskederne. Læs LXMF-dokumentationen, før du baserer projektet på store-and-forward.

Byg en lille netværksstruktur med vilje

Forestil dig to værksteder med lokale LoRa-brugere og en eksisterende IP-forbindelse mellem bygningerne. Reticulum kan bruge forskellige konfigurerede interfaces i samme løsning. IP-delen kan forbinde stederne, mens LoRa betjener lokale radiobrugere. Løsningen er ikke dermed uafhængig af IP-forbindelsen: fjernes den, kan værkstederne blive to separate netværk.

Tegn afhængighederne: vært, radio, strøm, antenne og forbindelsen mellem stederne. Spørg derefter, hvad der sker, hvis hver enkelt del svigter. Et godt design kan tåle nogle afbrydelser og acceptere andre. Beskriv det præcist frem for at kalde ethvert blandet netværk fuldstændigt off-grid.

Brug stabile systemer med gode forbindelser til transport, hvor det er nødvendigt. Transport på alle enheder er ikke automatisk bedre, især når vedligeholdelsestrafik skal over langsom radio. Netværkskapitlet beskriver rollerne og omkostningen ved at føre announces mellem forbindelser med meget forskellig kapacitet.

Tegn også sikkerhedsgrænserne

Kryptografien er central i Reticulum, men krypteret betyder ikke, at intet kan observeres, eller at alle tilsluttede programmer er sikre. Enheder opbevarer nøgler; kompromitterede endepunkter kan afsløre information. Radioaktivitet og brugen af en gateway kan stadig være synlig. Bekræft identiteter gennem en betroet kanal, når det er vigtigt, og beskyt sikkerhedskopier af identiteter.

En applikationsbro, som dekrypterer og omformaterer en besked, skaber en ny tillidsgrænse. Det er noget andet end at videresende en krypteret Reticulum-pakke. Tegn, hvor klartekst findes, hvem der styrer systemet, og hvilken beskyttelse hver del af ruten har. Beskeden er ikke nødvendigvis ende-til-ende-krypteret, blot fordi begge endeprogrammer bruger Reticulum.

Avanceret eksempel: en eksperimentel HF-bro

Videoen The Open Source Internet Is Here undersøger en eksperimentel bro over HF-radio. Omkring 27:20 forklares dekryptering ved en gateway; omkring 57:45 beskrives en fungerende bro. Ved 56:06 siger skaberen udtrykkeligt, at den planlagte skywave-test ikke blev gennemført. Det er et lærerigt forsøg, ikke dokumentation for en gennemført interkontinental Reticulum-forbindelse.

Eksemplet viser, hvorfor gateway, radiostrækning og ende-til-ende-beskyttelse skal vurderes hver for sig. Udstyr og regelsæt er anderledes end ved almindelig LoRa. Kopiér ikke videoens amatørradioindstillinger eller juridiske konklusioner til Danmark eller Sverige uden at kontrollere gældende regler. Videoen er inspiration til avancerede forsøg, ikke en færdig løsning med eBits-support.

Fejlsøg ét lag ad gangen

Brug små testbeskeder, og notér interfaces, leveringsstatus og tid. Gentag efter genstart af hver vært. Mål hele installationens strømforbrug. En energibesparende radio tilsluttet en computer, som altid er tændt, er stadig et computersystem, der altid er tændt.

Hvad vi skal vide for at hjælpe med hardware

Fortæl os, hvilket program og hvilken vært du vil bruge, om første forbindelse er LoRa eller IP, hvilke steder der skal forbindes, og hvordan systemet får strøm. Vi kan hjælpe med at indsnævre komponentvalget og finde de kompatibilitetspunkter, der skal kontrolleres. Alle LoRa-boards betragtes ikke som verificerede RNode-mål. Kontakt eBits, og sammenlign LoRa-grundlaget med Meshtastic, før du vælger protokol.

Gennemgået 28. september 2026. Guiden er teknisk planlægning, ikke et løfte om, at eBits har felttestet enhver netværksstruktur eller lagerfører et komplet HF-system. Følg den aktuelle projektdokumentation for installation og hardwareunderstøttelse.