Blogger Auto Poster: Aus einem Workspace automatisch Blogposts vorbereiten

Blogger Auto Poster

Zweck

Dieses Projekt ist entstanden, um aus vielen vorhandenen lokalen Projekten automatisch strukturierte Markdown-Dateien zu machen und daraus eine Blogger-Queue für klautesblog.blogspot.com aufzubauen. Die Dateien sollen nicht direkt blind veröffentlicht werden, sondern zuerst als geparkte Markdown-Posts im Backlog vorliegen. Danach kann ein Linux-Server in einem festen Intervall jeweils den nächsten Post aus der aktiven Queue hochladen.

Das eigentliche Ziel ist nicht nur ein Upload-Script. Der wichtige Teil ist der Workflow davor: Ein Workspace wird rekursiv analysiert, Projekte werden fachlich eingeordnet, uninteressante Dateien werden ausgeschlossen, relevante Projekte bekommen Story, Ziel, Labels und ein sauberes Markdown-Format.

Ausgangslage

In meinem Entwicklungsordner lagen viele kleine und größere Projekte: Smart-Home-Energiemanagement, Aquarium-Technik, Amateurfunk-Hardware, Homebridge-Integrationen, ESP32/ESP8266-Hacks, alte Software-Fixes und Tabletop-/Mordheim-Material.

Viele dieser Projekte waren technisch interessant, aber nicht direkt als Blogpost nutzbar. Es fehlte eine einheitliche Struktur:

• Was war das Problem?
• Warum wurde das Projekt angefangen?
• Was war das konkrete Ziel?
• Welche Hardware und Software gehören dazu?
• Ist das Projekt wirklich postbar?
• Welche Labels passen später in Blogger?
• Welche Dateien sollen ignoriert werden?

Grundidee

Der Ablauf besteht aus zwei getrennten Schritten:

1. Codex analysiert den Workspace und erzeugt Markdown-Dokumentation.
2. Der Blogger Auto Poster nimmt freigegebene Markdown-Dateien und lädt sie in festen Intervallen zu Blogger hoch.

Diese Trennung ist wichtig. Die Analyse darf ruhig interaktiv sein, weil Projektkontext oft nur im Kopf vorhanden ist. Der Upload soll dagegen langweilig und deterministisch laufen.

Prompt 1: Workspace rekursiv analysieren

Der erste Prompt beschreibt den Analyseauftrag. Er soll nicht sofort posten und auch keine Projektdateien verändern, sondern nur Dokumentation erzeugen.

Analysiere den aktuell geöffneten Workspace rekursiv.

Ziel:
- Finde alle relevanten Projekte.
- Erstelle pro Projekt eine Markdown-Datei im Ordner output/.
- Ändere keine bestehenden Projektdateien.
- Poste nichts automatisch.
- Beschreibe Zweck, Hardware, Software, Aufbau, Build, Konfiguration,
  Verwendung, Schnittstellen, Stolpersteine und offene Punkte.
- Kennzeichne Unsicherheiten klar.
- Dokumentiere keine Secrets, Tokens, privaten IPs oder Passwörter.

Damit entsteht zuerst eine technische Rohdokumentation. Sie ist noch kein fertiger Blogpost, aber sie macht sichtbar, welche Projekte es überhaupt gibt.

Prompt 2: Projekte fachlich bewerten

Danach folgt die Frage, welche Dateien für einen Blog interessant sind. Dabei geht es nicht um perfekte Texte, sondern um eine harte Vorauswahl.

Prüfe alle erzeugten Markdown-Dateien.

Ziel:
- Welche Dateien sind als einzige Posts auf klautesblog.blogspot.com interessant?
- Welche passen zu einem technischen Blog?
- Welche sind eher nicht interessant?
- Nichts posten und nichts extern ändern.
- Liste klar auf, welche Dateien passen und welche nicht.
- Die Story dahinter darf noch fehlen; das ist ein eigener Schritt.

Dieser Schritt trennt technische Artefakte von echten Blog-Kandidaten.

Prompt 3: Upstream-Projekte und Quellen prüfen

Viele kleine Projekte basieren auf fremden GitHub-Repositories, Schaltplänen, YouTube-Videos oder bestehenden Bibliotheken. Das muss sauber in die Dokumentation.

Prüfe bei welchen Projekten ein bestehendes Projekt eines anderen
auf GitHub oder eine andere externe Quelle als Basis genommen wurde.

Wenn das in der Dokumentation fehlt:
- Ergänze einen Hinweis auf Basis/Upstream.
- Mache klar, was eigenes Projekt ist und was nicht.
- Verlinke das Original, wenn es erkennbar ist.
- Ändere nur die erzeugten Dokumentationsdateien.

Das ist wichtig, weil ein Blogpost sonst schnell so wirkt, als sei alles komplett selbst entwickelt worden.

Prompt 4: Entstehung und Ziel interaktiv ergänzen

Die technische Analyse allein reicht nicht. Ein Projekt wird erst durch die Entstehungsgeschichte interessant.

Frage mich zu jedem relevanten Projekt:
- Warum habe ich dieses Projekt angefangen?
- Welches konkrete Problem sollte gelöst werden?
- Was war das Ziel?
- Was ist das Ergebnis oder der aktuelle Status?

Füge diese Angaben in die jeweilige Markdown-Datei im output-Ordner ein.

Ein Beispiel dafür ist PowerMgr.

Beispiel: PowerMgr

Die reine Codeanalyse erkennt ein Python-/Docker-Projekt für Energiemanagement. Der wichtige Blogwert steckt aber in der Geschichte dahinter:

• Es sollte ein Energiemanagement entstehen, das vorhandene Geräte weiter nutzt.
• Eingebunden wurden unter anderem StecaGrid-PV-Wechselrichter, Zimmermann Proxon FTW-2, Shelly-Geräte, DIY-Wetterstation, OpenWeather, ESP32-Geräte und EVCC.io.
• Angebote von Ingenieurbüros lagen bei etwa 15.000 bis 25.000 EUR für einen Umbau des Hauses.
• Das eigene System bindet einen Victron Multiplus ein.
• Ergebnis: etwa 50 Prozent weniger Stromkosten und etwa 70 Prozent Eigenverbrauch der PV-Erzeugung.

Aus einer technischen Datei wird dadurch ein nachvollziehbarer Artikel: Problem, Eigenbau, Integration, Ergebnis.

Prompt 5: Ignorierte Projekte verschieben

Nicht alles soll in die Blogqueue. Manche Projekte waren nur Tests, Sackgassen oder reine Fremdsoftware.

Alles, was ich als "ignorieren" markiert habe,
verschiebe in output/ignore.

Diese Dateien sollen erhalten bleiben, aber nicht als Blogpost-Kandidaten gelten.

Im Auto-Poster bleibt dieser Mechanismus erhalten: posts/queue/ignore/ wird vom Upload-Script übersprungen.

