INDI auf dem Raspberry einrichten

Status
Es sind keine weiteren Antworten möglich.
Hi Frank, konkret hab ich keine Empfehlung, du solltest nur darauf achten dass Linux oder Raspberry Pi unterstützt wird. Ich habe nach dem Chipsatz im GPS gesucht und verglichen ob er im Kernel unterstützt wird. So gehe ich fast immer vor.
USB Hubs machen keine mir bekannten Probleme, habe dafür einen CSL USB3 Hub (Amazon) genommen, ist klein, günstig und funktioniert gut. In meiner INDIbox stecken sogar 2 davon drin. Läuft.
 
Es gibt RTC (RealTimeClock) Module zum aufstecken am GPIO. Hab das mal probiert, es hat auch funktioniert aber diese Module sind nicht sonderlich genau. Nach wenigen Tagen waren es schon mehrere Minuten Differenz.

Hallo!

Das Thema Synchronisation mit der Zeit stand für mich auch am Anfang zur Debatte.
1. Gedanke, nimm GPS. Funktioniert richtig gut, mit einer Einschränkung. Liegt der Raspi <> 4h mit der Zeit daneben, wird nichts mehr synchronisiert, da geht's nur noch manuell.
2. Also es kommt noch ein RTC dazu. Der wird gepuffert von einem Gold-CAP, da auch der Platz ein Thema ist, konnte ich nur einen 0,5F verbauen. Die Energie reicht für ca. 14d den RTC "am Leben" zu halten.

Als GPS-Modul habe ich diese 2 im Einsatz: NEO-6M (nur GPS) und BN-220 (GPS, Glonass ...). Die Module haben als Interface die serielle Schnittstelle (9600,8,N,1).

Der RTC zu Testzwecken ist folgender: DS1307. Dieses Modul führt zusätzlich die serielle Schnittstelle inkl. GND, 3,3V und 5V mit heraus.
Um den Platzbedarf zu minimieren, habe ich allerdings eine Art "Sideboard" mit um 90° versetzten GPIO Anschlüssen inkl. RTC (Selbstbau in SMD), einen Versorgungsanschluss 5V inkl. Überspannungsschutz und einen 4pol. Pinheader für die serielle Schnittstelle für das GPS-Modul erstellt.

Die Konfiguration GPS und RTC ist unter Pkt. 8 und 9 weiter vorne im Thread in meiner Installations- und Konfigurationsbeschreibung zu finden.
Wichtig ist noch, dass die GPS-Antenne genau waagerecht liegt, um den maximalen Empfang zu haben. Zur Zeit wird die Aufnahme am Raspi-Gehäuse dahingehend geändert. Hatte gestern die Ehre, dass die Technik erstmals ohne Zicken fast 90min durchgelaufen ist, außer GPS, der hatte keinen Empfang.
 

Anhänge

  • RaspBiSide.sch.pdf
    16,7 KB · Aufrufe: 357
  • RaspBiSide.pdf
    27,4 KB · Aufrufe: 335
  • DSC_0506.JPG
    DSC_0506.JPG
    1,3 MB · Aufrufe: 355
Zuletzt bearbeitet:
Hallo zusammen,

ich verfolge diesen Beitrag immer so ein bischen, da ich selbst ein RPi mit Astroberry nutze. Da sind Guider, INDI-Tools, Webinterface, etc. schon vorinstalliert.

Vielleicht helfen uns nachstehende Informationen zur Antennenwahl/-auslegung.

Antennenwahl

Ich empfehle eine kleine Patch-Antenne, die sind extrem Preisgünstig, passen in jedes Smartphone und die Orientierung im Raum ist egal, solange die Antennenfläche nur irgendwie nach oben zeigt. Aufgrund der Symmetrie der Antennenplatte ist der Eintrittswinkel der einlaufenden elektromagnetischen Welle unbedeutend.

Eine Helixantenne ist technisch realisierbar aber zu groß und zu schwer.

Historisch sollte das Signal nicht von den Sovjiets gefunden werden, sodass sein Signal so moduliert wurde, dass es die Energie in Seitenbänder von der Trägerfrequenz verteilt und vom Rauschen überdeckt wird. Das L1 GPS hat eine Mittenfrequenz von 1,57542GHz.

