<![CDATA[LK0NOD - Forum - Community - CB Funk 11m - PR-Gateways, Nodes & Digipeater]]> https://lk0nod.de/forum/ Sun, 03 May 2026 11:17:13 +0000 MyBB <![CDATA[Internationale Space Station (ISS) als Digipeater]]> https://lk0nod.de/forum/thread-920.html Fri, 24 Apr 2026 21:42:54 +0200 Retrofan]]> https://lk0nod.de/forum/thread-920.html
Von einem C64 als Bodenstation!
Cool



Ein faszinierender Bericht:
Quelle:   alickgardiner.com/c64-packet-radio/

Anmerkung: 
Senden zur ISS ist legal nur mit einer entsprechenden Funkamateur-Lizenz.]]>
Von einem C64 als Bodenstation!
Cool



Ein faszinierender Bericht:
Quelle:   alickgardiner.com/c64-packet-radio/

Anmerkung: 
Senden zur ISS ist legal nur mit einer entsprechenden Funkamateur-Lizenz.]]> <![CDATA[Aus meinem Archiv: XNet und NETROM]]> https://lk0nod.de/forum/thread-911.html Sun, 19 Apr 2026 13:36:18 +0200 DMA284]]> https://lk0nod.de/forum/thread-911.html
Seit einigen Wochen experimentiere ich wieder mit Packet Radio und leider
muss man sagen, das man das Netz voellig vergessen kann und das trotz AXUDP
Verbindungen zwischen den Nodes.

Faellt denn Niemanden ausser mir auf das NETROM nicht wirklich funktioniert?

Ja, es gibt ein tolle Nodeliste, aber wenn man versucht vor allem entferntere
Nodes zu erreichen dann funktioniert das nicht. Der Grund ist auch voellig
klar. Es liegt daran das immer noch viel zu haeufig die Software XNet
verwendet wird.

XNet ist an sich gar nicht mal schlecht aber es hat einen grossen Makel. Es
mixt die beiden Routing Grundlagen naemlich die des Time Dependent Routing
(TDR) via INP3 und dem Qualitaets basierten Routingshema.

Das Qualitaets basierte Routing Schema ist das urspruengliche Verfahren wie
eine Route zu einem Nachbar NETROM Node berechnet wird. Der Sysop gibt den
einzelnen Ports seines Nodes eine "Qualitaet" fest vor. Jede Software die
NETROM kann muss also einem Port eine Qualitaet zuweisen. In der
Vergangenheit war das oft der Wert 192 fuer einen 1200 Baud Funkport im CB.

Ein NETROM Node schickt in regelmaessigen Abstaenden ein NODES Broadcast als
AX.25 UI Frame an das Call NODES aus. Damit identifiziert er sich bei anderen
Nodes als NETROM Node und gleichzeitig schickt er damit eine Liste mit NETROM
Nodes mit die er selber kennt. Ein Node Broadcast sieht so aus:

10:09:38T DNO284>NODES Port=1 <UI C> NODES broadcast from WITBPQ
  WITPBXBig GrinBO284 via DNO284 qlty=192
  WITCNVBig GrinNO284-4 via DNO284 qlty=192

Empfaengt ein NETROM Node so einen Broadcast, traegt er den sendenden Node bei
sich in der Nodeliste mit der Port Qualitaet 192 ein. Weitere Nodes in der
Liste ebenfalls, aber reduziert in der Qualitaet basierend auf der Port
Qualitaet und der Qualitaet die der sendene Node diese Nodes selber bei sich
eingetragen hat.

Zur veranschaulichung:

Wir haben 3 Nodes. NODE01 <> NODE02 <> NODE03.
                         
Alle Nodes haben eine Port Qualitaet von 192 eingetragen. NODE01 und NODE03
sehen sich nicht direkt.

NODE02 sendet an NODE03 das er NODE01 mit Qualitaet 192 empfaengt. NODE03
berechnet nun die Qualitaet von NODE01 so:
192/256 * 192/256 = 0,75 * 0,75 = 0,5625 * 256 = 144

Wuerde es jetzt noch einen NODE04 geben der NODE03 hoert wuerde NODE01 bei
ihm mit Qualitaet 108 eingetragen werden.

144/256 * 192/256 = 0,5625 * 0,75 = 0,421875 * 256 = 108

Und so geht das immer weiter wenn noch mehr Nodes in diesem Netz hinzukommen.

Die Qualitaet kann den Wert 0-255 annehmen. Und wie man in den Berechnungen
sieht kommt bei 192/256 der Wert 0,75 bei raus. Damit wollte man abbilden wie
zuverlaessig ein Funkverbindung zwischen zwei Nodes fuer gewoehnlich ist. Man
koennte auch schreiben 75% der AX.25 Pakete zwischen zwei via Funk
verbundenen Nodes kommen an. Dieser Wert kann erreicht werden, wenn zwei
Nodes die Frequenz ganz fuer sich alleine haben, aber nicht wenn auf diesem
Kanal noch weitere Stationen sind. Tummeln sich jetzt mehrere Nodes und ggf.
noch User auf einer Frequenz wie es bei CB-PR ueblich war, war 192 auch schon
immer zu hoch gesetzt. Wenn man Glueck hatte kamen vielleicht gerade mal 50%
der AX.25 Pakete an oder noch weniger. Dementsprechend muesste man die
Qualitaet  entsprechend anpassen bei 50% waere 128 ein guten Wert. Die
meisten Nodes haben Port Statistiken gefuehrt, anhand diesen haette man
ermitteln koennen wie gut ein Port performt.

Obiges war jetzt die Beschreibung fuer Funk Links. Im heutigen CB-PR kommen
vor allem AXUDP Links via Internet vor, welche die Nodes miteinander
vernetzen. Das ist im Grunde nicht schlimm da wir, anders als im AFU, keine
exklusiven Frequenzen fuer eine Backbone Vernetzung zwischen Nodes haben.
Haeufig wir hier dann gerne die Port Qualitaet fuer solche AXIP/AXUDP Links
von 255 eingetragen. Das ist aber genauso falsch, weil Internet, welches auch
Paket basiert ist, nicht 100% Fehlerfrei ist. IP Pakete koennen und duerfen
verloren gehen. Nun ist unzweifelhaft das Links ueber Internet stabiler sind,
also kann man hier einen besseren Wert fuer die Qualitaet eintragen.

Die NADA (NorthEast Digital Association), eine in den 80er Jahren in den USA
gegruendete Organisation von Funkamateur Packet Radio Sysops hat fuer ihr
Netz Richtlinien herausgebracht. Dort wurde unter anderem festgelegt das
fuer AXIP/AXUDP Links die Port Qualitaet 203 betragen soll. Ich denke das ist
ein gute Wert. Er liegt hoeher als bei Funk Links und laesst die Moeglichkeit
zu das Internet Routen besser dastehen als reine Funk Links. Fuer lokale
Dienste wie z.B. die eigene Box oder der Convers kann der Wert 228 genutzt
werden. Dann resultiert daraus im Nodes Broadcast bei Nachbar Node eine
Qualitaet von 203 und ist somit genauso hoch wie der eigene Node.

Das oben genannte Routing mittels Qualitaeten hat schon in den Anfangstagen
so seine Probleme gehabt. Wie sich ja aus der von mir oben hoffentlich
einigermassen beschrieben kurzen Beschreibung ergibt, gibt die Qualitaet
ueberhaupt keinen Anhaltspunkt wie gut eine Node zu Node Verbindung
tatsaechlich ist. Sie ist ja nur angenommen und von den Sysops parametrisiert.
Jeder weiss, wenn sich Bedingungen aendern, muesste sich auch die Qualitaet am
besten automatisch mit aendern. Das koennen verschiedene Dinge sein. Zum
Beispiel wenn ein Link oder eine Frequenz stark ausgelastet ist, sinkt der
Datendurchsatz. Ergo muesste die Qualitaet sich verschlechtern. Tut sie aber
nach dem alten NETROM verfahren nicht.

