Kategorie:Digitaltechnik

2025-10-28T18:29:39Z

IN3FQQ: inhalt gehört nicht in die kategoriebeschreibung

HAMNET-Geschichte

2025-10-27T08:30:03Z

IN3FQQ:

Die digitale Vernetzung von automatisch arbeitenden Amateurfunkstellen auf Basis des TCP/IP-Protokolls hat eine lange Geschichte.

Bereits im Jahre 1970 hat Hank Magnuski den Klasse A Adressblock 44.0.0.0/8 (<nowiki>http://www.ampr.org</nowiki>) zugewiesen bekommen. Bei der IANA (Internet Assigned Numbers Authority, <nowiki>http://www.iana.org</nowiki>) wird dieser Adressblock als „Amateur Radio Digital Communications“ aufgeführt (<nowiki>http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml</nowiki>). Seit einer langen Zeit verwaltet Brian Kantor, WB6CYT, das Netz.

Das „Network 44“ wird auch als „AMPRNet“ bezeichnet. Diese Abkürzung steht für „AMateur Packet Radio Network“ und ist von der Terminologie her an die Betriebsart Packet Radio gebunden. Mittlerweile geht die Nutzung des „Network 44“ aber weit über die Betriebsart Packet Radio hinaus. Daher kann auch das HAMNET ein Teil des AMPRNet sein.

Bei dem Aufbau des Packet Radio Netzes in Deutschland wurde von Anfang an mit der Übertragung von TCP/IP-Paketen über AX.25 experimentiert. Der geschätzte Höhepunkt der Aktivität war Mitte der 90er Jahre und brachte zuletzt das sogenannte „HamWeb“ hervor. Viele Betreiber von Packet Radio Knoten hatten sich entschlossen, auch TCP/IP-Dienste wie HTTP anzubieten. Die Nutzer konnten so im „HamWeb“ surfen.

Im Laufe der Jahre haben die Anzahl der Medien und die verfügbaren Informationskanäle stark zugenommen. Die Attraktivität mit langsamen TCP/IP-über-AX.25-Verbindungen Informationen auszutauschen ging nach und nach verloren. Heute ist es zu einer der vielen Nischen im Amateurfunk geworden.

Im folgenden nun eine Übersicht der Anfänge des HAMNET-Projekts in Südtirol bis heute (wird laufend aktualisiert)

== Projektverlauf 2008 ==
Unzählige Stunden an Vorbereitungen und Testläufe in '''Meran (Mut), Völlan, Bozen (Gantkofel), Auer''' mit verschiedenstem WiFi-Equipement und in kleinstem Kreise: '''IW3BRC, IW3AMQ, IW3BWH'''

== Projektverlauf 2009 ==

=== Juli ===
2009-07-18: Marco IW2OHX, der nazionale IP-Koordinator, erteilt dem Hamnet-Projekt in der italienischen Provinz Bozen/Trient die nötige Zuweisung von 3 öffentlichen Subnetzen aus dem AMPR-Netz (44.134.0.0/16 ↔ ampr.org).

=== Ende 2009 ===
Inbetriebnahme des ersten Interlink IR3UGM<>OE7XGR sowie der Hamnet-Strecke Gantkofel-Marling.

== Projektverlauf 2010 ==

=== Februar ===
2010-02-16: Erste brauchbare AXIP-Verbindung via Hamnet zwischen '''IW3BRC in Meran''' (Italien) und der PR-Mailbox von '''OE2XZR in Salzburg''' (Österreich).

=== März ===
2010-03-28: Erste erfolgreiche Mumble-Session (VoIP) via Hamnet zwischen IW3BRC (Tobias) in Meran und OE7FMI (Markus) in Mayrhofen im Zillertal. Die VoIP-Konversation wurde dabei von einem Mumble-Server in Oberösterreich vermittelt.

=== April ===
2010-04-10: Erster Test einer 5GHz-Useranbindung im Raum Meran war erfolgreich.

Nun können im Raum Meran/Burggrafenamt weitere Anbindungen erfolgen.

=== Juni ===
2010-06-12: Weitere 5GHz-Useranbindung im Raum Bozen erfolgreich getestet.

Nun können auch dort registrierte User an HAMNET teilnehmen.

=== Juli ===
2010-07-03: Hamnet wurde am '''Rittner Horn''' montiert und die Verbindung zum Gantkofel hergestellt.

Dieser Standort wird künftig ein weiterer lokaler Grossverteiler von Hamnet für den Südtiroler Raum darstellen.

2010-07-31: Ein erster konkreter Dienst (sog. Service) nimmt über Hamnet testweise seinen Dienst auf.

Es handelt sich dabei um einen '''Packet Radio Digipeater''' der „neuen“ Generation, der einerseits noch einen klassischen 1k2 PR-Einstieg auf 144.925 MHz bietet und andererseits bereits das Hamnet als High-Speed-Interlink zwischen Bozen (IR3UGM - Gantkofel) und Zillertal (OE7XGR - Gefrorene Wand) verwendet, um darüber im „Huckepack“-Verfahren AX25-Pakete zu transportieren.

Darüber hinaus kann auch über Hamnet selbst dieser Einstiegsknoten in voller Wifi-Geschwindigkeit genutzt werden.

=== August ===
2010-08-10: Ein weiterer Meilenstein im Hamnet-Projekt wurde am Rittner Horn gelegt: Die '''Verbindung zur Marmolada''' konnte erfolgreich hergestellt werden mit -70db.

== Projektverlauf 2011 ==
Generalüberholung und Vorbereitung von IR3EB „Piz Chavalatsch“ fürs HAMNET.

Gleiches für die neuen Hamnet-Standorte „Seceda Nord“ und „Gitschberg“. Auch hier musste erst das Equipement organisiert und vor Ort gebracht werden. Am Ende der Saison konnte '''IR3EB erfolgreich ans Hamnet angebunden''' werden.

== Projektverlauf 2012 ==

=== März ===
2012-03-31: Hamnet-Einsatz Marmolada, um einen weiteren Interlink '''IR3AO<>OE8XDR''' (Dobratsch) zu aktivieren.

=== April ===
2012-04-11: Kontaktaufnahme mit den Hamnet-Kollegen in HB9 - momentan leider (noch) keine Anbindungsmöglichkeiten vorhanden.

2012-04-14: Integration der neuen Linkstrecken ins Hamnet, soweit möglich - bei der neuen Linkstrecke IR3AO<>IR3UHF scheint ein HW-Schaden offensichtlich.

2012-04-26: Erörterung/Planung der weiteren Bedarfslisten und Einsätze für die Hamnet-Saison 2012.

=== Mai ===
2012-05-09: Dokumentationsplattform ins Leben gerufen - <nowiki>http://hamnet.cisarbz.org</nowiki> oder <nowiki>http://hamnet.drc.bz</nowiki>

2012-05-18: Echtzeit-Monitoring aktiviert - <nowiki>http://hammon.iw3brc.net</nowiki>

=== Juli ===
2012-07-07: Erneuter Einsatz Marmolada, um defekte Hamnet-Antenne samt Board zu wechseln und die Linkstrecke Kronplatz (IR3DV) vorzubereiten.

2012-07-08: Hamnet-Einsatz Gitschberg (IR3UHI), wobei auch dort eine defekte Hamnet-Antenne Richtung Kronplatz (IR3DV) ersetzt werden musste.

=== September ===
2012-09-08: Dritter Hamnet-Einsatz Marmolada, um Blitzschaden am gesamten Umsetzerstandort zu beheben.

Folgende Linkstrecken konnten dabei reaktiviert bzw. neu aktiviert werden:

IR3AO <> IR3UHF läuft nun wieder wie gehabt -75 dBi

IR3AO <> IR3DV konnte zusätzlich aktiviert werden -73 dBi

IR3AO <> OE8XDR-2 wartet auf die Gegenseite

IR3AO <> IR3UDZ schwächelt noch ein wenig, Gegenseite muss kontrolliert werden

=== Oktober ===
2012-10-13: Flori (DL8MBT) bastelt eine Software zur Verwaltung von Standorten und IP-Adressen, u.a. findet sich darin auch das AS64600 wieder.

Hamnet IP Database: <nowiki>http://hamnetdb.net</nowiki>

Mirror South Tyrol: <nowiki>http://hamnetdb.iw3brc.net</nowiki>

=== November ===
2012-11-30: HAMMON <nowiki>http://hammon.iw3brc.net</nowiki> wird geupdatet und mit Verknüpfungen zur neuen IP-Dokumentation und zu weiteren Realtimedaten erweitert.

== Projektverlauf 2013 ==

=== erstes Halbjahr 2013 ===
Softwareseitige Optimierungen an den bestehenden Strukturen IR3UHE, IR3UGM, IR3UHF, IR3EB, IR3AO, IR3DV, IR3UHI

=== Juli ===
2013-07-12: Vorbereitung eines weiteren Hamnetknotens am '''Schludernser Berg IR3UBE''' für die Verbindung zu IR3EB.

2013-07-14: Erste Aktivierung von AllstarLink auf den Knoten IR3UGM Gantkofel und IR3DV Kronplatz. Weitere Infos unter [Http://drc.bz/wordpress/link-sudtirol-gantkofel-und-kronplatz-in-betrieb/ http://drc.bz/wordpress/link-sudtirol-gantkofel-und-kronplatz-in-betrieb/]

=== August ===
2013-08-10: Aktivierung des Hamnet-Knotens '''IR3UGB''' auf der '''Seceda'''.

2013-08-16: Aktivierung der '''Linkstrecke Piz Chavalatsch (IR3EB) ↔ Schludernser Berg (IR3UBE)''' und weiter bis zu IN3XOZ in Mals.

2013-08-17: Start der 2-Tages-Grossaktion am Piz Chavalatsch mit Hubschraubereinsatz. Verschiedenste Umbau- und Reparaturarbeiten konnten beendet werden.

2013-08-18: Erfolgreiche Reparatur des R6 Vinschgau und Inbetriebnahme des „Südtirol Link“ auf 70cm, der den Piz Chavalatsch mit Gantkofel und Kronplatz via Hamnet und quer durch Südtirol permanent verbindet.

Krönung war dann noch die erfolgreiche Aktivierung einer Foto-Webcam von Flori (DL8MBT) Richtung Ortlermassiv: https://www.foto-webcam.eu/webcam/chavalatsch/

=== September ===
2013-09-28: Aktivierung des Hamnet-Knotens '''IR3UGD''' am '''Jaufenpass''' und gleichzeitige Installation des Link Südtirol an diesem Standort.

== Projektverlauf 2014 ==

=== April ===
2014-04-24: Die ehemalige Gewerbeoberschule (GOB) und jetzige Technologische Fachoberschule (TFO) “Max Valier” in Bozen konnte erfolgreich ans HAMNET angebunden werden.

=== Juli ===
2014-07-11: Am Hamnet-Standort Seceda wird nun erstmals das Signal der '''Zugspitze DB0ZU/70''' empfangen, um es dann an bestimmte Knoten zu nutzen (Gantkofel, Chavalatsch, Kronplatz).

Über den 70cm-Einstieg Gantkofel kann das deutsche Relais bereits erfolgreich gearbeitet werden.

=== August ===
2014-08-03: Der (Hamnet)Standort Rittnerhorn konnte erfolgreich auf den neuen Funkmast des Zivilschutzes migriert werden.

2014-08-23: Am Standort Chavalatsch wurde neben zahlreichen Wartungsarbeiten nun auch der „Link Zugspitze“ aktiviert.

2014-08-30: Der Standort Plose wurde hamnet-technisch erschlossen und mit einem weiteren Einstieg zum „Link Südtirol“ versorgt.

2014-09-30: Am Standort Rittnerhorn IR3UHF wurden die letzten Arbeiten nach dem Umzug auf den neuen Masten erledigt, die bis dato noch offen geblieben waren.

2014-10-04: Der Standort auf der Seceda wird generalüberholt, d.h. die leidigen Linkstrecken wurden nun durch kompakte QRT5 ersetzt, um damit endlich die gewünschte Linkstabilität zu erreichen, nachdem der Standort Marmolada durch erneuten Blitzschaden ausgefallen ist.

== Projektverlauf 2015 ==

=== April ===
2015-04-06: Die Zugspitzanbindung im Pustertal wird vom Kronplatz IR3DV auf den Gitschberg IR3UHI verlegt.

2015-04-28: Der Standort am Schludernser Berg erhält eine neue Linkantenne zu IR3EB und wird ab nun mit zusätzlichem Strom aus Windkraft unterstützt.

=== Mai ===
2015-05-01: Der Standort am Gantkofel IR3UGM erhält ein neues DStar-Interface (UP4DAR).

=== Juni ===
2015-06-14: Inspektions- und Reparatureinsatz am Standort Chavalatsch IR3EB.

== 2017 ==

=== September/Oktober: ===
Nach einem Standortumzug auf der Plose besteht nun Sicht zu '''OE7XGR Gefrorene Wand'''. Damit konnte die Linkstrecke Gantkofel-Gefrorene Wand auf die Plose umgezogen werden. Die Strecke nach OE7 funktioniert nun aufgrund der wesentlich kürzeren Strecke erheblich stabiler.

Außerdem besteht vom neuen Standort Plose auch Sicht zum '''Kronplatz''' und zum '''Gitschberg'''. Somit wurden auch die Standorte Gitschberg und Kronplatz direkt über die Plose angebunden, was insgesamt zu kürzeren Strecken, weniger Hops und somit weniger Ausfallrisiko führt.

== 2018 ==

=== Juli ===
Aktivierung der Verbindung vom Kronplatz zu '''OE7XJH Hollbruck''' in Osttirol

=== Gesamtes Jahr ===
Erneuerung/Einrichtung Userzugänge mit 120° Sektorantennen im 2,3GHz Band auf den Standorten Gantkofel (für den Raum Etschtal/Bozen), Marlinger Berg (Raum Meran), Rittnerhorn (Raum Überetsch/Unterland), Gitschberg (Raum Brixen) und Kronplatz (Raum Bruneck)

=== Dezember ===
Aktivierung Standort '''IR3UFM Schöneben''' im oberen Vinschgau, vorerst noch ohne HAMNET-Anbindung

== 2019 ==

=== September ===
Aktivierung Standort '''IR3UFM Helm''' und Anbindung an '''IR3DV Kronplatz''' (PtMP mit der Antenne richtung Hollbruck)

Später dann wurde auf PTP mit einer eigenen Antenne umgebaut.

Durch Aktivierung der Zwischenstation am '''IR3UFL Grauner Berg''' konnte nun auch '''IR3UFM Schöneben''' via Richtfunk ans HAMNET angebunden werden.

== 2021 ==

=== Juli ===
Aktivierung des Standortes '''IR3BC Vigiljoch.''' Von hier aus können nun '''IR3EB Chavalatsch''' und '''IR3UGD Jaufen''' direkt erreicht werden.

Somit ergeben sich auch hier eine Verkürzung der Strecke (Chavalatsch) und insgesamt kürzere netzwerktechnische Wege.

=== Dezember ===
Das gesamte HAMNET in Südtirol wird auf 32-Bit-AS-Nummern umgestellt.

Damit agiert nun jeder Standort routingtechnisch komplett eigenständig und es ist möglich, bei einem Ausfall eines zentralen Knotens in Südtirol - z.B. Rittnerhorn - die HAMNET-Kommunikation zwischen unseren Standorten automatisch über andere Regionen, beispielsweise über OE7 - umzuleiten.

== 2022 ==

=== April ===
Unsere Kollegen in Tirol aktivieren '''OE7XNP Gueser Kopf''' bei Nauders, von wo aus Sicht zu IR3UFM Schöneben besteht.

Mit der Aktivierung dieses Links besteht nun ein HAMNET-Kreis zwischen Südtirol und OE7. Zusammen mit den 32-bit-AS-Nummern kann dies auch tatsächlich genutzt werden, falls innerhalb Südtirols wichtige Knoten ausfallen würden.

[[Kategorie:HAMNET]]

HAMNET-Geschichte

2025-10-27T08:06:41Z

IN3FQQ: HAMNET-Ausbau von 2015 bis 2022

Die digitale Vernetzung von automatisch arbeitenden Amateurfunkstellen auf Basis des TCP/IP-Protokolls hat eine lange Geschichte.

Bereits im Jahre 1970 hat Hank Magnuski den Klasse A Adressblock 44.0.0.0/8 (<nowiki>http://www.ampr.org</nowiki>) zugewiesen bekommen. Bei der IANA (Internet Assigned Numbers Authority, <nowiki>http://www.iana.org</nowiki>) wird dieser Adressblock als „Amateur Radio Digital Communications“ aufgeführt (<nowiki>http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml</nowiki>). Seit einer langen Zeit verwaltet Brian Kantor, WB6CYT, das Netz.

Das „Network 44“ wird auch als „AMPRNet“ bezeichnet. Diese Abkürzung steht für „AMateur Packet Radio Network“ und ist von der Terminologie her an die Betriebsart Packet Radio gebunden. Mittlerweile geht die Nutzung des „Network 44“ aber weit über die Betriebsart Packet Radio hinaus. Daher kann auch das HAMNET ein Teil des AMPRNet sein.

Bei dem Aufbau des Packet Radio Netzes in Deutschland wurde von Anfang an mit der Übertragung von TCP/IP-Paketen über AX.25 experimentiert. Der geschätzte Höhepunkt der Aktivität war Mitte der 90er Jahre und brachte zuletzt das sogenannte „HamWeb“ hervor. Viele Betreiber von Packet Radio Knoten hatten sich entschlossen, auch TCP/IP-Dienste wie HTTP anzubieten. Die Nutzer konnten so im „HamWeb“ surfen.

Im Laufe der Jahre haben die Anzahl der Medien und die verfügbaren Informationskanäle stark zugenommen. Die Attraktivität mit langsamen TCP/IP-über-AX.25-Verbindungen Informationen auszutauschen ging nach und nach verloren. Heute ist es zu einer der vielen Nischen im Amateurfunk geworden.

Im folgenden nun eine Übersicht der Anfänge des HAMNET-Projekts in Südtirol bis heute (wird laufend aktualisiert)

== Projektverlauf 2008 ==
Unzählige Stunden an Vorbereitungen und Testläufe in '''Meran (Mut), Völlan, Bozen (Gantkofel), Auer''' mit verschiedenstem WiFi-Equipement und in kleinstem Kreise: '''IW3BRC, IW3AMQ, IW3BWH'''

== Projektverlauf 2009 ==

=== Juli ===
2009-07-18: Marco IW2OHX, der nazionale IP-Koordinator, erteilt dem Hamnet-Projekt in der italienischen Provinz Bozen/Trient die nötige Zuweisung von 3 öffentlichen Subnetzen aus dem AMPR-Netz (44.134.0.0/16 ↔ ampr.org).

=== Ende 2009 ===
Inbetriebnahme des ersten Interlink IR3UGM<>OE7XGR sowie der Hamnet-Strecke Gantkofel-Marling.

== Projektverlauf 2010 ==

=== Februar ===
2010-02-16: Erste brauchbare AXIP-Verbindung via Hamnet zwischen '''IW3BRC in Meran''' (Italien) und der PR-Mailbox von '''OE2XZR in Salzburg''' (Österreich).

=== März ===
2010-03-28: Erste erfolgreiche Mumble-Session (VoIP) via Hamnet zwischen IW3BRC (Tobias) in Meran und OE7FMI (Markus) in Mayrhofen im Zillertal. Die VoIP-Konversation wurde dabei von einem Mumble-Server in Oberösterreich vermittelt.

=== April ===
2010-04-10: Erster Test einer 5GHz-Useranbindung im Raum Meran war erfolgreich.

Nun können im Raum Meran/Burggrafenamt weitere Anbindungen erfolgen.

=== Juni ===
2010-06-12: Weitere 5GHz-Useranbindung im Raum Bozen erfolgreich getestet.

Nun können auch dort registrierte User an HAMNET teilnehmen.

=== Juli ===
2010-07-03: Hamnet wurde am '''Rittner Horn''' montiert und die Verbindung zum Gantkofel hergestellt.

Dieser Standort wird künftig ein weiterer lokaler Grossverteiler von Hamnet für den Südtiroler Raum darstellen.

2010-07-31: Ein erster konkreter Dienst (sog. Service) nimmt über Hamnet testweise seinen Dienst auf.

Es handelt sich dabei um einen '''Packet Radio Digipeater''' der „neuen“ Generation, der einerseits noch einen klassischen 1k2 PR-Einstieg auf 144.925 MHz bietet und andererseits bereits das Hamnet als High-Speed-Interlink zwischen Bozen (IR3UGM - Gantkofel) und Zillertal (OE7XGR - Gefrorene Wand) verwendet, um darüber im „Huckepack“-Verfahren AX25-Pakete zu transportieren.

Darüber hinaus kann auch über Hamnet selbst dieser Einstiegsknoten in voller Wifi-Geschwindigkeit genutzt werden.

=== August ===
2010-08-10: Ein weiterer Meilenstein im Hamnet-Projekt wurde am Rittner Horn gelegt: Die '''Verbindung zur Marmolada''' konnte erfolgreich hergestellt werden mit -70db.

== Projektverlauf 2011 ==
Generalüberholung und Vorbereitung von IR3EB „Piz Chavalatsch“ fürs HAMNET.

Gleiches für die neuen Hamnet-Standorte „Seceda Nord“ und „Gitschberg“. Auch hier musste erst das Equipement organisiert und vor Ort gebracht werden. Am Ende der Saison konnte '''IR3EB erfolgreich ans Hamnet angebunden''' werden.

== Projektverlauf 2012 ==

=== März ===
2012-03-31: Hamnet-Einsatz Marmolada, um einen weiteren Interlink '''IR3AO<>OE8XDR''' (Dobratsch) zu aktivieren.

=== April ===
2012-04-11: Kontaktaufnahme mit den Hamnet-Kollegen in HB9 - momentan leider (noch) keine Anbindungsmöglichkeiten vorhanden.

2012-04-14: Integration der neuen Linkstrecken ins Hamnet, soweit möglich - bei der neuen Linkstrecke IR3AO<>IR3UHF scheint ein HW-Schaden offensichtlich.

2012-04-26: Erörterung/Planung der weiteren Bedarfslisten und Einsätze für die Hamnet-Saison 2012.

=== Mai ===
2012-05-09: Dokumentationsplattform ins Leben gerufen - <nowiki>http://hamnet.cisarbz.org</nowiki> oder <nowiki>http://hamnet.drc.bz</nowiki>

2012-05-18: Echtzeit-Monitoring aktiviert - <nowiki>http://hammon.iw3brc.net</nowiki>

=== Juli ===
2012-07-07: Erneuter Einsatz Marmolada, um defekte Hamnet-Antenne samt Board zu wechseln und die Linkstrecke Kronplatz (IR3DV) vorzubereiten.

2012-07-08: Hamnet-Einsatz Gitschberg (IR3UHI), wobei auch dort eine defekte Hamnet-Antenne Richtung Kronplatz (IR3DV) ersetzt werden musste.

=== September ===
2012-09-08: Dritter Hamnet-Einsatz Marmolada, um Blitzschaden am gesamten Umsetzerstandort zu beheben.

Folgende Linkstrecken konnten dabei reaktiviert bzw. neu aktiviert werden:

IR3AO <> IR3UHF läuft nun wieder wie gehabt -75 dBi

IR3AO <> IR3DV konnte zusätzlich aktiviert werden -73 dBi

IR3AO <> OE8XDR-2 wartet auf die Gegenseite

IR3AO <> IR3UDZ schwächelt noch ein wenig, Gegenseite muss kontrolliert werden

=== Oktober ===
2012-10-13: Flori (DL8MBT) bastelt eine Software zur Verwaltung von Standorten und IP-Adressen, u.a. findet sich darin auch das AS64600 wieder.

Hamnet IP Database: <nowiki>http://hamnetdb.net</nowiki>

Mirror South Tyrol: <nowiki>http://hamnetdb.iw3brc.net</nowiki>

=== November ===
2012-11-30: HAMMON <nowiki>http://hammon.iw3brc.net</nowiki> wird geupdatet und mit Verknüpfungen zur neuen IP-Dokumentation und zu weiteren Realtimedaten erweitert.

== Projektverlauf 2013 ==

=== erstes Halbjahr 2013 ===
Softwareseitige Optimierungen an den bestehenden Strukturen IR3UHE, IR3UGM, IR3UHF, IR3EB, IR3AO, IR3DV, IR3UHI

=== Juli ===
2013-07-12: Vorbereitung eines weiteren Hamnetknotens am '''Schludernser Berg IR3UBE''' für die Verbindung zu IR3EB.

2013-07-14: Erste Aktivierung von AllstarLink auf den Knoten IR3UGM Gantkofel und IR3DV Kronplatz. Weitere Infos unter [Http://drc.bz/wordpress/link-sudtirol-gantkofel-und-kronplatz-in-betrieb/ http://drc.bz/wordpress/link-sudtirol-gantkofel-und-kronplatz-in-betrieb/]

=== August ===
2013-08-10: Aktivierung des Hamnet-Knotens '''IR3UGB''' auf der '''Seceda'''.

2013-08-16: Aktivierung der '''Linkstrecke Piz Chavalatsch (IR3EB) ↔ Schludernser Berg (IR3UBE)''' und weiter bis zu IN3XOZ in Mals.

2013-08-17: Start der 2-Tages-Grossaktion am Piz Chavalatsch mit Hubschraubereinsatz. Verschiedenste Umbau- und Reparaturarbeiten konnten beendet werden.

2013-08-18: Erfolgreiche Reparatur des R6 Vinschgau und Inbetriebnahme des „Südtirol Link“ auf 70cm, der den Piz Chavalatsch mit Gantkofel und Kronplatz via Hamnet und quer durch Südtirol permanent verbindet.

Krönung war dann noch die erfolgreiche Aktivierung einer Foto-Webcam von Flori (DL8MBT) Richtung Ortlermassiv: https://www.foto-webcam.eu/webcam/chavalatsch/

=== September ===
2013-09-28: Aktivierung des Hamnet-Knotens '''IR3UGD''' am '''Jaufenpass''' und gleichzeitige Installation des Link Südtirol an diesem Standort.

== Projektverlauf 2014 ==

=== April ===
2014-04-24: Die ehemalige Gewerbeoberschule (GOB) und jetzige Technologische Fachoberschule (TFO) “Max Valier” in Bozen konnte erfolgreich ans HAMNET angebunden werden.

=== Juli ===
2014-07-11: Am Hamnet-Standort Seceda wird nun erstmals das Signal der '''Zugspitze DB0ZU/70''' empfangen, um es dann an bestimmte Knoten zu nutzen (Gantkofel, Chavalatsch, Kronplatz).

Über den 70cm-Einstieg Gantkofel kann das deutsche Relais bereits erfolgreich gearbeitet werden.

=== August ===
2014-08-03: Der (Hamnet)Standort Rittnerhorn konnte erfolgreich auf den neuen Funkmast des Zivilschutzes migriert werden.

2014-08-23: Am Standort Chavalatsch wurde neben zahlreichen Wartungsarbeiten nun auch der „Link Zugspitze“ aktiviert.

2014-08-30: Der Standort Plose wurde hamnet-technisch erschlossen und mit einem weiteren Einstieg zum „Link Südtirol“ versorgt.

2014-09-30: Am Standort Rittnerhorn IR3UHF wurden die letzten Arbeiten nach dem Umzug auf den neuen Masten erledigt, die bis dato noch offen geblieben waren.

2014-10-04: Der Standort auf der Seceda wird generalüberholt, d.h. die leidigen Linkstrecken wurden nun durch kompakte QRT5 ersetzt, um damit endlich die gewünschte Linkstabilität zu erreichen, nachdem der Standort Marmolada durch erneuten Blitzschaden ausgefallen ist.

== Projektverlauf 2015 ==

=== April ===
2015-04-06: Die Zugspitzanbindung im Pustertal wird vom Kronplatz IR3DV auf den Gitschberg IR3UHI verlegt.

2015-04-28: Der Standort am Schludernser Berg erhält eine neue Linkantenne zu IR3EB und wird ab nun mit zusätzlichem Strom aus Windkraft unterstützt.

=== Mai ===
2015-05-01: Der Standort am Gantkofel IR3UGM erhält ein neues DStar-Interface (UP4DAR).

=== Juni ===
2015-06-14: Inspektions- und Reparatureinsatz am Standort Chavalatsch IR3EB.

== 2017 ==

=== September/Oktober: ===
Nach einem Standortumzug auf der Plose besteht nun Sicht zu '''OE7XGR Gefrorene Wand'''. Damit konnte die Linkstrecke Gantkofel-Gefrorene Wand auf die Plose umgezogen werden. Die Strecke nach OE7 funktioniert nun aufgrund der wesentlich kürzeren Strecke erheblich stabiler.

Außerdem besteht vom neuen Standort Plose auch Sicht zum '''Kronplatz''' und zum '''Gitschberg'''. Somit wurden auch die Standorte Gitschberg und Kronplatz direkt über die Plose angebunden, was insgesamt zu kürzeren Strecken, weniger Hops und somit weniger Ausfallrisiko führt.

== 2018 ==

=== Juli ===
Aktivierung der Verbindung vom Kronplatz zu '''OE7XJH Hollbruck''' in Osttirol

=== Gesamtes Jahr ===
Erneuerung/Einrichtung Userzugänge mit 120° Sektorantennen im 2,3GHz Band auf den Standorten Gantkofel (für den Raum Etschtal/Bozen), Marlinger Berg (Raum Meran), Rittnerhorn (Raum Überetsch/Unterland), Gitschberg (Raum Brixen) und Kronplatz (Raum Bruneck)

=== Dezember ===
Aktivierung Standort '''IR3UFM Schöneben''' im oberen Vinschgau, vorerst noch ohne HAMNET-Anbindung

== 2019 ==

=== September ===
Aktivierung Standort '''IR3UFM Helm''' und Anbindung an '''IR3DV Kronplatz''' (PtMP mit der Antenne richtung Hollbruck)

Später dann wurde auf PTP mit einer eigenen Antenne umgebaut.

== 2020 ==
Durch Aktivierung der Zwischenstation am '''IR3UFL Grauner Berg''' konnte nun auch '''IR3UFM Schöneben''' via Richtfunk ans HAMNET angebunden werden.

== 2021 ==

=== Juli ===
Aktivierung des Standortes '''IR3BC Vigiljoch.''' Von hier aus können nun '''IR3EB Chavalatsch''' und '''IR3UGD Jaufen''' direkt erreicht werden.

Somit ergeben sich auch hier eine Verkürzung der Strecke (Chavalatsch) und insgesamt kürzere netzwerktechnische Wege.

=== Dezember ===
Das gesamte HAMNET in Südtirol wird auf 32-Bit-AS-Nummern umgestellt.

Damit agiert nun jeder Standort routingtechnisch komplett eigenständig und es ist möglich, bei einem Ausfall eines zentralen Knotens in Südtirol - z.B. Rittnerhorn - die HAMNET-Kommunikation zwischen unseren Standorten automatisch über andere Regionen, beispielsweise über OE7 - umzuleiten.

== 2022 ==

=== April ===
Unsere Kollegen in Tirol aktivieren '''OE7XNP Gueser Kopf''' bei Nauders, von wo aus Sicht zu IR3UFM Schöneben besteht.

Mit der aktivierung dieses Links besteht nun ein HAMNET-Kreis zwischen Südtirol und OE7. Zusammen mit den 32-bit-AS-Nummern kann dies auch tatsächlich genutzt werden, falls innerhalb Südtirols wichtige Knoten ausfallen würden.
[[Kategorie:HAMNET]]

PR-Digi mit Direwolf

2025-10-25T07:10:52Z

IN3FQQ: AXUDP Troubleshooting mit Wireshark

Mit recht einfachen Software-Mitteln ist es möglich, eine 'Moderne' Variante eines Packet Radio Digipeaters zu betreiben, welche (abgesehen vom AF-Interface zum Funkgerät) ganz ohne Spezialhardware auskommt.

Im folgenden wird ein Aufbau beschrieben, welcher sowohl einen Multibaud RF-Zugang, als auch einen HAMNET-Zugang über das AXUDP-Protokoll bereitstellen kann.

=== Plattform ===
Als systemtechnische Plattform eignet sich im Grunde ein Mikro-PC ähnlich Raspberry PI, auf welchem ein Linux-Betriebssystem lauffähig ist.

Auf unserem Standort [[Gantkofel IR3UGM]] läuft das in diesem Artikel beschriebene Setup beispielsweise mit einem OrangePi Zero (ARM Cortex A7 CPU mit 512MB RAM), aber es sind natürlich auch andere ARM- oder x86-Basierte Systeme möglich.

Zu beachten ist jedoch, dass - vor allem beim Betrieb von MultiBaud oder generell bei mehreren parallelen Zugängen - die verschiedenen Direwolf-Modems zeitgleich laufen und somit CPU-Last erzeugen.

Etwas schnellere CPUs sind daher vorteilhaft.

=== (Soft)Modem ===
Wo früher Hardware-TNCs ihre Arbeit verrichtet haben, kommen bei moderneren Setups vermehrt Software-Implementierungen zum Einsatz, die sich mittlerweile durchaus mit ihren Hardware-Pendants messen können.

In unserem Setup wird als Software-Modem [https://github.com/wb2osz/direwolf Direwolf] verwendet, mit welchem das Basisband-Signal erzeugt bzw. decodiert werden kann.

Dabei werden mehrere verschiedene Modulationsverfahren/Baudraten unterstützt, unter Anderem:

* '''1200baud AFSK''' (der Klassiker)
* '''2400bps''' nach '''ITU-T V.26b'''
** Sollte mit "klassischen" 1k2 fähigen Funkgeräten (also nur über Lautsprecher/Mikrofon Anschlüsse, ohne Zugang auf den FM-Diskriminator/Modulator) noch machbar sein
** hier wird ebenfalls eine Symbolrate von '''1200 Symbolen/Sekunde''' verwendet, jedoch mit '''4 möglichen Zuständen'''
** Somit können ''log2(4) = '''2''''' '''bit pro Symbol''' übertragen werden
** 1200 Symbole/Sekunde * 2bit/Symbol = '''2400 bit/Sekunde'''
* '''4800bps''' nach '''ITU-T V.27'''
** die Symbolrate beträgt hier '''1600 Symbole/Sekunde'''
** Das Modulationsschema benutzt '''8 mögliche Zustände'''
** Somit ''log2(8) = 3'' bit pro Symbol
** bei 1600Symbolen/Sekunde ergibt das '''4800 bit/Sekunde'''

Für den Multibaud-Betrieb ist eine weitere Eigenheit zu beachten: Direwolf kann jeweils nur ein Modem pro Sound-Interface verwenden.

Man kann sich jedoch eines Tricks des Linux-Audio-Subsystems ALSA bedienen: ALSA unterstützt nämlich '''virtuelle Sound-Interfaces''', welche schlussendlich "gemixt" und auf das gleiche physische Audiogerät ausgegeben werden.

Somit ist es möglich, in der Direwolf-Konfiguration beispielsweise die Modems für 1k2, 2k4 und 4k8 gleichzeitig auf dem gleichen Audio-Interface und somit schlussendlich auf der gleichen QRG zu verwenden.

Für die Anbindung an die PR-Node-Software gilt zu beachten, dass Direwolf nur ein einziges Pseudo-TTY-Gerät anlegen kann. In unserem Fall bräuchten wir nun aber für 3 Modems folglich 3 Stück.

Auch hier bedienen wir uns eines kleinen Tricks, um die vorher definierten Direwolf-Modems anzubinden:

Direwolf unterstützt zwar nur ein einziges Pseudo-TTY-Gerät, wohl aber mehrere TCP-KISS Verbindungen. Mit diesen kann aber unsere PR-Node-Software (X)Net nichts anfangen.

Als Bindeglied dient deshalb das Tool ''udpflex'' aus der dxlAPRS Toolchain, welches sich als '''Bridge''' dazwischenschalten lässt und von '''TCP-KISS''' ins '''AXUDP'''-Protokoll konvertiert, welches in (X)Net problemlos angesprochen werden kann.

Die Port-Konfiguration in unserer Direwolf.conf sieht nun folgendermaßen aus:
KISSPORT 8000 0
KISSPORT 8001 2
KISSPORT 8002 4
.. wobei der erste Wert den zu bindenden TCP-Port definiert, der Zweite steht für den CHANNEL (also das Modem).

Zu beachten: die Channels in Direwolf sind immer STEREO (also immer Paarweise) zu verstehen; somit muss das zweite Modem ''CHANNEL 2'' (das dritte ''CHANNEL 4'' usw.) sein.

Nun starten wir unsere udpflex-Instanzen, welche sich (option <code>-T host:port</code>) mit den verschiedenen TCP-KISS Ports am lokalen Host verbinden und ihrerseits UDP-Ports (option <code>-U host:tx-port:rx-port</code>) am lokalen Host öffnen, wo dann über AXUDP die AX.25 Pakete empfangen/gesendet werden:
# udpflex als TCP-KISS <> AXUDP Bridge fuers Anbinden der drei Direwolf-Modems an XNET
./udpflex -T 127.0.0.1:8000 -U 127.0.0.1:10001:10002 &
./udpflex -T 127.0.0.1:8001 -U 127.0.0.1:10003:10004 &
./udpflex -T 127.0.0.1:8002 -U 127.0.0.1:10005:10006 &
Eine sehr hilfreiche Dokumentation von ''udpflex'' und den anderen Hilfsmitteln aus der dxlAPRS-Toolchain findet sich bei [https://dxlwiki.dl1nux.de/index.php?title=Udpflex dxlwiki.dl1nux.de]

=== Packet-Router (X)Net ===
Als Packet Node Software bzw. Router ist (X)Net im Einsatz. Dieses ist auch auf neueren Plattformen noch Lauffähig.

Die Anbindung zwischen Direwolf und (X)NET erfolgt wie vorher beschrieben über '''AXUDP''', wobei pro Modem (=Baudrate) ein Port konfiguriert wid.

Somit kann von (X)NET aus durch Auswahl des Ports gewählt werden, in welcher Baudrate eine Station via RF kontaktiert werden soll. Auch ''MHeard'' usw. wird dann entsprechend pro Port/Baudrate angezeigt.

Die Attach-Befehle sehen in unserem Fall beispielsweise folgendermaßen aus:
att ip0 axudp 1 1 l10001 d10002 127.0.0.1
att ip1 axudp 2 1 l10003 d10004 127.0.0.1
att ip2 axudp 3 1 l10005 d10006 127.0.0.1
Die TX- und RX-Ports müssen hier natürlich genau invertiert zur ''udpflex''-Konfiguration angegeben werden

=== AXUDP für Userzugang ===
Wenn neben dem Zugang via RF auch ein AXUDP-Zugang angeboten werden soll, braucht es dazu noch einmal einen kleinen Trick:

(X)Net hat einen AXIP/AXUDP Treiber integriert, mit welchem AXUDP Verbindungen zu anderen Nodes gemacht werden können.

Dabei nimmt (X)Net laut Doku aber aus Sicherheitsgründen nur AXUDP Frames an, die '''explizit vom konfigurierten Linkpartner kommen.'''

Wildcards o.Ä. können keine angegeben werden.

Als Workaround ist nach österreichischem Vorbild ''udphub'' aus der dxlAPRS Toolchain vorgeschaltet.

Konfigurationstechnisch stellt (X)Net eine '''AXUDP-Verbindung mit 127.0.0.1 her''' (bei uns beispielsweise über die Ports '''9007''' und '''9008'''), dort lauscht ''udphub''.

Da für (X)Net nun alle Verbindungen "''vom konfigurierten AXUDP-Partner 127.0.0.1 kommen''", ist (X)Net zufrieden.

Diese Lösung hat außerdem noch einen weiteren Vorteil: ''udphub'' merkt sich die IP-Adressen der anrufenden Stationen für eine via Konfigurationsparameter definierbare Zeit und kann somit auch ausgehende Connects machen.

Die Verwendung ist also gleich, wie bei Usern die via RF ankommen würden.

Für Troubleshooting-Zwecke kann ''udphub'' mit der option <code>-w</code> angewiesen werden, einen Log der letzten bekannten AXUDP-Verbindungen (sozusagen den "Switching-Table") in eine Datei (z.B. <code>/tmp/udphub.log</code>) zu schreiben.

# Port fuer AXUDP User-Zugang
USERPORT=10093
# udphub als AXUDP-Switch - Workaround damit XNET AXUDP Calls von Usern entgegennimmt
# udphub merkt sich intern fuer die angegebene Zeitdauer (option -l in Sekunden)
# die IP-Adressen/Ports der AXUDP-User.
# Somit koennen ueber diesen Port auch Stationen connected werden
./udphub -u 127.0.0.1:9007:9008 -l 1440 -p $USERPORT -w /tmp/udphub.log &

Bei einem ausgehenden Connect ist natürlich zu beachten, dass es durchaus passieren könnte, dass der remote Node nach einiger Zeit auf demselben Port '''nicht mehr antwortet'''.

Das passiert beispielsweise, wenn zwischen dem PR-Node und dem zu verbindenden User ein '''NAT dazwischen ist''' - beispielsweise weil das Packet-Gerät im LAN des OMs läuft und bei der Verbindung ins HAMNET mit der 44er IP der HAMNET-Antenne ''geNATted'' wird. In diesem Fall wird die '''NAT-Session''' irgendwann in '''Timeout''' gehen und folglich ein '''Connect von außen nicht mehr funktionieren.'''

In solchen Fällen gilt also: Soll der eigene PR-Node im QTH auch von außen via AXUDP verbindbar sein, dann ist darauf zu achten, dass dieser im idealfall selbst eine 44er IP aus dem HAMNET zugewiesen bekommt.

In diesen Fällen ist es am besten, sich mit einem HAMNET-Sysop zu besprechen.

=== AXUDP Troubleshooting mit Wireshark ===
Um AXUDP-Traffic zu analysieren, eignet sich das bewährte Netzwerkanalysetool Wireshark bestens.

Damit Wireshark die in UDP "Eingekapselten" AX.25 Frames auch als solche decodiert, ist folgende Konfiguration erforderlich (eventuell weitere verwendete Ports sind entsprechend hinzuzufügen):

-- ax25-udp.lua

-- load the udp.port table
udp_table = DissectorTable.get( "udp.port" )

-- get a handle to the AX.25 dissector
proto_ax25 = Dissector.get( "ax25" )

-- register AX.25 to handle udp port
udp_table:add( 10093, proto_ax25 )
udp_table:add( 93, proto_ax25 )
Weitere Dokumentation findet sich in der Wireshark-Dokumentation https://wiki.wireshark.org/AmateurRadioProtocolFamily
[[Kategorie:HAMNET]]
[[Kategorie:Digitaltechnik]]

MMDVM-Relais

2025-09-24T12:59:56Z

IN3FQQ: RSSI Anzeige

Auf allen MMDVM-Relais des DRC ist aktuell (stand September 2025) das folgende MMDVM Modem Board verbaut:

* '''MMDVM_POG''' Board, nach dem Design von SQ6POG
** '''STM32F105RBT''' MCU (ARM Cortex M3, 72MHz Clock, 128kB Flash)
** '''19.2 MHz''' TCXO
** Sallen-Key Butterworth-Tiefpassfilter für RX und TX
** Open-Source Hardware Design
** Hardware-Design: https://github.com/wojciechk8/MMDVM_pog/

Wenn man den verbauten 19,2MHz TCXO durch ein 12MHz-Äquivalent austauscht, ist diversen Berichten zufolge die Firmware der ''Repeater Builder STM32-DVM V2'' Boards (Stand 2025 auch nicht mehr offiziell unterstützt) auf diesen Platinen lauffähig.

=== In-System Flashing Mod ===
Damit die Firmware per remote geflasht werden kann, müssen zwei Verbindungen gelötet werden:
[[Datei:Mmdvm-flashing-mod.png|alternativtext=MMDVM In-System-Flashing-Mod|mini|MMDVM In-System-Flashing-Mod]]

* Raspberry PI '''GPIO 21''' (HW Pin 40, im Bild das Erste oben links) -> '''NRST''' (auf ST-LINK Pin Header, das Pin neben dem Kondensator)
* Raspberry PI '''GPIO 20''' (HW Pin 38, im Bild das Zweite von oben links) -> '''BOOT0''' (JP1 Pin 2), über einen 10kOhm Widerstand

Zum Flashen muss zuerst MMDVMHost gestoppt werden:
systemctl stop mmdvmhost.timer
systemctl stop mmdvmhost
Dann kann mit ''stm32flash'' mit angabe der Pin-Folge (option <code>-i</code>) geflasht werden:
# MMDVM Modem in Flash-Modus bringen (BOOT0 high, NRST low->high)
stm32flash -i 20,-21,21 /dev/ttyAMA0
# Firmware flashen
stm32flash -w mmdvm_pog-fw.hex -g 0x0 -R /dev/ttyAMA0
# MMDVM nochmal via NRST (low->high) resetten
stm32flash -i -21,21 /dev/ttyAMA0

# nun kann MMDVMHost wieder gestartet werden
systemctl start mmdvmhost.timer
systemctl start mmdvmhost

=== MMDVMHost Einstellungen ===
Der Modem-Type ist auf '''STM32-DVM / MMDVM_HS - Raspberry Pi Hat (GPIO)''' zu stellen.

Baudrate ist '''115200'''. Schnellere Baudraten, wie sie beispielsweise für FM oder andere Betriebsarten notwendig sind, schafft der ''STM32F105'' nicht mehr.

=== Kalibrierung ===
Die Kalibrierung der RX und TX-Pegel vom MMDVM passiert in unserem Fall über die einstellung zweier Trimmerpotentiometer, sowie über die digitale Gain-Einstellung.

Zum Kalibrieren wird das Programm MMDVMCal (in PiStar direkt mit pistar-mmdvmcal aufrufbar) verwendet.

Achtung: MMDVMCal startet immer mit den Default-Einstellungen (alle Gain-Level auf 50%, kein TXInvert und kein RXInvert). Außerdem werden die eingestellten Werte '''nicht''' automatisch in die Konfigurationsdatei übernommen! Das muss manuell erledigt werden.

==== TX Kalibrierung ====
Die Pegel für den Sender können durch Auswahl der Funktion <code>D Set DMR Deviation Mode. Generates a 1.2Khz Sinewave. Set radio for 2.75 Khz Deviation</code> eingestellt werden.

Besonders bei DMR ist die Hub-Einstellung kritisch.

Die Einstellung erfolgt mit hilfe eines Spektrum-Analyzers, wobei sich auch ein TinySA oder ein RTL-SDR eignen.

Die Anzeige wird auf die Sendefrequenz zentriert, der angezeigte Bandausschnitt sollte ca 15-20kHz betragen.

Nun wird der Trimmer solange bewegt, bis der Träger (so gut wie möglich) verschwunden ist:
[[Datei:Mmdvm-tx-calibration.png|alternativtext=MMDVM TX-Kalibrierung mit der Bessel-Null-Methode|zentriert|mini|502x502px|MMDVM TX-Kalibrierung mit der Bessel-Null-Methode]]

Für die Feineinstellung kann in MMDVMCal durch die Tasten <code>T</code> und <code>t</code> der TX-Pegel digital in halben Prozentschritten erhöht (''T'') oder verringert (''t'') werden.

Nun hat man ca. einen Hub von 2,88kHz eingestellt. Um zum gewünschten Hub von 2,75kHz zu gelangen, muss der Ermittelte ''TXLevel'' Wert noch mit 95% multipliziert und anschließend in der mmdvmhost-Konfigurationsdatei als ''TXLevel'' abgespeichert werden.

==== RX Kalibrierung ====
Für die Kalibrierung der RX-Pegel gibt es zwei Varianten: die genauere, Messtechnische Variante mit einem Oszilloskop, und alternativ die "Trial and Error"-Methode.

===== "Trial and Error"-Methode =====
MMDVMCal bietet mehrere BER-Testing-Modes, welche entsprechend ein DSTAR/DMR/C4FM Signal erwarten und für jeden empfangenen Datenframe die BER anzeigen.
K/k BER Test Mode (FEC) for D-Star
b BER Test Mode (FEC) for DMR Simplex (CC1)
J BER Test Mode (FEC) for YSF
Nun wird mit einem entsprechenden Digitalfunkgerät ein Signal auf das Relais gegeben und der RX-Trimmer (und somit der NF-Pegel des Empfangssignals) durch ''"testen"'' solange variiert, bis etwas decodiert wird.

Danach wird durch die tasten <code>R</code> und <code>r</code> der RXLevel (also der Gain auf der digitalen Seite) angepasst, bis die angezeigten BER-Werte minimal sind.

Am Ende wird der ermittelte Wert unverändert in der MMDVMHost-Konfigurationsdatei als ''RXLevel'' abgespeichert.

Achtung: Die Einstellung des Trimmers ist der kritische Teil! Wenn das analog anliegende Signal '''über VCC (=3.3V)''' geht und der ADC somit ins '''Clipping''' kommt, hilft jede darauffolgende digitale Gain-Einstellung auch nichts mehr!

===== Messtechnische Methode =====
Mit einem Oszilloskop wird das RX-Signal von einem Testpunkt auf der Platine abgegriffen.

Bei unserem MMDVM-POG Board gibt es dafür den Testpunkt ''TP32'', der sich schaltungstechnisch direkt hinter dem Butterworth-Filter der RX-Eingabe befindet.

Physisch befindet sich der Testpoint ''TP32'' unterhalb der ST-LINK Pins, welche links vom STM32-Prozessor liegen.

Nun wird mit einem RF-Generator bzw. mit einem Funkgerät ein Testsignal auf den Empfänger gegeben und das am Testpunkt ''TP32'' anliegende Signal gemessen.

Ziel ist es, das Signal so einzustellen, dass der ADC nicht übersteuert wird. Das Signal soll also '''nie unter 0V und über 3.3V gehen'''.

Der DC-Offset des Signals sollte genau die Hälfte von VCC, also '''1,65V''' betragen.

Die Amplitude des Signals sollte '''ca. 0,4V bis 0,5V Abstand''' von den beiden Grenzwerten (0V und 3,3V) haben. Das ergibt somit '''ca. 2,3Vpp.'''

Auch wenn nur Rauschen am Empfänger anliegt, sollten die 3,3Vpp nicht überschritten werden.

=== Erweiterte Tests ===
Als nächstes setzt man nun in der MMDVMHost-Konfigurationsdatei in der <code>[Modem]</code> Stanza den Wert <code>Debug=1</code>.

Sobald man nach der Änderung den MMDVMHost neu startet, schreibt dieser nützliche Infos ins Logfile, die zur Bestimmung der RX-Frequenzabweichung und für die Beurteilung des Timing-Drifts und der RX-Pegel nützlich sind.

Hier ein Beispiel einer solchen Logzeile:
M: 2025-09-11 08:08:58.636 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 452 679 631
M: 2025-09-11 08:08:58.696 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 452 646 632
M: 2025-09-11 08:08:58.756 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 452 590 636
M: 2025-09-11 08:08:59.116 Debug: DMRSlotRX: voice terminator found slot/pos/centre/threshold 2 452 425

==== RX Frequenzabweichung ====
Anhand des Wertes ''centre'' kann man feststellen, ob es einen Frequenzversatz beim Empfänger gibt.

Der Wert sollte sich im Idealfall um 0 herum bewegen (Empfänger ist genau auf der Frequenz).

Sollte der Wert größer als 100 sein, muss der RX nachjustiert werden.

Bei der Bewertung dieser Werte ist darauf zu achten, dass das eingegebene Testsignal selbst keinen Frequenzversatz (oder zumindest einen bekannten) hat. Vor allem bei preisgünstigen DMR-Funkgeräten ist durchaus öfters ein Frequenzversatz zu beobachten.

Die besten Ergebnisse würde natürlich ein kalibriertes DMR Test Set liefern, was jedoch bei den wenigsten im Shack stehen wird.

Am besten man testet also einfach mit mehreren Funkgeräten, nach Möglichkeit mit verschiedenen Modellen von verschiedenen Herstellern.

Wenn das Relais bereits eine Weile im Einsatz war, ist auch eine Langzeit-Auswertung über die Logfiles möglich. Dazu einfach den folgenden Befehl verwenden:

<code>grep -i dmrslot /var/log/pistar/MMDVM*.log</code>

==== Timing-Drift ====
Bei längeren DMR-Durchgängen (>180s) kann es vorkommen, dass man eine Veränderung des ''pos''-Werts beobachten kann.

Dies deutet auf einen Timing-Drift hin, der meistens vom TCXO auf der MMDVM-Platine verursacht wird, wenn dieser eine schlechte Frequenzstabilität aufweist.

Hier ein entsprechendes Beispiel (Log-Auszug aus https://github.com/juribeparada/MMDVM_HS/issues/109), bei welchem dieses Problem auftritt:
M: 2019-11-06 16:28:10.529 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 447 26 337
M: 2019-11-06 16:28:10.589 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 447 13 338
M: 2019-11-06 16:28:10.649 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 447 7 341
.......
M: 2019-11-06 16:31:04.891 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 16 345
M: 2019-11-06 16:31:05.251 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 11 344
M: 2019-11-06 16:31:05.611 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 9 348
M: 2019-11-06 16:31:05.971 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 20 370
E: 2019-11-06 16:31:08.326 No reply from the modem for some time, resetting it
M: 2019-11-06 16:31:08.326 Closing the MMDVM
M: 2019-11-06 16:31:10.352 Opening the MMDVM
E: 2019-11-06 16:31:23.169 Unable to read the firmware version after six attempts
Zu beobachten ist, dass der erste Wert (''pos'') mit länger werdendem Durchgang immer weiter sinkt, bis schlussendlich das Modem neu startet.

Wenn das bei mehreren verschiedenen Usern/Geräten auffällt (auch hier gilt: es kann auch am Endgerät des Benutzers liegen!), liegt es vermutlich am TCXO auf dem MMDVM Board.

Ggf. sollte dieser durch ein besseres Äquivalent ausgetauscht werden, z.B. ein 12MHz TCXO von namhaften Herstellern.

Achtung: Wenn der Wert von den originalen 19.2MHz auf 12MHz abgeändert wird, '''muss die Firmware neu compiliert werden!''' In der ''Config.h'' muss entsprechend die Zeile für den 19.2MHz TCXO auskommentiert und dafür das Kommentarzeichen beim 12MHz TCXO entfernt werden.

=== RSSI-Anzeige ===
Damit für empfangene Signale die Signalstärke (''RSSI'', Received Signal Strength Indicator) angezeigt werden kann, muss der verwendete Empfänger über ein RSSI-Pin verfügen, auf welchem je nach Empfangspegel eine Spannung ausgegeben wird.

Als erstes muss ermittelt werden, wie hoch die maximal ausgegebene Spannung am RSSI-Pin des empfängers ist. Das kann entweder aus dem Handbuch des Empfängers ermittelt oder messtechnisch durch anlegen eines starken Pegels, z.B. S9+40 und messen der Spannung am RSSI-Pin geprüft werden.

Danach sollte über einen Spannungsteiler die Spannung so reduziert werden, dass am RSSI-Pin des MMDVM-Boards '''maximal 3,3V''' ankommen.

Danach wird ''MMDVMCal'' gestartet und der ''RSSI Mode'' gewählt.

Nun müssen nacheinander definierte RF-Pegel - beispielsweise von S9+40 bis S1 - angelegt und der auf dem Bildschirm ausgegebene Wert (jeweils ''average'' verwenden) aufgeschrieben werden.

Diese werden anschließend in folgender Form die Datei ''/usr/local/etc/RSSI.dat'' gespeichert:
# WERT SIGNALPEGEL
4094 -73
3912 -83
3364 -93
3159 -99
2900 -105
2670 -111
2388 -117
2131 -123
1943 -129
1851 -135
1820 -141
[[Kategorie:Digitaltechnik]]

2025-09-22T14:10:49Z

IN3FQQ:

mmdvm-flashing-mod

2025-08-22T18:28:16Z

IN3FQQ:

[[Datei:Graunerberg-standort.png|alternativtext=Standort Graunerberg inkl. Installationsteam|mini|398x398px|Standort Graunerberg inkl. Installationsteam]]

== Stromversorgung ==

=== Solarzellen ===

- Leistung: '''140 W'''
- Spannung: '''18 V'''
- Anzahl: '''2'''
- Sicherungen: '''2 x arretrierbare Sicherungen zu 20 A (auf + und auf GND)'''

=== Batterien ===
[[Datei:Graunerberg-batterien.png|links|mini|389x389px|Eigenbau LTO-Batterie am Graunerberg*]]
- Typologie: '''LTO''' (Lithiun Titanat Oxyd)
- Anzahl Zellen: '''10'''
- Nominalspannung Einzelzelle: '''2,3 V'''
- Kapazität Einzelzelle: '''40 Ah'''
- Konfiguration: '''2 Zellen parallel, 5 Zellen serie'''
- Nominalspannung Block: '''11,5 V'''
- Kapazität Block: '''80 Ah'''
- BMS (Batteriemanagementsystem): '''5S2P - 12 V / 80 A'''
- Sicherungen: '''2 x arretrierbare Sicherungen zu 20 A''' (auf + und auf GND)

*Auf dem Label der Batterie im Foto ist fälschlicherweise "'''10S1P'''" angegeben. Richtig ist natürlich '''5S2P'''

=== Laderegler ===
[[Datei:Graunerberg-laderegler.png|mini|326x326px|EPEVER Tracer 2210 Laderegler]]
- Marke: '''EPEVER'''
- Modell: '''Tracer 2210 AN'''
- Max. Strom: '''20 A'''
- Spannung: '''12 V'''
- Leistung: '''260 W'''

=== Spannungsregler ===

- Upconverter: '''8-14 V => 24 V / 8 A'''
- Downconverter: '''24 V => 12 V / 10 A (Webcam)'''
- Downconverter: '''24 V => 5 V / 1,5 A (Raspberry für Solarregler)'''
[[Datei:Graunerberg-blockschaltbild.png|zentriert|mini|466x466px|Blockschaltbild]]

== Hamnet ==

=== Router ===

- Marke: Mikrotik
- Modell: RB750up
- Spannungsversorgung: 24 V
- Portbelegung: siehe Blockschaltbild am Ende der Seite

=== Link Schöneben ===
- Marke: Mikrotik
- Modell: SxtSQ
- Licence level: 4
- Spannungsversorgung: POE via Router
- Installationsort: Hauswand

=== Link Chavalatsch ===
- Marke: Mikrotik
- Modell: QRT5
- Licence level: 4
- Spannungsversorgung: POE via Router
- Installationsort: Hauswand
[[Kategorie:Standorte]]

IN3FQQ:

Der Begriff „'''HAMNET'''“ steht für Highspeed Amateurradio Multimedia Network.

Es handelt sich um ein internationales Projekt zur digitalen Vernetzung von automatisch arbeitenden Amateurfunkstellen. Die gemeinsame Basis des HAMNET ist das TCP/IP-Protokoll unter Verwendung des für Funkamateure zugewiesenen IPv4-Adressbereichs 44.0.0.0/8 (Network 44) und des Routingprotokolls BGP4 (Border Gateway Protokoll), welches auch das Internet zusammenhält.

Das HAMNET ist ein nichtöffentliches Netzwerk (Intranet) mit einem begrenzten Nutzerkreis (Funkamateure). Einzelne Netzsegmente können über das Internet oder WLAN (ISM) verbunden werden. Endnutzer können sich neben direktem Funkzugang auch über öffentliche Netze (z.B. dem Internet) unter Verwendung von Authentifizierungsmechanismen in das HAMNET einwählen. Innerhalb des HAMNET gilt jeder als vertrauenswürdig, so dass keine zusätzliche Authentifizierung erfolgen muss.

=== Weitere Infos ===

* '''HAMNET Datenbank''' mit allen Sites, Richtfunkstrecken und Diensten: https://hamnetdb.net
* Informationsseiten unserer Kollegen der '''IP Koordination DL''': https://de.hamnet.network
* Ansprechpartner in IN3
** Thomas, IW3AMQ (Koordinator)
** Simon, IN3FQQ

Kategorie:HAMNET

2025-08-22T09:33:17Z

IN3FQQ: Die Seite wurde neu angelegt: „Der Begriff „'''HAMNET'''“ steht für Highspeed Amateurradio Multimedia Network. Es handelt sich um ein internationales Projekt zur digitalen Vernetzung von automatisch arbeitenden Amateurfunkstellen. Die gemeinsame Basis des HAMNET ist das TCP/IP-Protokoll unter Verwendung des für Funkamateure zugewiesenen IPv4-Adressbereichs 44.0.0.0/8 (Network 44) und des Routingprotokolls BGP4 (Border Gateway Protokoll), welches auch das Internet zusammenhält.…“