Würde man eine Stabantenne verwenden, eignet sich die Lamda/4 Länge mit 4,75cm am besten. Du hast Glück, wenn das überhaupt funktioniert, denn die Signale werden rotations-polarisiert moduliert, das heißt die Welle schraubt sich in Deine Antenne hinein, falls die Geometrie passt.

Wellenlänge = Lichtgeschwindigkeit / Trägerfrequenz

> 299792460/1575420000
299792460 / 1575420000 = approx. 0,19029367

> 0,19029367/4
0,19029367 / 4 = approx. 0,047573418


Allgemeines zu GPS:
Generell ist zu beachten: Die GPS Satelliten ändern naturgemäß ständig ihre Position, meist spannt die Verbindung zwischen zwei Satelliten einen Winkel von rund 120° ein, jedoch brauchst Du zu mindestens 3 Satelliten Sichtfeld. Demnach würde ich eine Stabantenne sogar senkrecht aufstellen. Meist sind 3 bis 4 Satelliten im Sichtfeld.

Alle Satelliten senden pulsweise exakt jede Sekunde gleichzeitig (eine Rubidium Atomuhr in jedem Satellit), abzüglich der Laufzeitunterschiede, aus denen die Position errechnet wird.

Die Freiraumdämpfung zu den maximal 32 aktiven Satelliten beträgt rund 171dB. Das Signal wird aus dem Rauschen wieder herausmoduliert. Geschickterweise ist die Empfangsantenne möglichst schmalbandig auf die Trägerfrequenz abgestimmt.

Du wirst tags- und nachtsüber unterschiedliche Empfangscharakteristika haben, da die Signale von der Ionosphäre der Erde stark beeinflusst werden. Nachts verschwindet die Ionosphäre nach ca. 23Uhr über Deinem Empfangsort fast vollständig. Die Welle schraubt sich bei idealbedingungen von jedem Sendesatellit ca. 2,3 mal um ihre Ausbreitungsrichtung bevor sie in Deine Antenne knallt. Gute GPS-Empfänger haben hierfür Korrekturfaktoren in der Firmware.

Wenn die Satelliten-Ephemeriden nicht bekannt sind (nicht aktualisiert werden), kann es bis über 6 Minuten dauern, bis die Position errechnet wird.



Mit *Daumendrück* Grüßen,

Sebastian.
 
Ach, die Stabantenne auf dem Bild, ist die WLAN-Antenne?

Also ich bestell mir die RTC auch und teste auch ein bischen mit.

Wird die Linux Systemzeit genutzt sollte der NTP-Daemon deaktiviert werden, da dieser die Uhrzeit aus dem Netz synchronisiert. Die Schaltsekunden machen dann alles kaputt...

hwclock -w ## schreibt die aktuelle Systemzeit in die HW-Clock (Rootrechte erforderlich), falls diese Funktion unterstützt wird.

Haben wir Datenblätter zum DS1307? Was für ein Chip ist da verbaut? Das kann ich auf den Amazon Fotos nicht erkennen. Welcher Quarz ist drin?
 
Zuletzt bearbeitet:
Hmm, das schöne am RPi ist, das man alles von Grund auf selbst bauen kann. Das unschöne am RPi ist, dass man oft von Grund auf alles selbst bauen muss.

Ah jetzt sehe ich auch die Patchantenne des NEO-6M (nur GPS) . Die Ublox Module sind alle durchqualifiziert. Kann man ein Fehlerregister zur Analog-Versorgung auslesen? Hilf mir schnell das Modul ist mit AT-Kommandos über die UART zu steuern?

Das von den Astroberry-Jungs vorkonfigurierte SD-Karten Image ist sehr umfangreichend mit Tools und Server-Diensten. Da sind auch RTC-Treiber installiert. Nur, mit der RTC des RPi selbst musste ich mich noch nicht auseinandersetzen. Linux hat sehr guten Support für RTCs. Embedded Module mit Linux gibt es wie Sand am Mehr.

Im Allgemeinen gibt es keinen Quarz der so ungenau läuft, dass nach ein paar wenigen Tagen schon Sekunden verloren gehen. Wenn nicht die Versorgungsspannung zu niedrig ist oder die Phasenregelschleife verkonfiguriert wurde ist irgendwas anderes noch faulig. Ich tippe auf den NTP-Daemon:

service --status-all

Kommt was von der Art
...
[+] ntpd
...

Wenn ja, schaltet mal ab mit:
sudo systemctl disable ntpd
sudo service ntpd stop


@Thomas: Was ist mit dem 0,5F gemeint?

Ich les mich erst mal richtig in den Beitrag ein und dann senfe ich wieder dazu.
 
Zuletzt bearbeitet:
Ach, die Stabantenne auf dem Bild, ist die WLAN-Antenne?

Also ich bestell mir die RTC auch und teste auch ein bischen mit.

Wird die Linux Systemzeit genutzt sollte der NTP-Daemon deaktiviert werden, da dieser die Uhrzeit aus dem Netz synchronisiert. Die Schaltsekunden machen dann alles kaputt...

hwclock -w ## schreibt die aktuelle Systemzeit in die HW-Clock (Rootrechte erforderlich), falls diese Funktion unterstützt wird.

Haben wir Datenblätter zum DS1307? Was für ein Chip ist da verbaut? Das kann ich auf den Amazon Fotos nicht erkennen. Welcher Quarz ist drin?

Hallo!

1. Die Stabantenne ist für WLAN und Bluetooth, selbst nachgerüstet.
2. Die GPS-Antennen sind in der Regel Keramik-Flachantennen, daraus ergibt sich eine Waagerechte Einbaulage.
3. Der NTP Daemon ist für den Sync für Netzwerk und GPS nötig. ein Deaktivieren halte ich für nicht sinnvoll
4. Verbaut ist ein DS1307, Datenblätter gibt es hier (z.B.), verbaut ist ein Quarz mit 32768Hz, also Uhrenquarz.
 
Hmm, das schöne am RPi ist, das man alles von Grund auf selbst bauen kann. Das unschöne am RPi ist, dass man oft von Grund auf alles selbst bauen muss.

@Thomas: Was ist mit dem 0,5F gemeint?

Ich les mich erst mal richtig in den Beitrag ein und dann senfe ich wieder dazu.

Hallo!
Mit 0,5F sind 0,5 Farad Kapazität gemeint. Es gibt noch größere, sodass man bis zu 20 Wochen den RTC versorgen kann.
Vorteil, man braucht sich nicht um irgendwelche Ladeschaltungen zu kümmern oder Knopfzellenwechsel. Gespeißt wird der Goldcap automatisch beim Nutzen am Teleskop oder in der Vor- und Nachbereitung in der Bude.
 
Hallo,

ich wollte keinen Spionagesatelliten bauen, sondern ne Möglichkeit haben Datum und Uhrzeit zu speichern:) Warum ist das so umständlich mit einem Raspi? Es gibt doch unzählige Devices heutzutage die das ohne große Probleme können.

CS Frank

Hallo Frank,

sollst du ja auch nicht. Da bei der technischen Ausrüstung der Standort per GPS die erste Wahl ist, bietet sich eine Synchronisation darüber geradezu an. Es sind nur die kleinen, tlw. fiesen, Details, welche da ein wenig mehr Aufwand erfordern.
Möglich wäre auch noch die Synchronisation Indi zu überlassen, habe ich allerdings noch nicht getestet.
Der hier beschriebene weg läuft komplett auf Betriebssystemebene ab.
 
Hallo!

Kleine Änderung unter Pkt. 8 - RTC. Wird ein Raspberry 4 verwendet, bitte folgendes Modul ändern:
Code:
#Raspi 3

# edit /etc/modules at the end
# i2c-bcm2708 <-
# i2c-dev
# rtc-ds1307

#Raspi 4
# edit /etc/modules at the end
# i2c-bcm2835 <-
# i2c-dev
# rtc-ds1307

Hatte immer mal für richtige Verwirrung der Technik in Bezug auf die Zeit gesorgt.

Weitere Frage:
Wie schaut es mit dem GPS-Empfang während der Nacht aus?
Meine Erfahrungen sind, dass mit zunehmender Zeit der Empfang immer schlechter wird, und dann irgendwann ganz abbricht. Sobald man an der Stelle Indi erlaubt, die Koordinaten und Zeit über GPS abgzugleichen und der Empfang ist weg, kommt da ganz schöner Murks raus.
Eine Lösung dafür suche ich noch.
 
Zuletzt bearbeitet:
Der Empfang sollte besser werden, da die Ionosphäre verschwindet. Besser gesagt das Signal-Rausch-Verhältnis sollte größer werden - ab ca. 2 Stunden nach Sonnenunergang deutlich.