Ein weiterer Grund ist wie Nodes wieder aus der Nodes Tabelle verschwinden.
Das geschieht aus einer reinen Zeit Komponente heraus. Es gibt bei NETROM den
Parameter OBSINIT. Das ist der Startwert des Veraltenszaehlers. Wird ein Node
das erste mal in einem Node Broadcast empfangen bekommt dieser den
Zaehlerwert von OBSINIT. Sendet unser Node ebenfalls einen Node Broadcast
wird dieser Wert um 1 verringert. Ist dieser Wert auf 0, fliegt der Node aus
unserer eigenen Nodes Tabelle raus. Ein Zweiter Parameter ist der Wert
OBSMIN. Dieser gibt an wann ein Node unserer Nodes Tabelle nicht mehr weiter
gemeldet wird. OBSINIT und OBSMIN haengen also davon ab wie oft unser Node
seinen Node Broadcast sendet. Ein guter Wert sind meiner Meinung nach 10
bis 15 Minuten. Ich bin der Meinung wenn man einen Node seit einer Stunde
nicht mehr im Broadcast gelesen hat, sollte er aus der Liste fliegen. Also
setzt man OBSINIT bei 10 Minuten Broadcast Intervall auf 6. Bei 15 Minuten
auf 4. Alle Node in einem Netz sollten bei Node Broadcast Intervall und bei
OBSINIT und OBSMIN die selben Werte haben, ansonsten ist das Netz von vorn
herein zum scheitern verurteilt. Sysops die nicht angepasste Werte dort
stehen haben, sollte vom Netz ausgeschlossen werden.

Weil das alte NETROM Node Austauschverfahren so unzuverlaessig ist, hat man
sich INP3 fuer NETROM ausgedacht. Hier werden mehrere Dinge ueberprueft damit
ein Link und somit der Nachbar Node und dessen erreichbare Nodes in der
eigenen Nodesliste angezeigt wird und auch an andere Nodes weiter geleitet
wird.

* Es muss ein AX25 Link zwischen den Nodes dauerhaft bestehen.

Im alten Netrom Netz wurde mit den oben beschriebenen Nodes Broadcasts auf
sich aufmerksam gemacht. Nun konnte die Situation entstehen das er Broadcast
aussendene Node den empfangenen Node selbst garnicht hoeren kann. Der
empfangene Node traegt den aussendenen Node und die weiteren im Broadcast
enthaltenen Nodes aber in seine Node Tabelle ein und sendet auch die darueber
verbreiteten Nodes weiter aus. Kommt jetzt eine NETROM Paket an beim Broadcast
empfangenden Node an, kann dieses Paket nicht weitergeleitet werden zum zuvor
Broadcast sendenen Node.

Sieht also ein INP3 NETROM Node einen Nachbar Node via Node Broadcast, baut er
einen AX.25 Connect zu diesem auf. Nur wenn das klappt, wird der Node erst in
die Nodes Tabelle bei ihm eingetragen.

* Laufzeitmessung

Zwischen INP3 Netrom Nodes werden Paketlaufzeiten ermittelt. Laufzeiten geben
einen Anhalt wie schnell ein Paket von Sender zum Empfaenger und zurueck
braucht. Das Ganze nennt sich abgeuerzt RTT (RoundTripTime). Da die Bandbreite
eines Links ja vorgeben ist, bedeutet eine kurze laufzeit das hoher Daten
Durchsatz moeglich ist. Ist ein Link ausgelastet oder sogar von Stoerungen
betroffen, werden die Laufzeiten schlechter.

* Hopcount

INP3 weiss wie viele Nodes zwischen den Nodes sind.

* Gesicherte Uebermittlung von Routing Informationen

INP3 sendet zu den Nachbar Nodes keine Nodes Broadcast mehr aus. Sondern die
Informationen werden gesichert in der AX.25 Verbindung zwischen beides Nodes
uebertragen.

* Negative Routing Informationen

INP3 meldet nicht mehr verfuegbare Links und darueber gelernte Nodes sofort als
nicht mehr erreichbar zu seinen anderen Nachbar Nodes weiter. Anders als beim
Routing ueber Qualitaet wo erst ein Node aus der Tabelle fliegt wenn von ihm
nach einer bestimmten Zeit kein Nodes Broadcast mehr empfangen wird.


Was hat nun XNet mit dem ganzen zu tun?

Nun es ist eigentlich einfach. NETROM an sich ist erstmal nur ein Protokoll
was Verbindungen herstellt zwischen entfernten Nodes. Die Routing
Informationen werden aber wie oben beschrieben auf zwei verschiedene Arten
ermittelt. Qualitaet und INP3. Waehrend Routing nach Qualitaetsangaben sich
quasi nur auf die Einschaetzungen der Sysops aufbaut, ermittelt INP3 Fakten
anhand von Laufzeitmessungen und ob ein Link tatsaechlich existiert, also
zwei Nodes auch wirklich eine Verbindung herstellen koennen.

Es ist auch gar kein Problem wenn diese zwei verschiedenen Verfahren in einem
Netz zusammen kommen. Es muss aber sichergestellt sein das jeder Node diese
Verfahren getrennt haelt. Ausser XNet macht das jede NETROM Node Software die
ich kenne.

XNet berechnet aus Laufzeiten Qualitaeten und aus Qualitaeten Laufzeiten. Das
ist ein absolutes NoGo! Aber welche Folgen hat das denn nun?

Schauen wir uns das noch mal an. Qualitaet = Von Sysop festgelegt und wenn
ein Nodes ueber ungesicherte Broadcasts weiter gemeldet wird, verringert sich
von Node zu Node die Qualitaet. Ueber einen auch vom Sysop einzurichtenen
Veraltenszaehler kann ein Node, wenn er nicht mehr in Broadcasts gehoert wird
auch wieder aus einer Nodes Liste verschwinden.

INP3 = Zeitbasiert mittels RTT ermittelte Laufzeiten, gesicherte Uebertragung
von Routing Infos via AX.25 Link und negative Rueckmeldungen. Nodes fliegen
bei AX.25 Abbruch zum Nachbarknoten direkt aus der Nodeliste und werden auch
sofort als nicht mehr erreichbar an andere Nachbar Nodes weitergemeldet.
Somit eine vertrauenswuerdige Routing Umgebung, mit gesicherten Informationen
zum Netzzustand.

Die Folge ist nun, dass ein Node, der nur in der nicht vertrauenswuerdigen
Qualitaets Umgebung existiert und in dieser Umgebung moeglicherweise ausserhalb
unseres Qualitaets Horizonts lag, nun in der vertrauenswuerdigeren INP3
Umgebung auftaucht, wo er den NetRom veraltens Prozess umgehen kann. Die
Information koennte dann mit einer hoeheren "Qualitaet" in das qualitaets
Netrom-Netz zurueckkehren, als wenn sie ueber eine direktere reine Netrom-Route
empfangen worden waere.

Hier ein Beispiel wie das aussieht:

AP1DIG ==>n dnx284 +

routing WITXROBig GrinNX284 v AP0NOD

  LOCAL      Inp 3    rx:  -.-  (unreach) tx:  -.-
  DAB563-9  Inp 3    rx:  1.48 ( 9 hops) tx:  -.-
> AP0NOD    Inp 3    rx:  1.21 ( 6 hops) tx:  -.-
  CB0ESN    Inp 3    rx:  -.-  (unreach) tx:  1.38
  CB0GER    Inp 3    rx:  -.-  (unreach) tx:  -.-
  AX25N0    Inp 3    rx:  -.-  (unreach) tx:  1.44
  CT1NET    Q BC      Obs  0 RxQual  0
  AP1NOD    Q BC      Obs  6 RxQual  0
  NL5POP    Q BC      Obs  0 RxQual  0
  Broadcasted 432s ago with quality 244

