Beiträge von JensStark

    Danke euch drei!

    Platz ist das Problem, also wird die große Montierung und der große Tubus (aus einem China-Dobson von Wolfi) unter den Sachen sein, die ich nicht behalten werde.
    Ich werde aber, sobald ich mit dem Packen so weit fortgeschritten bin, die Sachen mal fotografieren und eine Liste machen.

    Gruß,
    Jens

    Tja.
    Ws macht man, wenn man feststellt, daß man das Hobby eigentlich aufgegeben hat?
    Ich ziehe gerade aus Halstenbek bei Hamburg um und stelle fest, daß ich noch alles mögliche liegen habe, teilweise muß ich das noch alles wieder zusammensuchen und testen.

    Gibt es irgendwann mal einen Astroflohmarkt in Hamburg oder nördlich davon?

    Gruß,

    Jens

    Hallo mal wieder nach längerer Pause!


    Ich sah eben bei mehreren Händlern eine Skywatcher Merlin.
    Würde die einen kleinen Mak stabil tagen und schon jemand Erfahrungen damit?


    (Interessant die Preisstuktur. Bei einem Anbieter ist der L-Adapter dabei, bei einem anderen nicht)


    Gruß und CS,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>
    wolfi (microVAX + Fortran77 eggsberde)
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    microVAX? Verzeichnisse mit SET DEFAULT wechseln? :)


    Gruß,
    Jens


    (FORTRAN IV-Frickler auf diversen Plattformen)

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>
    <br />hi!
    ich hätte gerne eine steuerung, die
    - links/rechts/auffi/obi mit 2 geschwindigkeiten per handbox kann - bluetooth wär nett, ist aber nicht notwendig ...
    - einigermassen motorstrom erträgt
    - ST4 versteht
    - sich über LX200 ansteuern (seriell) lässt - und wenns ein INDI/ASCOM treiber ist, der seriell auf TCP...UDP...bits übersetzt, oder ein USB/RS232 konverter ...
    - sich über softwarestandardschnittstellen (!) ansprechen lasst


    ...



    UUUUND


    ...
    - kein pascal zur programmierung braucht (!)


    mehr brauch ich nicht.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Das und die Drehsteuerung sind doch schon mal klare Vorgaben! :)


    Wurde mir wahrscheinlich auch vollkommen reichen - alles andere kann bei lokalem Einsatz ein Netbook machen. Für das, was die mittlerweile kosten, lohnt es kaum, die Hardware für diesen Teil der Steuerung zusammenzulöten. Und wenn es GANZ einfach sein soll: Selbst auf wunderlichen Gurken wie diesen läuft angeblich Limux:


    http://www.dealextreme.com/details.dx/sku.39391



    Also. Fasse ich noch einmal zusammen:


    - Steuerung steuert (max.) drei Motoren.


    - Schnittstellen: ST4-Port und (intern) Seriell für LX200, eventuell erweiterbar auf USB, Bluetooth, Ethernet, WLAN, was auch immer - für den Einbau kann man ja Platz im Gehäuse vorsehen.


    - dazu Anschluß für einfache Handbox (nur Potis, Taster, Schalter, LEDs etc.).


    Wäre für mich als Projekt noch überschaubar, wahrscheinlich preiswert genug zu realisieren und setzt auf erprobte Standards (LX200 und ST4).


    Logisch. Sowas kann man fertig kaufen. Eine EQ-5 damit und mit Motoren und Netbook auszustatten, wird wahrscheinlich nicht billiger, als eine CAM zu kaufen. Nur kann ich beispielsweise bei einer "offenen" Steuerung dem System klar machen, daß ich GOTO nicht mit ohrenschädlicher Höchstgeschwindigkeit sondern zügig aber langsam möchte. Dazu noch kann ich an Software verwenden, was ich will.


    Würde ich als kommerzielel Proidukt wahrscheinlich kaufen! :)


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>
    hier prallen WELTEN aufeinander. der controller will nur bits/bytes - der socket liefert das. wieso so kompliziert?
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Yep. Trotzdem ist so ein wenig Sicherheit mit TCP keine schlechte Sache.
    Kommt halt auch darauf an, was preiswerte Ethernet-Hardware so kann, und das ist inzwischen nicht ohne.
    Eine Ethernetlösung für den Arduino arbeitet beispielsweise mit dem W5100 von Wiznet. Kostet wohl um die 5€, kann aber überraschend viel.


    Schau mal:
    http://www.i-vis.co.jp/pdf/wiz…tasheet_v1%5B1%5D.0.1.pdf


    Damit kann man sicher schon mit dem Arduino Mega und dem Servo-Shield eine primitive, netzwerkfähige Motorsteuerung bauen.


    Gruß,
    Jens


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>
    genau, IP hat so viele Vorteile ... daß als erstes Mal UDP/TCP drübergestülpt wurden, damit man (im letzteren Fall) überhaupt sagen kann, ob ein Datenpaket beim Empfänger angekommen ist.


    Und darüber kommen dann Protokolle, mit denen man wirklich etwas anfangen kann ... ftp, http, um zwei verbreitete zu nennen, die standardisierte Methoden/Funktionen bereitstellen (z.B. PUT, POST).
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Brauchst Du mir nicht wirklich zu erklären - habe mal eine Zeitlang in dem Bereich unterrichtet und bin nicht bei Datenkommunikation mit Kermit hängengeblieben. :)


    Aber irgendwie bewegen wir uns hier auf einem Nebenschauplatz.


    Das Bild auf Seite 8 habe ich eben noch einmal studiert.


    Der Kasten links in der Mitte ist eine große, eierlegende Wollmilchsau. Fehlt noch die Ansteuerung für die Kuppel und Bildfelddrehung.


    Im Augenblick erinnert mich das Ganze ein wenig an die berühmte Graphik mit der Schaukel, hier mal in einer mir zuvor aucn noch nicht bekannten Version:


    http://code.reduxo.de/media/20…aukel-baum-seil-gross.png


    Aalso.


    Das Teil muß ja nicht viel können. Jeden Montierungstyp mit jeder Motorisierung. Angesprochen wird es seriell, über USB, Ethernet, Bluetooth, Firewire, seriell und wohl auch noch WLAN (dann aber nicht ohne 802.1X!) und SNA. Angesteuert werden muß alles bis einschließlich der Sucherheizung.
    Wesentliche Funktionen (alles bis auf die Sucherheizung) müssen aber auch durch einfache Handbox bedienbar bleiben. Es darf nix kosten und muß mit wenig know-how zu fertigen sein.


    Geht alles, wird dann aber wahrscheinlich 2065 in den ersten Test gehen. :)


    Also. Wo liegt die 90%-Lösung? <b>Was ist unbedingt notwendig, was ist nice-to-have?</b>


    Und - reichen wir mit einem einzigen Thread hier aus? Ich finde nicht, daß das Ganze noch wirklich übersichtlich ist.


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>
    Und weshalb sollte man mit Socket-Programmierung anfangen - wenn es die CPU des Moduls hergibt macht doch gleich was Anständiges ... Webservices - saubere API, universelles Protokoll mit SOAP/HTTP :)
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Bist Du Webdesigner? :) Egal, welche Datenmengen man schiebt, Hauptsache, das Ganze ist in feinstem XML geschrieben.
    Bitte dann aber auch mit Schnittstellen an SAP und DATEV :)


    Webinterface mag Sinn machen - aber nicht jeder will sich unendlich viel Encapsulation geben. Fatware läßt grüßen...


    Nichts gegen "lesbare" Protokolle! Um Himmels Willen - ich habe hier in der Firma Geräte, die Statusmeldungen in 4K großen Binärdateien reporten. Die Zahlen dann je nach Laune in BCD oder binär.
    (Ach so, je nach Gerätegeneration auch noch in verschiedenen Varianten.) Ähnlich lesbar wie SMB-Pakete von Microsoft :)


    LX200 scheint mir da schon etwas lesbarer. Aber es ist zumindest ein Standard - da erfindet man nicht notwendigerwese das Rad neu.


    Und auch TELNET (oder SSH) ist ein erprobter Standard - und für LX200 schreibt sich schneller ein Parser als für einen neu zu definierenden SOAP-basierenden Standard. (DEN Kram sprechen die gleichen Geräte übrigens auch. Vor lauter Bibliotheken haben die Entwickler kaum noch Platz für Funktionen, die dem Benutzer wirklich etwas bringen...)


    Ich gebe allerdings AUCH zu, daß ich ein Fable für Kommandozeilen habe. :)


    Gruß,
    Jens

    Wenn wir abstimmen würden - IP hat eindeutig Vorteile. :)


    Plattformunabhängig, läuft über alles mögliche an Medien, kann alles mögliche simultan, ist netzwerkfähig :)...
    Dazu noch gibt es offene IP-Stacks, teilweise sogar schon auf Ethernet-Chips fertig und man hat etablierte Standards. Sofort läßt sich das mit allem verbinden, was IP spricht - und das sind mehr Systeme als bei USB.


    Die Frage ist nur - welche Funktionalität braucht die Steuerung auf der Montierungsseite des Netzwerkkabels?
    Mit Sicherheit eine Handbox(-ansclußmöglichkeit), aber wo trennt man die Komponenten? Über das Internet direkt Motoren anzusprechen, halte ich aus diversen Gründen für Unfug. Einmal eingestellt sollte die Montierung schon nachgeführt werden, dabei die mechanisch nicht mögliche Positionen und die Sonne vermeiden(!), vielleicht sogar auf lokale Autoguiding-Signale reagieren können. Filterrrad und Kamerasteuerung können andere autarke Einheiten übernehmen.


    Das heißt aber: Die Montierung muß wissen, wo sie steht (GPS-Anschluß vorsehen?), sie muß Datum und Uhrzeit kennen, muß in der Lage sein, ihre eigene Ausrichtung (Az/El.) irgendwie nachzuvollziehen und in der Lage sein, verschiedene Standardobjekte autark nachzuführen, auch wenn sie sie nicht beim Namen kennen muß.


    Warum der Aufwand? Das schöne Teleskop mit der neuen Kamera neben der Berghütte verliert irgendwann den Kontakt zum Kontrollrechner, weil das Konto der GSM-Karte erschöpft ist. Dann soll sie weder versuchen, ungefiltert Bilder der Sonne aufzunehmen, noch mit grober Gewalt versuchen, 720° nachzufahren, weil sie nicht weiß, daß das nicht geht und etwas kaputt macht.


    Alles, was das nicht kann, würde ich nicht für sinnvoll vernetzbar halten. Im Augenblick komme ich also auf drei Komponenten:


    1) Motoransteuerung (jeweils in beide Richtungen, mit mehreren Geschwindigkeiten) mit angebauter Handbox.


    2) Box, die mit eigener Intelligenz Katastrophen verhindert und ansonsten autark nachführt. Optional kann sie natürlich mehr, aber eigentlich sehe ich das GOTO in einem Notebook oder irgendwas PDA-artigem.


    3) PDA/Notebook/wasauchimmer


    Netzwerk ist ideal für Verbindung von 2 und 3. Verbindung zwischen 1 und 2 ist sicher eher "simpel elektrisch".


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>


    Bitte keine spezial-treiberlösungen, wie sie von elektronikern leider gerne und oft genutzt werden. das ist nicht notwendig und nicht zukunftssicher!
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Da bleibt dann außer Seriell und Netzwerk nicht wirklich viel. (USB HID?) :)


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>


    Mir gefällt die Kombi USB+Ethernet sehr gut - es gibt fertige Bausteine, die an Hardware alles mitbringen, die Programmierung ist vielleicht kein Spaziergang aber Dank entsprechender Bibliotheken gut machbar - über Bluetooth-Adapter (am USB-Port) oder einen WLAN-Router (Ethernet) läßt sich an Distanzen so ziemlich alles überbrücken ... und wenn die Privatsternwarte auf der anderen Seite des Erdballs steht!
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Meine Meinung zu USB habe ich ja schon lautstark kundgetan :)


    Die Frage ist hier ja - welche Komponenten sollen kommunizieren? Wenn die Komponente "Motorsteuerung" wirklich nur diese Aufgaben übernimmt (zwei Motoren in verschiedenen Geschwindigkeiten und Richtungen fahren und vielleicht noch Status/Positionsmeldungen abgeben), würde ich zumindest noch ein wenig mehr Logik auf der Teleskopseite des Netzwerkkabels haben wollen. Das ist ja die Komponente, die mit einer einfachen Handbox gefahren werden können soll oder diese sogar enthält.


    Der Schritt darüber wäre dann der Betrieb durch eine Komponente, die die Handbox im einfachsten Falle emuliert, aber mehr kann.


    Diese beiden Komponenten brauchen zwar ein definiertes Interface, aber das wird sicher keinen Webserver brauchen :)
    Dafür aber eventuell einen Stecker, der ein wenig mehr aushält und eine ausreichende Anzahl an Verbindungen zur Verfügung stellt.


    Sobald diese Box dann beispielsweise in der Lage ist, Koordinaten anzufahren und beispielsweise einen Systemstatus zurückzuliefern, würde allerdings in meinen Augen eine Netzwerkverbindung - oder eine andere Art "klassischer Byteströme" Sinn machen.


    Gruß und CS,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>
    <br />Hallo Jens,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    sorry, da bist Du völlig auf dem Holzweg ...
    Fakt ist, daß kaum ein PC/Notebook noch mit serieller Schnittstelle ausgerüstet ist - und Adapterkarten zum Nachrüsten sind inzwischen auch eher Mangelware.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Wäre ja auch Unfug. Heutzutage setzen aber viele Systeme (auch der Arduino) Seriell-&gt;USB-Wandler ein. Auf dem PC läuft dann ein Treiber, welcher eine virtuelle serielle Schnittstelle anbietet. Das gibt es auch für Seriell auf Bluetooth und was nicht alles.


    Mir wäre ja irgendwas mit sauberem IP-Stack auch lieber, aber wir wollen ja klein bleiben.
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Und hier im Forum wirst genügend Beiträge von Leuten finden, die mit USB-/Seriell-Adaptern ihre liebe Mühe hatten und haben ... des Glump dut nämlich net zuverlässig!
    [quote]
    Nun, ich gehe schon davon aus, das Ganze mit "vertrauenswürdigen" Empfehlungen zu versehen. USB ist ja nun auch nicht unproblematisch - was nutzt einem automatische Geräteerkennung, wenn man keine Vendor-ID bekommt oder bezahlen will und was ist mit Leuten (die es durchaus gibt), die mit anderen Geräten als PCs oder Notebooks auf das Teil zugreifen wollen? (Zu Zeiten von Entwicklern, die teilweise nie etwas anderes als i386 gesehen haben, allerdings fast eine verzeihliche Annahme.)
    [quote]
    Ich weiß nicht, ob Du Anwendungs- oder Systementwickler bist - aber
    ein sauberes Protokoll auf RS-232 zu implementieren ist NICHT trivial.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Oh, ich entwickle seit Jahren nur noch gelegentlich, eines meiner ersten Projekte war allerdings etwas zur Datenübernahme von WANG 2200 auf Norsk Data ND100. Zufällig seriell - mit den damaligen Systemen durchaus hundsgemein. Seitdem alles mögliche andere, von Kernelpfuschereien (macht Spaß) bis hin zu Anwendungssoftware (bringt länger Geld). Aber wie gesagt - als "Hello World" als installierbares Programm mit einer der Umgebungen von MS nicht mehr auf eine Floppy paßte, wurde mir das Ganze zu bunt. Das überlasse ich dann den jungen Leuten und schreibe höchstens mal was für den Eigenbedarf.


    Ein sauberes, serielles Protokoll zu entwerfen und zu implementieren war zumindest früher grundlegendes Handwerkszeug. So viel kann da nicht wirklich schiefgehen - dafür ist es einfach zu dämlich. Und: Ich muß mich nicht großartig auf riesige Bibliotheken verlassen.


    Interessant wird es, wenn Du auf Schicht 5 patzt, besonders, wenn die Kommunikation nicht nur aus Befehl/Antwort besteht, sondern man auch asynchron Statusmeldungen schicken will. Aber es ist beherrschbar.


    Warum siehst Du ein sauberes Protokoll auf Seriell als schwieriger als beispielsweise auf sockets?
    [quote]
    Zur Handbox - die 'Sparlösung' (nur Richtungstasten + Geschwindigkeit) würde ich inzwischen (schließe mich da der Meinung der 'Puristen' an) komplett an irgendwelchen Protokollen/Stacks vorbei direkt anschließen - im Prinzip Relais, die Strom auf die Stepper geben.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Yep, und sei's als fallback...


    Vielleicht gleich als Notbedienelemente/Testschalter gleich in die Stuerung integriert.


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Gamma Ray</i>
    <br />
    Die haben ja wirklich prima Dinge! [:p] Das Board ist schon gekauft! ;)
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Die haben sogar tolle Sachen :)


    Mit http://www.watterott.com/de/Atmel-AVR-Butterfly
    kann man beispielsweise einen programmierbaren Auslöser für die EOS bauen :)


    Gruß,
    Jens
    (Der mit Motoren und Servos nur mit einem Arduino-Shield gespielt hat, das aber sehr einfach fand.)

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>
    serielle Schnittstelle ist seitens der Hardware vielleicht einfacher - obwohl ich da so meine Zweifel hab - Software-seitig aber ein ziemlicher Horror weil es kein verbindliches Protokoll gibt, im Gegensatz zu USB und Firewire; und von so Goodies wie automatischer Erkennung des Gerätes am Host beim Einstecken haben wir da noch gar nicht gesprochen ...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Ich mag mich hier als DV-Dino outen, aber sowas braucht kein Mensch :)
    Wenn ich auf serieller ebene arbeite, muß ich auf beiden Seiten die Schnittstellenparameter passend auswählen, alles andere kann man trivial in Software lösen. Das kann sogar eine einfache Handbox, auch wenn man da vielleicht ein NOCH einfacheres Interface möchte. (Notbetrieb?)


    Die Nachteile bei RS-232 (sind wir noch bei C?) sind Geschwindigkeit und die Beschränkung auf zwei Geräte. Dazu noch kein out-of-band-signalling, außer, man schreibt sich da was, aber das wäre Streß. Vorteile: Man kann von seriell aus auf ziemlich alles wandeln, preiswert auf USB und Bluetooth, etwas teurer auf Ethernet mit irgendeinem TCP-Port. Dazu gibt es kaum eine erprobtere, kompatiblere und besser beherrschte Schnittstelle. Die kann ein moderner Microcontroller notfalls auf ein paar Beinchen in Software abfahren.


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>


    um den USB-Anschluß werden wir einfach nicht herumkommen, denke ich - irgendwie muß der Controller sich ja mit dem Rechner unterhalten (ok, es gibt noch Firewire, aber das ist in Summe sicherlich nicht einfacher zu realisieren).


    Muß aber zu meiner Schande gestehen, daß ich die Alt-Az Fraktion gar nicht mit auf der Rechnung hatte (obwohl ich auch gelegentlich mal mit einem Dob beobachte) ... das kann man natürlich auch mit Software auf einem externen Rechner erschlagen, wenn der Controller partout mit ohne Gimmicks aufgebaut sein soll; aber elegant ist des net.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    USB ist reine Faulheit der PC-Fraktion, die das Leben auf der Modulseite wieder komplizierter macht :)


    Man könnte ja auch seriell arbeiten, dann einen USB-&gt;Seriell-Wandler einsetzen. Oder andenken, die Geräte über Ethernet zu vernetzen.


    Ich bin ja durchaus von USB angetan, wenn es um billige Massenspeicher oder HIDs geht, aber damit Geräte steuern?
    Für diejenigen, die statt einem PC auf die Schnittstelle mit irgendwas an Selbstbaubix zugreifen wollen, heißt das, einen USB-Master zu bauen. Für eine Handbox nicht wirklich toll...


    Gruß und CS,
    Jens


    ("Wenn man nur einen Hammer hat, sieht alles aus wie ein Nagel" :) )

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: a_treff</i>
    Warum keinen Objektkatalog auf SD am Controller? Ist nicht sehr kompliziert und entsprechende Datenquellen gibt es auch.
    LX200 hat es ja auch im Protokoll.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Klingt wieder reichlich monolithisch. :)


    Klar, SD kann ich selbst mit einem Shield für den Arduino beackern.
    Sogar auf relativ hohem Level, da muß man nicht unbedingt sektorweise arbeiten.


    Die Minimalversion würde doch zwei Motoren treiben und über eine Handbox bedienen. Die ist sicherlich einfacher gedacht als das hier:


    http://jyetech.com/Products/LcdScope/06203P_3.jpg


    (Habe den Vorgänger, gut bedienbar!)


    Nur sind monolithische Ansätze schlecht in Gruppe zu entwickeln, schwer an Änderungen anzupassen und typischerweise unflexibel. Was man dadurch spart, daß man einen großen Block produziert, bezahlt man durch deutlich höhere Komplexität. Nicht umsonst besteht Software üblicherweise aus Schichten - man schaue sich nur mal Netzwerksoftware an.


    Schauen wir mal von oben:


    Oberste Schicht ist die, die der Benutzer sieht. Der will im Extremfall eine automatisierte Beobachtungsnacht mit Fotografie.
    Das System würde vielleicht nur eine Warteschlange voller Befehle abfahren:


    Da reden wir über "Gehe zu M31, fahre Fotoprogramm X ab", "Bleibe an augenblicklicher Position, fahre Fotoprogramm Y ab" und so weiter.


    Darunter dann der Objektkatalog (mit Verwaltung, mit Bahndaten falls erforderlich, mit Mimik zur Wartung usw.
    Also: "Gib mir die Position von M31 und Daten zur subjektiven Bewegung." (Ich könnte ja auch die ISS oder den Mond beobachten. Und hier kann man auch schauen, ob man die Sonne treffen würde.)


    Darunter dann eine Schicht, die ein Objekt mit bekannter Position anfahren und verfolgen kann - hier würde vielleicht auch ein Autoguider angreifen. Hier muß man unabhängig von der Art der Montierung eine Möglichkeit zur Verfügung stellen, zu positionieren und nachzuführen. Diese Schicht weiß auch etwas über PEC.


    Darunter kommt dann wirklich die Motorsteuerung mit Anschluß für Handbox. :)


    5 Schichten, nur Software, stark vereinfacht (die Fotoarie ist beispielsweise nicht 'drin). Es wird immer Punkte geben, wo man diese saubere Trennung verletzen muß: "Tut mir leid, lieber Anwender, aber mit DIESER Montierung kannst Du die ISS nicht verfolgen!", trotzdem aber glaube ich, daß es anders schwierig wird.


    Gruß,
    Jens

    Hallo Steffen,


    der ist ARM-Mäßig am unteren Ende, bringt aber einiges mit :)


    "The Stellaris® LM3S8962 microcontroller is based on the ARM® Cortex™-M3 controller core operating at 50 MHz, with 256 kB single-cycle flash, 64 kB single-cycle SRAM, 10/100 Ethernet MAC/PHY, a CAN controller, a 24-bit Systick Timer, 4x 32-bit or 8x 16-bit general-purpose timers, a watchdog timer, a SSI / SPI controller, an I2C interface, 2 UARTs, an analog comparator, a 10-bit analog-to-digital converter (ADC) with 4 input channels (+/- 1LSb of accuracy), a motion-control Pulse Width Modulation (PWM) module with 6 output channels, two Quadrature Encoder Inputs, a battery-backed hibernation module with RTC and 256 bytes of non-volatile state-saving memory, a low drop-out voltage regulator, brown-out reset, power-on reset controller, and up to 42 GPIOs. The LM3S8962 also features hardware-assisted support for synchronized industrial networks utilizing the IEEE 1588 Precision Time Protocol (PTP)."


    Aber es gibt sicherlich auch Boards mit mehr Fump, beispielsweise BeagleBoard - aber das wird teuer.


    Atmel hingegen: http://www.watterott.com/de/Atmel-AVRXPLAIN :)


    Wie üblich aber - wir sind zu früh!


    CAN hingegen klingt gut. Bussystem, das heißt: man kann wunderbar alles modularisieren und die Komponenten können miteinander reden, wobei ich nicht weiß, wie sich das vom Implementationsaufwand verhält. Seriell ist blödsinnig einfach, aber immer nur Punkt-zu-Punkt. BUS-System wäre schon sehr gut - und ein Großteil der Arbeit wird wohl darin bestehen, ein flexibles high-level-Protokoll zu spezifizieren. :)


    Aber - welche Module soll es überhaupt geben und wie sollen sie miteinander reden? Welche Module sind optional und welche müssen da sein? Was davon ist der Boß - oder ist der ein eigenes Modul?


    Mal in's Unreine geschrieben:


    - User Interface Modul (mindestens oder genau eines?)
    - Minimal: Dumme Box mit Richtung und Geschwindigkeit
    - Schnittstelle zu PC mit definitertem Protokoll (via USB?)
    - Schlaue Box mit GOTO. Real Time Clock und GPS
    - Beliebige benutzerdefiniterte Lösungen (z.B. Bluetooth, LAN)
    - Autiguiding-Eingang


    - Motorensteuerung, parametrisierbar, mit und ohne Winkelsensoren.
    Braucht Speicher für Konfiguratiosnparameter, PEC, ...


    - Filterrad (optional)


    Ich versuche nur immer noch, mir das irgendwie vorzustellen.


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: a_treff</i>
    Nochmal der Vergleich AVR vs. ARM:

    Code
    ATmega1280  | AT91SAM7S256
    Register:       8-bit | 32-bit
    Takt:          16MHz  | 55MHz
    Flash:          128kB | 256kB
    SRAM:            8kB  | 64kB
    Preis:      9.96 EUR  | 7.30 EUR


    Für mich spricht da nichts für AVR...


    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Yepp...


    Die Sachen, die ich mit dem AVR machen würde, sind alle nicht wild - eine Handbox mit LCD-Display beispielsweise würde damit einfach zu machen sein. Aber wenn die Motorsteuerung wirklich etwas schlauer sein soll, ist man sicher über Platz und Geschwindigkeit dankbar, insbesondere, da der Preis nicht höher ist. Das ROM sollte eigentlich reichen, wenn man nicht vom Webdesigner auf Softwareentwickler umgeschult wurde, aber das RAM ist beim AVR übel knapp. Die Dinger haben allerdings durchaus nette Features, da weiß ich über die ARMs noch zu wenig...


    Bei meinem Standardhöker ist allerdings eines der billigsten Entwicklungssysteme das hier:


    http://www.watterott.com/de/EK…thernetCAN-Evaluation-Kit


    Kann eindeutig zu viel. :)


    Was müßte man denn anlegen?


    Gruß,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: a_treff</i>


    Stellt sich die Frage, ob man eine kommerzielle Nutzung (z.B. CC-BY-NC-SA) ausschließen will, oder nicht (wie bei GPL)?


    Ich könnte mit beiden Varianten leben...


    Kann man einen Ausschluss wirklich durchsetzen? (z.B. in Fernost)
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Warum soll man kommerzielle Verwendung ausschließen? Um ewig eine Nischenlösung für Bastler zu schaffen?


    Es gibt genügend tolle Projekte, die für mich ausscheiden, weil ich nicht in der Lage (oder willens) bin, den Kram selber zu fertigen.
    Schön, aber für mich wertlos.


    Nehmen wir mal Linux als Beispiel.
    Auf dem Desktop immer noch nicht durchgesetzt, zur Zeit vom "Ich bin so geil, ich mache alles besser als die Vorgänger"-Problem gebeutelt (ich verweise mal auf Fefe : http://blog.fefe.de/?ts=b53326b6 ), setzt sich aber als beliebte Plattform für Embedded-Devices einer gewissen Komplexität immer mehr durch. Warum? Weil es auch kommerziell einsetzbar ist.


    Jetzt stellen wir uns mal vor, es gäbe eine schöne, modulare Steuerung für Montierungen. Open Source, flexibel, erweiterbar.


    Und: Standardisiert. Kommunikation zwischen dem Modulen folgt eine Reihe an wohldefinierten Schnittstellen. Das ist so viel besser als alles, was man bisher kaufen kann, daß ich geradezu erwarte, daß kleine Firmen und auch größere Firmen von dem Kuchen gerne eine Scheibe hätten. Wenn das hier diskutierte Projekt jetzt Referenzimplementationen schafft, die sich qualitativ behaupten, so hat man nicht nur eine Platine für eine Motorsteuerung und zwei verschiedene Handboxen designt, sondern eventuell eine kleine Revolution angestoßen.


    Warum soll ich eine Platine selber fertigen und bestücken müssen, wenn das jemand in China für 20 Euro machen kann? Niemand hindert mich daran, es zu tun. Aber ich habe die Wahl.


    Aber was will man?
    Wem entsteht durch eventuelle kommerzielle Nutzung was für ein Schaden? (Abgesehen davon, dazu muß die Qualität der Lösung schon wirklich gut sein!)


    Gruß,
    Jens

    Zum Thema "Coding conventions":


    Hier die Dokumentation eines "simplen" Drucksystems, welches überwiegend als Solo-Projekt anfing:


    http://www.cups.org/documentation.php


    Man beachte den kleinen Block unten rechts.


    Der Code ist nicht umsonst einer der lesbarsten, mit denen ich jemals gearbeitet habe. Inzwischen ist CUPS das Standard-Drucksystem für OSX und Linux. Aber wenn Mike Sweet irgendwann keine Lut mehr hat, bleibt alles pflegbar.


    SO gute Software habe ich nie geschrieben :)


    Gruß und CS,
    Jens

    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: a_treff</i>
    <br />Hallo Jens,


    vergleich mal:
    http://www.watterott.com/de/Arduino-Duemilanove
    mit z.B.
    http://shop.embedded-projects.…ikel&action=artikel&id=69


    Da hat der ARM, bezüglich SRAM, Flash, etc. aber mehr zu bieten...


    Großer Vorteil ist auch der eingebaute Bootloader (USB u. seriell) der AT91-Reihe von Atmel. (SAM-BA)
    Wie bereits geschrieben kostet der AT 91SAM7S256 bei Reichelt 7,30 EUR.


    Ganz wichtig für mich ist der freie Zugang zu der Entwicklungsumgebung und günstige Dev-Boards, damit möglichst viele am Projekt partizipieren können.


    Grüße
    Michael


    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo Michael,


    Vergleiche nicht Äpfel mit Birnen. Natürlich ist die gesamte Arduino-Umgebung Open Source.
    Die Arduinos sind Entwicklungsboards, nachher braucht man nur noch den ATMEGA (auch übrigens mit Bootloader), der DEUTLICH billiger ist.


    http://www.watterott.com/de/ATMEGA328P-PU


    Auch den Arduino kann man recht billig selber bauen! :)


    http://blog.makezine.com/archive/2009/05/paperduino.html



    Den ATmega1280 als großen Bruder bekommt man auch noch für unter 10€, wobei ja die CPU des motornahen Teils nicht allzuviel können muß.
    Dazu gibt es bei der Arduino-Plattform noch jede Menge an "Shields", gewissermaßen Erweiterungskarten, die man dann ebenso als Ausgangspunkt für eigene Erweiterungen nutzen kann.


    Hier mal ein Beispiel:


    http://www.adafruit.com/index.…Path=17_21&products_id=81


    Ich behaupte mal, daß für den angegebenen Zweck schon der 328 vollkommen ausreichen sollte - wobei zur Motorsteuerung ja auch noch ein bissl Sensorik kommt :)


    WAS man nachher einsetzt, wird sicherlich die Fraktion entscheiden, die die Hardware designt, wenn es sonst softwaremäßig keine Ausschlußkriterien gibt. Die werden wissen, was sich am einfachsten implementieren läßt - oder was aus Gründen der Stabilität oder des Stromverbrauchs Vorteile hat. Laufen würde es auch auf 8080 oder 6502. :)


    Zur Frage "Pascal oder C" - wir hatten in den frühen 80ern mal eine Pascal-Fraktion, die vor einem Projekt erst einmal anfing, jede Menge Räder neu zu erfinden. Eine Lehrsprache ist genau das, ein enges Korsett, in dem man explizit alles mögliche selbst ausformulieren muß.


    Und ja, ich habe mit FORTRAN IV angefangen (paßte perfekt zur Anwendung), kenne den Zusammenhang der C-Syntax mit Assembler-Befehlsvorrat der PDP-11 und natürlich auch diesen Artikel:


    http://www.pbm.com/~lindahl/real.programmers.html


    Aber im Prinzip ist es ziemlich egal, wir sind sicherlich noch ein Jahr vor der Zeit, in der man sich über Implementationsdetails Gedanken machen sollte...


    C bietet sich für die meisten Projekte mit Hardwarekontakt irgendwie an - und für das Frontend kann es sicher mehrere verschiedene Implementationen geben...


    Gruß,
    Jens

    Schöner Thread!


    Arduino ist übriges offen, preiswert und spricht etwas wie C, wobei man auf etliche Fertiglösungen zugreifen kann. :)


    Man wird sich sicher schnell daruaf einigen, daß das Projekt ein Schichtenmodell irgendeiner Art abbilden wird und daß man die untersten Schichten (Motorsteuerung evtl. bis hin zur Positionierung) wohl auf Mikrocontrollern realisieren kann, während alles darüber vielleicht auf Netbook oder ähnlichem läuft.


    Henning hat aber vollkommen Recht. Selbst für den einsamen Bastler im stillen Kämmerlein macht es wenig Sinn, einfach loszuentwickeln - und Ideen sind einfach, der Teufel sitzt aber in Realisierung und Detail.


    (Dilbert: "Welche Farbe soll die Datenbank haben?" Chef: "Rosa, hat am meisten RAM!")


    Aber was man vorher klären könnte: Welche Standards existieren eigentlich bezüglich der Kommunikation mit und innerhalb von Montierungen? Wenn sich die "lower layer"-Komponente verhält wie der Motorteil beispielsweise der CAM und der Rest wie die Handbox, kann man wunderbar auf bestehenden Entwürfen aufbauen und beispielsweise bestehende Steurung oder Motorisierung mit neuen Komponenten weiterverwenden.


    Aber gut, Schall und Rauch. Verdammt. Macht einfach zu viel Spaß!


    Für mich die ersten Fragen:


    - Was soll mit der Steuerung genau gesteuert werden?



    :)


    Gruß,
    Jens

    Hm... Link habe ich eben noch mal probiert!


    Hier ncoh einmal der englische:
    http://www.satunisia.info/angstro.htm


    Wobei es sich in Tunesien um ein früheres Fort der Fremdenlegion handelt - die haben da einmal pro Jahr hochbetrieb, ansonsten ist nix los, daher fragen, ob der Pool gefüllt ist. (Ich war wie gesagt zu vorastronomischer Zeit da, das ist locker 15 Jahre her.)


    Ansonsten ist natürlich auch Jordanien eine Option, wenn man preiswert hinkommt!


    Da haben die Astronomen eine nette Website.
    http://www.jas.org.jo/index2.html
    http://www.jas.org.jo/arab.html


    Gruß,
    Jens

    Tunesien? Auch da meine Erfahrungen vor der Astrozeit.
    Fort des Autruches in Kebili ist ziemlich ab vom Schuß, gute Küche, aber ob da jemand Deinen Sohn bespaßen kann und wie man in's Nirgendwo etwas weg vom Hotel kommt?
    Ansonsten gibt es im Hinterland jede Menge wenig besiedelte Ecken - aber wie es da mit dem ÖPNV ausschaut? Nach Kebilil kommt man mit dem Zug von Tunis nach Douz, dann weiter mit der Louage (Sammeltaxi).


    Aber man kann natürlich mal HIER nachfragen: http://www.satunisia.info/index.htm


    Marokko? Vielleicht Merzouga oder Zagora - der Transfer läßt sich sicher irgendwie arrangieren.


    Ansonsten:
    Bis Ouarzazate Hinweise zur Anreise hier:
    http://wikitravel.org/en/Ouarzazate
    (Ouarzazate lohnt auch als Besichtigungsziel!)


    Direkte Anreise ab Marrakech hier:
    http://wikitravel.org/en/Zagora


    Astronomieurlaub ohne Mietwagen ist offensichtlich nicht ganz einfach.