Die haben von v3 nach v4 schon wieder einen neuen Chip im RPi verbaut?! Um Hardware zu checken sind übrigens die Kommandos sehr hilfreich:
lshw
lspci
(Groß-PC)
dmesg


Noch ne Frage: Lädst Du ein Kernelmodul, oder schreibst Du die Software als User-Space-Programm? Wir könnten uns da zusammen tun.

Ich habe das Thema bei mir noch hinten angestellt, da ich immer noch Software-Fehler bei meinem wireless-seriellem-Kabel habe.
 
Du schreibst, es wird schlechter. Die Welle tritt dann auch in einem anderen Winkel auf die Antenne. Vielleicht nachts die Antenne mal bischen drehen, also nicht schräg stellen, sondern um die senkrechte Achse rotieren. 30° oder so.
 
Ich benutze StellarMate OS auf einem Raspi 4B.
Bei Kstars kann man einstellen das die Uhrzeit vom GPS synchronisiert wird und das funktioniert sehr gut.
Hatte früher auch mal mit RTC probiert aber wie jemand im Thread schon erwähnt hat war der nicht genau.
Mit GPS (uBlox mit USB Anschluss) habe ich dann auch gleich noch die richtigen Koordinaten.
 
Du schreibst, es wird schlechter. Die Welle tritt dann auch in einem anderen Winkel auf die Antenne. Vielleicht nachts die Antenne mal bischen drehen, also nicht schräg stellen, sondern um die senkrechte Achse rotieren. 30° oder so.
Hallo ksnguyen!

ich habe schon einige Module ausprobiert. Angefangen vom NEO-6M über Beitian-BN220 bis hin zu NEO-8M, wobei letzteres am stabilsten läuft. Das Modul ist fest im Raspi verbaut, ich werde ihn wohl mal am Stativ anders Montieren.
Eine betagte Bluetooth Maus benötigte auch länger, bis ein Fix anstand, es dauerte allerdings ~20Min und die Qualität war schlecht.
 

Anhänge

  • DSC_0521.JPG
    DSC_0521.JPG
    470,9 KB · Aufrufe: 342
  • DSC_0522.JPG
    DSC_0522.JPG
    303,8 KB · Aufrufe: 326
Zuletzt bearbeitet:
Noch ne Frage: Lädst Du ein Kernelmodul, oder schreibst Du die Software als User-Space-Programm? Wir könnten uns da zusammen tun.

Ich habe das Thema bei mir noch hinten angestellt, da ich immer noch Software-Fehler bei meinem wireless-seriellem-Kabel habe.

Die RTC wird über I2C als solches eingebunden und hwclock kann damit direkt umgehen (/dev/rtcx).
GPS wird über die serielle Schnittstelle angebunden und beim Dienst gpsd als solches angemeldet.
Sind alles Systemdienste.
NTPd greift über SHM auf die GPS Daten zu für ein TimeSync.
Was ich noch Suche, ist ein Bluetooth Modul mit zwei UART's. Da könnte ich sogar das GPS-Modul in die Meteostation auslagern, und die steht immer genug weit weg, um keine Störungen einzufangen.
 
Linux ist so krass.

Das Zeug ist in der astroberry-Distribution schon vorinstalliert. Testweise habe ich auch mal die mobilen Daten meines Smartphones dem RPi per USB-Thethering zugewiesen und tatsächlich bei aktivierter Standorterkennung wird die Position auch dem RPi bereitgestellt.

Die astroberry-Distribution hat im INDI-Webmanager auch gpsd zum aktivieren drin und eine Map mit aktuellen Standortinformationen im Webinterface. Die astroberry-Jungs haben da tolle Arbeit gemacht.

Ich habe an der Stelle den Vorschlag, ein bis zwei Software-Ebenen höher zu arbeiten, glaube aber das im Linux schon alles fertig ist:
gpsd-clients ist eine Toolsammlung von Programmen um GPS zu debuggen und Module zu steuern. Das macht auf mich einen soliden Eindruck, wenn ich mir gerade so den Quellcode anschaue (apt-get source gpsd-clients). Die Portieren die GPS-Daten auf ein konformes IP-Protokoll, an dem sich der Client bindet, wie auch gpsd das tut.