AP1DIG ==>
*** route: AP1DIG AP0NOD KS0NOD KS1NOD-2 AP0NOD* AP1DIG

DNX284 ist ein Test Node von mir, den ich jetzt seit mehrern Tagen Offline
genommen habe. Trotzdem ist er in Nodes Listen weiterhin vorhanden und wird
von XNet Nodes wie hier zu sehen mit der Qualitaet von 244 weiter
gebroadcastet und natuerlich somit auch via INP3 mit einer fiktiven RTT
weiter gegeben.

Ein weiterer Grund den ich nicht verschweigen moechte ist das einige Nodes
die z.B. mit BPQ laufen den Parameter AUTOSAVE fuer die Nodes Liste
aktiviert haben. Dieser sollte immer ausgeschaltet werden. Denn damit
werden bei jedem Neustart von BPQ ggf. alte nicht mehr vorhandene Nodes
neu ins Netz eingespielt, obwohl die schon lange weg sind.

Deswegen ist XNet fuer das CB-PR und fuer alle sonstigen Netze die schlechteste
Software die man AX.25 NETROM Netzen antun kann. Im AFU Bereich wo Packet
auch nur noch von wenigen betrieben wird, ist die Software so gut wie
verschwunden. Ich finde man sollte dieses auch im CB-PR so handhaben. Im
Grunde bleiben einem nur drei NETROM Node Programme uebrig wenn man sich
umschaut.

BPQ: Aktive Weiterentwicklung inklusive Source-Code verfuegbar. Fuer Windows,
Linux und auch auf nem RasPi lauffaehig. Aeltere Versionen auch auf DOS.
Zahlreiche Schnittstellen vorhanden. INP3 faehig und rudimentaer sogar schon
IPv6 faehig. Bevorzugt leider altes Qulitätsbasiertes NETROm Routing, kann
jedoch mit dem Parameter PREFERINP3ROUTES=1 dazu gezwungen werden INP3 zu
bevorzugen bei der Routing Entscheidung.

Xrouter: Aktive Weiterentwicklung. Leider closed Source. Nur auf Linux,
Windows und RasPi verfuegbar. Aeltere Versionen auch fuer DOS. INP3 faehig
und bevorzugt von Haus aus INP3, wenn vorhanden.

TNN: Keine aktive Weiterentwicklung. Open Source Quellcode aber nicht fuer
aktuelle Compiler angepasst und Probleme wenn auf 64Bit System compiliert
wird. Angepasste CB Versionen verfuegbar. INP3 faehig und bevorzugt von Haus
aus INP3, wenn vorhanden.

Ich moechte jedem Sysop bitten sich mal die Alternativen anzusehen. Zum einen
erweitert man dadurch seinen Horizont und tut, wenn man sich entschliesst
XNet aufzugeben, auch was Gutes fuer das Netz.

Fuer Sysops die nicht wechseln koennen, weil sie XNet in einem TNC3 oder TNC4
laufen haben. Sollten nur Links zu Nodes aufbauen die keine NODES Broadcast
aussenden. Ebenso sollten sie selber mit dem Befehl "ro bc del nodes" das
Aussenden von Nodes Broadcast abschalten.

Link Partner zu XNet Nodes sollten nur INP3 erlauben. Nodes Broadcast zum
XNet Nodes ebenfalls abschalten und Nodes Broadcast von XNet Nodes
ignorieren oder die Port Qualitaet auf 0 oder 1 setzen.

Falls das alles nix hilft bleibt nur noch, das XNet Nodes von Sysops ohne
XNet vom Netz ausgeschlossen werden.


55 & 73 Marc-Andre DMA284]]>
Seit einigen Wochen experimentiere ich wieder mit Packet Radio und leider
muss man sagen, das man das Netz voellig vergessen kann und das trotz AXUDP
Verbindungen zwischen den Nodes.

Faellt denn Niemanden ausser mir auf das NETROM nicht wirklich funktioniert?

Ja, es gibt ein tolle Nodeliste, aber wenn man versucht vor allem entferntere
Nodes zu erreichen dann funktioniert das nicht. Der Grund ist auch voellig
klar. Es liegt daran das immer noch viel zu haeufig die Software XNet
verwendet wird.

XNet ist an sich gar nicht mal schlecht aber es hat einen grossen Makel. Es
mixt die beiden Routing Grundlagen naemlich die des Time Dependent Routing
(TDR) via INP3 und dem Qualitaets basierten Routingshema.

Das Qualitaets basierte Routing Schema ist das urspruengliche Verfahren wie
eine Route zu einem Nachbar NETROM Node berechnet wird. Der Sysop gibt den
einzelnen Ports seines Nodes eine "Qualitaet" fest vor. Jede Software die
NETROM kann muss also einem Port eine Qualitaet zuweisen. In der
Vergangenheit war das oft der Wert 192 fuer einen 1200 Baud Funkport im CB.

Ein NETROM Node schickt in regelmaessigen Abstaenden ein NODES Broadcast als
AX.25 UI Frame an das Call NODES aus. Damit identifiziert er sich bei anderen
Nodes als NETROM Node und gleichzeitig schickt er damit eine Liste mit NETROM
Nodes mit die er selber kennt. Ein Node Broadcast sieht so aus:

10:09:38T DNO284>NODES Port=1 <UI C> NODES broadcast from WITBPQ
  WITPBXBig GrinBO284 via DNO284 qlty=192
  WITCNVBig GrinNO284-4 via DNO284 qlty=192

Empfaengt ein NETROM Node so einen Broadcast, traegt er den sendenden Node bei
sich in der Nodeliste mit der Port Qualitaet 192 ein. Weitere Nodes in der
Liste ebenfalls, aber reduziert in der Qualitaet basierend auf der Port
Qualitaet und der Qualitaet die der sendene Node diese Nodes selber bei sich
eingetragen hat.

Zur veranschaulichung:

Wir haben 3 Nodes. NODE01 <> NODE02 <> NODE03.
                         
Alle Nodes haben eine Port Qualitaet von 192 eingetragen. NODE01 und NODE03
sehen sich nicht direkt.

NODE02 sendet an NODE03 das er NODE01 mit Qualitaet 192 empfaengt. NODE03
berechnet nun die Qualitaet von NODE01 so:
192/256 * 192/256 = 0,75 * 0,75 = 0,5625 * 256 = 144

Wuerde es jetzt noch einen NODE04 geben der NODE03 hoert wuerde NODE01 bei
ihm mit Qualitaet 108 eingetragen werden.

144/256 * 192/256 = 0,5625 * 0,75 = 0,421875 * 256 = 108

Und so geht das immer weiter wenn noch mehr Nodes in diesem Netz hinzukommen.

Die Qualitaet kann den Wert 0-255 annehmen. Und wie man in den Berechnungen
sieht kommt bei 192/256 der Wert 0,75 bei raus. Damit wollte man abbilden wie
zuverlaessig ein Funkverbindung zwischen zwei Nodes fuer gewoehnlich ist. Man
koennte auch schreiben 75% der AX.25 Pakete zwischen zwei via Funk
verbundenen Nodes kommen an. Dieser Wert kann erreicht werden, wenn zwei
Nodes die Frequenz ganz fuer sich alleine haben, aber nicht wenn auf diesem
Kanal noch weitere Stationen sind. Tummeln sich jetzt mehrere Nodes und ggf.
noch User auf einer Frequenz wie es bei CB-PR ueblich war, war 192 auch schon
immer zu hoch gesetzt. Wenn man Glueck hatte kamen vielleicht gerade mal 50%
der AX.25 Pakete an oder noch weniger. Dementsprechend muesste man die
Qualitaet  entsprechend anpassen bei 50% waere 128 ein guten Wert. Die
meisten Nodes haben Port Statistiken gefuehrt, anhand diesen haette man
ermitteln koennen wie gut ein Port performt.

