Mastmontage an der Clubstation DL0ROS

Unsere Clubstation wird noch attraktiver.

Nicht nur, dass sie ein neuer Antennenmast ziert, sondern auch für den Funkbetrieb gibt es Neuigkeiten: Ein starker Rotor wird dort bald einen Fritzel FB-33 3-Band-Beam für 10m, 15m und 20m drehen. An der Spitze wird eine Diamond-X6000-Antenne den 2-m- und 70-cm-Betrieb verbessern.
Der nächste Contest wird uns damit gut gelingen.

Unsere OMs Andreas (DH9AT), Stephan (DL3SH), Jörg (DO1HOZ), Richard (DL1RHS) und Holger (DG3CR) haben am Wochenende dafür gesorgt, dass der neue Mast an der Außenwand befestigt werden konnte. Eine Dachöffnung in Giebelnähe und Verankerungen durch die Wand hindurch, ermöglichten so eine sichere und optimale Montage.

Dank an alle engagierten Helfer. Ihr seid eine tolle Bereicherung!

DB0TR/qrp im Testbetrieb

Bestandteil der neuen Hochriestechnik ist ein auf niedrigen Stromverbrauch optimiertes Reserve-Relais DB0TR/qrp. Wie das Call vermuten lässt, verfügt dieses Relais nur über eine begrenzte Ausgangsleistung von 1W / 4W. Das Relais ist nicht wie der große Bruder mit Mobilgeräten, sondern mit Handsprechfunkgeräten der Serie GP340 von Motorola aufgebaut. Es verfügt über alle Möglichkeiten, welche die SvxLink Steuerung bietet, wie EchoLink oder Sprachpapagei. Welche Leistung und welche Dienste wir zukünftig verwenden, werden wir erst nach der Testphase entscheiden.

Die Testphase hat am 19.07.24 begonnen und dauert bis zum 26.07.24. Momentan läuft DB0TR/qrp anstatt DB0TR. Wenn die neue Hochriestechnik installiert ist, planen wir DB0TR/qrp über Nacht zu aktivieren, um Strom zu sparen. Darüber hinaus soll im Falle eines Stromausfalls automatisch auf das stromsparende DB0TR/qrp umgeschaltet werden, damit der Betrieb mit den Akkus möglichst lange aufrecht erhalten werden kann. Wir möchten diesen (Not-) Betrieb für mehrere Tage gewährleisten; Die Akkus werden aus dem Stromnetz nachgeladen. Ein autarker Betrieb ist nicht geplant.

Bitte alle Beobachtungen, Reporte und Hinweise, aber auch Vorschläge und Kommentare dem OV C14 mitteilen.

73 de DH9AT, Andreas

VHF Helix Bandpassfilter

Bei vielen wechselnden Hobbys beobachtet man diverse Bänder nicht immer kontinuierlich und bekommt plötzlich auftretende „Störungen“ im näheren Bandbereich nicht immer sofort mit. Eine Suche nach dem Auslöser gestaltet sich nicht immer leicht.

Nach einer längeren Pause bekam ich durch die Medien mit, dass wieder vermehrt interessante LEO und ein HEO Satelliten ins All geschossen wurden. Schnell in den Keller und das Funkgerät angeschaltet. Aber halt, was war das? Auf dem 2m Band war Nähe der Bandgrenzen ein ziemlich starker Träger zu hören. Mit der X300 Dualband Vertikal kein großes Problem. Allerdings mit der 8 Element Yagi inkl. Vorverstärker war der Träger zu stark und vertopfte den Empfänger.

Da ich den Auslöser in der Nachbarschaft nicht wirklich finden konnte kontaktierte ich die BNetzA, diese konnte den Störer lokalisieren. Allerdings hat die BNetzA keine Handhabe mehr, sofern der Besitzer des störenden Gerätes nicht kooperativ ist. Es musste also eine Lösung her um die Situation etwas zu verbessern.

Nach ein paar Tagen Recherche bin auf den VHF Bandpassfilter von Z33T gestoßen.

Über diesen Filter gibt es sehr viele erfolgreiche Bauberichte und Videos.