Prompt 6: Neues Auto-Poster-Projekt erzeugen

Aus der analysierten Dokumentation wurde danach ein eigenes Projekt gebaut.

Erstelle ein neues Projekt für einen Blogger Auto Poster.

Anforderungen:
- Dockerfile
- docker-compose.yml
- Upload-Script
- Config-Datei für Blogger und Input-Ordner
- Shared Input-Folder im Docker Compose Setup
- Post-Intervall in der Config
- Bereits erledigte Markdown-Dateien nach done/ verschieben
- output-Ordner in das neue Projekt verschieben und umbenennen
- Neues Git-Repository initialisieren
- Markdown-Dateien mit Labels und sauberem Post-Format vorbereiten

Das Ergebnis ist dieses Repository.

Umsetzung im Projekt

Aus dem ersten Upload-Script ist inzwischen ein kleines, klar getrenntes Tooling-Projekt geworden. Die wichtigste Änderung ist die Aufteilung nach Verantwortlichkeiten: Benutzereingabe, Markdown-Logik, Blogger-API, lokale State-Datei, Zeitplanung und Docker-Runtime liegen nicht mehr vermischt in einem Script.

Der nachbaubare Stand des Tools liegt öffentlich auf GitHub: klaute/blogger-auto-poster.

Dieses öffentliche Repository enthält nur das Tooling, eine Beispielkonfiguration, einen neutralen Beispielpost und die Setup-Anleitung. Die echten Blogpost-Entwürfe, lokale State-Dateien, OAuth-Konfigurationen und Tokens bleiben im privaten Arbeitsverzeichnis.

Die aktuelle Projektstruktur sieht so aus:

config/
  config.example.yml
posts/
  queue/
    backlog/
    ignore/
  done/
  failed/
  order.txt
scripts/
  update-venv.sh
  load-venv.sh
  get_blogger_token.py
  extract-refresh-key.py
  diagnose-oauth-config.py
  manage-posts.py
  build-and-verify.sh
  test-blogger-config.sh
src/
  config.py
  markdown_posts.py
  state.py
  scheduling.py
  notifications.py
  blogger_api.py
  posting_runtime.py
  post_management.py
  blogger_auto_poster.py
  prepare_posts.py
Dockerfile
docker-compose.yml
requirements.txt

Die Aufteilung ist bewusst pragmatisch:

• scripts/manage-posts.py ist nur die interaktive Bedienung.
• src/markdown_posts.py kennt Markdown, Frontmatter, Labels und HTML-Erzeugung.
• src/blogger_api.py kapselt OAuth und Blogger-API-Aufrufe.
• src/posting_runtime.py enthält den automatischen Posting-Zyklus.
• src/post_management.py enthält manuelle Aktionen wie aktualisieren, offline nehmen oder veröffentlichen.
• src/state.py verwaltet die lokale Tracking-Datei.
• src/notifications.py kümmert sich um Pushover.
• src/blogger_auto_poster.py ist nur noch der CLI-Einstieg für den Container und Kompatibilitäts-Exports.

Markdown-Queue

posts/queue/ enthält die aktiven Markdown-Dateien, die der Server verarbeiten darf. posts/queue/backlog/ enthält geparkte Entwürfe, die der Server ignoriert, die aber vom Management-Script bewusst ausgewählt werden können. posts/queue/ignore/ enthält Dateien, die erhalten bleiben, aber nicht automatisch gepostet werden.

Jede Markdown-Datei hat Frontmatter:

---
title: "PowerMgr"
labels:
  - Smart Home
  - Energie
  - PV
---

Die Freigabe ist absichtlich einfach und erfolgt über Ordner:

• posts/queue/: aktiv, darf vom Server verarbeitet werden.
• posts/queue/backlog/: geparkt, wird vom Server nicht automatisch verarbeitet, kann aber vom Management-Script ausgewählt werden.
• posts/queue/ignore/: ignoriert oder Rohmaterial.

Nach erfolgreichem Upload wandert die Datei nach posts/done/. Fehlerhafte Dateien, die nicht gelesen werden können, wandern nach posts/failed/. Der lokale Upload-Status wird zusätzlich in posts/state.json gespeichert.

Wichtig ist die Trennung zwischen lokaler Datei und Blogger-Post: posts/done/ bedeutet nur, dass die Markdown-Datei lokal bereits verarbeitet wurde. Der Eintrag kann mit einem Blogger-Post verknüpft sein, muss es aber nicht mehr sein, wenn der Post auf Blogger gelöscht wurde oder nicht mehr auffindbar ist.

Labels

Labels werden direkt in die Markdown-Dateien geschrieben. Dadurch ist jede Datei für sich vollständig. Das Upload-Script muss nicht raten, welcher Post welche Kategorien braucht.

Die Config enthält keine Label-Regeln. Bestehende Labels können über das Management-Script aus Blogger als Referenz gelesen werden. Vor echten Blogger-Schreibzugriffen gleicht das Tool die Schreibweise der lokalen Labels mit den vorhandenen Blogger-Labels ab. Neue Labels sind erlaubt, werden aber im Log als neu ausgewiesen.

Zusätzlich haben automatisch erzeugte Dateien das Label KI generiert. Damit bleibt im Blog nachvollziehbar, welche Artikel aus diesem Dokumentationsworkflow stammen.

Upload-Zyklus

Der Auto-Poster läuft im Container. In der Config steht das Intervall:

posting:
  interval_seconds: 604800

604800 Sekunden sind eine Woche. Wenn ein Post fällig ist, nimmt das Script die nächste Datei direkt aus posts/queue, wandelt Markdown nach HTML, setzt Titel und Labels und legt den Post über die Blogger API an. Die Reihenfolge kommt aus posts/order.txt; Dateien, die dort nicht stehen, folgen alphabetisch nach Dateiname.

Dabei wird ein unsichtbarer Tracking-Kommentar in den Blogger-Post geschrieben. Dadurch kann das Tool einen vorhandenen Blogger-Post später wiederfinden und aktualisieren, statt versehentlich einen zweiten Post zu erzeugen.

Sicherheitsmodus

Initial ist der Auto-Poster auf Dry-Run gestellt:

posting:
  dry_run: true
  publish_mode: "draft"

So kann man prüfen, welcher Post als nächstes hochgeladen würde, ohne Blogger zu verändern. Für den echten Betrieb wird dry_run auf false gesetzt. publish_mode: draft ist die vorsichtige Variante, weil Blogger dann nur Entwürfe erzeugt.

Für geplante Veröffentlichung gibt es zusätzlich:

posting:
  dry_run: false
  due_mode: "weekly_schedule"
  publish_mode: "scheduled"
  schedule:
    weekday: "friday"
    time: "09:00"
    timezone: "Europe/Berlin"

Damit prüft der Container regelmäßig die Queue, startet echte Uploads aber nur am eingestellten Wochentag zur eingestellten Uhrzeit.

Blogger OAuth