Obiges war jetzt die Beschreibung fuer Funk Links. Im heutigen CB-PR kommen
vor allem AXUDP Links via Internet vor, welche die Nodes miteinander
vernetzen. Das ist im Grunde nicht schlimm da wir, anders als im AFU, keine
exklusiven Frequenzen fuer eine Backbone Vernetzung zwischen Nodes haben.
Haeufig wir hier dann gerne die Port Qualitaet fuer solche AXIP/AXUDP Links
von 255 eingetragen. Das ist aber genauso falsch, weil Internet, welches auch
Paket basiert ist, nicht 100% Fehlerfrei ist. IP Pakete koennen und duerfen
verloren gehen. Nun ist unzweifelhaft das Links ueber Internet stabiler sind,
also kann man hier einen besseren Wert fuer die Qualitaet eintragen.

Die NADA (NorthEast Digital Association), eine in den 80er Jahren in den USA
gegruendete Organisation von Funkamateur Packet Radio Sysops hat fuer ihr
Netz Richtlinien herausgebracht. Dort wurde unter anderem festgelegt das
fuer AXIP/AXUDP Links die Port Qualitaet 203 betragen soll. Ich denke das ist
ein gute Wert. Er liegt hoeher als bei Funk Links und laesst die Moeglichkeit
zu das Internet Routen besser dastehen als reine Funk Links. Fuer lokale
Dienste wie z.B. die eigene Box oder der Convers kann der Wert 228 genutzt
werden. Dann resultiert daraus im Nodes Broadcast bei Nachbar Node eine
Qualitaet von 203 und ist somit genauso hoch wie der eigene Node.

Das oben genannte Routing mittels Qualitaeten hat schon in den Anfangstagen
so seine Probleme gehabt. Wie sich ja aus der von mir oben hoffentlich
einigermassen beschrieben kurzen Beschreibung ergibt, gibt die Qualitaet
ueberhaupt keinen Anhaltspunkt wie gut eine Node zu Node Verbindung
tatsaechlich ist. Sie ist ja nur angenommen und von den Sysops parametrisiert.
Jeder weiss, wenn sich Bedingungen aendern, muesste sich auch die Qualitaet am
besten automatisch mit aendern. Das koennen verschiedene Dinge sein. Zum
Beispiel wenn ein Link oder eine Frequenz stark ausgelastet ist, sinkt der
Datendurchsatz. Ergo muesste die Qualitaet sich verschlechtern. Tut sie aber
nach dem alten NETROM verfahren nicht.

Ein weiterer Grund ist wie Nodes wieder aus der Nodes Tabelle verschwinden.
Das geschieht aus einer reinen Zeit Komponente heraus. Es gibt bei NETROM den
Parameter OBSINIT. Das ist der Startwert des Veraltenszaehlers. Wird ein Node
das erste mal in einem Node Broadcast empfangen bekommt dieser den
Zaehlerwert von OBSINIT. Sendet unser Node ebenfalls einen Node Broadcast
wird dieser Wert um 1 verringert. Ist dieser Wert auf 0, fliegt der Node aus
unserer eigenen Nodes Tabelle raus. Ein Zweiter Parameter ist der Wert
OBSMIN. Dieser gibt an wann ein Node unserer Nodes Tabelle nicht mehr weiter
gemeldet wird. OBSINIT und OBSMIN haengen also davon ab wie oft unser Node
seinen Node Broadcast sendet. Ein guter Wert sind meiner Meinung nach 10
bis 15 Minuten. Ich bin der Meinung wenn man einen Node seit einer Stunde
nicht mehr im Broadcast gelesen hat, sollte er aus der Liste fliegen. Also
setzt man OBSINIT bei 10 Minuten Broadcast Intervall auf 6. Bei 15 Minuten
auf 4. Alle Node in einem Netz sollten bei Node Broadcast Intervall und bei
OBSINIT und OBSMIN die selben Werte haben, ansonsten ist das Netz von vorn
herein zum scheitern verurteilt. Sysops die nicht angepasste Werte dort
stehen haben, sollte vom Netz ausgeschlossen werden.

Weil das alte NETROM Node Austauschverfahren so unzuverlaessig ist, hat man
sich INP3 fuer NETROM ausgedacht. Hier werden mehrere Dinge ueberprueft damit
ein Link und somit der Nachbar Node und dessen erreichbare Nodes in der
eigenen Nodesliste angezeigt wird und auch an andere Nodes weiter geleitet
wird.

* Es muss ein AX25 Link zwischen den Nodes dauerhaft bestehen.

Im alten Netrom Netz wurde mit den oben beschriebenen Nodes Broadcasts auf
sich aufmerksam gemacht. Nun konnte die Situation entstehen das er Broadcast
aussendene Node den empfangenen Node selbst garnicht hoeren kann. Der
empfangene Node traegt den aussendenen Node und die weiteren im Broadcast
enthaltenen Nodes aber in seine Node Tabelle ein und sendet auch die darueber
verbreiteten Nodes weiter aus. Kommt jetzt eine NETROM Paket an beim Broadcast
empfangenden Node an, kann dieses Paket nicht weitergeleitet werden zum zuvor
Broadcast sendenen Node.

Sieht also ein INP3 NETROM Node einen Nachbar Node via Node Broadcast, baut er
einen AX.25 Connect zu diesem auf. Nur wenn das klappt, wird der Node erst in
die Nodes Tabelle bei ihm eingetragen.

* Laufzeitmessung

Zwischen INP3 Netrom Nodes werden Paketlaufzeiten ermittelt. Laufzeiten geben
einen Anhalt wie schnell ein Paket von Sender zum Empfaenger und zurueck
braucht. Das Ganze nennt sich abgeuerzt RTT (RoundTripTime). Da die Bandbreite
eines Links ja vorgeben ist, bedeutet eine kurze laufzeit das hoher Daten
Durchsatz moeglich ist. Ist ein Link ausgelastet oder sogar von Stoerungen
betroffen, werden die Laufzeiten schlechter.

* Hopcount

INP3 weiss wie viele Nodes zwischen den Nodes sind.

* Gesicherte Uebermittlung von Routing Informationen

INP3 sendet zu den Nachbar Nodes keine Nodes Broadcast mehr aus. Sondern die
Informationen werden gesichert in der AX.25 Verbindung zwischen beides Nodes
uebertragen.

* Negative Routing Informationen

INP3 meldet nicht mehr verfuegbare Links und darueber gelernte Nodes sofort als
nicht mehr erreichbar zu seinen anderen Nachbar Nodes weiter. Anders als beim
Routing ueber Qualitaet wo erst ein Node aus der Tabelle fliegt wenn von ihm
nach einer bestimmten Zeit kein Nodes Broadcast mehr empfangen wird.


Was hat nun XNet mit dem ganzen zu tun?

Nun es ist eigentlich einfach. NETROM an sich ist erstmal nur ein Protokoll
was Verbindungen herstellt zwischen entfernten Nodes. Die Routing
Informationen werden aber wie oben beschrieben auf zwei verschiedene Arten
ermittelt. Qualitaet und INP3. Waehrend Routing nach Qualitaetsangaben sich
quasi nur auf die Einschaetzungen der Sysops aufbaut, ermittelt INP3 Fakten
anhand von Laufzeitmessungen und ob ein Link tatsaechlich existiert, also
zwei Nodes auch wirklich eine Verbindung herstellen koennen.