Dabei wird der Ublox Treiber im Quellcode unter driver_ubx.c/.h geführt. Das AZ-NEO sehe ich dort nicht, das würde ich dann aber den udev-Mechanismen überlassen.

Ob die Hardware erkannt wird, kann auch geprüft werden mit
udev-adm monitor (Zeigt die Hotplug-Events, wenn das Gerät an und abgesteckt wird) (Beenden mit CTRL+C).
dmesg (Kernelnachrichten)
lshw

Das INSTALL Manual sagt zur Vorbereitung, die UART soll vorher konfiguriert werden (mit stty) und die folgenden Bibliotheken werden noch benötigt:

apt-get update
apt-get dist-upgrade
rpi-update
reboot
apt-get install scons libncurses5-dev python-dev pps-tools
apt-get install git-core

(Curses ist für grafische Oberflächen, PPS-Tools für den Zeitgeber, Git ist Git und Scons liefert eine Programmiersprachen-Querübersetzung zur Portation von Programmen für Webinterfaces. Läuft das Raspberry mit Wheezy muss noch mehr gemacht werden als einfach nur apt-get install gpsd-clients.


Die haben auch RTC-Support und bringen wie vermute die Uhrzeit von PPS zum NTPd:

"[...] You can verify gpsd is using the PPS by running ntpshmmon:
--------------------------------------------------------------
~ # ntpshmmon
# Name Seen@ Clock Real L Prec
sample NTP0 1461619703.641899335 1461619703.445224418 1461619703.000000000 0 -1
sample NTP2 1461619703.642203397 1461619702.999262204 1461619703.000000000 0 -20
sample NTP0 1461619704.142097363 1461619703.445224418 1461619703.000000000 0 -1
sample NTP2 1461619704.142204134 1461619703.999258157 1461619704.000000000 0 -20
--------------------------------------------------------------
If you do not see NTP2 then you misconfigured the pps_gpio driver.
The serial time is provided to ntpd on NTP0, the PPS time is on NTP2, not
on NTP1 like described earlier. So your ntp.conf will need to be adjusted
from: [...]"

Das Modul ist fest im Raspi verbaut, ich werde ihn wohl mal am Stativ anders Montieren.
>> Wenn eine Patch-Antenne verwendet wird, einfach (ungefähr) horizontal positionieren wie das Bild zum NEO-6M zeigt. Da das GPS Signal sowieso von überall herkommen wird, abhängig von den Satellitenpositionen, gibt eine versuchte genaue Ausrichtung auch keinen Sinn. Noch was: Verwendet Ihr nicht aktuelle Satelliten-Ephemeriden, dann braucht es einfach bis zu 5 oder 6 Minuten, bis die Position errechnet werden kann. Das Zeitsignal kommt auch von GPS (PPS-Modul in Linux (Pulses per seconds)). Das oben genannte INSTALL-Manual sagt auch:

"[...]​
5. Have patience. If you are cold-starting a new GPS, it may take
15-20 minutes after it gets a skyview for it to download an ephemeris
and begin delivering fixes. [...]"​

___

Ein zweites Bluetooth Modul ist nicht notwendig. Wenn es darum geht einfach nur das /dev/ttyXY zu duplizieren, reicht ein einfaches C-Programm, dass die UART nach /dev/pts/XY forked. Dafür sollten wir aber ein neues Thema erstellen.

Grüße erstmal (wieder),

Sebastian.
 
Ein zweites Bluetooth Modul ist nicht notwendig. Wenn es darum geht einfach nur das /dev/ttyXY zu duplizieren, reicht ein einfaches C-Programm, dass die UART nach /dev/pts/XY forked. Dafür sollten wir aber ein neues Thema erstellen.

Grüße erstmal (wieder),

Sebastian.
Hallo Sebastian,
ich will nicht duplizieren, ich möchte zwei serielle Datenströme in einen Bluetooth-Link packen.
z.B. auf /dev/rfcomm0 kommen die Daten von der Meteostation an und auf /dev/rfcomm1 die vom GPS-Modul,
oder logisch richtiger /dev/rfcomm0.0 und /dev/rfcomm0.1. Die Beiden Datenformate sind zueinander nicht kompatibel.
 
Hallo Sebastian

Ich wäre sehr vorsichtig mit diesem Befehl - es gibt nur ganz wenige Use Cases, wo Firmware- und Kernel-Update notwendig sind.

Grüsse, David

Hallo David!
wichtig ist die Commit-Number, welcher Kernel genau da installiert werden soll
Code:
sudo rpi-update {Commit-Nummer}
Genau beschrieben wird das Hier. Wenn man das beachtet und sich genau informiert, kann man da durchaus einige stabilisierende Effekte erzielen und sogar im 64-Bit Modus den Kernel laufen lassen, was den Raspi effizienter macht.
Hab ich hier am laufen, extrem stabil.
 
Hallo Thomas,
Ein BT Modul mit zwei UARTs kenne ich nicht. Warum nimmst du nicht zwei HC05 oder HC06?
Ich habe mal bei den BT-Modulen mich informiert. Es gibt lt. Spezifikation nur einen schnellen UART-Kanal, parallel laufen noch andere Sachen wie Audio etc. Die haben allerdings nicht die Bandbreite und die Saignale werden im Bluetooth-Stak auch anders behandelt. Die Idee ist nicht schlecht, wenn da nicht die Quasselstrippe GPS wäre.
Die Meteostation überträgt nur, wenn sie gefragt wird. Deswegen kann man hier die Abfragezeit nicht ins Uferlose laufen lassen, sonst disconnected BT die Verbindung, weil nix los ist.
GPS haut im 1s Takt die Daten raus, werde mal eine Änderung der Konfig nach dieser Anleitung probieren
 
Hey zusammen - Danke Thomas für die Erinnerung ;-) Eine Kopie der SD-Karte mache ich immer wieder mal. Die gehen naturgemäß auch sehr schnell kaputt, ScanDisk und Kingston sind noch die langlebigsten.

Das merkt man auch immer sehr spät, zu spät wenn so viele Sektoren im Nirvana sind, dass man eben keine Image-Kopie mehr machen kann. Linux macht da immer heimlich Umhänge- und Reparaturarbeiten, und ich ignoriere die Kernelmeldungen gerne. An dieser Stelle ist vielleicht gut anzumerken, dass man Bildaufnahmen und große Schreibzyklen eher auf einen USB-Stick oder Cloudspeicher parken sollte.

Ein defekter Kernel ist auch kein Beinbruch: SD-Karte an PC, neuer Kernel drauf und die boot-Konfigurationen anpassen.

Was ich allerdings immer mache ist das Home-Verzeichnis von einer seperaten Partition einhängen, dann kann auch einfach das Betriebssystem wechseln bei Bedarf und mit dem Home-Verzeichnis einfach umziehen (Einstellung in /etc/fstab).

Es gibt noch so viele abgefahrene Möglichkeiten der Systemhärtung...
 
Hey liebe Astros,
jetzt weiss ich, warum der Raspberry bei mir in der Spielzeugkiste liegt.
Clear Skies
Dietrich
 
Vielleicht weil er kinderleicht zu bedienen ist :unsure:

Ganz ehrlich wenn der Raspi im Netzwerk ist holt er sich wie jeder PC die Zeit vom Netzwerk.
Wenn man GPS anschliesst kommt die Zeit vom GPS .
Hat man beides nicht kann man ein RTC Modul für etwa 4€ verbauen. Das ist zwar nicht supergenau aber für ein paar Tage ohne Sync ist es genau genug. Das wird nur angesteckt und einmal eingestellt.
Ich habe nicht viel Ahnung von Linux und trotzdem habe ich es mit wenig Aufwand zum Laufen gebracht.
 
Hallo Thomas,

Ich benutze StellarMate OS. Das ist ein fertiges Image mit allem was der Astrofreund braucht und das kostet 49$.
Da macht man nicht mehr als sein Astroequipment zu konfigurieren. Da es schon automatisch in KStars bootet muss man da nichts mehr zusätzlich installieren oder sich mit dem Betriebssystem rumschlagen. INDI inklusive aller Treiber ist vorinstalliert. Man kann weitere Karten herunterladen per Knopfdruck ein SW Update machen, ...
Im EKOS Paket, das in KStars integriert ist, hat man alles was man so braucht, Kamerabedienung, Goto, Polaralignment, Fokus, Guiding, Sternkatalog, Plate Solving, automatisches Fokussieren nach n Bildern, Joystick Steuerung, da ist sogar Unterstützung für exotisches Equipment wie Staubdeckel oä. dabei.
Das soll mir mal einer auf einem PC inklusive HW und Betriebssystem für komplett 100€ zeigen.