Der Auto-Poster loggt sich nicht mit Benutzername und Passwort bei Blogger ein. Er nutzt die offizielle Blogger API über Google OAuth 2.0.

Die lokale Einrichtung besteht aus drei Teilen:

• credentials.json: OAuth-Client-Datei aus Google Cloud, bleibt lokal und wird nicht committed.
• config/config.yml: lokale Runtime-Config mit Blog-ID, Client-ID, Client-Secret und Refresh-Token.
• config/config.example.yml: versioniertes Beispiel ohne echte Secrets.

Der wichtigste Stolperstein war der Unterschied zwischen Authorization Code und Refresh Token. Die Callback-URL aus dem Browser enthält einen temporären code=... Wert. Dieser Code gehört nicht in die Config. Er muss erst gegen einen echten Refresh Token getauscht werden.

Dafür gibt es zwei Helper:

scripts/get_blogger_token.py
scripts/extract-refresh-key.py

get_blogger_token.py ist der normale Weg, wenn der Browser auf demselben System geöffnet werden kann. extract-refresh-key.py ist für den Server-Fall gedacht: Die Google-Login-URL kann auf einem anderen Rechner geöffnet werden, die komplette Callback-URL wird danach in das Script kopiert. Das Script tauscht den Code gegen einen Refresh Token und aktualisiert die lokale Config.

Zur Prüfung gibt es:

scripts/test-blogger-config.sh --software
scripts/test-blogger-config.sh --oauth
scripts/test-blogger-config.sh --blogger-draft

Der Software-Test prüft die Modulstruktur, Python-Syntax, CLI-Einstiegspunkte und den manuellen Update-Pfad ohne Blogger-Schreibzugriff.

Der Draft-Test erzeugt einen temporären Blogger-Entwurf, prüft die API-Antwort und löscht den Entwurf danach wieder. Er lädt keinen Markdown-Artikel aus der Queue hoch. Wenn das erfolgreich ist, funktionieren Token, Scope, Blog-ID und Schreibrechte.

Lokale Python-Umgebung

Für lokale Python-Scripte gibt es ein venv-Setup:

scripts/update-venv.sh
. scripts/load-venv.sh

update-venv.sh baut .venv neu auf, installiert requirements.txt und prüft die lokalen Python-Einstiegspunkte. load-venv.sh muss mit führendem Punkt geladen werden, weil ein normales Shell-Script die aufrufende Shell nicht dauerhaft aktivieren kann.

Pushover Benachrichtigungen

Der Auto-Poster kann vor echten Blogger-Schreibzugriffen und bei Fehlern Pushover-Nachrichten senden. Dabei wird nicht direkt die Pushover-API aus dem Container angesprochen, sondern der interne Pushover-Proxy aus dem eigenen Pushover-Server-Projekt.

Die Config sieht dafür vereinfacht so aus:

notifications:
  pushover:
    enabled: true
    host: "pushover-app-server"
    port: 8090
    mode: "get"
    token: "PUSHOVER_APP_TOKEN"
    app_name: "Blogger Auto Poster"
    dedupe_prefix: "blogger-auto-poster"

Das entspricht dem vorhandenen Pushover-Proxy-Vertrag: ein HTTP-Aufruf auf /send mit Token, Titel, Nachricht und optionalem dedupe_key. Der Dedupe-Key verhindert doppelte Nachrichten bei wiederholten Tests oder Retry-Situationen.

Benachrichtigt wird unter anderem bei:

• echtem Uploadversuch als Draft, Live-Post oder geplanter Post
• Update eines bestehenden Blogger-Posts
• Fehler im Posting-Zyklus
• fehlgeschlagenem Blogger-Draft-Test
• nicht lesbarer Markdown-Datei, die nach failed verschoben wurde

Auch Pushover wird über das Testscript geprüft:

scripts/test-blogger-config.sh --pushover

Ohne Parameter führt das Testscript den kompletten Check aus: Container vorhanden, Dry-Run, OAuth, Pushover und temporärer Blogger-Draft.

Management-Script

Für den normalen Betrieb reicht der Container. Für manuelle Arbeit an der Queue gibt es zusätzlich ein interaktives Management-Script:

scripts/manage-posts.py --config config/config.yml

Das Script listet die verfügbaren Markdown-Dateien aus posts/queue und posts/done mit Titel und Labels. Dateien im Backlog bleiben absichtlich unsichtbar, damit geparkte Entwürfe nicht versehentlich hochgeladen werden.

Bei done Dateien zeigt das Script zusätzlich, ob der lokale Artikel linked oder not linked ist. linked bedeutet: In posts/state.json ist eine Blogger-Post-ID bekannt. not linked bedeutet: Die Markdown-Datei liegt zwar lokal in done, aber das Tool kennt keinen aktuellen Blogger-Post dazu.

Danach können die wichtigsten Wartungsaktionen direkt ausgeführt werden:

1. Einen ausgewählten Queue-, Backlog- oder Done-Post mit dem konfigurierten publish_mode hochladen oder aktualisieren.
2. Einen Blogger-Post offline nehmen, also zurück auf Draft setzen, ohne ihn zu löschen.
3. Einen Blogger-Draft direkt veröffentlichen.
4. Einen bestehenden Blogger-Post jetzt aktualisieren.
5. Blogger-Status und die Verknüpfung lokale Datei -> Blogger post id anzeigen.
6. Die aktuell auf Blogger vorhandenen Labels anzeigen.
7. Einen Backlog-Post nur aktivieren, aber noch nicht hochladen.
8. Einen bereits erkannten Blogger-Post löschen.

Die Aktionen zum Offline-Schalten, Veröffentlichen, Aktualisieren, Statusanzeigen und Löschen brauchen eine bestehende Blogger-Verknüpfung. Ein not linked Artikel kann dafür nicht verwendet werden, weil keine Blogger-Post-ID vorhanden ist. Für einen neuen Upload eines not linked Artikels ist Aktion 1 zuständig.

Aktion 1 ist der normale Weg für neue Uploads, Reuploads und Updates. Das Script zeigt aktive Queue-Dateien, Done-Dateien mit oder ohne Blogger-Verknüpfung und Backlog-Dateien an. Eine verknüpfte Done-Datei wird direkt als bestehender Blogger-Post aktualisiert. Eine nicht verknüpfte Done-Datei wird als neuer Blogger-Post hochgeladen und danach neu in posts/state.json verknüpft. Eine Backlog-Datei wird zuerst auf Blogger geschrieben. Wenn es bereits eine lokale Blogger-Verknüpfung für diese Quelle gibt, wird der bestehende Blogger-Post aktualisiert. Erst nach erfolgreichem Blogger-Write wird eine gleichnamige lokale Datei aus posts/done/ nach posts/done/archive/ archiviert und die Backlog-Datei nach posts/done/ verschoben. Wenn die lokal gespeicherte Blogger-ID auf Blogger nicht mehr existiert und Blogger 404 zurückgibt, erstellt Aktion 1 den Post neu und speichert die neue Blogger-ID.