Ein Nachbau sollte somit also auch für den „Nicht-Profi-HF-Techniker“ möglich sein. Ein NanoVNA v2 war schon vorhanden. Somit besorgte ich ein entsprechendes Gehäuse, 2x N-Einbaubuchsen, Platinenmaterial (für den Kondensator) sowie Elektrokabel und es konnte losgehen.

Anbei ein paar Bilder vom Bau:

Nachdem der Bau abgeschlossen war wurde der Filter mit dem MiniVNA v2 ausgemessen und live getestet:

Fazit:

Das Störsignal ist jetzt deutlich schwächer und Satellitensignale können jetzt wieder viel besser „gelesen“ werden.

Schon alleine wegen der Bastelarbeit hat sich das Projekt für mich gelohnt.

73 de Patrick / DF2CA

Umbauarbeiten am Relaisstandort Hochries

Liebe Funkfreunde,

ab Freitag dem 31.03.2023, beginnt das Technikteam des OV C14 mit den Reparatur- und Umbauarbeiten am Relaisstandort Hochries. Es werden zuerst Arbeiten am FM-Repeater DB0TR durchgeführt. Eine teilweise Abschaltung des HAMNET und der Webseite charly14.de ist vom 30.03. bis 01.04.2023 notwendig. Wir bitten um etwas Geduld. Die erforderlichen Umbauarbeiten werden sich sicher bis zum Sommer hinziehen, kurzfristige zeitlich begrenzte Abschaltungen sind dazu nötig.

hier eine noch kleine Übersicht des HAMNET am Relaisstandort:

Wir bitten um Geduld. Uns kostet der Umbau bzw. Neubau vieler Sachen viel Geld, Spenden werden gerne angenommen.

73 es 55

Klaus, DL8MEW

Wie komme ich über die Hochries ins HAMNET?

Liebe Funkfreunde,

wir möchten Euch hier eine Hilfestellung für den Weg ins Rosenheimer HAMNET geben.

Es ist möglichst freie Sicht zu Hochries erforderlich.
Als Hardware ist zum Beispiel ein QRT 5 der Firma Mikrotik geeignet, aber auch andere kommerzielle 5 GHz WLAN Hardware wie der Mikrotik SXTsq 5 oder Nanostation/Nanobeam der Fa. Ubiquiti.

Der Router ist in ein Antennengehäuse mit Antenne integriert und kann über PoE (Power over Ethernet) direkt über ein Netzwerkkabel mit Strom versorgt werden. Es ist nur ein Netzwerkkabel zu einem Computer mit dem POE-Einspeise-Adater notwendig.

Beispielkonfiguration für Mikrotik QRT 5

Die erforderlichen Einstellungen in der Konfiguration des QRT 5 für den Zugang Hochries-Nord sind hier aufgeführt.

Hier die Befehle für eine Standardkonfiguration die in einem Terminal auf dem Mikrotik RouterOS ausgeführt werden müssen

In dem Beispiel wird der HAMNET Zugang Hochries-Nord verwendet, der auf 5695 MHz mit 10 MHz Bandbreite und MIMO arbeitet. Der Zugang deckt den Großraum Rosenheim Stadt ab.

Der Router stellt auf der LAN-Buchse einen DHCP-Server mit Adressbereich 192.168.73.2-254 zur Verfügung, d.h. angeschlossene Geräte (z.B. Laptop) erhalten hier automatische eine IP-Adresse.
Hinweis: Diese Konfiguration ist nicht für eine Integration ins Heimnetz (z.B. Anschluss an die FritzBox) geeignet, sondern nur als Standalone/Insellösung.

Das CALL muss mit dem eigenen Rufzeichen ersetzt werden (Erfüllung der Forderung des regelmäßigen Aussenden des Rufzeichens zur Identifikation).

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n channel-width=10mhz country=\
no_country_set disabled=no frequency=5695 frequency-mode=superchannel mode=\
station-bridge radio-name=CALL ssid=DB0HOB-ACCESS-NORD station-roaming=\
enabled wireless-protocol=802.11
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_pool0 ranges=192.168.73.2-192.168.73.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=ether1 name=dhcp1
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=192.168.73.1/24 interface=ether1 network=192.168.73.0
/ip dhcp-client
add disabled=no interface=wlan1
/ip dhcp-server network
add address=192.168.73.0/24 gateway=192.168.73.1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add distance=1 dst-address=44.142.0.0/17 gateway=wlan1
add distance=1 dst-address=44.148.0.0/17 gateway=wlan1
add distance=1 dst-address=44.160.0.0/17 gateway=wlan1
/system identity
set name=CALL-QRT5

