Raspberry Pi 5 - Fallstricke bei Installation

Thema Hotspot: läuft
Entweder war ich zu dämlich, oder ... I.d.R sitzen 95% aller Probleme vor dem Computer.
Anleitung Schritt für Schritt:
die eth0 Schnittstelle sollte mit unten aufgeführter Prio gesetzt werden:
1710618265560.png

Rest bleibt Standard:
HotSpot:
1710618344398.png

1710618401275.png

1710618440880.png

Proxy bleibt unverändert
bei IPV4 kann man noch die IP Adresse angeben z.B. 192.168.1.1 oder es bleibt bei der Class A Adresse.
Wichtig ist noch, dass der Hotspot aktiviert wird. Sollte dann so aussehen.
1710618632186.png


Dann sollte es klappen.
Habe es erst mit einem frischen aktuellem Image getestet, konnte dann die Einstellungen aber sinngemäß übertragen.
 
Hatte gestern übrigens meinen PI5 erstmals mit einer ASI-2600 im Einsatz. Raspbian Bookworm, INDI/KStars/PHD2 - lief sehr gut, Downloadzeiten so bei 1-2s, also deutlich schneller als beim PI4. Bin happy damit!
 
Thema Trockenübung:
Heute habe ich mir die Zeit genommen, um mal die gesamte SW zu testen. Fazit es läuft. :eek::eek::eek:
Selbst die Omegon veTEC571M wird erkannt und richtig angesprochen.
HW: Raspberry Pi 5 8GB als Ersatz für den 4-er im AstroRaspi V2
SW: aktuelles BookWorm, INDI 2.06, Kstars 3.6.9 (compiliert auf dem 5-er), RealVNC ohne Wayland
Astro-Setup: EQ6r-pro (Synscan Lagacy), ZWO EAF, ZWO EFW, ASI2600MC pro/Omegon veTEC571M, ASI290mm

Wenn jetzt noch das Thema mit dem Autoconnect und rfcomm gelöst wird, ist es schon fast perfekt.
Warte jetzt nur auf Gelegenheit seitens des Wetters, einen richtigen Probelauf hinzubekommen.:cool:
 
Hallo Thomas,
verstehe ich es richtig, meinst Du mit "Autoconnect", dass sich der RPi entweder an einem WLAN anmeldet, falls ein bekanntes gefunden wird, und andernfalls einen AccessPoint aufmacht? Wenn ja, da bin ich über AccessPopup gestolpert. Kennst Du das?
VG
Wolfgang
 
Hallo Wolfgang,
die rfcomm-Schnittstelle ist eine Serielle vom Bluetooth-System. Hier werden serielle Daten über BT übertragen. Beim 4-er bis Bulseye lief das wie folgt ab:
-BT Gerät paaren
-mittels der BT-MAC Adresse eine /de/rfcommx zuweisen
-Applikation greift dann einfach auf /dev/rfcommx zu, Verbindung baut sich auf, Daten können "fliesen"

Aktuell unter Bookworm geht das nur mit dem GPS-Deamon, selbst eine schon vorher manuell aufgebaute Verbindung, schlägt bei der Übertragung fehl. Auch die Änderung am Pythonsystem waren für einige Tage ein Aufreger.
 
Ach den Autoconnect meinst Du. OK, mit BT mache ich nix...
 
Wie hast Du eigentlich das Thema gelöst, dass der PI5 bei Bedarf einen eigenen Access Point aufbaut?

Ich habe mir nämlich gerade ein Skript gebastelt, mit dem die WLAN-Verbindung regelmäßig per cronjob überwacht wird. Falls diese zusammenbricht, versucht das Skript sich mit einem sichtbaren WLAN zu verbinden. Falls das fehlschlägt, stellt der NetworkManager um auf den konfigurierten AccessPoint.
 
Hallo Wolfgang,
siehe Anfang 4. Seite des Thread's. Du kannst das Ganze Steuern, in dem du unterschiedliche Verbindungsprioritäten setzt.
z.B. hier LAN = -999, Hotspot = 0, Für dich wäre dann noch die reine WLAN-Verbindung z.B. mit 10 oder 100 zu setzen.
Ich nutzte prinzipiell WLAN als Hotspot nur, wenn dieser am Setup hängt. Zur Pflege, Datenübertragung, etc. ... geht es bei mir nur Kabelgebunden.
Vereinfacht die Sache ungemein.
 
Hallo Thomas,
genau so habe ich es auch eingerichtet. Aus irgendwelchen Gründen bricht bei mir aber immer wieder die WLAN-Verbindung zusammen, obwohl das WLAN prinzipiell da ist. In dem Fall fällt der PI auf den Access-Point zurück und bleibt dann auch in dem Modus, obwohl er sich wieder mit dem WLAN verbinden könnte.

Das finde ich lästig, denn der Access-Point hat nur eine eingeschränkte Reichweite. Drum das Skript, dass immer wieder versucht, bei fehlender WLAN-Verbindung diese wieder herzustellen.
VG
Wolfgang
 
Meine Vermutung ist, dass sie die beiden WiFi Konfigurationen sich in die Quere kommen (Hotspot und Client) Der Hotspot ist bei mir immer aktiv, und irgendwie habe ich den Verdacht, dass sich der eigene Client dann mit dem eigenen Hotspot verbindet und somit andere Sachen ins Leere laufen. Wäre vielleicht hilfreich, den Hotspot Modus bei vorhandenen bekannten WLAN per Script zu deaktivieren, z.B. während des Starts oder Kontrolle regelmäßig durch einen Cron Job, wie du es ja schon machst.
 
Hallo,

Mal eine Frage in die Runde, würde die Installation auch auf einem Raspi 4 mit 4GB und SD-Karte funktionieren?