Aktion 7 ist nur noch für den Sonderfall gedacht, dass ein Backlog-Artikel zwar in die aktive Queue verschoben werden soll, aber der Upload später durch den Server oder einen separaten manuellen Lauf passieren soll.

Wenn derselbe Artikel lokal in mehreren Ordnern liegt, gruppiert Aktion 1 diese Kopien über die source_id und zeigt nur die aktive Kopie an. Die Reihenfolge ist posts/queue/, dann posts/queue/backlog/, dann verknüpfte Dateien aus posts/done/. Dadurch verdeckt eine ältere Done-Kopie nicht mehr eine neuere Backlog-Bearbeitung.

Beim lokalen Aufruf übersetzt das Management-Script die Docker-Pfade aus der Config automatisch auf das Repository: /data/queue wird zu posts/queue, /data/done zu posts/done und /data/state.json zu posts/state.json. Damit kann dieselbe config/config.yml für Container und Host-Wartung verwendet werden. Wenn die Config-Pfade bewusst unverändert genutzt werden sollen, gibt es dafür --use-config-paths.

Damit muss man für typische Betriebsfälle keinen API-Aufruf von Hand bauen und keine Markdown-Datei manuell zwischen Backlog, Queue und Done kopieren. Ein gelöschter oder not linked Artikel wird über Aktion 1 aus dem Backlog neu aktiviert und hochgeladen.

Build, Start und Test

Der Server-Betrieb läuft über docker-compose:

scripts/build-and-verify.sh

Das Script baut das Image, startet den Container und führt einen sicheren Dry-Run aus.

Wenn der Container läuft, prüft das Post-Start-Testscript die Installation:

scripts/test-blogger-config.sh --all

Die Ausgabe ist als Checkliste aufgebaut: Preflight, Software-Selbsttest, Dry-Run, OAuth, Pushover und temporärer Blogger-Draft. Am Ende gibt es eine kompakte PASS/SKIP/FAIL-Zusammenfassung.

Warum das nützlich ist

Der größte Vorteil ist nicht die Automatisierung an sich. Der Vorteil ist, dass viele alte Projekte wieder sichtbar werden. Statt in alten Ordnern zu verschwinden, bekommen sie eine einheitliche Struktur, passende Labels und eine klare Entscheidung: aktiv posten, im Backlog parken oder ignorieren.

So kann aus einem gewachsenen Entwicklungsordner schrittweise ein technisches Blogarchiv entstehen.

Ein kleines Update

Es ist inzwischen einige Jahre her, seit hier der letzte Artikel erschienen ist.

In dieser Zeit ist allerdings keineswegs weniger passiert – eher das Gegenteil. Statt Blogbeiträge zu schreiben, habe ich einen großen Teil meiner Freizeit in neue Hard- und Softwareprojekte investiert. Seit dem letzten Beitrag sind insgesamt 33 neue Projekte entstanden, von Embedded-Systemen über Home Automation und Energie-Management bis hin zu Elektronik, Linux, Python und KI-gestützten Werkzeugen.

Dabei habe ich gemerkt, dass klassische Blogartikel für mich nicht mehr die richtige Form sind. Sie benötigen viel Zeit, werden schnell unvollständig und sind oft schon wieder veraltet, bevor sie fertig sind. 

Deshalb wird sich dieser Blog verändern.

Fokus auf Projektdokumentation Künftig werde ich hier keine klassischen Artikel mehr veröffentlichen. Stattdessen werde ich nach und nach die Dokumentationen meiner Projekte bereitstellen.

Der Schwerpunkt liegt dabei nicht auf Marketing oder Hochglanz-Artikeln, sondern auf einer möglichst sachlichen Beschreibung:

• Welches Problem sollte gelöst werden? 
• Welche Hardware kam zum Einsatz?
• Welche Software wurde entwickelt?
• Welche Schwierigkeiten gab es?
• Welche Erkenntnisse haben sich ergeben?

Ich hoffe, dass diese Dokumentationen anderen Bastlern, Entwicklern oder einfach Interessierten nützlich sein können.

Ein Experiment

Ein weiterer Grund für diesen Wechsel ist "KI".

Die Dokumentationen werden größtenteils von einer KI aus meinem Quellcode, meinen Notizen und den Projektdaten erstellt. Inhaltlich stammen sie selbstverständlich aus meinen Projekten, die eigentliche Dokumentation wird jedoch automatisiert erzeugt.

Mich interessiert, wie gut KI komplexe technische Projekte über die kommenden Jahre dokumentieren kann und wie sich diese Fähigkeiten weiterentwickeln. Dieser Blog wird damit gleichzeitig auch zu einer kleinen Langzeitbeobachtung dieser Entwicklung.

Was als Nächstes kommt

Die vorhandenen 33 Projekte werde ich nach und nach veröffentlichen.

Vermutlich nicht in chronologischer Reihenfolge, sondern immer dann, wenn die jeweilige Dokumentation fertig ist. Vielleicht entstehen irgendwann auch wieder klassische Artikel. Im Moment möchte ich meine Zeit jedoch lieber in neue Projekte investieren als in lange Blogtexte.

UpConverter fixed

Vor einiger Zeit berichtete ich darüber das mein Versuch einen UpConverter für mein rad1o zu bauen leider fehlgeschlagen ist. Es lag an der Filterung der Eingangssignale - das Thema kann man hier nachlesen.

Mir ist es "heute" gelungen die Schaltung erfolgreich in Betrieb zu nehmen.

Der Testaufbau ist für meine Messungen identisch zum letzten mal gewesen. Mein rad1o empfängt die Signale, die Software gqrx verwende ich um diese zu visualisieren. Mein SWRMeter erzeugt die Testsignale.

Da ich die Tests und den Aufbau bereits detailliert beschrieben habe konzentriere ich mich in diesem Beitrag nur auf die Änderungen.

UpConverter:

Ich habe den Ausgangsfilter am ADE-1 von meinem letzten Versuch (RC-Glied mit 100pF und 14,5Ohm) durch einen 220nF Kondensator ersetzt.

Das Ergebnis sieht damit deutlich besser aus!

Vorher:

	Schalter auf Beipass		Schalter auf UpConvert
	+0 MHz	+110 MHz	+0 MHz	+110 MHz
Verstärkung	0 dB	-30 dB	-30 dB	-20 dB

Nachher:

	Schalter auf Beipass		Schalter auf UpConvert
	+0 MHz	+110 MHz	+0 MHz	+110 MHz
Verstärkung	0 dB	-15 dB	-30 dB	0 dB

Damit steht dem Empfang auf Kurzwelle mit dem rad1o nichts mehr im Weg.

#UpConverter Debugging results