Weitere Infos zum HAMNET Standort Hochries DB0HOB gibt es in der hamnetdb

Viel Spass im HAMNET

Chris, DL1COM und Klaus, DL8MEW

Update HAMNET Userzugänge

Beim letzten Hochries Arbeitseinsatz wurde ein weiterer QRT5 als Userzugang für den Raum Rosenheim installiert.

Zudem wurden die Frequenzen für den Userzugang auf den Access Points harmonisiert, da mittlerweile davon ausgegangen kann dass das ATV Relais durch den Einsatz eines entsprechenden Filters nicht gestört wird.

Somit ergeben sich aktuell folgende Userzugänge, weitere Infos wie gewohnt auf hamnetdb.net

ArtSSIDStandortZugang
Userzugang Hochries-WestDB0HOB-ACCESS-WESTRosenheim / Hochries5695 MHz, 10 MHz
Userzugang Hochries-West2DB0HOB-ACCESS-WEST2Rosenheim / Hochries5805 MHz, 10 MHz
Userzugang Hochries-NordDB0HOB-ACCESS-NORDRosenheim / Hochries5695 MHz, 10 MHz
Userzugang Hochries-OstDB0HOB-ACCESS-OSTRosenheim / Hochries5695 MHz, 10 MHz

SvxLink Teil III – weitere Konfiguration

Um Einstellungen am Verhalten von SvxLink vorzunehmen die über die Möglichkeiten die die svxlink.conf bzw. die Konfigurationsdateien der Module hinaus gehen, gibt es noch eine weitere Art von Dateien: die TCL Skripte.

Diese Dateien beschreiben das Verhalten von SvxLink bei so gut wie allen Events die im Repeater vorkommen. Daher kann man durch Änderung der mitgelieferten Dateien das Verhalten von SvxLink sehr detailliert steuern.

Um die Originaldateien nicht abändern zu müssen (z.B. weil sie bei einem Update wieder überschrieben werden würden), gibt es bei SvxLink das sogenannte „locale“ Konzept. Das bedeutet dass abgeänderte Dateien in einem Unterordner namens „locale“ abgelegt werden. Existiert dieser Ordner und entsprechende Dateien in ihm, so werden diese verwendet – ansonsten die Originaldateien.

Für unsere Installation haben wir bisher zwei Anpassungen an tcl Dateien vorgenommen: Um die Zwischenmeldung des Repeaters innerhalb des Sprecherwechsels zu unterbinden und um die Zeitansage auf deutsche Grammatik anzupassen.

Zwischenmeldung unterbinden

cd /usr/local/share/svxlink/events.d/
mkdir local
cd local
cp ../RepeaterLogic.tcl ./

In dieser Datei ./local/RepeaterLogic.tcl müssen in der Funktion „repeater_down“ folgende Zeilen durch voranstellen eines # auskommentiert werden:

#  spellWord $mycall;
#  playMsg "Core" "repeater";
#  playSilence 250;

Deutsche Grammatik für Zeitansagen

Um der deutschen Aussprache von Zahlen Rechnung zu tragen (z.B. einundzwanzig statt zwanzig-eins) muss auch hier eine Datei angepasst werden.
Hierzu wird unter /usr/share/svxlink/sounds/de_DE/events.d/local/locale.tcl folgender Inhalt abgelegt: https://gist.githubusercontent.com/unixweb/b808ba6d17905d253345efa9cdfbe52b/raw/02fdeb34dafcc36d0071ea4dca1eee8e0f6e57b7/locale.tcl

Um Änderungen an diesen Dateien wirksam zu machen, muss SvxLink neu gestartet werden.

SvxLink Teil II – weitere Konfiguration