Vielen Dank und viele Grüße,

Günther
 
Zuletzt bearbeitet:
Hallo Günther,
Bookworm läuft auch auf einem 4er, nur Bullseye und älter nicht auf dem 5er
 
Thema SSD und Firmware:
Mir ist gestern aufgefallen, dass erst mit der allerneusten Firmware der Raspi 5 die NMVE SSD richtig ansprechen konnte. Vor dem Update lief die SSD auch heiß, IMHO kam sie nicht in irgendeinen Ruhezustand. Kann bei neueren 5er Pi nicht mehr der Fall sein, aber bei den Ersten ist das so. Bitte bei der Installation beachten, ergo mit micro SD Card das Ganze erst fit machen.
 
Hinweis zur Compilation von Indi, Kstars ...
Beim Compilerlauf ist mir mehrfach und nachvollziehbar das ganze System abgestürzt, sobald ich alle Core's nutzen wollte bei 4GB RAM. Ein Test mit einem 8GB Pi 5 ergab einen stabilen Durchlauf von Anfang bis Ende.
 
Zitat von steins-ursel:
Beim Compilerlauf ist mir mehrfach und nachvollziehbar das ganze System abgestürzt, sobald ich alle Core's nutzen wollte bei 4GB RAM. Ein Test mit einem 8GB Pi 5 ergab einen stabilen Durchlauf von Anfang bis Ende.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Meiner Erfahrung nach tritt das Problem nur bei KStars auf, INDI und 3rd-party INDI hatte ich noch nie Probleme. Ich reduziere typischerweise bei KStars die Zahl der gleichzeitig laufenden Compiler-Aufrufe auf zwei und nutze nicht die theoretisch möglichen vier Threads. Natürlich ist dann ein Compiler-Lauf langsamer.
Bash: 
make -j2
Mit 8GB sollte das Problem nicht auftreten.
 
Zitat von steins-ursel:
Wäre vielleicht hilfreich, den Hotspot Modus bei vorhandenen bekannten WLAN per Script zu deaktivieren, z.B. während des Starts oder Kontrolle regelmäßig durch einen Cron Job, wie du es ja schon machst.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Genau das macht mein Skript. Falls es ein bekanntes WLAN findet und keine WLAN-Verbindung besteht, verbindet es sich mit diesem.

Ich habe gestern mal einen Test gemacht und über Prioritäten den Network-Manager so konfiguriert, dass eine WLAN-Verbindung Vorrang hat. Das funktioniert auch prima und schaltet auch von WLAN auf AP-Modus um, sobald keines der WLANs sichtbar ist. Nur den umgekehrten Weg macht der NetworkManager leider nicht, d.h. der AP-Modus bleibt bestehen, auch wenn ein WLAN wieder erreichbar ist. Das löse ich per Skript und cronjob.
 
Meine Vermutung
Sobald dein Pi im AP Modus ist, gibt es bis zum nächsten Reboot kein zurück mehr, da er ja mit sich selbst verbunden ist, und für die Konfiguration alles in bester Ordnung ist
 
Hallo,

Hat sich jemand von Euch schon mal AstroArch angesehen? Ich habe bisher noch nie mit einer Arch Linuxversion gearbeitet, zumindest laut der Github Seite sollten wohl etliche Probleme, die hier bisher aufgetaucht und auch gelöst wurden sind, bei AstroArch out of the box funktionieren.

Vielen Dank und viele Grüße,

Günther
 
Zuletzt bearbeitet:
Hallo
Wie ist es eigentlich mit dem Wlan beim Raspi 5? Welches Band (2.4 oder 5MHz) sollte (bei grösseren Distanzen) vermieden (Störungen) resp. welches bevorzugt werden?

Gruss David
 
Zuletzt bearbeitet:
moin, in der Regel ist auf 5 weniger los und damit störungsfreier. Allerdings ist die Reichweite geringer. Und ganz wichtig, ein Metallgehäuse zur Kühlung reduziert die nochmals deutlich.
CS Sigvald
 
Danke fürs Feedback. Störungen - da habe ich mich zu wenig klar ausgedrückt: meinte durch den Raspi selber und weniger durch (zu viele) andere Teilnehmer.

CS David
 
Eine Randfrage (passt mässig gut rein...): gibt es in der Raspi- resp. KStars-Umgebung etwas ähnliches wie den Bahtinov-Grabber?

CS David
 
Hallo David,
stimmt, passt mäßig ;). KStars hat eine Bahtinov-Funktion, aber ich kenne sie nicht so genau. KStars hat aber einen ausgefeilten Focus-Mechanismus, der ohne Bahtinov-Maske auskommt.
VG Wolfgang
 
Einen Fokusser kann ich damit ansteuern - das ist korrekt. Es geht mir mehr um die Kontrolle der Einstellung. Ich bin immer wieder erstaunt, dass nach dem Fokussieren mit der Bahtinov-Maske ein Restfehler vorliegt.
Ok, an die Zeit vor der Bahtinov-Maske - Scharfstellen am Live-View-Display der DSLR - möchte ich gar nicht mehr zurückdenken. Da geht es mit der Bahtinov-Maske um Welten besser.

CS David
 
Hallo,
passt zwar nur mäßig in das Thema, aber AstroBerry scheint zur Zeit still zu stehen. Weiß jemand mehr?
 
Ich schaue auch hin und wieder nach, aber da tut sich nichts. Aber das ist eben auch ein Problem, Radeck ist wohl der alleinige Entwickler und wenn der keine Zeit oder andere Prioritäten hat, dann steht die Weiterentwicklung. Bitte nicht falsch verstehen, das soll keine Kritik sein, sondern eine Beobachtung.

CS,

Günther
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben