Guten Abend,
hat jemand eine Idee, warum in Siril 1.0.3 das Markieren von Bildern in einem Ordner (z.B. lights) mit Strg+A nicht mehr funktioniert ?
Die Tastatur ist nicht das Problem, in Windows 10 kann ich alle Bilderstapel mit Strg +A auswählen und Strg +C in die entsprechenden Siril Ordner einfügen.
Aber den Bilderstapel in Siril mit Strg+A markieren und öffnen geht nicht mehr...
Ich habe Siril deinstalliert und neu geladen, aber auch damit geht es nicht.
CS Carsten
Hallo Tolga,
die Banding Reduzierung in Siril (1.0.2) kann ich auch sehr empfehlen.
Man muss mit den Werten der beiden Schieberegler "Anzahl" und "1/Sigma" etwas experimentieren, aber dann bekommt man ein besseres Ergebnis als in fitswork.
Am besten kann man die Streifen im Anzeigemodus "Auto-Stretch" oder "Histogramm" sehen. Wenn die Streifen in diesen Modis nach der Bearbeitung nur noch schwach sichtbar sind, sieht man sie bei der weiteren Bearbeitung nicht mehr.
Manchmal hat man in einem Stack auch vertikale Streifen. Die verschwinden sehr gut, wenn man die Box "Vertikale Rasterung" aktiviert.
VG
Carsten
Hallo Alexander,
der Treiber wurde von Howard Dutton entwickelt. Auch die OnStep (Montierungssteuerung) ist von ihm : https://github.com/hjd1964/OnStep
Vor ein paar Jahren habe ich diese Steuerung nachgebaut, der nächste Schritt war der Motorfokus, auch als Selbstbau.
Heute kann man das viel einfacher machen und und es auch nicht sehr teuer:
Die Motorfocus Steuerung ist in dem Paket mit enthalten. Die ASCOM Treiber sind aber ähnlich, wie ich sie auch verwende.
Das Problem ist behoben. Es lag aber nicht an den COM Ports, der Arduino wurde erkannt. Ein Treiberfehler war es auch nicht.
Im ASCOM Forum wurde mir empfohlen, Microsoft .NET Framework 3.5.1 zu deinstallieren und neu zu laden. Letzte Woche habe das Upgrade für ASCOM Version 6.6 installiert und auch bei anderen Usern gab nach es der Installation wohl ähnliche Probleme mit Framework.
Aber nach der Neuinstallation von Framework läuft jetzt alles wieder rund. Aber warum nur die Focuser- und nicht auch die Montierungsteuerung betroffen war, finde ich merkwürdig.
Auf meinem Astro Notebook läuft noch Windows 7, vielleicht hängt das damit zusammen.
Trotzdem vielen Dank für deinen Tipp, so konnte ich zumindest die COM Ports als Fehlerquelle ausschließen.
Viele Grüße
Carsten
Hallo zusammen,
vielleicht schreibe ich einem falschen Thema, aber es geht hier auch um Arduino, Ascom und Error- Handling.
Über den ASCOM Device Hub steuere ich meine Geräte für Astrofotografie : Steuerung Montierung (OnStep) und (OnFocus) in Kombination mit APT und PHD2. Das lief immer ohne Probleme, aber nun habe ich beim Verbinden mit dem Focuser diese Fehlermeldung erhalten.
Den vorhandenen ASCOM Treiber habe deinstalliert und im gleichen Ordner "Focuser" neu installiert, aber das zeigt auch keine Wirkung.
Die Verbindung mit der Montierung funktioniert weiterhin ohne Fehlermeldung.
Hat jemand eine Idee, was diese Ursache dieses Problems sein kann ?
Viele Grüße
Carsten
Hallo Martin,
wahrscheinlich hat Avast etwas überreagiert, über eine Woche lang gab es keine Meldung. Man kann Programme aber wieder aktivieren, nachdem Avast die vorher in Quarantäne geschickt hat.
Jetzt läuft es wieder.
Beim Öffnen von GraXpert ist auch bei mir das Fenster ca. 3 -4 Sekunden schwarz, aber dann kommt die Oberfläche. Ich habe auch die aktuelle Version 0.1.3.
Viele Grüße
Carsten
Ups, beim Öffnen von GraXpert (Windows 10) kam eben dieser Bedrohungshinweis. 
Die letzten Tage war alles o.k, ohne diese Meldung.
Ist das eine ernste Bedrohung oder eine Überreaktion von Avast ?
VG
Carsten
Hallo Frank,
es freut mich, dass du wieder einigermaßen gesund bist. Der trockene Husten hat mich noch 4 Wochen später begleitet, meistens am Morgen. Omikron scheint die Atemwege zu belasten, die ersten 2 Tage nach der Erkrankung konnte ich kaum sprechen. Aber wenn man 2 fach geimpft und geboostert ist, sowie die Infektion einmal durchgemacht hat, soll man gut gerüstet sein. Das sagen jedenfalls die Virologen, dann glauben wir das einfach mal 
Ich habe auch festgestellt, was Harald geschrieben hat. GraXpert setzt auf Nebel, Sternhaufen, Galaxien und Sterne keine Marker, man muss nur wenig Korrekturen machen. Für größere Galaxien wie M51 oder M101 usw. erhalte ich mit 22 Punkten pro Reihe, Gittertoleranz zwischen 5-6 und Smoothing 0,75 sehr gute Ergebnisse.
Hallo Harald,
die Flats habe ich bei diesem Vergleich bewusst wegelassen, weil ich sehen wollte, was die Hintergrund Extraktion bei diesen extremen Bedingungen leistet und welche Software die besten Ergebnisse gibt. Danach hat GraXpert die Nase vorn.
Ich gebe dir Recht, die Windows GraXpert Version scheint aktuell noch einen Tick besser zu sein, als der Siril integrierte Algorithmus.
Beide Fots sind im Siril Bildmodus Auto-Strech abgebildet. Das erste mit Siril Hintergrund Extraktion und das zweite mit GraXpert bearbeitet. Da muss man schon sehr genau schauen, um einen Unterschied zu sehen. GraXpert sieht für mich noch etwas ausgewogener, glatter aus.
Wenn man aber wieder auf einen "normalen" Stretchingmodus geht, werden diese Unterschiede kaum zu sehen sein.
mit Siril HE
mit GraXpert
Hallo zusammen,
gestern habe ich GraXpert geladen, nachdem ich mir Frank's Tutorial angeschaut habe. Bei mir läuft die Siril Version 1.0.2, aber den Reiter "Conversion" mit der Background Extraction finde ich ich nicht. Nach der Anleitung im Link soll der vor Sequenzen stehen.
Unabhängig davon scheint GraXpert gut zu funktionieren, das sieht man hier (Alle Bilder sind im Siril Histogramm Modus, RGB dargestellt):
1. Bild: mit Siril gestackt, sonst unbearbeitet
2. Bild: mit Siril Hintergrund-Extraction bearbeitet, man sieht noch deutlich einen Ring um M51
3. Bild: Original Stack mit APP bearbeitet, "correct vignetting" und "remove light pollution". Das Ergebnis ist schon etwas besser
4. Bild: Original Stack mit GraXPert bearbeitet: Der Hintergrund wirkt für mich am besten ausgeglichen, wenn man den das extreme Stretching in der Histogramm Ansicht berücksichtigt.
Die "Banding Noise" Streifen kann man übrigens mit dem Siril Tool "Banding Reduzierung" hervorragend entfernen, wesentlich effektiver als in Fitswork.
Es ist für mich kein Problem, bei der Hintergrundkalibrierung das gestackte Bild kurz in GraXpert zu laden. Aber wenn man das gleich in den Siril Workflow integrieren könnte, wäre das natürlich genial.
Vielleicht hat Frank eine Idee, wie man diesen Reiter "Background Extraction" ergänzen kann.
Ich hoffe, Frank geht es 2 Wochen nach Corona wieder besser. Kurz vor Ostern hatte ich das auch, aber der Verlauf war bei mir ähnlich wie etwas stärkere Erkältung. 3 Wochen nach der Erkrankung war alles wieder o.k.
Viele Grüße
Carsten
Hallo !
für die Teleskop- und Kamerasteuerung verwende ich ein altes Notebook mit Windows 7, darauf laufen die Programme APT und PHD2.
OnStep Steuerung, Canon Kamera, Guidingcam und Motorfokus sind über einen USB Hub mit dem Notebook verbunden.
Das Notebook ist in das WLAN eingebunden, in der Nähe des Stativs habe ich einen Repeater geschaltet.
Die eigentliche Fernsteuerung des Notebooks erfolgt durch meinen PC oder Tablett über Anydesk, eine ähnliche Plattform wie Teamviever, nur schlanker und deutlich schneller.
Mit dem PC bin ich ca. 25 m von der Montierung entfernt und habe keine Probleme. Man sieht z.B. am PC den Desktop des Notebook und kann mit der Maus zwischen Programmen wechseln oder auch Parameter ändern.
Nur die Poljusttage muss ich noch manuell machen, das habe ich noch nicht automatisiert.
Viele Grüße
Carsten
Hallo Thomas,
im Link zur Wellenkupplung ist der Punkt am Satzende mit drin, den bitte rausnehmen.
Viele Grüße
Carsten
Hallo Thomas,
Den Nema 17 habe ich auch gekauft, allerdings NEMA17-05GM, der hat ein Planetenradgetriebe mit 5:1. Übersetzung. Die Übersetzung der Schrittmotoreinheit ist damit 200 x 5.1 x 32, dann kommt noch das Schneckenrad hinzu.
Bei mir hat die Schneckenwelle ebenfalls einen anderen Durchmesser als die Antriebswelle des Nema 17. Zur Anpassung habe ich eine Wellenkupplung gekauft, die kann man verschiedenen Bohrungsdurchmessern kaufen: Für dich wäre diese Kupplung geeignet: https://www.christians-shop.de…upplung-20mm-25NM-5mm-6mm. Kleiner Nachteil: Die Breite der Schrittmotoreinheit verlängert sich um ca. 27 mm.
Ein weiterer Vorteil: die „geschlitzten“ Wellenkupplungen gleichen Toleranzen aus, wenn z.B. die Schrittmotorwelle nicht 100 % auf die Schneckenwelle ausgerichtet ist.
Die ST4 Anschluss ist eine Möglichkeit zum Guiden, aber es geht auch über den USB Port, an dem der Arduino Mega 2560 angeschlossen wird. Ohne ST4 benötigst du auch ein Kabel weniger.
Für OnStep kann ich dir den ASCOM POTH Treiber sehr empfehlen, der wird mit OnStep verbunden.
In allen gängigen Programmen wie PHD2, SkyChart, APT usw. kannst du für die Steuerung deiner Montierung ASCOM POTH auswählen und die Verbindung steht sofort. ASCOM POTH kannst du auch mit einem Motorfocus verbinden, in der OnStep 3.16 ist diese Funktion mit enthalten.
Viele Grüße
Carsten
Hallo Ewald,
durch einen dauernden Live View Modus wird der Kamarasensor sehr warm, das hat hohes Rauschen zur Folge. Alternativ kannst du mit DeepSkyStackerLive ein Paket von Einzelbildern stacken und siehst dann live auf dem Bildschirm die Entwicklung. Über ein LAN Kabel oder Teamviewer auch im warmen Wohnzimmer. Mit SharpCap geht das auch sehr gut.
Viele Grüße
Carsten
Hallo Thomas,
du musst nicht unbedingt mit diesem Calculator arbeiten, das Übersetzungsverhältnis kann man relativ einfach berechnen, in der OnStep Config.h ist diese Formel beschrieben:
Für RA:
“Define Steps per Degree Axis 1” = Stepper Steps x Micro steps x Gear reduction 1 / 360
Gear reduction 1 könnte z.B. noch ein Zahnriemenantrieb zwischen Schrittmotor und Schnecke sein.
Dein Stepper hat 200 steps, der Treiber 4988 hat max. 16 Micro Steps, das Schneckenrad hat 180 Zähne.
In „Define Steps per Degree Axis 1“ trägst du also 1.600 ein: (200 x 16 x 180/360)
Für DEC:
Das Zahnrad für die Deklination hat 36, die Welle 12 Zähne, damit hast du eine Übersetzung von 3 (36/12). „Define Steps per Degree Axis 2“ = 200 x 16 x 3/360 = 26,7
Mit dem Conrad Getriebe wäre das Umsetzungsverhältnis natürlich deutlich höher. Besser und auch nicht teurer als der Treiber 4988 ist der DRV8825 mit 32 MS, der hat also die doppelte Übersetzung.
Es lohnt sich, die Anzahl der Zähne exakt zu zählen, um den richtigen „Steps per Degree“ Wert zu berechnen, das Guiding läuft besser und benötigt nicht so viele Korrekturen.
Drei Fragen habe ich noch:
Mit welcher OnStep Version willst du arbeiten ?
Warum willst du über ST4 guiden ? Ich mache das ganz normal über USB, das geht problemlos.
Und wozu benötigst du die Ramps 1.4 ? Meine OnStep Steuerung hat nur den Mega 2560 und die beiden DRV8825.
Viele Grüße
Carsten
Hallo Jörg,
wenn ich die englischen Erklärungen in der PHD Beschreibung der Guiding Algorithmen richtig verstehe, hat der PHD-PPEC Modus gegenüber den üblichen PEC Korrektoren deutliche Vorteile.
Viele Montierungen haben eine PEC Korrektur, die aber nur selten gut läuft, weil es trotz PEC häufig Wiederholungsfehler gibt. Besonders wenn Trackingfehler mit einer Frequenz auftreten, die nicht dem ganzzahligen Bruchteil einer Schneckenperiode entspricht, können die meisten PEC Korrekturen diese Fehler nicht beheben. Ich verwende z.B. OnStep für meine Montierung, die hat ein PEC Korrektur, aber ich merke keinen Einfluss auf das Guiding, egal ob PEC an oder aus ist.
Der Ansatz von PPEC ist, dass der Algorithmus unterschiedliche Zyklen zur Bestimmung der möglichen Fehlerquellen analysiert:
Kurzfristig: für hochfrequente Fehler, wie z B. Zahnradrauheit oder Seeing
Mittelfristig: für periodische Fehler, die üblicherweise in Intervallen auftreten, die kleiner oder gleich der Schneckenperiode sind.
Längerfristig: für stetige Drift mit niedrigerer Frequenz (längeres Zeitintervall), die durch mehrere Zahnräder im Antriebsstrang verursacht werden (z.B. Planetenradgetriebe im Schrittmotor, Zahnriemenantrieb usw.)
Um nur die vorhersehbaren Einflüsse zu erkennen, werden die kurzfristigen Fehler ausgefiltert.
PPEC verwendet einen Lernprozess über ca. 2 Schneckenumdrehungen, um das Verhalten der Montierung zu analysieren. Während dieser Trainingsperiode verhält sich der Algorithmus wie der "Hysterese" -Algorithmus, sodass man normalerweise nicht bemerkt, wie im Hintergrund das interne PPEC Modell erstellt wird. Das Tracking soll sich stetig verbessern, während sich das Modell immer weiter verfeinert und der Algorithmus nahtlos von der Hysterese in den Vorhersagemodus wechselt. Diese Verbesserung soll sogar zu beobachten sein, bevor das mittelfristige Montierungsverhalten vollständig modelliert ist.
Das klingt doch schon mal gar nicht so schlecht, für lange Belichtungsserien scheint das ideal zu sein.
Um das rauszufinden, werde ich es mal ausprobieren, vielleicht haben andere Astrotreffler auch Interesse daran. Ich habe zwar im Netz gesucht, es gibt aber kaum Erfahrungen mit diesem Algorithmus.
Hier noch der Link zu der Erklärung der Guide Algorithms:
https://openphdguiding.org/man-dev/Guide_algorithms.htm
Viele Grüße
Carsten
Guten Abend !
Kurz vor Vollmond eine Frage an die PHD Experten.
Im RA Menü der aktuellen PHD2 Version gibt es die Auswahl „Predictive PEC Guide Algorithm (PPEC)”.
Lt. PHD User Manual analysiert der Algorithmus das Tracking der Montierung in Echtzeit und berechnet und löst erforderliche Korrekturen aus, bevor periodische Fehler auftreten. Mechanische Unregelmäßigkeiten z.B. an der Schnecke können solche periodischen Fehler verursachen.
Durch diese proaktiven Korrekturen wird die Zeitverzögerung kleiner, wodurch die Genauigkeit des Guiding erheblich verbessert werden kann.
Alle anderen Algorithmen in PHD2 reagieren erst dann, wenn die Gudingcam eine Abweichung erkennt.
Das klingt grundsätzlich interessant, aber bringt dieser Algorithmus wirklich einen entscheidenen Vorteil ?
Viele Grüße
Carsten
[:)]
Hallo Dirk,
mein Beobachtungsort ist Geesthacht, ca. 30 km südöstlich von Hamburg. Die Lichtverschmutzung ist deutlich, meistens Bortle 5.
Je größer die Lichtverschmutzung ist, desto geringer sollte die Belichtungsdauer sein. Dieser Zusammenhang wird hier sehr gut beschrieben, es gibt eine „max. sinnvolle Belichtungsdauer“, die „entscheidend abhängig ist von der Teleskopöffnung, vom Abbildungsmaßstab (wieviele Quadratbogensekunden Himmel pro Pixel), vom Eigenrauschen der Kamera und von der Qualität des Nachthimmels“.
https://astrofotografie.hohman…elichtung.astrokamera.php
Um diese max. Belichtungsdauer zu ermitteln, gibt es ein einfaches Verfahren: Grundlage sind Bias Bilder der Kamera, also das Grundrauschen ohne Lichteinwirkung, bei einem gewähltem ISO Wert. Diesen Wert RMS)kann man mit Fitswork auslesen.
Durch eine Fotoserie (Lightframes) mit dem gleichen ISO Wert und unterschiedlich langer Belichtungsdauerfindet man die sinnvolle Belichtungszeit: Man fängt z.B. mit 20 sec an und belichtet jedes weitere Bild 15 sec länger.
Für jedes Lightframe der Serie schaut man sich nun in einem überwiegend schwarzen Bildbereich den RMS: Ist dieser RMS Wert doppelt so hoch wie der RMS Wert des Bias, ist die optimale Belichtungszeit erreicht. Eine längere Belichtungsdauer bringt nichts mehr. Es ist daher sinnvoller, mehr Bilder mit der optimalen Belichtungszeit zu erstellen.
An meinem Beobachtungsort Geesthacht sind mit der Canon EOS 60dA bei ISO 1000 und 45 sec Belichtungszeit die Rauschwerte des Light- und Biasframe ungefähr gleich. Bei 60sec ist das Rauschen des Lightframes schon größer.
Ich glaube, dass du von M33 mit 256 x 30 sec noch deutlich mehr Details bekommst, als mit 64 x 120 sec.
Man erzeugt mit den kurzen Belichtungszeiten zwar wesentlich mehr Dateien, das kostet viel Speicherplatz und stacken dauert deutlich länger, aber es lohnt sich nach meiner Erfahrung.
Viele Grüße
Carsten
Hallo Konrad,
OneStep kann ich sehr empfehlen, ich verwende die Steuerung seit 4 Jahren und bin sehr zufrieden. Ich steuere ine parallaktische Montierung, aber OnStep geht auch für azimutale Monierungen. Das Prinzip basiert auf einer Schrittmotorsteuerung für beide Achsen. Das Software ist kostenlos, die Hardware kann man günstig und relativ einfach selber bauen.
Hier der Link zu OnStep: http://www.stellarjourney.com/
Viele Grüße
Carsten
Hallo zusammnen,
der Komet Neowise über der Seebrücke von Graal Müritz an der Ostsee. Trotz der beleuchteten Seebrücke und der blauen Stunde konnte ich den Kometen sehr gut zu erkennen. Aber auf dem Fotos kommt er noch besser.
Hallo Hans,
tritt dieser Ausreißer der DEC Achse immer wieder auf ?
wenn du etwas länger wartest, korrigiert PHD wieder zurück Richtung 1" ? Auf dem Screenshot geht der Trend schon wieder runter.
Du könntest mal eine neue Kalibrierung in dieser Teleskopposition versuchen, PHD berechnet dabei den Backslash für RA und DEC neu. Wenn du deine Montierung bei jeder Beobachtung neu aufbauen musst, solltest du grundsätzlich neu kalibrieren und nicht die alte Kalbrierung nehmen. In PHD das einstellen, dass bei jedem Start zuerst kalibriert wird.
Ich hatte ähnliche Problem schon häufiger, nach der Kalibrierung in Meridian- und Äquatornähe war alles in Ordnung. Nachdem ich zum Objekt gefahren bin, driftete die DEC ab. Nach der erneuten Kalbrierung an dieser Teleskopstellung lief es stundenlang glatt.
Viele Grüße
Carsten
Hallo Frank,
OnStep wird regelmäßig aktualisiert, meine Version (2018) läuft noch auf Basis eines Arduino Mega 2560. Durch die dynamische technische Entwicklung ist die Plattform nun der Controller Bluepill, ws gibt Applikationen wie Wifi, Ethernet und Motorfocussteuerung, auch bessere Schrittmotortreiber als 2018. Wenn ich mal mehr Zeit habe, schaue ich mir das genauer an, vielleicht ist es sinnvoll, auf diese Plattform zu wechseln. Allerdings gibt es in dem OnStep Forum sehr viele Diskussionen und Fragen wg. diverser Probleme bei der Umsetzung und im Betrieb.
Da meine Steuerung relativ zuverlässig läuft, hat dieses Upgrade für mich erstmal eine geringere Priorität.
Meine OnStep Version macht auch Pulsguiding, ich habe gestern den aktuellen ASCOM OnStep Treiber installiert: http://www.stellarjourney.com/…r=site/software_telescope
Bei der nächsten Gelegenheit werde ich prüfen, ob die PHD und CDC Fehler mit der Aktualisierung verschwunden sind.
Viele Grüße
Carsten
Hallo Frank,
mal wieder ein interessantes und lehrreiches Video.
Ich verwende für meine Montierung die OnStep Steuerung, für den Motorfokus OnFocus (beide von Howard Dutton) und verbinde beides mit APT und PHD über die Schnittstelle ASCOM POTH. Das geht auch mit CDC oder anderen Planetariums Programmen.
Es funktioniert relativ gut, nur mit CDC gibt es die Fehlermeldung „timeout for recieved data“. PDH meckert regelmäßig mit der Meldung „ASCOM Treiber versagte bei Is Puls Guding“, auf das Guiding hat das aber keinen merkbaren Einfluss.
Selten gibt es auch komplette Abstürze. Das ist sehr ärgerlich, weil ich nur durch Neustarten des Notebooks ASCOM POTH wieder aktivieren kann. Dann muss ich mit allen Einstellungen von vorn anfangen: Alignment, kalibrieren, Objekt neu anfahren, Fokus prüfen usw.
Wie du auch in deinem Video sinngemäß sagst: ASCOM ist ein Kompromiss, nicht alles funktioniert perfekt. Aber es ist kostenlos und dafür bietet es eine ganze Menge.
Viele Grüße
Carsten
Hallo Gernot,
Du hast Recht, die Preise der Canon Astrokameras bleiben aufgrund der geringen Nachfrage sicherlich auf hohem Niveau. Diese Optimierungen sind mir nicht bekannt, der Artikel im SuW war der erste gute Praxisvergleich, den ich gelesen habe.
Geschrieben hat das übrigens Frank Sackenheim, der sehr interessante YouTube Videos über Astrofotografie veröffentlicht hat (http://www.youtube.com/astrophotocologne). Frank (frasax) hat Dir auch geantwortet. Ich glaube, er kann deine Frage wg. Dynamik und Rauschen sicherlich am besten beantworten. Grundsätzlich kann ich Dir empfehlen, zum Thema Dynamik und Rauschen dieses Video anzuschauen:
Durch dieses Video habe ich viele hilfreiche Information über Dynamik und Rauschen erhalten. Wichtig ist, einen Mittelweg zwischen ISO Wert, Belichtungszeit und Helligkeit des Himmels finden, um ein Bild mit möglichst hoher Dynamik und geringem Rauschen zu erstellen.
Diese Faktoren in Griff zu bekommmen, hat sicherlich mehr Nutzen, als die paar Punkte mehr, die eine Kamera an Dynamikumfang oder Rauschen lt. technischem Datenblatt hat.
Viele Grüße
Carsten
Hallo Gernot,
im aktuellen Stern- und Weltraum Heft 06/2020 wird die EOS 60Da mit den spiegellosen EOS R und EOR Ra verglichen.
Beim Praxistest ist die H Alpha Empfindlichkeit der EOS 6Da deutlich höher als der EOS R. Der Vorsprung der EOR Ra gegenüber der EOS 6Da ist lt. Test „nicht groß, aber dennoch sichtbar“.
Das Rauschverhalten der EOR Ra ist leicht besser als bei der EOS 6Da. Weitere Vorteile der EOR Ra sind die kompaktere Bauweise und das geringe Auflagemaß, die Anbringung von Komakorrektoren, Flattener oder Filterschubladen wird einfacher.
Die Pixelgröße der EOR Ra ist etwas kleiner, dafür ist die Quanteneffizienz ca. 10 % höher als bei der EOS 6Da.
Allerdings erkauft man sich diese Vorteile mit einem erheblichen Preis, knapp unter 2.700 € kostet die EOR Ra aktuell. Den Body der EOS R kann man schon unter 2.000 € bekommen, eine Astromodifizierung der EOS R wäre günstiger als der Neukauf einer EOS Ra. Man sollte aber beachten, dass durch die Umrüstung der EOS R auch die Gewährleistung entfällt.
Es ist nun die Frage, ob Du jetzt schon umstellen willst oder noch etwas warten möchtest, bis die Preise sinken.
Viele Grüße
Carsten
Hallo Arne,
ein 3D Drucker fehlt mir noch, das wäre wirklich eine große Hilfe für den Selbstbau. Was für einen 3D Drucker verwendest du ?
Mit der Montierungssteuerung OnStep habe ich viel Geld gespart und auch beim Motorfokus, das müsste sich irgendwann mal rechen...;-)
Viele Grüße
Carsten