Natürlich kann man es auch kompliziert machen, muss man aber nicht.
 
Hi Roger.

Das soll mir mal einer auf einem PC inklusive HW und Betriebssystem für komplett 100€ zeigen.


Die Rechnung geht nicht auf. Mit der notwendigen Peripherie UND SM OS kommst Du mit 100 Euro lange nicht hin. Außer Du hast eh alles herumliegen, aber dann stimmt die Rechnung auch nicht.

Ich hab' mir eben einen NUC geholt, weil der Pi Lucky Imaging nicht hinbekommt und ich keine Lust habe eine SSD am Pi zu verwenden. Den kleinsten NUC mit x86 bekomme ich für etwa 105€. Inkl. Netzteil und Gehäuse. Dazu 4GB RAM für 20 € und eine 128 GB SSD für 25 €. Das sind 150 € für ein System dessen Performance den Pi recht alt ausschauen lässt und eine kompatiblere Plattform bereitstellt. Einzig die GPIO fehlen, aber die nutzt am StellarMate, AstroBerry & Konsorten eh kaum jemand.

Ich hab mir übrigens einen NUC mit Pentium J5005 und 8GB Ram geholt. Jaja, ich hab's krachen lassen ;)

Viele Grüße
Sven
 
Hallo Sven,
Nun ja ein Raspi kostet 35€ (57€ bei 4B mit 4GB) eine SD Karte mit 64GB liegt bei 10€, Gehäuse 5€ ,Netzteil 10€, StellarMate OS 44€. Da sind wir bei 104€ inklusive aller SW die du bei einem NUC nicht hast. Da musst du zumindest noch Windows mit einrechnen wenn du eine kompatiblere Platform haben willst. Das Netzteil brauche ich aber nicht mal wenn ich mobil unterwegs bin da meine Powerbox direkt 5V liefert. Stromverbrauch liegt im Schnitt bei 600mA. Das ist Größenordnungen weniger als jeder PC und das zählt wenn man mobil unterwegs ist.
Allerdings habe ich mich persönlich bei Windows mehr über Probleme mit Treibern etc. geärgert als bei StellarMate.
Bei StellarMate war der Setup all meiner Geräte (ASI, ATIK, QHY, Canon, SX Lodestar, Polemaster, SX Filterrad, FocusLynx, EQ MOD Montierung über Bluetooth, Joystick, GPS) in 10 Minuten erledigt und ich hatte keine Upgrade Orgien seitdem.

Du hast Recht für Lucky Imaging ist der PI 3B+ nicht gut geeignet wie es beim PI 4B mit mehr DRAM und USB3 ausschaut weiss ich nicht.
 
Hi Roger,
das ist preislich die selbe Liga. Und die Performance des NUCs ist deutlich besser. Und ich brauche kein Windows für den NUC, mit kompatibel meinte ich die Architektur, also x86(_64) vs. ARM. Aber egal, in einem Hobby, in der ein Adapter von M42 auf M48 45€ kostet, interessiert mich der geringe Aufpreis für tatsächlichen Mehrwert (natürlich abhängig von der Anwendung) nicht. Und 12V brauche ich sowieso für Montierung, Fokus und Kamerakühlung. Dann nehme ich die Batterie halt eine Nummer größer.

Was ich eigentlich sagen möchte; beide Systeme haben Ihre Vor- und Nachteile; der Preis ist es aber sicherlich nicht.

Leider läuft das Lucky Imaging auch mit RPi4 und 4GB RAM nicht, zuindest nicht auf SD oder USB3-Stick. Mit FireCapture und einer ROI von etwa 1000x1000 Pixeln komme ich auf einstellige Frameraten mit langen Verschnaufpausen (20 bis 30s!). Der NUC z.B. macht bei der ROI mindestens 40 FPS, ohne Pausen. aber der hat natürlich hinreichend schnellen Massenspeicher.
Mit einer SSD an USB3 könnte das vielleicht auch am RPi4 klappen. Die sind, wenn man Benchmarks glauben mag, tatsächlich ausreichend fix.

Viele Grüße
Sven
 
Status
Es sind keine weiteren Antworten möglich.
Oben