Es ist auch gar kein Problem wenn diese zwei verschiedenen Verfahren in einem
Netz zusammen kommen. Es muss aber sichergestellt sein das jeder Node diese
Verfahren getrennt haelt. Ausser XNet macht das jede NETROM Node Software die
ich kenne.

XNet berechnet aus Laufzeiten Qualitaeten und aus Qualitaeten Laufzeiten. Das
ist ein absolutes NoGo! Aber welche Folgen hat das denn nun?

Schauen wir uns das noch mal an. Qualitaet = Von Sysop festgelegt und wenn
ein Nodes ueber ungesicherte Broadcasts weiter gemeldet wird, verringert sich
von Node zu Node die Qualitaet. Ueber einen auch vom Sysop einzurichtenen
Veraltenszaehler kann ein Node, wenn er nicht mehr in Broadcasts gehoert wird
auch wieder aus einer Nodes Liste verschwinden.

INP3 = Zeitbasiert mittels RTT ermittelte Laufzeiten, gesicherte Uebertragung
von Routing Infos via AX.25 Link und negative Rueckmeldungen. Nodes fliegen
bei AX.25 Abbruch zum Nachbarknoten direkt aus der Nodeliste und werden auch
sofort als nicht mehr erreichbar an andere Nachbar Nodes weitergemeldet.
Somit eine vertrauenswuerdige Routing Umgebung, mit gesicherten Informationen
zum Netzzustand.

Die Folge ist nun, dass ein Node, der nur in der nicht vertrauenswuerdigen
Qualitaets Umgebung existiert und in dieser Umgebung moeglicherweise ausserhalb
unseres Qualitaets Horizonts lag, nun in der vertrauenswuerdigeren INP3
Umgebung auftaucht, wo er den NetRom veraltens Prozess umgehen kann. Die
Information koennte dann mit einer hoeheren "Qualitaet" in das qualitaets
Netrom-Netz zurueckkehren, als wenn sie ueber eine direktere reine Netrom-Route
empfangen worden waere.

Hier ein Beispiel wie das aussieht:

AP1DIG ==>n dnx284 +

routing WITXROBig GrinNX284 v AP0NOD

  LOCAL      Inp 3    rx:  -.-  (unreach) tx:  -.-
  DAB563-9  Inp 3    rx:  1.48 ( 9 hops) tx:  -.-
> AP0NOD    Inp 3    rx:  1.21 ( 6 hops) tx:  -.-
  CB0ESN    Inp 3    rx:  -.-  (unreach) tx:  1.38
  CB0GER    Inp 3    rx:  -.-  (unreach) tx:  -.-
  AX25N0    Inp 3    rx:  -.-  (unreach) tx:  1.44
  CT1NET    Q BC      Obs  0 RxQual  0
  AP1NOD    Q BC      Obs  6 RxQual  0
  NL5POP    Q BC      Obs  0 RxQual  0
  Broadcasted 432s ago with quality 244

AP1DIG ==>
*** route: AP1DIG AP0NOD KS0NOD KS1NOD-2 AP0NOD* AP1DIG

DNX284 ist ein Test Node von mir, den ich jetzt seit mehrern Tagen Offline
genommen habe. Trotzdem ist er in Nodes Listen weiterhin vorhanden und wird
von XNet Nodes wie hier zu sehen mit der Qualitaet von 244 weiter
gebroadcastet und natuerlich somit auch via INP3 mit einer fiktiven RTT
weiter gegeben.

Ein weiterer Grund den ich nicht verschweigen moechte ist das einige Nodes
die z.B. mit BPQ laufen den Parameter AUTOSAVE fuer die Nodes Liste
aktiviert haben. Dieser sollte immer ausgeschaltet werden. Denn damit
werden bei jedem Neustart von BPQ ggf. alte nicht mehr vorhandene Nodes
neu ins Netz eingespielt, obwohl die schon lange weg sind.

Deswegen ist XNet fuer das CB-PR und fuer alle sonstigen Netze die schlechteste
Software die man AX.25 NETROM Netzen antun kann. Im AFU Bereich wo Packet
auch nur noch von wenigen betrieben wird, ist die Software so gut wie
verschwunden. Ich finde man sollte dieses auch im CB-PR so handhaben. Im
Grunde bleiben einem nur drei NETROM Node Programme uebrig wenn man sich
umschaut.

BPQ: Aktive Weiterentwicklung inklusive Source-Code verfuegbar. Fuer Windows,
Linux und auch auf nem RasPi lauffaehig. Aeltere Versionen auch auf DOS.
Zahlreiche Schnittstellen vorhanden. INP3 faehig und rudimentaer sogar schon
IPv6 faehig. Bevorzugt leider altes Qulitätsbasiertes NETROm Routing, kann
jedoch mit dem Parameter PREFERINP3ROUTES=1 dazu gezwungen werden INP3 zu
bevorzugen bei der Routing Entscheidung.

Xrouter: Aktive Weiterentwicklung. Leider closed Source. Nur auf Linux,
Windows und RasPi verfuegbar. Aeltere Versionen auch fuer DOS. INP3 faehig
und bevorzugt von Haus aus INP3, wenn vorhanden.

TNN: Keine aktive Weiterentwicklung. Open Source Quellcode aber nicht fuer
aktuelle Compiler angepasst und Probleme wenn auf 64Bit System compiliert
wird. Angepasste CB Versionen verfuegbar. INP3 faehig und bevorzugt von Haus
aus INP3, wenn vorhanden.

Ich moechte jedem Sysop bitten sich mal die Alternativen anzusehen. Zum einen
erweitert man dadurch seinen Horizont und tut, wenn man sich entschliesst
XNet aufzugeben, auch was Gutes fuer das Netz.

Fuer Sysops die nicht wechseln koennen, weil sie XNet in einem TNC3 oder TNC4
laufen haben. Sollten nur Links zu Nodes aufbauen die keine NODES Broadcast
aussenden. Ebenso sollten sie selber mit dem Befehl "ro bc del nodes" das
Aussenden von Nodes Broadcast abschalten.

Link Partner zu XNet Nodes sollten nur INP3 erlauben. Nodes Broadcast zum
XNet Nodes ebenfalls abschalten und Nodes Broadcast von XNet Nodes
ignorieren oder die Port Qualitaet auf 0 oder 1 setzen.

Falls das alles nix hilft bleibt nur noch, das XNet Nodes von Sysops ohne
XNet vom Netz ausgeschlossen werden.


55 & 73 Marc-Andre DMA284]]> <![CDATA[DNX284 - Neues Funkgerät]]> https://lk0nod.de/forum/thread-775.html Fri, 20 Feb 2026 07:16:31 +0100 DMA284]]> https://lk0nod.de/forum/thread-775.html
Da ich ja nur verstaubte Technik derzeit habe und bisher sehr schlecht selbst nur 20km entfernte Stationen empfange, versuche ich mein Glück mit einem neuen Funkgerät. Ich habe mir das Albrecht AE6199 ANC bestellt und hoffe das ich damit meinen Empfang verbessern kann. In wie weit NRC kompatibel mit Packet ist, wird sich raus stellen müssen.

Ich werde hier berichten wenn das Gerät bei mir und angeschlossen ist.

55 & 73 Marc-Andre]]>
Da ich ja nur verstaubte Technik derzeit habe und bisher sehr schlecht selbst nur 20km entfernte Stationen empfange, versuche ich mein Glück mit einem neuen Funkgerät. Ich habe mir das Albrecht AE6199 ANC bestellt und hoffe das ich damit meinen Empfang verbessern kann. In wie weit NRC kompatibel mit Packet ist, wird sich raus stellen müssen.

Ich werde hier berichten wenn das Gerät bei mir und angeschlossen ist.

55 & 73 Marc-Andre]]> <![CDATA[MH-List DNX284]]> https://lk0nod.de/forum/thread-773.html Wed, 18 Feb 2026 21:32:22 +0100 DMA284]]> https://lk0nod.de/forum/thread-773.html
Code:
DNX284:WITTNG} Heard list for port 2:

Callsign  Date  Time  Frames  Via      Type    Position        Dist Dir
POR001-8  18/02 18:08    286            N  38.6141N  9.1771W 2186Km 232
D1WKA-11  18/02 17:51      1               
DAC476-15 18/02 17:30     23                50.9695N  13.9225E 292Km 130
LK0BOX    18/02 17:26      5                52.3030N  8.6961E 146Km 252
LK0NOD    18/02 16:34      3                52.3030N  8.6961E 146Km 252
D0HHB     18/02 16:31      1  CEN0DE-5     
CEN0DE-5  18/02 16:31      1            D   
DPH206-15 18/02 16:23     11               
ME0BBS    18/02 16:20      3                53.8241N  12.9808E 192Km  50
VR3NOD    18/02 16:19      1                54.0703N  13.1420E 218Km  46
DO7MPA    18/02 15:14      8               
ESP7NA    18/02 15:03    159               
ME0BBS    18/02 14:40      1  DIGN0D       
DIGN0D    18/02 14:40      1            D   
PORNOD    18/02 14:28     20               
NL5VKL    18/02 14:27      1  WIDE1         
DND665    18/02 12:12      1  WIDE1          54.3566N  12.5978E 219Km  33
DAC476-14 18/02 12:10      3               
DPH206    18/02 12:09      1               
AP4BOX    18/02 10:41      1               
UEN0DE    18/02 10:40      1               
HH3NOD    18/02 09:21      1  WIDE1          52.8691N  10.5851E  20Km 327
HH3NOD    18/02 09:14      1                 52.8690N  10.5860E  20Km 327
DAC476-15 18/02 09:13      1  WIDE2          50.9695N  13.9225E 292Km 130
(End of list)
]]>
Code:
DNX284:WITTNG} Heard list for port 2:

Callsign  Date  Time  Frames  Via      Type    Position        Dist Dir
POR001-8  18/02 18:08    286            N  38.6141N  9.1771W 2186Km 232
D1WKA-11  18/02 17:51      1               
DAC476-15 18/02 17:30     23                50.9695N  13.9225E 292Km 130
LK0BOX    18/02 17:26      5                52.3030N  8.6961E 146Km 252
LK0NOD    18/02 16:34      3                52.3030N  8.6961E 146Km 252
D0HHB     18/02 16:31      1  CEN0DE-5     
CEN0DE-5  18/02 16:31      1            D   
DPH206-15 18/02 16:23     11               
ME0BBS    18/02 16:20      3                53.8241N  12.9808E 192Km  50
VR3NOD    18/02 16:19      1                54.0703N  13.1420E 218Km  46
DO7MPA    18/02 15:14      8               
ESP7NA    18/02 15:03    159               
ME0BBS    18/02 14:40      1  DIGN0D       
DIGN0D    18/02 14:40      1            D   
PORNOD    18/02 14:28     20               
NL5VKL    18/02 14:27      1  WIDE1         
DND665    18/02 12:12      1  WIDE1          54.3566N  12.5978E 219Km  33
DAC476-14 18/02 12:10      3               
DPH206    18/02 12:09      1               
AP4BOX    18/02 10:41      1               
UEN0DE    18/02 10:40      1               
HH3NOD    18/02 09:21      1  WIDE1          52.8691N  10.5851E  20Km 327
HH3NOD    18/02 09:14      1                 52.8690N  10.5860E  20Km 327
DAC476-15 18/02 09:13      1  WIDE2          50.9695N  13.9225E 292Km 130
(End of list)
]]> <![CDATA[Node Netz ist kaputt]]> https://lk0nod.de/forum/thread-715.html Sun, 08 Feb 2026 16:03:41 +0100 DMA284]]> https://lk0nod.de/forum/thread-715.html
Das Thema bewegt mich schon ziemlich lange. Es geht darum das unser Node Netz, trotz Internet Links, einfach nur kaputt ist. Ich hatte schon mehrmals das Thema aufgebracht, aber es scheint keine Diskussion darüber, weder hier im Box Netz noch in Internet Foren, darüber zu geben.

Deswegen möchte ich nochmals vor allem die XNet und BPQ Sysops ansprechen.

XNet ist hier immer noch das Hauptproblem. Denn es mischt NETROM Routig basierend auf Qualität mit dem INP3 Routing auf Laufzeiten. Das ist nicht vereinbar und man möchte den XNet Programmierern heute noch nach rufen das das eine Sau blöde Idee war!

Deswegen die bitte an die XNet Sysops. Linkt nicht mit Nodes die nur NETROM Routing auf Qualitäts-Basis machen. Schmeißt sie raus, blockt sie oder was auch immer. Wenn ihr altes NETROM auf Funk machen wollt, nehmt nicht XNet dazu, wenn ihr gleichzeitig INP3 auf anderen Ports macht.

Reines NETROM Routing macht unter anderem auch BPQ. Wenn man es nicht richtig konfiguriert. Deswegen der Appell an BPQ Sysops. Auf Internet Links mittels AXUPD/IP/TCP bitte für den eingerichteten Port folgende Parameter setzen.

QUALITY=1
L3ONLY=1
INP3ONLY=1

In der Haupt Sektion des Config Files bei den NETROM Parametern dann noch diesen Eintrag setzen.

PREFERINP3ROUTES=1

Der verhindert das komische, durch XNet versaubeutelte, Qualitäten Einfluss auf die Routing Entscheidung von BPQ haben und immer nach Laufzeiten, statt nach Qualitäten geroutet wird.


55 & 73 Marc-Andre]]>
Das Thema bewegt mich schon ziemlich lange. Es geht darum das unser Node Netz, trotz Internet Links, einfach nur kaputt ist. Ich hatte schon mehrmals das Thema aufgebracht, aber es scheint keine Diskussion darüber, weder hier im Box Netz noch in Internet Foren, darüber zu geben.

Deswegen möchte ich nochmals vor allem die XNet und BPQ Sysops ansprechen.

XNet ist hier immer noch das Hauptproblem. Denn es mischt NETROM Routig basierend auf Qualität mit dem INP3 Routing auf Laufzeiten. Das ist nicht vereinbar und man möchte den XNet Programmierern heute noch nach rufen das das eine Sau blöde Idee war!

Deswegen die bitte an die XNet Sysops. Linkt nicht mit Nodes die nur NETROM Routing auf Qualitäts-Basis machen. Schmeißt sie raus, blockt sie oder was auch immer. Wenn ihr altes NETROM auf Funk machen wollt, nehmt nicht XNet dazu, wenn ihr gleichzeitig INP3 auf anderen Ports macht.

Reines NETROM Routing macht unter anderem auch BPQ. Wenn man es nicht richtig konfiguriert. Deswegen der Appell an BPQ Sysops. Auf Internet Links mittels AXUPD/IP/TCP bitte für den eingerichteten Port folgende Parameter setzen.

QUALITY=1
L3ONLY=1
INP3ONLY=1

In der Haupt Sektion des Config Files bei den NETROM Parametern dann noch diesen Eintrag setzen.

PREFERINP3ROUTES=1

Der verhindert das komische, durch XNet versaubeutelte, Qualitäten Einfluss auf die Routing Entscheidung von BPQ haben und immer nach Laufzeiten, statt nach Qualitäten geroutet wird.