Wie im ersten Teil angekündigt werde ich in diesem Beitrag beschreiben wie man das Raspberry Dateisystem in einen „read-only“ Modus versetzt. Der Grund hierfür: Durch das Schreiben von Logdateien etc. „verschleißt“ die SD-Karte, denn Flash-Speicherzellen haben eine endliche Anzahl von Schreibzyklen bei der sie zuverlässig arbeiten. Danach kann es zu defekten Dateien bis hin zu einem nicht mehr funktionierendem Dateisystem kommen.

Um dem entgegenzuwirken, wird das komplette Dateisystem schreibgeschützt, da wir in der Regel während des Betriebs keine Dateien persistent auf der Speicherkarte ablegen wollen. Alle Dateien die zur Laufzeit beschrieben werden müssen, werden in eine sogenannte Ramdisk gelegt, also in ein Dateisystem das im Arbeitsspeicher lebt.
Dies bedeutet aber auch, dass all diese Dateien bei einem Neustart verloren sind.
Will man solche Dateien (z.B. Logdateien) für den Fall eines unvorhergesehenen Events (Absturz, Stromausfall) sichern, muss man sich selber darum kümmern diese Datei von Zeit zu Zeit entweder lokal oder remote zu sichern.

Ich habe mich für das Einrichten des read-only Dateisystems recht nah an diesem Blogbeitrag auf Hamspirit.de orientiert. Hier aber nochmal in meinen Worten bzw. mit meinen Kommentaren:

Entfernen von nicht mehr benötigten Diensten

Zuerst entfernen wir Dienstprogramme, die wir in einem read-only Dateisystem nicht mehr benötigen, bzw. die in einem read-only Dateisystem nicht mehr funktionieren.
Für unsere Anwendung sind diese allerdings auch nicht notwendig.

sudo apt-get remove --purge logrotate triggerhappy dphys-swapfile fake-hwclock samba-common
sudo apt-get autoremove --purge

Ummappen von Systemverzeichnissen nach /tmp

Einige Programme wollen zur Laufzeit in Dateien schreiben. Diese leiten wir nun nach /tmp um, damit diese auch im read-only Dateisystem einen beschreibbaren Ort haben.

sudo rm -rf /var/lib/dhcp/ /var/spool /var/lock
sudo ln -s /tmp /var/lib/dhcp
sudo ln -s /tmp /var/spool
sudo ln -s /tmp /var/lock
sudo mv /etc/resolv.conf /tmp/
sudo ln -s /tmp/resolv.conf /etc/resolv.conf

Einstellungen in der Partitionstabelle

Nun bearbeiten wir /etc/fstab und setzen die boot und root Partitionen auf read-only („ro“) und erzeugen drei tmpfs Partitionen.
Die hervorgehobenen Anteile müsst ihr in die Datei eintragen, der Rest sollte schon vorhanden sein (die PARTUUID unterscheidet sich auf jedem System)

proc /proc proc defaults 0 0
PARTUUID=d8cc668c-01 /boot vfat ro,defaults 0 2
PARTUUID=d8cc668c-02 / ext4 ro,defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
tmpfs /var/log tmpfs nodev,nosuid 0 0
tmpfs /var/tmp tmpfs nodev,nosuid 0 0
tmpfs /tmp tmpfs nodev,nosuid 0 0

Nun aktivieren wir noch fastboot (wir haben kein beschreibbares Dateisystem und sparen uns somit fsck) und noswap (wir haben kein beschreibbares Dateisystem wo man hinswappen könnte) in der Datei /boot/cmdline.txt.

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait fastboot noswap

Alias für rw und ro

Nach einem Neustart würde man nun in einem read-only Dateisystem landen. Um das Dateisystem beschreibbar zu machen, kann man den Befehl sudo mount -o remount,rw / ; sudo mount -o remount,rw /boot nutzen.
Das kann man mit einem bash alias etwas eleganter machen (wie man es eventuell von Pi-Star kennt).

Wir fügen folgendes an die Datei /etc/bash.bashrc an:

set_bash_prompt(){
fs_mode=$(mount | sed -n -e "s/^\/dev\/.* on \/ .*(\(r[w|o]\).*/\1/p")
PS1='\[\033[01;32m\]\u@\h${fs_mode:+($fs_mode)}\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
}

