Reticulum gör det möjligt att bygga datanät över olika kommunikationsmedier. LoRa kan vara ett av dem, men Reticulum är varken en viss radio eller ett enda globalt nätverk som blir tillgängligt när ett kort slås på. Du väljer förbindelser och applikationer; stacken tillhandahåller adressering, krypterad kommunikation och transport.

Det passar lokala experiment, gemensam infrastruktur och nät som blandar långsam radio med snabbare länkar. Men ett “Reticulum-kort” utan en plan för värdenheten kan betyda att halva systemet saknas.

Skilj applikation, stack och radio åt

I en vanlig LoRa-installation körs program och Reticulum på en telefon eller dator, medan en ansluten RNode tillhandahåller radion. Integrerade produkter kan kombinera delarna, men ett kompatibelt radiokort är inte nödvändigtvis en komplett meddelandeenhet. Startguiden presenterar programmen och hårdvarukapitlet beskriver interface.

Destinationer och vägar skiljer sig från IP

Applikationer kommunicerar genom destinationer i stället för kombinationen IP-adress och port. Destinationen hör till en applikationsändpunkt. Kryptografisk identitet ingår i identifieringen av vanliga single-destinationer. Identitet och applikationens meddelandeadress är besläktade, men utbyt den adress som programmet faktiskt efterfrågar.

Announces gör destinationer och information om deras publika nycklar upptäckbara. Transportnoder kan föra trafik över flera hopp. Mekanismerna ersätter inte fysiska länkar: ett onåbart radiosegment förblir onåbart. Börja med två ändpunkter innan transportinfrastruktur läggs till. Arkitekturkapitlet förklarar destinations- och länktyper.

RNode-stöd måste kontrolleras exakt

RNode är ett radiointerface med firmware för stödd hårdvara. En LoRa-krets eller ESP32 i produktnamnet räcker inte som bevis. Kontrollera kortrevision, radiokrets, frekvensvariant och exakt firmwaremål. USB, Bluetooth och andra anslutningar beror också på implementation och värdenhet.

RNode-firmware som ersätter Meshtastic-firmware ändrar enhetens roll. Protokollen börjar inte förstå varandra, och båda kan inte förväntas dela en vanlig firmwareinstallation. Spara relevanta inställningar och följ rätt installations- och återställningsförfarande. Använd RNode-projektet som kompatibilitetskälla, inte ett liknande produktfoto.

Börja utan radio och lägg till den sedan

Ett bra första test skiljer programvarufrågor från radiofrågor. Installera ett stött program på två lämpliga enheter och använd ett dokumenterat lokalt nätverksinterface. Utbyt applikationsadresser, skicka åt båda håll och hitta leveransstatus. Då vet du att program och identiteter fungerar innan antenner och serieportar tillkommer.

Lägg sedan till två kompatibla RNodes med lämpliga antenner, dataanslutningar och stabil ström. Konfigurera matchande radioparametrar enligt interface-dokumentationen. Följ lokala villkor; en exempelfrekvens i en manual är inte automatiskt sändningstillstånd. Dokumentera fungerande parametrar och kopplingen mellan värd och radio.

Isolera till sist radiovägen. Stäng av andra Reticulum-interface som annars kan bära testmeddelandet, men behåll värdens lokala anslutning till RNode. Skicka ett nytt meddelande åt varje håll. Ett meddelande mellan datorer som också delar IP-nät bevisar inte att det gick över LoRa.

LXMF och offlineleverans är inte samma sak som routing

LXMF är ett meddelandeprotokoll byggt på Reticulum. Det stöder bland annat direktleverans och propagation, där en lämpligt konfigurerad propagation-nod kan lagra meddelanden för senare hämtning. Det hjälper när ändpunkter inte alltid är online men innebär inte att varje radio automatiskt lagrar meddelanden.

En Reticulum-transportnod och en LXMF-propagation-nod har olika uppgifter. Den ena flyttar nätverkstrafik; den andra stödjer leverans på applikationsnivå. Bestäm om du behöver en, båda eller ingen. En offline mottagare behöver ett fungerande leveransarrangemang och senare möjlighet att hämta meddelanden. Läs LXMF-dokumentationen innan du förlitar dig på store-and-forward.

Planera en liten nätverksstruktur medvetet

Tänk dig två verkstäder med lokala LoRa-användare och en befintlig IP-länk mellan byggnaderna. Reticulum kan använda olika konfigurerade interface i samma lösning. IP-delen förbinder platserna medan LoRa betjänar lokala radioanvändare. Det gör inte lösningen oberoende av IP-länken: kopplas den ur kan verkstäderna bli separata nät.

Rita varje beroende: värd, radio, ström, antenn och förbindelsen mellan platserna. Fråga vad som händer när varje del slutar fungera. En bra design kan tåla vissa avbrott och acceptera andra. Beskriv det ärligt i stället för att kalla varje blandat nät helt off-grid.

Välj stabila och välanslutna system för transport där det behövs. Transport överallt är inte automatiskt bättre, särskilt när underhållstrafik ska över långsam radio. Nätverkskapitlet beskriver rollerna och kostnaden för announces mellan länkar med olika kapacitet.

Rita säkerhetsgränserna också

Kryptografin är central, men krypterat betyder inte att inget kan observeras eller att alla applikationer är säkra. Enheter innehåller nycklar; komprometterade ändpunkter kan läcka information. Radioaktivitet och gateways kan fortfarande observeras. Bekräfta identiteter genom en betrodd kanal när det behövs och skydda identitetsbackuper.

En applikationsbrygga som dekrypterar och omformaterar ett meddelande skapar en ny tillitsgräns. Det är något annat än att vidarebefordra ett krypterat Reticulum-paket. Rita var klartext finns, vem som driver systemet och vilket skydd varje del har. Meddelandet är inte nödvändigtvis ändpunktskrypterat bara för att båda programmen använder Reticulum.

Avancerat exempel: en experimentell HF-brygga

Videon The Open Source Internet Is Here undersöker en experimentell HF-brygga. Omkring 27:20 beskrivs dekryptering vid en gateway och omkring 57:45 en fungerande brygga. Vid 56:06 säger skaparen uttryckligen att det planerade skywave-testet inte genomfördes. Det är ett lärorikt experiment, inte belägg för en genomförd interkontinental Reticulum-länk.

Exemplet visar varför gateway, radioväg och ändpunktsskydd måste bedömas var för sig. Utrustning och regelverk skiljer sig från en vanlig LoRa-installation. Kopiera inte amatörradioinställningar eller juridiska slutsatser till Sverige eller Danmark utan att kontrollera aktuella regler. Videon inspirerar till avancerade experiment; den visar ingen färdig lösning med eBits-support.

Felsök ett lager i taget

Använd små testmeddelanden och notera interface, leveransstatus och tid. Upprepa efter omstart av varje värd. Mät hela installationens strömbehov. En strömsnål radio kopplad till en ständigt påslagen dator är fortfarande ett ständigt påslaget datorsystem.

Vad vi behöver veta inför hårdvaruvalet

Berätta vilket program och vilken värd du vill använda, om första länken är LoRa eller IP, vilka platser som ska anslutas och hur systemet får ström. Vi hjälper dig att undersöka komponenter och vad som kräver kompatibilitetskontroll. Alla LoRa-kort är inte verifierade RNode-mål. Kontakta eBits och jämför LoRa-grunderna med Meshtastic innan du väljer protokoll.

Granskat 28 september 2026. Guiden är teknisk planering, inte ett påstående om att eBits fälttestat varje struktur eller lagerför ett komplett HF-system. Följ aktuell projektdokumentation för installation och hårdvarustöd.