Die letzen Tage habe ich damit verbracht meine UpConverter-Schaltung in Betrieb zu nehmen. Leider war der erste Test ernüchternd. Immerhin hat das Umschalten per Wechselschalter auf die Stellung "Überbrücken" direkt funktioniert. Bei der restlichen Schaltung war ich mir zunächst unsicher was hier überhaupt funktioniert. Im Grunde genommen habe ich für den ersten Test auch keine spezifische Umgebung geschaffen sondern die Platine einfach an mein rad1o angeschlossen und die ersten Empfangsversuche vorgenommen. Mit der Schalterstellung welche die UpConverter-Funktionalität der Platine überbrückt konnte ich direkt diverse QSO empfangen, darunter einige die per CW (Morsen) geführt wurden.

Nach dem umschalten auf den eigentlichen Betriebsmodus waren diese Signale dann nicht mehr im Spektrum meines SDR zu erkennen. Der Filter am Ausgang des Mixers scheint also offensichtlich zu funktionieren, ein erster Erfolg. Im Frequenzspektrum 110 MHz höher sollte darauf hin jedoch zu erkennen sein dass die Signale vom Mixer korrekt umgesetzt werden. Hier ist von den zuvor empfangenen Signalen jedoch nichts zu sehen gewesen. Diverse Messungen mit dem Oszilloskop und dem Multimeter ergaben mir jedoch keine Erkenntnisse die das Verhalten erklären würden. Zurück auf Überbrückung geschaltet waren die Signale auch wieder auf der Ursprungsfrequenz vorhanden.

Es musste zunächst eine definierte Testumgebung eingerichtet und ein Plan für einen ordentlichen Test aufgestellt werden.
Mein Plan war es nun also ein fixes Signal in den UpConverter einzuspeisen und daraufhin mit der SDR-Software das Verhalten weiterhin zu beobachten. Als Signalgenerator für das benötigte Signal habe ich mein SWRMeter verwendet. Dieses ist in der Lage Signale/Frequenzen im Bereich von 800 kHz bis zu 160 MHz zu erzeugen, was den Gewünschten Kurzwellenbereich vollständig und darüber hinaus abdeckt. Im folgenden Bild ist der Aufbau der Komponenten zu sehen.

Rad1o, UpConverter, SWRMeter

Das SWRMeter gibt während den Messungen ein Signal im Frequenzbereich der Kurzwelle aus. Das Signal verändert über die Zeit die Frequenz und wird direkt in den UpConverter eingespeist. Das verhalten des Signals kann dann, wie bereits beschrieben, per SDR-Software beobachtet werden. Für eine Bewertung der Funktionalität wird in diesem Schritt hauptsächlich die Differenz der Signalstärke - in dB über dem Grundrauschen - aus dem Frequenzspektrum abgelesen. Die tatsächliche Signalstärke ist bei den Tests nicht relevant, da diese nicht mit den Signalen vergleichbar ist welche ich bisher empfangen habe.

Das folgende Video zeigt die eine Messung exemplarisch. Eine Messung der Dämpfung des Schalters werde ich bei Gelegenheit noch nachreichen, sofern diese relevant wird.

Die folgenden Erkenntnisse sind aus den Messungen hervorgegangen:

	Schalter auf Beipass		Schalter auf UpConvert
	+0 MHz	+110 MHz	+0 MHz	+110 MHz
Verstärkung	0 dB	-30 dB	-30 dB	-20 dB

Von der ersten Spalte abgesehen sind ausschließlich negative Werte in der Tabelle enthalten. Eigentlich muss man bei diesen Werten eher von einer Dämpfung (Abschwächung) als von einer Verstärkung reden.
Die dB-Angaben sind nicht 100% genau, zeigen jedoch deutlich warum in den oberen Frequenzen (+110 MHz) bei Aktivierung des UpConverters keine Signale aus den originalen Frequenzbereichen zu sehen sind.
Selbst wenn in der SDR-Software die Verstärkung auf mehr als 30 dB einstellen würde wird dies nicht funktionieren, da das rad1o quasi kein Signal mehr aus dem Rauschen heraus aufnimmt. Das originale Eingangssignal ist nicht mehr messbar/vorhanden.

Bei der Verwendung des UpConverters und im originalen Frequenzbereich ist das Signal sogar um 30 dB geringer - 1000-mal kleiner als zuvor. Diese Eigenschaft können wir jedoch als positiv ansehen, da der Frequenzbereich unterhalb von 110 MHz nicht weiter benötigt wird und nur Störungen erzeugen würde.

Auch positiv zu sehen ist das das Test-Signal auf der neuen Frequenz ebenfalls zu sehen. Es wurde jedoch um 20 dB abgeschwächt, was einem 100ten Teil der vorherigen Signalstärke entspricht. Daher konnten die sehr schwachen Signale der QSOs auch nicht gesehen werden da die Eingangspegel weit unter 20 dB über dem Rauschen lagen - sofern die Anzeige von GQRX korrekt ist...

Auch zu vermuten ist das auch im Beipass-Modus wohl eine Kopplung des Eingangssignals in die UpConverter-Schaltung, als auch wieder auf das Ausgangssignal, stattfindet. Dies kann man durch das im oberen Frequenzbereich (+110 MHz) sichtbare Test-Signal zumindest vermuten. Es sollte dort nicht sichtbar sein.

Die Frage ist nun wie ich an dieser Stelle weiter vorgehen kann!?

Zum einen könnte ich die Qualität der Schaltung versuchen zu verbessern um die Dämpfung von 20 dB auf einen deutlich besseren Wert zu bekommen und zum anderen ggfls. einen Vorverstärker verwenden welcher die Dämpfung ausgleicht.
Alternativ könnte ich auch eine noch bessere Antennen bauen und diese im Freien und großer Höhe aufhängen, damit der Empfang deutlich verbessert werden würde. Noch habe ich hier aber keine Entscheidung getroffen.

Ergebnis: Die Schaltung an sich ist funktionstüchtig, wenn auch mit der unvorteilhaften Eigenschaft - der enormen Dämpfung von etwa 20 -30 dB. Verwenden kann ich sie so nur leider (noch) nicht.

#UpConverter für das #rad1obadge

Mein Rad1o-Badge vom CCC lag nun bestimmt mehr als ein Jahr lang in der Schublade. Es handelt sich dabei um ein SDR, also ein Funkgerät welches komplett per Software bedient wird. Empfangsfrequenz, Übertragungsrate zum Rechner als auch Leistungsverstärkung oder auch Bandbreite des Eingangsfilters wird komplett vom PC aus festgelegt. Software für die Bedienung gibt es einige verschiedene, ich verwende beispielsweise GQRX. Alternativ kann man auch #SDR verwenden. Mehr Informationen zum Rad1o gibt es übrigens hier.