alias ro='sudo mount -o remount,ro / ; sudo mount -o remount,ro /boot'
alias rw='sudo mount -o remount,rw / ; sudo mount -o remount,rw /boot'

PROMPT_COMMAND=set_bash_prompt

Nachdem man sich neu eingeloggt hat, wird nun in der Kommandozeile angezeigt, ob das Dateisystem aktuell schreibbar ist oder nicht (rw / ro). Mit den Befehlen rw und ro kann nun zwischen den beiden Zuständen gewechselt werden.
Will man nun z.B. die svxlink.conf bearbeiten, muss man vorher in den rw Modus wechseln und danach auch wieder in ro.

Besonderheiten

Zeitsynchronisation

Die der Standarddienst zur Zeitsynchronisation über Netzwerk systemd-timesyncd ist ebenfalls auf beschreibbare Dateien angewiesen, deren Zielorte wir mit obigen Kommandos allerdings nicht nicht abgedeckt haben. Es sind folgende Änderungen notwendig um den Service weiterhin nutzen zu können.
In /lib/systemd/system/systemd-timesyncd.service müssen folgende Zeilen auskommentiert bzw. geändert werden:

#CapabilityBoundingSet=CAP_SYS_TIME
#PrivateTmp=yes
StateDirectory=

Nach dem Ändern der Datei muss sie mit sudo systemctl daemon-reload neu eingelesen werden. Nach einem Neustart sollte der Dienst seinen Dienst aufnehmen.

Cronjobs

Was wir nun vermissen werden, ist das Dienstprogramm cron. cron legt Dateien werden in /var/spool/crontab abgelegt, was nun auf /tmp gemappt ist und somit beim Reboot verloren geht.
Lösung: Wir können unsere Cronjobs auch einfach in /etc/crontab ablegen.
Dort habe ich nun die Cron calls für die Telemetrie (Temperatur- und Lüftersensor) abgelegt – weitere Infos dazu in einem der nächsten Artikel!

Im nächsten Beitrag werde ich beschreiben welche Anpassungen ich noch an der Konfiguration von svxlink vorgenommen habe, die über die reine Anpassung der Konfigurationsdatei hinausgehen.

Neubau von DB0TR und DB0FHR

Aufbau im 19 Zoll 2HE Rack

In letzter Zeit war der Betrieb von DB0TR von vielen Problemen und Ausfällen gekennzeichnet. Ganz zum Ärger vieler OMs, da dieses Hochries Relais einen recht großen Einzugsbereich hat.

Nach vielen Reparaturen und Verbesserungsversuchen haben wir uns letztlich zu einem Neubau mit professionellen Funkgeräten von Motorola entschlossen. Bei der Gelegenheit wollten wir auch gleich einige Funktionen wie Temperaturüberwachung der PA und ein SvxLink Modul mit Echolink implementieren.

Im Aufmacherfoto sieht man die Anordnung der einzelnen Komponenten. Diese sind nicht willkürlich, sondern genau durchdacht angeordnet. Die beiden Motorola Geräte (ein Gerät arbeitet im RX Betrieb, während das zweite beim Auftasten den TX Betrieb aufnimmt) sind völlig identisch programmiert. So kann man im Falle eines Defektes die beiden Geräte tauschen und so relativ kurzfristig wieder die Funktion herstellen. Wir hoffen natürlich, daß das nicht notwendig sein wird.

Direkt am Lüfter ist das TX-Gerät angeordnet, da dieses die größte Wärme erzeugt und so direkt mit kalter Frischluft angeblasen wird. Das RX-Gerät entwickelt keine Wärme und die entweichende Luft streicht noch über den Raspberry bevor es über die Bohrungen in der Rückwand wieder das Gerät verlässt.

Oben ist DB0FHR abgebildet, DB0TR ist völlig identisch aufgebaut. Es ist noch eine Stromspar-Variante für DB0TR mit 2 Handfunkgeräten geplant. Dazu mehr im nächsten Artikel.

Andreas, DH9AT

WordPress Appliance - Powered by TurnKey Linux