Antennenanpassung per Raspberry

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Guten Morgen Leutz und Amateurfunker

    Zur Vorstellung: Ich Ralf ;- Rentner, Amateurfunker seit 1984, einige Erfahrungen mit Raspi, Programmierung in Pascal und Python, bisserl Maschinensprache- aber was fehlt kann man sich ja anlesen!

    Also meine Idee ist eine Antennenanpassung für Kurzwelle 1,8 MHz bis 30 (50/70) MHz per Raspi.

    Ich stelle mir das so vor:

    Raspi benötigt folgende Hardware:

    Netzteil für Raspi , Meßhilfsmittel und Schrittmotore - !KEIN Schaltnetzteil! Konventionell!

    AD-Wandler zur Messung SWR, eventuell mit Vorteiler

    Tastatur - Zahlen 0-9, 4 Menuetasten + 1 Entertaste

    4 oder 5 Relais zur Umschaltung der Anpassungsmethode,

    2 Relais zur Umschaltung Bypass oder Messung,

    3 Schrittmotore ,

    ein Meßdummy 50 Ohm (Kunst-Ant oder Antennenersatz genannt)

    Monitor 5Zoll

    Zwecks Abschirmung Metallgehäuse bzw abgeschirmte Kammer innerhalb des Anpassgerätes(Tuner)

    Vorgehensweise:

    Raspi mißt Sendefrequenz und schaltet demzufolge eine Schaltungsart - wie Pi-Filter LC oder andere - je nach Anpassungsbedingungen der Antenne-

    Oder Frequenzeingabe per Tastaur für reine Empfangsanlagen oder als Startpunkt für eine automatische Abstimmung,

    Raspi mißt als erstens momentanes Stehwellenverhältnis (SWR) und zeigt es an,

    Dann Suche im Speicher, ob zu dieser Frequenz schon mal getunt wurde,

    Falls ja, Presets einstellen,

    Erneute Überprüfung des SWR,

    Falls keine Werte vorhanden, Ansteuerung jeweils eines Drehkondensator und einer Drehspule abwechselnd in kleinen Schritten,

    Dies wird mit Symbolen am Display angezeigt,

    SWR erneut überprüfen,

    Falls Wert akzeptabel, von SWR-Messung auf Betrieb umstellen

    SWR weiterhin überwachen und anzeigen bei Sendebetrieb

    Eventuell Anzeige der Arbeitsfrequenz - mit Unterscheidung RX oder TX

    ~~~~~

    So,das ist m.M nach das grundsätzliche in Sachen Hardware und Programmierung.

    Ich überlege noch, ob ich einige Arduinos als Meßknechte einsetze, da der Raspi ja keine AD-Wandler hat,

    vielleicht tuns ja auch kleinere Hilfsschaltungen - ESP82,86 oder so.

    Zur Anzeige:

    Wenn der Tuner neben dem Sender auf dem Tisch steht :

    5 Zoll sollten es schon sein - alles drunter verdirbt man sich die Augen;

    Falls im abgesetztem Betrieb :

    Entweder alle Meßwerte per USB in die Funkbude, oder per Wlan, SSH.

    Mein größtes Problem ist aber die Gestaltung der Anzeige, da hab ich überhaupt keine Vorstellung der Programmierung.

    Ich hab zwar irgendwo was gelesen von programmierbare Grafikdisplays, Namen weiß ich im Moment nichrt, aber da schreckt mich der Preis.

    Und nun meine Frage an die Leser hier:

    Ist das GRUNDSÄTZLICH realisierbar?

    Weiß jemand, obs schon ähnliches gibt? Hab Tante Google befragt, die konntemir aber nix liefern; Vielleicht hab ich nur die Frage falsch gestellt.

    Bin deshalb dankbar für Ideen, Anregungen und Hinweisen auf Lesenswertes.

    Gutes Neues Jahr und Gesundheit für alle

  • Moin Ralf,

    da hast du dir aber eine eierlegende Wollmichsau ausgedacht...

    Einige Dinge wird der RPi einfach nicht können.

    Frequenzmessung im MHz-Bereich. Nur mit externen Komponenten und dann sicher sehr ungenau.

    Stehwelle auch nur mit externen Komponenten. AD-Wandler usw.

    Was ich mir vorstellen kann ist, das der RPi als Anzeige- und Schaltzentrale dient. Die eigentliche Arbeit übernehmen dann Mikrocontroller, die die Ergebnisse dann via XYZ an den RPi liefern und der arbeitet dann mit den Daten und gibt neue Anweisungen raus.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Wenn auch nicht RPi-basierend, aber folgende kennst du?

    https://github.com/Dfinitski/N7DD…extended-boards

    https://www.qrpforum.de/forum/index.ph…ichen/&pageNo=1

    https://www.dl4jal.de/picatu/picatu.html

    Vielleicht finden sich in den Projekten Anregungen für dein eigenes.

    ich würde Bernd666 zustimmen, lieber µController die Arbeit machen lassen.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    4 Mal editiert, zuletzt von llutz (31. Dezember 2020 um 15:31) aus folgendem Grund: Link korrigiert, danke @bernd666

  • Ich bedanke mich erstmal bei allen, die hier einen konstruktiven Kommentar hinterlassen haben.

    Konnte mich wegen Verwandtenbesuch - selbstverständlich Korona-Konform - nicht gleich melden.

    Werde erst mal die Links durcharbeiten.

    Ja, an so etwas dachte ich schon- nach dem Motto verteilte Lasten. Für jede Messart einne Spezialisten.

  • ..das ganze wird schlicht und einfach scheitern

    dein Pflichtenheft ist Hardwaremäßig nicht zu schaffen, auch der Raspberry ist da wohl überfordert

    Ich frag mal einfach so :Wieso "Hardwaremäßig nicht zu schaffen" ?

    Da ich vor Erstellung des Pflichtenheftes mich über die Fähigkeiten des Raspi belesen hab, ist mir schon klar geworden, das er Meßgehilfen braucht.

    Hatte ich ja auch schon im ersten Post erwähnt.

    Z.B: Frequenzmessung - Kann der Raspi nicht, also kleine Hilfsplatine mit PIC; ev. mit Vorteiler.

    Das Ergebnis wird de Raspi ja wohl verdauen können.

    Und wo siehst du die Überforderung ? Ich hatte schon an einen 4er gedacht, obwohl ich noch 2er und 3er hier liegen hab.

    ~~~

    Also ich will Dich hier nicht irgendwie dissen oder sonstwie anmachen, mir ist an einer Diskussion zum Thema gelegen, weil solch "kleine" Hardwarebasteleien das einzigste ist, was ich mit meine Behinderung noch machen kann. Aufm Dach rumklettern und Antennenbasteln ist nicht mehr.

    Also bleibt mir nur noch "Schreibtischtäterei"

  • Ich kann den HF-Teil des ganzen nicht beurteilen - nicht meine Baustelle. Wenn wir also davon ausgehen, dass die Elektronik hergibt, was du von ihr verlangst, dann fallen mir zwei Probleme auf:

    1) Wann immer ein Schrittmotor etwas dreht, das einen Anschlag hat, braucht man einen Null-Geber. Denn deine Steuerung kann immer zur Unzeit ausfallen, und dann hast du keine Ahnung, wo der steht. Und machst schlimmstenfalls etwas kaputt. Die anderen genannten Projekte scheinen das mit diskreten L/C Schritten zu lösen. Warum nicht du auch?

    2) grafische Oberflächen zu programmieren ist nicht trivial. Mit “ein bisschen” wird es recht schwer. Da du gleichzeitig auch noch Hardware-Eingaben machen willst, würde ich dir tatsächlich zu einem simpleren Microcontroller-Setup raten. Mit einem Nextion Display. Ja, die Kosten etwas mehr. Aber Pi + 5” Bildschirm sind ja auch nicht umsonst. Doch dafür ist die Gestaltung und Ansteuerung einfacher, und kann problemlos vom Microcontroller gestemmt werden.

  • grafische Oberflächen zu programmieren ist nicht trivial.

    Es fällt ja immer wieder einmal, nur halte ich diese Aussage aus der Sicht eines Python Mächtigen dafür OK, jedoch gibt es viele andere Möglichkeiten (in Anbetracht der Erwähnung von Pascal vielleicht Larazus?), wenn es denn wirklich eine grafische Oberfläche sein muss. Und auch, wenn alles wie ein Nagel aussieht, wenn man einen Hammer in der Hand hat, ist Python nun auch nicht der Mittelpunkt der Welt.

    Die Unmenge an Forderungen in der Beschreibung halte ich mindestens für sehr schwierig umzuzsetzen, jedoch muss es ja nicht an mit geeigneten Werkzeugen umzusetzende Lösungen hängen.

  • STF: ich habe das bewusst nicht sprachspezifisch formuliert. Das, was Lazarus einem AFAIK bietet, ist ein eingebauter Designer, und eine gewisse Unterstützung der IDE zb zur Anlage von Ereignisbehandlungen. Das muss man in python mehr (tkinter) oder weniger (Qt + Designer + pyuic) selbst machen. Wenn einem das den start erleichtert - bitte, gerne.

    Das ist aber nicht, worauf ich mich hier beziehe. Sondern auf die inhärent ereignisbasierte Art, wie GUIs funktionieren. Jedenfalls die üblichen, Lazarus inklusive. Und das, woran dann die Leute hier üblicherweise scheitern, sind nicht die Fragen danach, wie sie nun ihre Buttons an die rechte Stelle bugsiert bekommen. Und auf Knopfdruck einen GPIO schalten.

    Sondern diesen gefundenen Code mit drei geschachtelten while-Schleifen zur Ansteuerung von Hardware mit diesem Paradigma verheiraten. Wo dann plötzlich Threads, thread-sichere Datenstrukturen, Timer, Zustandsautomaten etc ins Spiel kommen. DAS ist schwer. Egal in welcher Sprache.

    Aber vielleicht täusche ich mich da. Ich schaue mir - ganz im Ernst - gerne Beispiele an, wie es anders/besser geht. Ich mag Python, aber ich programmiere auch C++, Rust, JS, Lua. Doch ich habe hier bis dato immer nur den Hinweis gelesen, “mach’s doch mit Lazarus”. Aber noch nicht eine Zeile Code. Wenn du da da ein Beispiel hast, würde mich das aufrichtig(!) freuen.

  • DAS ist schwer. Egal in welcher Sprache.

    Nein, nein. Oder besser: Ja, natürlich. Meine "Kenntnisse", Delphi und Lazarus betreffend sind nicht ansatzweise so fundiert (und teilweise ca. 20 Jahre vergraben gewesen), wie ich das von Dir immer wieder lese. Die ersten Tage des "advent of code" hab ich aus Spass mit Lazarus auf dem Mac gelöst. Danach verschlang mir das zuviel Zeit, meine Profession liegt an völlig anderer Stelle. Wo ich Dir absolut Recht gebe, ist die Tatsache, dass natürlich der Code im Hintergrund die deutlich komplexere und vor allem wichtigere Komponente darstellt.

    Es ging mir um die abstrakte Aussage, dass "Oberflächen schwer zu programmieren" seien. Und ja, natürlich musst Du von Skriptsprachen aus kommend etwas umdenken, was Objekte, Eigenschaften, Ereignisse/behandlungen etc. betrifft. Für mich (und meine zeitunkritischen Dinge) reichte das bisher völlig aus und ließ sich sehr gut, einfach und mit Spaß in Lazarus abbilden.

    gefundenen Code mit drei geschachtelten while-Schleifen zur Ansteuerung von Hardware

    Wobei sich dann ja auch die Frage stellt, was das oberhalb der Treiber im OS (außer zu Testzwecken) zu suchen hat - aber das ist ein ganz anderes Blatt Papier.;)

  • @STF

    Ich gebe Dir recht, in irgendeine Prog.-Sprache einzutauchen, ist schwierig, aber bei halbwegs normaler Auffassungsgabe nicht unmöglich.

    Wenn ich mir meine Herankommen an heutiges Programmieren in Python oder C anschaue, dann glaube ich zu den Dinosauriern zu gehören.

    Meine erste Sprache war Forth, dann Commodore-Assembler und Basic, was für mich ein gefühlte Rückschritt war, und ich fast die Lust an der Materie verlor.

    Aufgrund eines schweren Unfalls durfte ich dann 1990 auf Kosten der Rentenversicherung eine Umschulung zum Kommunikationselektroniker machen.

    Lerninhalt zB: Während auf dem Markt durchaus schon PCs mit 386er Prozessor waren, mußten wir mit einem 4BitProz von HP eine Ampelsteuerung bauen, obwohl in meiner Klasse die überwiegende Mehrheit Programmierkenntnisse hatten.

    Ich hab dort einen weiteren behinderten Kollegen kennengelernt, der sich mit Pascal beschäftigte. Und da wir die uns gestellten täglichen Lernaufgaben schon zur Frühstückspause erledigt hatten, konnten wir mit Unterstützung -sprich Duldung - unseres Ausbilders uns mit eignem beschäftigen. Wir haben dann gemeinsam ein Oszilloskop gebaut; er die Grafik, ich die Hardware. Auf einem 286er haben wir das so hingekriegt, das unser Skope ohne Problem sich mit einem 2-Strahl-Hameg bis 20 MHz messen konnte. (Allerdings mit einem Frequenzvorteiler) Dort habe ich zB eine automatische Bereichsumschaltung für Spannung ,Strom und Frequenz mit analogen Bauteilen aufgebaut. Gut heute wäre das nicht mehr Stand der Technik.Aber das damals diesbezüglich gelernte kann mir heute bestimmt auch noch helfen.

    Aber mein Kollege hatte das mit der Grafik prima gelöst, obwohl er von Elektronik bis dahin kaum Ahnung hatte.

    Wir hatten sogar eine Strahlpositionierung per Poti eingebaut, und die Bereichsumschaltung konnte ebenfalls auf Hand umgestellt werden

    Das Projekt lebte einfach von de Zusammenarbeit und einigen zerschossenen Bauteilen. ;-))

    Einmal editiert, zuletzt von Ralf-DC7FB (1. Januar 2021 um 18:40)

  • So, ich hab noch mal in einen älteren von mir gebautem Antennen-Tuner reingeschaut.

    Der war ohne Digitaltech und funktionierte auch im Remote-Betrieb.

    2 Drehkos, 1 Spule mit Schrittmotoren jeweils mit 2 Endschaltern und einige Relais zum Umschalten zwischen den verschiedenen Anpaßmodi.

    Achja, noch jeweils ein kommerzielles Stromstoßrelais, was per Spannungsimpuls jeweils 1 Pos weiterschalteten. Also eigentlich ein motorisierter Schalter, der bei Bedarf weitere Kondensatoren den Drehkos vorschaltete. Für de Spule hatte ich sowas dann nicht mehr, war auch nicht zwingend erforderlich.

    Für den Remote-Betrieb bedurfte es nur eines längeren 24poligem (ehemaligem Drucker-)Kabels, da ich die Bedieneinheit separat aufgebaut hatte.

    Klappt bis heute noch, nur ist bei mir de Wunsch hochgekommen, das alles digital zu steuern.

    Und ich glaube, das vieles von dem was in de analogen Büchse steckt, auch in einer digitalen Version möglich ist.

    Ja, und mit Nextion werde ich mich mal näher auseinandersetzen. Denke, wenn mans erstmal begriffen hat, kann man auch andere Projekte damit ausstatten.

  • Also ich hab mich da mal bischen belesen...

    Merkwürdig finde ich die Aussage vieler Händler, das die Nextion Displays nur für Rasp 2 und 3 funktionieren. Kann ich mir schwer vorstellen.

    Oder weiß da wer anderes?

  • Moin Ralf,

    ich habe mir eben ein Display von Nextion angesehen. Eigentlich die Datenblätter. In der basic-Version, 4,3 und 5 Zoll.

    Sie wollen seriellen Datenverkehr und das kann jeder RPi.

    Schau einfach mal bei Nextion rum..

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Moin Bernd;

    Neujahr gut überstanden ?

    Hier im Süden Berlins werden grad noch die Restbestände an Altböllern entsorgt, vorwiegend in Mülltonnen und Briefkästen der Nachbarn, grrrrr

    Ja ;auch bei mir Lesestunde beendet und hab mir für erste Tests ein 4,3" Nextion bestellt, da ich auf dem Gebiet den meißten Nachholbedarf hab.

    Und was ich auch noch fand war eine Programmierumgebung unter Linux, da ich hier keinen Windows-Rechner habe. Ich denke mir, dass wenn es diese Möglichkeit gibt, dann ist es wahrscheinlich sogar möglich, das Nextion auch direkt auf dem RPI zu progammieren.

  • Ich bezweifele, das das direkt auf dem PI geht. Die wird nicht für ARM verfügbar sein. Scheint leider noch nicht mal für Linux da zu sein. Das ist natürlich doof. Es Scheint möglich, Wine zu benutzen.

  • Zitat von Tom, wb6b, auf Yahoo:

    " I believe I downloaded Wine directly from the Wine site (https://www.winehq.org), as the versions that installed with Linux installers (and Mac installers like Homebrew) may be very old.

    The program I was able to get to run under Wine was: "/uBITX_MM_1.81/uBITX_Manager.exe".

    The version of Wine I'm using is: "wine-3.0.1". It was called wine-stable.

    The uBITX_Manager is OK on my Linux Mint with Mono. I sent a message to Nextion and they answered ....."

    Zitat von Paul ,KL7FLRauf Yahoo:"I am running Linux Mint 18.3 as my primary OS and utilize VirtualBox for running Windows OS’.

    I downloaded the Nextion editor and it seems to run on Windows 7 as expected"

    OK, dies ist das, was ich zu Linux fand, habs mir erstmal nur runterkopiert und leider erst grad eben genauer durchgelesen.

    @__deets__ :

    Hast Recht; es scheint nur via Wine oder anderen Emulatoren unter Linux und Mac zu klappen und dann auch nur mit Tricks:

    Zitat von AB8XA auf TGIF.Network :
    " This is what seems to work for me on Ubuntu 18.04 LTS

    Install wine and winetricks

    Enter the command:

    WINEARCH=win32 WINEPREFIX=$HOME/.wine wine wineboot

    Run winetricks

    Choose Select the default wineprefix

    Choose Install a Windows DLL or component

    Choose these components and click OK:

    comctl32ocx

    comdlg32ocx

    dotnet35sp1 (also installs 20, 30sp1, 35 -- don't check them)

    ole32

    riched30

    richtx32

    setupapi

    Cancel out of winetricks

    cd to the directory of the setup file

    Enter wine nextion-setup-v053.exe

    It started the program and added a launcher.

    I've been able to open and compile the PD0DIB HMI files. "

    Da überleg ich mir doch, ob ich mir nicht auf Ebay für "kleines" so ein MiniPC mit Win7 anschaffe.

    Denn ich hab bisher mit Wine und Mono und wie die Emulatoren sonst so heißen, keine guten Erfahrungen gemacht.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!