55 & 73 Marc-Andre]]> <![CDATA[Frequenzen]]> https://lk0nod.de/forum/thread-411.html Mon, 12 Jan 2026 15:04:13 +0100 DF2WKR]]> https://lk0nod.de/forum/thread-411.html
Vielleicht hat jemand interesse mal als SWLer mitzulesen :-) ? Hier ein Liste mit den QRGs für APRS und Packet Radio aus dem Afu-Bereich.

73 / 55 de DF2WKR

40m: 7035 MHz in LSB, 300 Bd
 
30m: 10.147,6 MHz in LSB, 300 Bd

20m: 14.103 MHz in USB, 300 Bd

10m: 29.250 MHz in FM, 1k2

2m: 144.800 MHz in FM, 1k2
      145.825 MHZ in FM 1k2 Downlink, OSCAR 44

70cm: 432.500 MHz in FM, 1k2]]>
Vielleicht hat jemand interesse mal als SWLer mitzulesen :-) ? Hier ein Liste mit den QRGs für APRS und Packet Radio aus dem Afu-Bereich.

73 / 55 de DF2WKR

40m: 7035 MHz in LSB, 300 Bd
 
30m: 10.147,6 MHz in LSB, 300 Bd

20m: 14.103 MHz in USB, 300 Bd

10m: 29.250 MHz in FM, 1k2

2m: 144.800 MHz in FM, 1k2
      145.825 MHZ in FM 1k2 Downlink, OSCAR 44

70cm: 432.500 MHz in FM, 1k2]]> <![CDATA[Upgrade der Station]]> https://lk0nod.de/forum/thread-201.html Sun, 24 Aug 2025 11:42:56 +0200 Sebastian LG1BG]]> https://lk0nod.de/forum/thread-201.html Die alte S2000 wurde von einer Vector 4000 (Lambda 6/8) mit 8,50m Länge ersetzt.
Die Ergebnisse können sich sehen lassen, seitdem lese ich den LK0NOD täglich, LG1UG, DOHHH, DAK263 und DNO381 sporadisch.
Auch das rauskommen hat sich spürbar verbessert, bei guten Bedingungen vor allem in den späten Abendstunden gelingt mir ein
Connect zum LK0NOD.
Der Transceiver wurde vor kurzem gegen eine AE8000 ausgetauscht, welche konkreten Ergebnisse das nun hervorbringt wird
sich noch zeigen.]]> Die alte S2000 wurde von einer Vector 4000 (Lambda 6/8) mit 8,50m Länge ersetzt.
Die Ergebnisse können sich sehen lassen, seitdem lese ich den LK0NOD täglich, LG1UG, DOHHH, DAK263 und DNO381 sporadisch.
Auch das rauskommen hat sich spürbar verbessert, bei guten Bedingungen vor allem in den späten Abendstunden gelingt mir ein
Connect zum LK0NOD.
Der Transceiver wurde vor kurzem gegen eine AE8000 ausgetauscht, welche konkreten Ergebnisse das nun hervorbringt wird
sich noch zeigen.]]> <![CDATA[Änderung vom Setup]]> https://lk0nod.de/forum/thread-113.html Fri, 23 May 2025 23:51:02 +0200 Sebastian LG1BG]]> https://lk0nod.de/forum/thread-113.html Auf dem Pi läuft Direwolf als Modem mit FX25, da dieses System doch etwas besser decodiert, ausserdem hat sich der DOS-Rechner
als nicht sehr stabil gezeigt.
Es mussten öfter Fahrten dort hin unternommen werden um das System neu zu starten.]]> Auf dem Pi läuft Direwolf als Modem mit FX25, da dieses System doch etwas besser decodiert, ausserdem hat sich der DOS-Rechner
als nicht sehr stabil gezeigt.
Es mussten öfter Fahrten dort hin unternommen werden um das System neu zu starten.]]> <![CDATA[AP2NOD/AP2BOX]]> https://lk0nod.de/forum/thread-105.html Mon, 19 May 2025 03:31:56 +0200 Apolo1]]> https://lk0nod.de/forum/thread-105.html
Sysop          APOLO1
Co-Sysop     APOLO2
Email             AP1BOX@GMX.DE
Mailbox         AP2BBS:AP2BOX.#H.NDS.DEU.EU
Antenne        GP27 von Albrecht laenge 6,20m mit drei Radilas von 90cm laenge
                     die Antenne steht im 2OG auf einem 6 Meter mast
RX/TX Port 1 Internetport anbindung unter ap1nod.ddns.net UDP 8093
RX/TX Port 2 Funkport auf Kanal 24/27.235mhz Hier laeuft eine Stabo XM5012 mit einem Selbstgebauten Modem
                     Software BPQ 4.08 & F6FBB V700I unter DOS
Computer     Pentium 1 233 mmx

Der AP2NOD hat Funk verbindung auf Kanal 24 zum BTC0IN Hannover List und zum RADIO7 Hannover/Ronnenberg]]>
Sysop          APOLO1
Co-Sysop     APOLO2
Email             AP1BOX@GMX.DE
Mailbox         AP2BBS:AP2BOX.#H.NDS.DEU.EU
Antenne        GP27 von Albrecht laenge 6,20m mit drei Radilas von 90cm laenge
                     die Antenne steht im 2OG auf einem 6 Meter mast
RX/TX Port 1 Internetport anbindung unter ap1nod.ddns.net UDP 8093
RX/TX Port 2 Funkport auf Kanal 24/27.235mhz Hier laeuft eine Stabo XM5012 mit einem Selbstgebauten Modem
                     Software BPQ 4.08 & F6FBB V700I unter DOS
Computer     Pentium 1 233 mmx

Der AP2NOD hat Funk verbindung auf Kanal 24 zum BTC0IN Hannover List und zum RADIO7 Hannover/Ronnenberg]]> <![CDATA[AP1NOD/AP1BOX]]> https://lk0nod.de/forum/thread-104.html Mon, 19 May 2025 03:07:47 +0200 Apolo1]]> https://lk0nod.de/forum/thread-104.html
Dieser Node verfuegt ueber 4 Ports

Port 1 APRS
Port 2 Internetport
Port 3 AGWPE
Port 4 Nullmodem Port zum Funk Node AP2NOD/AP2BOX

Dieser Node laeuft auf einen WINXP Rechner
und der steht bei mir aufen dachboden dereckt am AP2NOD.

Wenn man mochte kann man sich auch, am AP1NOD via AXIP
anbinden unter ap1nod.ddns.net UDP 8093

Dieser Node besitzt auch noch eien BCM Box und zwar die AP1BOX.
Diese Mailbox macht Forward mit der AP2BOX  und gilt als Archivmailbox.
Die Mailbox kann man ueber das Netrom Routing Erreichen. Oder auf Port 3
vom AP1NOD aus.

Und zusätzlich laeuft auf dem Rechner noch UI-View was mit dem BPQ vom AP1NOD
Verbunden ist und zusammen Arbeitet unter dem call AP1NOD-13 und AP1NOD-3

Info vom AP1NOD

Sysop APOLO1/DHH507
QTH Hannover/Badenstedt
Loc JO42UI
Email AP1BOX@GMX.DE
Mailbox AP1BOX.#H.NDS.DEU.EU
Software WinBpq auf WinXp mit APRS UI-View
Computer AMD Sempron Processor 3000+ 1.81 Ghz,
1.00GB Ram mit Microsoft WinXp Pro SP2 Ver2002


Bei weiteren fragen könnt ihr mich fragen oder Connectet das System und schaut Euch um. :-)

MfG Peer
APOLO1@AP2BOX.#H.NDS.DEU.EU]]>
Dieser Node verfuegt ueber 4 Ports

Port 1 APRS
Port 2 Internetport
Port 3 AGWPE
Port 4 Nullmodem Port zum Funk Node AP2NOD/AP2BOX

Dieser Node laeuft auf einen WINXP Rechner
und der steht bei mir aufen dachboden dereckt am AP2NOD.