Das hört sich nun erstmal sehr gut an, im Detail gibt es mit diesem Gerät jedoch ein Problem. Der Frequenzbereich den dass SDR empfangen kann bewegt sich im Bereich von 40 MHz bis 4 GHz. Damit sind nur die Frequenzbänder des Amateurfunks in Deutschland ab 6m (50,08 MHz) bis einschließlich 9cm (3,475) abgedeckt. Jetzt umfasst der Amateurfunk - welchen man in Deutschland auch ohne Amateurfunklizenz empfangen darf - noch weitere Frequenzbänder. Die aus meiner Sicht spannenderen Bänder befinden sich allesamt unterhalb der minimalen Frequenz die das rad1o empfangen kann - 40 MHz. Eine Übersicht über die Frequenzbänder des Amateurfunks in Deutschland kann man hier entnehmen.

Nun ist es zwar möglich in der Software wie GQRX die Limitierung der Hardware zu ignorieren (no limits Checkbox), was zum einen Schäden an der Hardware hinterlassen könnte und zum anderen einfach nicht so gut funktioniert da die Hardware und die eingesetzten Filter nicht auf die Frequenzbereiche abgestimmt sind. Per Software kann man dann noch die Eingangssignale allesamt stark verstärken lassen, was dann aber in fast jedem Fall zu einer extremen Übersteuerung führt. In der Regel habe ich auf diese Weise noch kein SSB-Signal verstehen können und auch mit den Digimodes gibt es größere Probleme.

Ich kann dennoch einige Erfolge mit dieser Betriebsweise des rad1o verzeichnen, so ist es mir beispielsweise möglich gewesen von N6PEQ ein QSO - welches mit Kanada über RTTY geführt wurde - zu empfangen. Alleine N6PEQ ist von meinem privaten Standort 9426 km entfernt (USA - Los Angeles). Und wenn man sich überlegt das meine Antenne eine im Wohnzimmer aufgehängte Groundplane war - ausgelegt für das 2m Band - dann wird die Tatsache des Empfangs immer unwahrscheinlicher. Beeindruckend - jedenfalls für mich!

Es sind also Erfolge zu erzielen, aber insgesamt ist das Empfangsgerät trotzdem nicht optimal ausgenutzt wenn man es ständig im undefinierten oder gar vollständig übersteuerten Modus betreibt.

Um die Frequenzen unterhalb von 40 MHz optimal empfangen zu können (den Kurzwellenbereich) benötigt man im ersten Schritt eine gut abgestimmte Antenne. Meine Groundplane ist für 2m abgestimmt. Also für 144 MHz bis 146 MHz was offensichtlich nicht passt.

Meine zweite Antenne ist eine MagnetLoop-Antenne, welche auf die Frequenzen von 2,5 MHz bis etwa 19 MHz abgestimmt werden kann. Sie ist für die unteren Frequenzen der Kurzwelle deutlich besser geeignet. Kurz: Mit dieser Antenne wird die Anzahl der Eingehenden Funksignale sowie deren Eingangspegel bereits deutlich besser.

Dennoch muss ich das rad1o weiter außerhalb seines Frequenzbereiches betreiben. Auf die Details beim Aufbau oder beim Kauf einer Antenne gehe ich an dieser Stelle nicht ein da man sich auch hierbei schnell im Detail verlieren kann.

Um nun aber das Problem mit dem Frequenzbereich in den Griff zu bekommen, genauer gesagt den Kurzwellenbereich mit dem rad1o sinnvoll empfangen zu können, gibt es eine Lösung. Man verwendet entweder einen Transverter oder einen UpConverter.

Ein Transverter ist wie auch der UpConverter ein Gerät welches man zwischen Antenne und Empfangsgerät in die Zuleitung einsetzt. Der Transverter setzt eingehende und ausgehende Signale von einer Frequenz auf eine andere um.

Das bedeutet das zum Beispiel das 40m Band (7 - 7,2 MHz) um eine definierte Frequenz nach oben verschoben wird. Also zum Beispiel von 7 MHz auf 107 MHz sofern die 100 MHz der Frequenz zweiten Frequenz entspricht.

Damit bewegt sich das zu empfangene Signal durch diese Verschiebung im normalen Arbeitsbereich des rad1o und kann ohne spezielle Einstellungen direkt empfangen werden. Jetzt könnte man auch statt 100 MHz nur 40 MHz verwenden, was uns aber mehr Probleme beim herausfiltern unerwünschter Signale bereiten würde.

Ein UpConverter realisiert diese Frequenzumsetzung quasi identisch. Der Unterschied zwischen UpConverter und Transverter ist dass der UpConverter nur in Empfangsrichtung funktioniert. Mit dem Transverter findet auch eine Anpassung der Sendefrequenz nach unten statt, so dass Funksprüche vom Funkgerät aus auf z.B. 107 MHz gesendet werden - tatsächlich aber auf 7 MHz ausgesendet werden.

Bild Schema

Die technischen Details halten sich für den UpConverter sehr in Grenzen (siehe Schema im vorherigen Bild). Eigentlich besteht dieser nur aus einem Eingangsfilter an den die Antenne angeschlossen ist. Dann aus einem Oszillator welcher einem die neue Mindestfrequenz erzeugt. Und einem Mixer der einem auf den Empfangs-Frequenzbereich die Frequenz des Oszillators aufaddiert. In meiner Schaltung ist die minimale Eingangsfrequenz bedingt durch den Mixer auf 0,5 MHz limitiert. Der Eingangsfilter filtert alle Eingangssignale oberhalb von ~60 MHz heraus. Dies hat den Vorteil das auch lokale FM-Sender die schwächeren Eingangssignale nicht überlagern.

Da ich auch für den UpConverter nicht unbedingt das Rad/die Schaltung neu erfinden wollte habe ich mich mit meiner Schaltung stark an ein anderes Projekt angelehnt. Dort ist die Umsetzung recht umfangreich beschrieben. Aufgrund der Umstände bei der Organisation mancher Bauteile habe ich ein paar Teile ersetzen müssen. Die schwierig zu beschaffenden oder unnötig teure Teile habe ich wieder in China bestellt.

Die unverschämte Einstellung deutscher Webshops/Firmen zum einen Versandkosten in der Höhe von um die 7 € zu verlangen (für einen Brief) und zum anderen für Bauteile welche sie ebenfalls aus China beziehen/in China fertigen lassen den 10-20 fachen Preis zu verlangen will ich - zumindest privat - nicht unterstützen. Mein Mixer aus China mit gleicher Güte kostet 70 Euro-Cent inkl. Versandkosten, und in Deutschland bestellt wäre dieser insgesamt bei etwa 14€.

Den Aufbau der Schaltung habe ich in diesem kurzen Video auf YouTube dargestellt. Dort ist zu sehen das ich auch dieses Mal wieder eine Lochrasterplatine verwende.

Die Spulen habe ich wie in der originalen Anleitung beschrieben von Hand gewickelt. Dazu wickelt man jeweils 0,8mm dicken Kupferlackdraht mit je 8 Windungen auf einen 6mm dicken Körper und berechnet die Länge der Spule un Abhängigkeit zur gewünschten Induktivität.

