Grundlagen und Winkelberechnungen für H-H DiSEqC Motor Antennenanlagen

  • Hallo Leute.


    Dieser Thread erklärt den im VDR verwendeten Code und die mathematischen Funktionen für H-H Polarmount Motoren (Rotorsteuerung). Alle wichtigen Funktionen aus dem positioner.c ab VDR Version 2.1.3 werden in menschenverständlicher Form abgeleitet.


    Bedeutung von Polarmount


    Polarmount ist eine Montagemethode für bewegliche Satellitenantennen. Der einzige Motor dreht die Antennenhalterung in einer Ebene, die zur Äquatorialebene parallel verläuft. Die H-H Motorhalterung wird auf einem Antennenmast befestigt, welcher zum Erdoberfläche lotrecht montiert ist, genauso wie bei einer Festinstallation. Abhängig vom Standort wird der Winkel zwischen Motor und Motorhalterung nach Skala eingestellt. Die korrekte Einstellung ist die, bei der die tatsächliche Motorachse parallel zur Rotationsachse der Erde verläuft. Die Montage der Antenne auf dem um ca. 35° abgewinkelten Motorflansch erfolgt nach Herstellervorgaben. Eingestellt wird dabei einmalig der Elevationswinkel. Nach erfolgreicher Montage kann, allein durch das Drehen des Motors, die Antenne auf alle sichtbaren geostationären Nachrichtensatelliten mit Hilfe von DiSEqC korrekt ausgerichtet werden. Die Polarmount Montage unterscheidet sich von der Montagemethode Azimut, Elevation, Skew, bei der prinzipiell drei Achsen, bzw. Winkel (Azimut, Elevation und Skew) mit drei Motoren gleichzeitig verstellt werden müssen.


    Berechnung des Drehwinkels für den Motor „CalcHourAngle(int Longitude)“


    Bild 3D:


    - Die Punkte (NP)AB(SP) liegen auf einem Großkreis, welcher ein Längengrad ist.
    - Die Punkte (NP)AB(SP)M liegen auf einer Ebene, die die Erde halbiert, M ist der Erdmittelpunkt.
    - In dieser Ebene befindet sich das rechtwinklige Dreieck MAC.
    - Von dem Punkt A (Antenne) fällen wir ein Lot auf dem Äquator, damit entsteht bei C ein rechter Winkel.
    - NP-SP ist die Erdachse, AC die Motorachse.
    - Die Strecke MA entspricht dem Erdradius, MC ist die Entfernung Motorachse zum Erdachse.
    - Punkt A liegt auf dem Breitengrad des Antennenstandortes, der Winkel Theta entspricht der geographischen Breite.
    - In dem rechtwinkligen Dreieck MAC ist die Strecke MA die Hypotenuse und MC die Ankathete.


    MA=Erdradius=r (re)
    MC=r*cos(Theta), also Erdradius*cos(Breite) ergibt die Entfernung Motorachse zum Erdachse.


    Bild 2D:


    - Wir schauen die Erde genau von Norden nach Süden an, direkt in die Erdachse hinein.
    - Die Strecke MS ist die Entfernung Erdmittelpunkt zum Satellit -> R (rs).
    - Die Strecke MC=r*cos(Breite), SQ=R*sin(Alpha), MQ=R*cos(Alpha).
    - Im rechtwinkligen Dreieck CQS gilt: tan(Delta)=SQ/CQ.
    - CQ=MQ-MC.


    Die Gleichung:


    tan(Delta)=R*sin(Alpha)/(R*cos(Alpha)-r*cos(Breite)) #/R
    tan(Delta)=sin(Alpha)/(cos(Alpha)-cos(Breite)*r/R)


    Code
    return Sign * round(DEG(atan2(sin(Alpha), cos(Alpha) - cos(Lat) * SAT_EARTH_RATIO)));


    Aus dem Motorwinkel die Orbitposition berechnen „CalcLongitude(int HourAngle)“


    Nachdem wir den Motorwinkel in Abhängigkeit zur Orbitposition abgeleitet haben, werden wir die Funktion umkehren. Wir bestimmen aus einem vorgegebenen Motorwinkel die dazu gehörige Orbitposition. Ich nehme dazu den Sinussatz und zwei Winkelsummen, so ist die Gleichung nicht quadratisch.


    Bild 2D:


    Im Dreieck MCS sind die Strecken MS, MC und der Außenwinkel Delta bekannt. Wir suchen den Winkel Alpha.


    1. MS/sin(Beta)=MC/sin(Gamma) -> sin(Gamma)=sin(Beta)*MC/MS aus dem Sinussatz.
    2. Alpha+Beta+Gamma=180° Innenwinkelsumme eines Dreiecks.
    3. Beta+Delta=180° die beiden Winkel bilden einen Halbkreis bei Punkt C.


    Aus 2. und 3. Gamma=Delta-Alpha, Beta=180°-Delta und Alpha=Delta-Gamma. Beta setzen wir in der ersten Gleichung ein.


    Die Gleichung:


    Alpha=Delta-Gamma=Delta-asin(sin(180°-Delta)*cos(Breite)*r/R)


    Code
    double Alpha = Delta - asin(sin(M_PI - Delta) * cos(Lat) * SAT_EARTH_RATIO);


    Bestimmen des maximal sichtbaren Ausschnittes des Satellitenkreises „HorizonLongitude(ePositionerDirection Direction)“


    Der maximal sichtbare Ausschnitt des Sattelitenkreises wird über die Elevation bestimmt. Dort wo der Satellitenkreis den Horizont schneidet, ist die Elevation Null. Es gibt zwei solcher Punkte, sie bestimmen den Winkel. In dem speziellen Fall, dass die geografische Breite des Standortes Richtung 81° geht, tangiert der Winkel gegen null, die zwei Punkte verschmelzen ineinander. Darüber hinaus ist kein Satellit mehr sichtbar, die Funktion ist danach nicht mehr gegeben. Die Elevation hängt vom Winkel zwischen Standort und Subsatellitenpunkt ab.


    Ich verwende zwei Gleichungen aus der sphärischen Trigonometrie: für den Winkel der Orthodrome zwischen dem Standort und Subsatellitenpunkt und die Elevation. Sie sind schon mehrfach abgeleitet worden, ich werde sie ohne Beweis verwenden. Einen Link gibt es trotzdem dazu.


    Bild 3D:


    - Winkel der Orhrodome -> cos(Delta)=cos(Breite)*cos(Längendifferenz).
    - Elevation -> tan(Epsylon)=(cos(Delta)-r/R)/sin(Delta). #Epsylon wird nicht dargestellt.
    - Die Elevation ist dann null, wenn der Quotient null ist. Dazu müssen wir den Dividenden nullsetzen: cos(Delta)-r/R=0 -> cos(Delta)=r/R, das setzen wir in der ersten Gleichung ein:
    - cos(Längendifferenz)=r/R/cos(Breite).


    Die Gleichung:


    Delta=acos(r/R/cos(Breite))


    Code
    Delta = acos(SAT_EARTH_RATIO / cos(RAD(Setup.SiteLat)));




    Compiler.


    Albert

    Bilder

    9 Mal editiert, zuletzt von ATD ()

  • Ich bin damit soweit fertig. Es wäre nett, wenn Klaus, SHF und mini73 sich es ansehen und prüfen würden. Das gilt natürlich für alle, die davon etwas verstehen. Verbesserungsvorschläge sind willkommen, grammatische Korrekturen auch, aber etwas verhalten bitte.


    Wer will, der kann den Testcode über den verlinkten Online Compiler jagen um sich die Werte anzuschauen. Nur der Testcode ist dort lauffähig!


    Albert

  • Moin!


    Nach dem ersten Lesen finde ich erst mal keinen logischen Fehler. Ich hab allerdings die sphärische Trigonometrie sind ganz so parat, die müsste ich erst mal nachschlagen. Müsste bei Gelegenheit mal auf die Suche nach meinem Bronstein gehen.


    Unglücklich finde ich die Doppelbenutzung von Punktnamen. A ist in beiden Bildern ein anderer Punkt (3D vs. 2D-Projektion), dadurch ist die Strecke MA in beiden Bildern etwas anderes. Ich würde die Punkte in Bild 2 vermutlich mit einem A' (gelesen "A Strich") usw. benennen. P und M sind in Ordnung, da MP in beiden Bildern gleich ist. Delta und Alpha meinen in beiden Bilder auch etwas anderes, die würden bei mir auch einen Strich in Bild 2 bekommen.
    Macht das Lesen leichter.


    "Sign" ist nicht erklärt. Ist das das Kennzeichen, ob A auf der Nord- oder Südhalbkugel ist? Hm, scheint noch mehr Bedeutungen zu haben... Zu müde heute, um den Code zu lesen.


    Ziel ist es, den Motor um "delta aus Bild 2" zu drehen, richtig? Da ich "nur" Kabeluser bin, bin ich mit den Tücken der Schüsselausrichtung nicht ganz so vertraut. :)


    Lars.

  • Lars, danke für Deine Anregungen.


    Ich hab allerdings die sphärische Trigonometrie sind ganz so parat, die müsste ich erst mal nachschlagen.


    Dazu kann ich Dir gleich zwei nützliche Links geben: Link 1 und Link 2.


    Unglücklich finde ich die Doppelbenutzung von Punktnamen.


    Das mit dem Punkten und Winkel werde ich noch überarbeiten.


    "Sign" ist nicht erklärt. Ist das das Kennzeichen, ob A auf der Nord- oder Südhalbkugel ist? Hm, scheint noch mehr Bedeutungen zu haben...


    Ja, das ist es. Je nachdem ob der Motor auf der nördlichen oder südlichen Halbkugel sich befindet, ändert sich die Rotationsrichtung für den Motor um denselben Satelliten anzusteuern. Eine andere Funktion dafür kann ich nicht ersehen.


    Ziel ist es, den Motor um "delta aus Bild 2" zu drehen, richtig?


    Ja, das ist richtig als Teilaufgabe. Klaus wollte darüber hinaus die Umkehrfunktion haben um Delta in Orbitpositionen (momentan Alpha im Bild 2) umrechnen zu können und außerdem den Winkel des sichtbaren Satellitenkreises. Beide letztere Funktionen dienen der Darstellung, der erste errechnet den Motorwinkel.


    Albert

  • Unglücklich finde ich die Doppelbenutzung von Punktnamen. A ist in beiden Bildern ein anderer Punkt (3D vs. 2D-Projektion), dadurch ist die Strecke MA in beiden Bildern etwas anderes. Ich würde die Punkte in Bild 2 vermutlich mit einem A' (gelesen "A Strich") usw. benennen. P und M sind in Ordnung, da MP in beiden Bildern gleich ist. Delta und Alpha meinen in beiden Bilder auch etwas anderes, die würden bei mir auch einen Strich in Bild 2 bekommen.


    Das müsste jetzt im Text und Bild eine bessere Figur machen.


    Albert

  • Nachdem wir den Rotorwinkel in Abhängigkeit der Orbitposition abgeleitet haben, werden wir die Funktion umkehren. Wir bestimmen aus einem vorgegebenen Motorwinkel die dazu gehörige Orbitposition. SHF hat es schon mit dem Kosinussatz gelöst. Ich wähle dazu den Sinussatz und zwei Winkelsummen. So ist die Gleichung nicht mehr quadratisch. Es soll nicht bedeuten, dass meine Lösung besser ist. Sie ist kürzer, tut aber genau das gleiche.

    Dein Ansatz ist definitiv geschickter, das kann ich neidlos sagen.
    Das meine Gleichung noch zu vereinfachen wäre, hatte ich mir auch schon gedacht und auch geschrieben.
    Da waren zu viele Variablen mehrfach vorhanden und der Kurvenverlauf ist zu unnspektakulär dafür.


    Für mich sieht das eigentlich soweit stimmig aus.


    Nur eine Kleinigkeit hab ich entdeckt:

    - Im Rechteck A'PS gilt: tan(Delta)=SP/A'P.


    Das "Rechteck" ist eigentlich ein "rechtwinkliges Dreieck".

    Gruss
    SHF


  • SHF Danke, das Du Dir es angesehen hast.


    Das meine Gleichung noch zu vereinfachen wäre, hatte ich mir auch schon gedacht und auch geschrieben.


    Das habe ich erst auch versucht, geht leider nicht. Du hast im Kosinussatz mit der anderen Gleichung zusammen sin und cos auf demselben Winkel, ganz gleich, ob nach p-q oder a-b-c Formel aufgelöst wird. Das bedeutet: Satz des Pythagoras, was quadratisch ist! Ich habe es nach sin, cos und tan abgeleitet, etliche A4 Seiten. Binomische Formel (Additionstheoreme), Beziehungen zwischen den Funktionen. Es fällt schon manches aus, aber am Ende hast Du immer noch sqr und sqrt.


    So einfach die initial Gleichung war, wollte ich es auch nicht glauben, dass die Umkehrung extrem kompliziert ist. Da kam mir der Sinussatz entgegen.


    Deine Formel funktioniert. Der Rechenleistung ist auch nicht das Problem! :tup


    Das "Rechteck" ist eigentlich ein "rechtwinkliges Dreieck".


    Das ist wohl Wahr. Ich will das ganze noch etwas fein schleifen. Mit A' bin ich auch nicht so glücklich. Ich denke, A' wird zum Q und der Schnittpunkt Lat., Lon. zum R. Ich will nur nicht Edit 395637 haben.


    Wenn Klaus mit der Heizung fertig ist, dann hätte ich trotzdem noch ein Paar Fragen an ihn. Ich glaube nicht, das es das ganze Code ist (z.B. FindFirstSat, GoToX, Calibrate!?).


    Das Polarmount macht aber Eindruck und auch Spaß!


    Albert

  • Ich habe deinen Code jetzt mal hier eingebaut und es funktioniert soweit alles wie vorher.
    Danke für die ausführliche Herleitung.


    Wegen des "Delta" vs. "Alpha": Delta ist einfach der Unterschied zwischen dem Längengrad der Satellitenposition und des Standorts. Meinetwegen kann ich die beiden im Code auch vertauschen, damit sie mit deiner Herleitung übereinstimmen (oder du änderst es in der Herleitung ;-). Auf jeden Fall würde ich es für sinnvoll halten, wenn Bezeichnungen, die im Code und in deiner Herleitung vorkommen, auch immer das Gleiche bedeuten würden. Sag bitte Bescheid, was dir lieber ist.


    Bzgl. "FindFirstSat, GoToX, Calibrate!?": im ersten Schritt wird davon ausgegangen, daß die diseqc.conf die richtigen Einträge bereits enthält. Für einen USALS-Motor ist das sowieso sehr einfach, weil der mit z.B.


    Code
    S360E   11700 V  9750  t v W20 P W20 t v
    S360E   99999 V 10600  t v W20 P W20 T v
    S360E   11700 H  9750  t v W20 P W20 t V
    S360E   99999 H 10600  t v W20 P W20 T V


    bereits alle sichtbaren Satelliten ansteuern kann.
    Für einen reinen DiSEqC-Motor muß es für jeden Satelliten eine eigene solche Sequenz geben, wobei der 'P'-Parameter um die Nummer der Position, wie sie im Motor gespeichert ist, ergänzt wird.


    Das manuelle Positionieren sowie das Speichern von Positionen folgt dann später.


    Klaus

  • Danke für die ausführliche Herleitung.


    Klaus, wir alle danken Dir, nicht umgekehrt!


    Wegen des "Delta" vs. "Alpha": Delta ist einfach der Unterschied zwischen dem Längengrad der Satellitenposition und des Standorts.


    Ich denke, das stimmt nur bei CalcHourAngle, nicht aber bei: CalcLongitude und auch nicht bei: HorizonLongitude.


    Auf jeden Fall würde ich es für sinnvoll halten, wenn Bezeichnungen, die im Code und in deiner Herleitung vorkommen, auch immer das Gleiche bedeuten würden.


    Ich bin voll Deiner Meinung. Lasse mir bitte etwas Zeit das ganze durchs Kopf gehen zu lassen. Momentan ist die Ableitung vs. Code nur suboptimal.


    der 'P'-Parameter um die Nummer der Position, wie sie im Motor gespeichert ist, ergänzt wird


    "P"aula aus dem DiSEqC sagt mir jetzt nicht viel. Vielleicht eine nähere Erklärung!?


    Frage Nr. 1: muss der Motor kalibriert werden? Ja oder nein?


    Das manuelle Positionieren sowie das Speichern von Positionen folgt dann später.


    Meinerseits werden noch zwei Fragen folgen, aber heute nicht. Ich möchte sie gern explizit und präzise stellen. Ich stecke momentan in Badsanierung mit Durchlauferhitzer, 24 KW :-(.


    Albert

  • Ich habe mich mal kurz umgeschaut. Was hat USALS Patentiert? Die Geometrie ist Allgemeingut. Gefunden habe ich lediglich das. Pizzablech!?


    Albert

  • Ich habe mich mal kurz umgeschaut. Was hat USALS Patentiert? Die Geometrie ist Allgemeingut. Gefunden habe ich lediglich das. Pizzablech!?


    Soweit ich das verstehe geht es da lediglich um die Wortmarke "STAB - USALS". Und selbst die wurde bereits am 24.4.2010 gelöscht (Status: CANCELLED).


    Ich glaube nicht, daß wir uns wegen der Ansteuerung solcher Positionierer irgendwelche Sorgen machen müssen.


    Klaus


  • "P"aula aus dem DiSEqC sagt mir jetzt nicht viel. Vielleicht eine nähere Erklärung!?


    Das ist einfach der neue Parameter, der angibt, daß ein Positionierer verwendet wird (war im GOTOX-Patch 'G').


    Zitat


    Frage Nr. 1: muss der Motor kalibriert werden? Ja oder nein?


    Am Motor ist eine Skala, mit der man die Neigung (standortabhängig) einstellt. Die Motorhalterung wird genau nach Süden (bzw. Norden) ausgerichtet, dann sollte es eigentlich schon passen.


    Klaus

  • Klaus, was Math. betrifft: ich würde die Grafik optimieren wollen (Winkel, Punkte, etc.) und Text, Code anpassen. Dann hast Du es vom Hals (Guttenberg Tastatur). Zeitvorstellung: n.W., obwohl W am Mi. Geburtstag hat.


    Das ist einfach der neue Parameter, der angibt, daß ein Positionierer verwendet wird (war im GOTOX-Patch 'G').


    Ist das der Winkel: CalcHourAngle?


    Am Motor ist eine Skala, mit der man die Neigung (standortabhängig) einstellt. Die Motorhalterung wird genau nach Süden (bzw. Norden) ausgerichtet, dann sollte es eigentlich schon passen.


    Schon klar. Da es hier aber auch um Grundlagen geht, möchte ich das Ganze so gut wie möglich verstehen und den Eingangspost entsprechend ergänzen.


    Eine Kurze Recherche im Net ergibt folgendes: es gibt H-H Motoren mit USALS- aber auch mit DiSEqC Steuerung. Ich würde den SG-2100 als Referenzmodell nehmen. Der unterschied sollte sein, das bei USALS die Positionen im Motor gespeichert werden, dagegen bei DiSEqC im Receiver. Wir aber speichern nichts, wir rechnen!?


    Du hast offensichtlich einen H-H Motor, von dem ich vor ein Paar Wochen nicht einmal wusste, dass es so was gibt. Mich beeindruckt, dass man mit so eine simple Konstruktion den Clarke Belt Kurve incl. Skew/Tilt (Sonderfall Astra!) mit wenig Geld abfahren kann. Tauschen wir uns also aus.


    Technisch würde ich bei einem solchen Motor keinen Linearmotor vermuten (zu Teuer und Windlast). Ich glaube, es ist ein Schrittmotor verbaut, welcher über eine lang übersetztes Getriebe den Spiegel dreht, ca. 1,5°/s bis 2,4°/s je nach Spannung. Ich nehme an, dass es außerdem über eine interne Skala verfügt, sonst würde ein Goto X immer erst den Goto 0 ansteuern müssen. Dabei gehe ich aus den von Dir genannten traditionellen Installation aus: Motorwinkel 0 strikt nach Süden, bzw. Norden, je nach Aufstellungsort (Erdhalbkugel)!


    Wenn das soweit stimmt, dann ist eine Kalibrierung nie nötig, FindFirstSat wird bereits errechnet und Goto X bedarf nicht eines Referenzpunktes!?


    Beispiel:


    - Antenne ist im Paris Aufgestellt
    - aktuelle Position 19,2°E
    - Wechsel auf 13°E
    - "P"aula ist der Drehwinkel des Motors, was wir errechnen (CalcHourAngle)
    - Der Motor bewegt sich nach seinem interner Skala linear um den nötigen Winkel (nicht Orbitwinkel!) zu dem neuen Position


    Ist das so weit korrekt?


    Albert

  • Wäre Theta für den Winkel für den Breitengrad würdig?


    Alpha, Beta und Gamma in 2D-Bild würde ich wegen der allgemeinen Bezeichnung eines Dreiecks behalten wollen, auch wenn die Punkte und Geraden nicht definitionsgerecht dargestellt werden.


    Albert

  • Klaus, fehlt in "int cPositioner::CalcHourAngle(int Longitude)" nicht ein " NormalizeAngle" in der Zeile: "return Sign * round(DEG(atan2(sin(Delta), cos(Delta) - cos(Lat) * SAT_EARTH_RATIO)));"?


    Albert


  • Ist das der Winkel: CalcHourAngle?


    In der diseqc.conf steht z.B.

    Code
    S360E   11700 V  9750  t v W20 P W20 t v
    S360E   99999 V 10600  t v W20 P W20 T v
    S360E   11700 H  9750  t v W20 P W20 t V
    S360E   99999 H 10600  t v W20 P W20 T V


    Das 'P' hier bedeutet, daß VDR an dieser Stelle der Abarbeitung der DiSEqC-Zeile die entsprechenden Schritte unternimmt, um den Positionierer zum gewünschten Satelliten hin auszurichten. Dazu schickt er ihm standardmäßig den mit CalcHourAngle() berechneten Winkel.


    Zitat


    ...
    Der unterschied sollte sein, das bei USALS die Positionen im Motor gespeichert werden, dagegen bei DiSEqC im Receiver. Wir aber speichern nichts, wir rechnen!?


    Bei USALS ist im Motor eigentlich gar nichts gespeichert. Der Motor kann lediglich jede gewünschte Position anfahren. Der "hour angle" wird immer im Receiver berechnet und an den Motor geschickt.


    Zitat


    Ich glaube, es ist ein Schrittmotor verbaut, welcher über eine lang übersetztes Getriebe den Spiegel dreht,


    Das glaube ich eigentlich weniger. Wird wohl ein ganz normaler Gleichstrommotor sein.


    Zitat


    ca. 1,5°/s bis 2,4°/s je nach Spannung.


    Das gilt zumindest für den Motor, den ich hier habe.


    Zitat


    Ich nehme an, dass es außerdem über eine interne Skala verfügt, sonst würde ein Goto X immer erst den Goto 0 ansteuern müssen.


    So wird's wohl sein, und deshalb braucht's auch keinen Schrittmotor. Der Motor kennt übrigens seine momentane Position auch über einen
    Stromausfall hinweg. Es ist also eine absolute Skala.



    Ja, das stimmt.


    Klaus

  • Wäre Theta für den Winkel für den Breitengrad würdig?


    Alpha, Beta und Gamma in 2D-Bild würde ich wegen der allgemeinen Bezeichnung eines Dreiecks behalten wollen, auch wenn die Punkte und Geraden nicht definitionsgerecht dargestellt werden.


    Mir sind die Namen eigentlich ziemlich egal. Nachdem du dir mit der Herleitung so viel Arbeit gemacht hast, sollten sie halt auch im tatsächlichen Programmcode entsprechend auftauchen.


    Klaus

  • Klaus, fehlt in "int cPositioner::CalcHourAngle(int Longitude)" nicht ein " NormalizeAngle" in der Zeile: "return Sign * round(DEG(atan2(sin(Delta), cos(Delta) - cos(Lat) * SAT_EARTH_RATIO)));"?


    Ich glaube nicht, da sich dieser Wert ja immer zwischen +/-90 Grad bewegen wird, egal wo auf der Erde man sitzt.


    Klaus

  • Klaus, danke für die Erläuterung, soweit alles klar, außer das:


    Ich glaube nicht, da sich dieser Wert ja immer zwischen +/-90 Grad bewegen wird, egal wo auf der Erde man sitzt.


    Ich formuliere es mal anders. Mag sein, dass uns die "NormalizeAngle" dort nicht weiter hilft. Der Eingangswinkel ist aber per Code nicht begrenzt!


    Code
    double Delta = RAD(Longitude - Setup.SiteLon);


    Was passiert, wenn San Francisco (37° 47' N, 122° 25' W) Astra 19,2° E in der Kanalliste hat? Dann ist Delta=141,67°.


    Wenn ich das mal durchlaufen lasse:


    Code
    int main(void)
    {
      Setup.SiteLat = 375;
      Setup.SiteLon = 1222;
      for (int i = -1800; i <= 1800; i += 200)
          fprintf(stderr, "%5d %5d %5d -> %5d %5d %5d\n", Setup.SiteLat, Setup.SiteLon, i, CalcLongitude(i), CalcHourAngle(CalcLongitude(i)), HorizonLongitude(i));
      return 0;
    }


    dann kommt Teilweise unbrauchbares heraus:



    Mein Vorschlag wäre ein if auf "Longitude - Setup.SiteLon"<=81° und dann erst CalcHourAngle (oder überhaupt den cPositioner) erlauben. Was meinst Du dazu?


    Albert


  • Mein Vorschlag wäre ein if auf "Longitude - Setup.SiteLon"<=81° und dann erst CalcHourAngle (oder überhaupt den cPositioner) erlauben. Was meinst Du dazu?


    Das habe ich sowieso noch vor, daß nur die Satelliten angeboten werden, die am aktuellen Standort auch wirklich sichtbar sind.
    Aber im ersten Schritt wird jetzt erstmal die reine Positionierung gehen. Alles weitere, wie z.B. manuelles Positionieren, Feinjustieren und Abspeichern von festen Positionen kommt dann im nächsten Schritt...


    Klaus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!