Wenn man mochte kann man sich auch, am AP1NOD via AXIP
anbinden unter ap1nod.ddns.net UDP 8093

Dieser Node besitzt auch noch eien BCM Box und zwar die AP1BOX.
Diese Mailbox macht Forward mit der AP2BOX  und gilt als Archivmailbox.
Die Mailbox kann man ueber das Netrom Routing Erreichen. Oder auf Port 3
vom AP1NOD aus.

Und zusätzlich laeuft auf dem Rechner noch UI-View was mit dem BPQ vom AP1NOD
Verbunden ist und zusammen Arbeitet unter dem call AP1NOD-13 und AP1NOD-3

Info vom AP1NOD

Sysop APOLO1/DHH507
QTH Hannover/Badenstedt
Loc JO42UI
Email AP1BOX@GMX.DE
Mailbox AP1BOX.#H.NDS.DEU.EU
Software WinBpq auf WinXp mit APRS UI-View
Computer AMD Sempron Processor 3000+ 1.81 Ghz,
1.00GB Ram mit Microsoft WinXp Pro SP2 Ver2002


Bei weiteren fragen könnt ihr mich fragen oder Connectet das System und schaut Euch um. :-)

MfG Peer
APOLO1@AP2BOX.#H.NDS.DEU.EU]]> <![CDATA[D0HHH (Gateway Node) HF + AXIP]]> https://lk0nod.de/forum/thread-85.html Mon, 28 Apr 2025 18:14:07 +0200 D1TNE]]> https://lk0nod.de/forum/thread-85.html
Funk und Internet-Gateway
-----------------------------------
QTH Loc  HH-Harburg JO43XK

Platform Betriebssystem: Linux

CPU       Intel Atom CPU (2x 1.86Ghz)
Chipsatz PD12TI Mini-ITX Mainboard
RAM      4GB SO-DDR3 RAM
HDD      120 GB No SSD
RAM:     2 GB
RX/TX: Albrecht AE 8000
Modem : Symek TNC2S (6Pack-Mode)
Software TNN 1.79 (Linux) (CB)

TNC     Port 0: Funkanbindung Kanal 24
AXIP    Port 1: Web, d0hhh.ramoip.de udp 10093
Box      Port 2: LAN Aanbindung zu D0HHB
           Port 3:
HTTP   Port 4:

Systemspannung 12 Volt
Akku       12V 100AH zZ Bleiakku derzeit umbau auf LFP akkus
Ladung    2x 200watt PV wird erweitert auf 2x400Watt
Regler     MPPT 30 Amp. umbau auf 60Amp
Somit ist die Anlage ausfallsicher.]]>
Funk und Internet-Gateway
-----------------------------------
QTH Loc  HH-Harburg JO43XK

Platform Betriebssystem: Linux

CPU       Intel Atom CPU (2x 1.86Ghz)
Chipsatz PD12TI Mini-ITX Mainboard
RAM      4GB SO-DDR3 RAM
HDD      120 GB No SSD
RAM:     2 GB
RX/TX: Albrecht AE 8000
Modem : Symek TNC2S (6Pack-Mode)
Software TNN 1.79 (Linux) (CB)

TNC     Port 0: Funkanbindung Kanal 24
AXIP    Port 1: Web, d0hhh.ramoip.de udp 10093
Box      Port 2: LAN Aanbindung zu D0HHB
           Port 3:
HTTP   Port 4:

Systemspannung 12 Volt
Akku       12V 100AH zZ Bleiakku derzeit umbau auf LFP akkus
Ladung    2x 200watt PV wird erweitert auf 2x400Watt
Regler     MPPT 30 Amp. umbau auf 60Amp
Somit ist die Anlage ausfallsicher.]]> <![CDATA[reines HF DOS Node]]> https://lk0nod.de/forum/thread-71.html Wed, 09 Apr 2025 23:29:15 +0200 Sebastian LG1BG]]> https://lk0nod.de/forum/thread-71.html Das Node steht auf einem Bauernhof in Wrestedt und arbeitet mit einem klassischen Modem
über TFPCX in Verbindung mit einem DOS System.

Ich bin noch am optimieren und feinjustieren.... Angel

Hier die technischen Daten

PC           : Thin Client 500Mhz, 128MB RAM  (7W Leistungsaufnahme)
TRX         : Albrecht AE 5290
Modem    : Alan RMD1200 TFPCX 2.73
Antenne   : 5/8 Sirtel
OS           : Free DOS 1.3
Software  : HSGNODE (von Ralph Y02HAL)
QTH        : Wrestedt JO52HU


Viele Dank an Michael (ehemals LG1PI) für den Standort
Und vielen Dank an Ralph für den Software Support

.jpg   photo_2025-03-28_13-11-03.jpg (Größe: 133,3 KB / Downloads: 6)
.jpg   photo_2025-03-28_13-11-01.jpg (Größe: 194,47 KB / Downloads: 6) ]]> Das Node steht auf einem Bauernhof in Wrestedt und arbeitet mit einem klassischen Modem
über TFPCX in Verbindung mit einem DOS System.

Ich bin noch am optimieren und feinjustieren.... Angel

Hier die technischen Daten

PC           : Thin Client 500Mhz, 128MB RAM  (7W Leistungsaufnahme)
TRX         : Albrecht AE 5290
Modem    : Alan RMD1200 TFPCX 2.73
Antenne   : 5/8 Sirtel
OS           : Free DOS 1.3
Software  : HSGNODE (von Ralph Y02HAL)
QTH        : Wrestedt JO52HU


Viele Dank an Michael (ehemals LG1PI) für den Standort
Und vielen Dank an Ralph für den Software Support

.jpg   photo_2025-03-28_13-11-03.jpg (Größe: 133,3 KB / Downloads: 6)
.jpg   photo_2025-03-28_13-11-01.jpg (Größe: 194,47 KB / Downloads: 6) ]]> <![CDATA[CEN0DE]]> https://lk0nod.de/forum/thread-69.html Wed, 09 Apr 2025 22:49:11 +0200 Sebastian LG1BG]]> https://lk0nod.de/forum/thread-69.html
***********************************************
*  Antenne  : Vector 4000 in 13M Höhe (88m ü.n.N.)      *
*  Kabel      : 20M RG213 MIL                                       *
*  Trx         : AE6110                                      *
*  Modem   : Direwolf 1.7                                             *
*  Software : TNN 1.79                                                *
*  PC          : Raspberry PI 3B+                                     *
*  QRG       : 27,235 Mhz                                              *
*                                                                                *
***********************************************

Das Node steht im Wald und hat den großen Vorteil, das hier im dunkeln
absolut kein QRM vorhanden ist.
Seit Oktober 2022  dauerhaft in Betrieb und 24/7 erreichbar.
Viel Spaß beim gemeinsamen Hobby Wink


.jpg   photo_2025-04-09_22-25-44.jpg (Größe: 200,55 KB / Downloads: 5) ]]>
***********************************************
*  Antenne  : Vector 4000 in 13M Höhe (88m ü.n.N.)      *
*  Kabel      : 20M RG213 MIL                                       *
*  Trx         : AE6110                                      *
*  Modem   : Direwolf 1.7                                             *
*  Software : TNN 1.79                                                *
*  PC          : Raspberry PI 3B+                                     *
*  QRG       : 27,235 Mhz                                              *
*                                                                                *
***********************************************

Das Node steht im Wald und hat den großen Vorteil, das hier im dunkeln
absolut kein QRM vorhanden ist.
Seit Oktober 2022  dauerhaft in Betrieb und 24/7 erreichbar.
Viel Spaß beim gemeinsamen Hobby Wink


.jpg   photo_2025-04-09_22-25-44.jpg (Größe: 200,55 KB / Downloads: 5) ]]>