l = µ * n^2 * (A / L)

Wobei ich als Wert für µ 1nH eingesetzt habe und für L die Induktivitäten von 151nH, 143nH und 141nH eingesetzt habe.

Sofern verfügbar kann man die Abstimmung der Spulen mit einem Messgerät durchführen. Der Autor des Originalprojekts schreibt dazu jedoch dass es aber auch mit der einfachen Wicklung der Spule getan sein kann, da sie gut genug sind so wie man sie gewickelt hat.

Nun ja... lieber einmal mehr gemessen als an dieser Stelle an der Qualität der Schaltung Zeit gespart aber ohne entsprechendes Messgerät muss man hoffen das es einigermaßen passt.

Wie man im Video oben sieht wird die Schaltung per USB mit Spannung versorgt. Ausschließlich der Oszillator ist an dieser angeschlossen. Alle weiteren Bauteile der Schaltung werden nur passiv betrieben. Eine weitere Änderung in der Schaltung ist dass ich einen Schalter verwende um die Schaltung auch überbrücken zu können, also um den Eingang der Platine direkt mit der Ausgangsbuchse zu verbinden. Damit kann man auch die oberen Frequenzbänder verwenden ohne Antenne und Geräte an- und abschrauben zu müssen.

Im Video erkennt man ebenfalls das ich sehr viele Kondensatoren parallel betreibe. Das liegt daran das ich nicht alle Werte der benötigten Kondensatoren zur Hand hatte und auch nicht teuer bestellen wollte. Rechnerisch passt das soweit.

Der Schaltplan ist im folgenden Bild zu sehen, und das vollständige Projekt im GIT. Ich verwende übrigens mittlerweile KiCad für das Schaltungs- und Layout-Design.

Schaltplan

Hier noch ein Bild der fertig aufgebauten Platine von oben und unten. Gut zu sehen sind hier die oben genannten parallel geschalteten Kondensatoren und die Spulen.

Fertige UpConverter-Platine (oben)

UpConverter-Platine (unten)

Aktuell bin ich dabei die Platine in Betrieb zu nehmen. Meine letzten Aktivitäten lagen bei der Planung und beim Aufbau der Platine (siehe Oben). Momentan funktioniert die Platine nur partiell, mit einem Nachbau würde ich daher noch warten... Sobald es an dieser Stelle Neuigkeiten gibt werde ich davon berichten.

Ich möchte hier am Ende dieses Artikels noch einmal darauf hinweisen das man mit diesem Gerät nicht in der Lage ist in den Kurzwellenbereichen zu senden! Es geht hierbei rein um den Empfang und das mithören.

Wer senden möchte benötigt für das rad1o einen Transverter und die dazugehörige Amateurfunklizenz.

Stehwellenmessgerät frei nach ZL1CVD - #SWRMeter

In diesem Beitrag geht es um ein Stehwellenmessgerät. Es handelt sich dabei - im wesentlichen - um ein ähnliches Gerät wie auch ZL1CVD in seinen Videos auf Youtube zeigt. Allerdings sehe ich es - im Vergleich zu Ihm - nicht so kritisch mit der Veröffentlichung der Software und der Hardware.

Wer das Gerät also nachbauen möchte kann dies gerne tun. Ich würde jedoch gerne um eine Rückmeldung zum Aufbau und auch die Messungen mit dem Gerät bitten. Auch Verbesserungen der Schaltung und der Software sind absolut gerne gesehen und auch erwünscht.

Es gibt neben der Umsetzung von ZL1CVD sehr viele andere Umsetzungen und Ausführungen eines solchen Messgerätes im Internet, so dass es keinen Sinn ergeben würde auch nur daran zu denken meine Arbeit zurück halten zu müssen.

Auch gibt es für einige hundert Euro kommerzielle Produkte, für beispielsweise diejenigen welche sich den Aufwand und Spaß des selbst basteln ersparen wollen.

Die Varianten für die im Internet vorhandenen Messgeräte bestehen aus verschiedenen Ausführungen, angefangen mit einem Stück Koaxialkabel und wenigen Bauteilen (einfachste Variante) bis hin zum vollautomatischen Messgerät mit Display, Mikrocontroller, Tasten und Batterie.

Was macht nun aber ein solches Gerät?

Antwort: Es liefert Informationen über die Anpassung einer Antennenanlage an einen Sender. Hierzu muss man wissen dass eine Antennenanlage an den Wellenwiderstand des Senders angepasst werden muss.

Ist sie das nicht werden die hochfrequenten Signale von der Antenne, oder auch dem Kabel in das Gerät zurück reflektiert. Man bringt also durch das aussenden von Signalen wieder Energie in den Sender ein, die eigentlich aber von der Antenne abgestrahlt werden soll.
Schlimmer noch entstehen durch diese Reflexionen im Kabel sogenannte Mantelwellen, die unerwünschte Nebenaussendungen auf anderen Frequenzen erzeugen.

Das Messgerät ermittelt nur den Grad der Anpassung für eine oder mehrere Frequenzen. In der Regel misst man mit einem solchen Gerät die Anpassung für einen ganzen Frequenzbereich.

Das Ergebniss wird dann entweder auf angeschlossenen Zeigergeräten oder wie im Fall des Messgeräts von ZL1CVD sogar auf einem kleinen Display dargestellt. Worauf ich aber aufgrund des Aufwandes der Implementierung momentan verzichte.

Was benötigt man nun also um eine solche Messung durchführen zu können?

Antwort: Eine Einheit welche in der Lage ist ein Signal in einer bestimmten Frequenz und mit einer guten Stabilität zu erzeugen. Dabei sollte die Frequenz des Signals anpassbar sein. Dann eine Messschaltung um die Reflexionen als auch das in das Antennensystem eingebrachte Signal hinreichend zu erfassen.

Und zuletzt noch eine Möglichkeit die gemessenen Daten zu erfassen, abzuspeichern oder auch weiter an einen PC zu transferieren. Alternativ einen integrierten Puffer der die Messdaten bis zum Abruf vorhält.

Auf meinem Git kann die Schaltung für das Gerät heruntergeladen werden. Eine Platine habe ich dazu nicht erstellt. Mein Aufbau befindet sich auf einer beidseitigen Lochraster-Platine. Lediglich die grundlegenden Positionen der diskret aufzubauenden Komponenten habe ich im Layout der Schaltung skizziert. Dies hilft mir beim Aufbau auf einer Lochrasterplatine ungemein.
Das folgende Bild zeigt die fertig aufgebaute Platine von oben. Das darauf folgende Bild die Platine von oben.

Platine von oben

Platine von unten

Hier ist zu sehen das ich für die Verbindungen Leiterbahnen aus Draht und Lötzinn erstellt habe und die Abstände zwischen den Bauteilen recht großzügig gestaltet habe. Für die Messbrücke (Wheatstone) habe ich möglichst genaue Bauteile (Bauteile mit geringer Toleranz) verwendet - zumindest für die verwendeten 50 Ohm Widerstände.

Die zu messenden Signale werden mittels einem LM358 um den Faktor 11 verstärkt, die gemessene Spannung also angehoben. Der LM358 ist ein Operationsverstärker welcher zwar bereits in die Jahre gekommen ist, jedoch trotzdem gute Ergebnisse liefert. Den von ZL1CVD verwendeten OPAMP erwarte ich noch per China-Mail, ich bin gespannt wie sich die Messergebnisse verändern werden.

Als Signalgenerator - welcher einen Frequenzbereich von etwa 800kHz bis 160MHz ausgeben kann - verwende ich wie auch ZL1CVD einen Si5351 Chip.

Breakoutboard Si5351

Allerdings verzichte auch auf die Erstellung einer Schaltung um den Si5351 und verwende direkt ein Breakout-Board von adafru.it. Dieses kann mit verschiedenen Eingangsspannungen verwendet werden und ist 5V tolerant an den I2C Eingangsleitungen. Dies ist im besonderen wichtig, da der Mikrocontroller ein Arduino Nano ist der mit 5V betrieben wird.

Die maximale Stromstärke, mit der das hochfrequente Signal aus dem Signalgenerator ausgegeben wird, liegt bei 8mA. Als Spannungsquelle wird der USB-Anschluss eines Rechners verwendet, mit dem das Gerät auch gesteuert wird.

Der Ablauf der Messung(en) erfolgt in etwa wie folgt:

Zunächst beginnt der Signalgenerator ein Signal auszusenden, getriggert durch den Arduino. Hierbei entstehen die oben beschriebenen Reflexionen, oder auch nicht. Eine Wheatstone-Messbrücke teilt die fortlaufenden und zurücklaufenden Signale auf und speist diese (gefiltert) in den Operationsverstärker, den LM358. Die Aufteilung geschieht durch die beiden in der Schaltung enthaltenen Germaniumdioden (1N60).

Der Operationsverstärker verstärkt die beiden Signale jeweils um den Faktor 11, so dass die Messwerte vom Mikrocontroller in einer für Ihn besseren Auflösung messbar werden.

Der Mikrocontroller misst - sobald der Signalgenerator sein HF-Signal aussendet - eine vom Anwender zu definierende Zeit lang die vorlaufenden und zurücklaufende Reflektionen. Genauer gesagt die Spannungen welche von Operationsverstärker ausgegeben werden.

Die Anpassung der Antenne an den Sender ermittelt man nun durch die Bildung des Verhältnisses aus den beiden Messwerten. Das VSWR ist immer größer gleich dem Wert 1, daher muss immer durch den größeren Wert geteilt werden.

VSWR = Umax / Umin

Mein SWRMeter kann, wie im Folgenden Bild zu sehen ist, bis in den VHF - Bereich, also dem 2m Band arbeiten. Der VSWR-Wert ist übrigens nicht linear, so wird bei einem VSWR von drei (Zahlenwert 3) 25% der eingebrachten Leistung reflektiert. Und bei einem Zahlenwert von 1.5, 4% und bei einem VSWR von 2 = 11%.

Der Vorgang des Messens wird dann normalerweise für einen ganzen Frequenzbereich wiederholt, so dass eine Aussage für die Anpassung eines Antennensystems auf diesen Messbereich getroffen werden kann. Das folgende Bild zeigt die Messung einer selbst gebastelten Groundplane-Antenne welche für das 2m Band und 70cm ausgelegt worden ist.

Messung 2m - Band einer Groundplane

Ein Vergleich zu anderen Messgeräten und eine Kalibrierung bleibt momentan noch aus, der Signalgenerator ist jedoch in der Lage Kalibrierungswerte anzunehmen und auch anzuwenden. Auch die Genauigkeit der Messungen werde ich bei Gelegenheit einem anderen Messgerät gegenüberstellen.

Als Interface für den Anwender verwende ich kein Display und Taster sondern die USB-Schnittstelle des verwendeten Arduino. Ich habe ein Python-Script geschrieben welches in der Lage ist alle Funktionen des Messgerätes zu bedienen zu können.

Es können Messungen über Frequenzbereiche definiert und durchgeführt, Standard-Einstellungen gespeichert, die Signal-Ausgabestärke in mA gesetzt und die drei Ausgabekanäle des Breakoutboards separat angesteuert werden. 

Mögliche Script-Parameter

Weiter gibt das Script wenn erwünscht eine grafische Darstellung der Messung und oder auch eine CSV-Datei aus. Die grafische Darstellung wird dabei zur Laufzeit der Messung aktualisiert. Wird das Script ohne die Ausgabe der grafischen Ausgabe gestartet wird lediglich ein Fortschrittsbalken auf der Konsole angezeigt.

Wer nun aber ein Problem damit hat eine Kommandozeile zu bedienen findet diverse Windows-Batch-Files und Scripte welche dazu verwendet werden können um die einzelnen Amateurfunk-Bänder scannen zu können.

Die Skripte verwenden Standard-Parameter, welche jedoch durch bearbeiten geändert werden können.

Ausgabebeispiel einer Messung

Es existiert auch ein Script über das per PIP alle benötigten Python-Module nachträglich installiert werden können. Wichtig ist nur das python 2.7.x bereits installiert ist.

Wie bereits erwähnt ist es auch möglich die drei Ausgabe-Kanäle des Signalgenerators einzeln zu aktivieren und deaktivieren, um diese auch separat verwenden zu können. Wichtig bei der Verwendung dieser ist es zu wissen das nur der Kanal "0" an der Messbrücke angeschlossen ist, dass die Ausgabefrequenz per Angabe der Start-Frequenz definiert wird, und dass die Stromstärke der sekundären Kanäle aktuell fest bei 2mA liegt.

Hier ein Video mit einer Messung:

Schlussendlich muss ich noch dazu sagen: Die dargestellten Messungen habe ich nicht selbst durchgeführt sondern mir von einem befreundeten und lizenzierten Funkamateur helfen und durchführen lassen.

New look for #chinacluster monitoring UI #grafana

Das Webinterface für das Monitoring meines ChinaCluster habe ich nochmal überarbeitet. Die wichtigen Details sind nun deutlich besser zu erkennen. Zudem ist zu sehen in wie weit das neue 150 Watt Netzteil ausgelastet ist. Das vorherige hatte lediglich 60 Watt und war bei Vollauslastung des Systems bereits am Limit seiner Kräfte angelangt.

Mit dem neuen ist nun eine deutliche Reserve verfügbar und es können weitere Komponenten in das System eingebaut werden - wie zum Beispiel ein Belüftungssystem und die bereits eingebaute SSD-Festplatte.

An dieser Stelle möchte ich nochmal Aaron danke sagen der mir sehr geduldig das Gehäuse nochmal umgebaut hat um all meine Sonderwünsche umzusetzen, vielen Dank!