Beiträge von XPosition

    Wenn es jetzt geht, brauchst du es eh nicht mehr. oder ?
    Alles ist mir auch nicht bekannt.


    Wichtig ist doch für dich nur:
    pdat->azim = azimuth = Himmelsrichtung in der die Sonne steht.
    pdat->elevref = elevation = Wie hoch die Sonne steht.


    Mit aspect wird eingestellt welche Himmelsrichtung = 0 ist. Default = Süden.
    Timezone kannst du vegessen, falls Du eh mit UTC rechnest.


    Normal wird alles berechnet. Das solltest du ausschalten, falls alles geht.
    Also nur : pdat->function = L_GEOM | L_REFRAC | L_SOLAZM


    Hoffe, ich habe jetzt nichts übersehen. ;)

    Dein Datum wird wohl nicht stimmen. oder ?
    So etwas wie Monat von 1..12 anstatt 0..11.
    Oder etwas ähnliches ;)


    Schau mal auf einer Internetseite, welches astronomisches Julianische Datum gerade ist und welches du berechnest.


    Die andere Variante wären falsche Ortskoordinaten.
    von 180 bis -180 anstatt von 0 bis 360.
    Oder etwas ähnliches ;)


    Aber wie wär es mit:
    Link
    Das benutzt nur float. Gut für den ARM und könnte auch teilweise auf fixed-point erweitert werden.

    Hallo Bill,
    ja das hört sich ja vielversprechend an.
    Auch wenn nur RTCM 2.0 unterstützt würde, als eine Genauigkeit von 0,5 bis 5 Meter, wäre das ja schon mal prima.
    Garantiert wird zur Zeit oft nur RTCM 2.0 an allen Standorten. Oder ?
    Welcher Chip soll denn da benutzt werden ?
    Welcher Preis wird für die Maus angestrebt ?
    Hat jemand eine Ahnung welche Tel. Kosten Prepaid für 1 Stunde online gerade zu bezahlen sind bei dem Datenaufkommen ?

    Hier kannst du z.B. die GPS-Week-Number für einen bestimmten Tag ersehen.
    Und die Sekunden für die vergangenen Tage der Woche und die Sekunden des aktuellen Tages dann noch dazu addieren.


    oder hier die aktuelle Zeit

    Nun ja, ich hab jetzt keine Lust diesem Al die Hölle heiß zu machen.
    Keine Ahnung unter welchem Druck der steht, wieviel der verdient und welche Position der hat.
    Außerdem ist es leicht erstmal groß zu labern, aber wenn man es software-technisch umsetzt stellt man dann fest, dass doch einiges anderst(schwieriger) ist.
    Also seh das mal als oberflächlich schnelle Einschätzung:


    Er hat also eine Entwicklungs-Umgebung die nur float kennt und keine doubles.
    float ist eine Fließkomma-Zahl mit 4 bytes. Und das ist wirklich wenig für den rießigen Zahlenbereich, den sie abdecken will.
    Damit hat man wirklich schnell Ungenauigkeiten.
    Deswegen sollte er sie eigentlich erst gar nicht benutzen.
    Man kann Festkomma-Zahlen benutzen, also z.B. 16bit vor dem Komma und 16 bit nach dem Komma. Das wäre genauer, aber auch in der Größe der Zahl begrenzt. Ist aber außreichend zwischen 2 Logeinträgen.


    Dann kommt es noch darauf an was ihm eigentlich an Daten zur Verfügung stehen:


    Benutzt er NNMEA(was nicht so klug wäre), dann muß er zwischen Längs-und Breitengraden die Entfernung messen. Das wäre viel Trigonometrie und ganz
    schlecht für die CPU, da er wieder zurück auf XYZ Vektoren rechen muß.


    Benutzt der UBX, kann er einfach die XYZ Vektoren benutzen die ihm der Chip liefert und braucht dafür überhaupt keine Nachkomma Arithmetik. Sollte also mehr als genau sein.


    Aber ich vermute, er benutzt aus irgend einem Grund NMEA.
    Und so aus dem Bauch herraus, benutzt er eine supergenaue Methode, die die Erdkrümmung mit berücksichtigt. Das ist aber bei den kurzen Distanzen gar nicht notwendig, führt aber mit den "floats" zu mehr Ungenauigkeit.


    Nun ja, ich könnte jetzt noch mehr spekulieren.
    Was mir gefallen würde wäre ein open-source logger. Da könnte man
    man wirklich hilfreich sein.

    Zitat

    Das würd mich auch mal interessieren. Ich glaube, alle GPS Geräte zeigen die 2D Geschwindigkeit (also über Grund) an. Wenn man sich den Berg rauf bewegt, fehlt eben die vertikale Komponente. Ist für die Fortbewegung bezogen auf die zurückgelegte Strecke ja auch korrekt.
    Weiß jemand Genaues?


    Also falls sie den NMEA GPVTG Datensatz benutzen, so ist das definitiv 2D.
    Also nur die horizontale Geschwindigkeit.
    Und via UBX Datensatz: NAV-VELNED wäre beides möglich.


    Zitat

    das ist der richtige Weg wie du es anpackst. Allerdings werden die wohl nichts verbessern können, da die Anzeigeungenauigkeit wohl durch den Prozessor verursacht wird, der nur 4 bit hat.


    Also das kann ich mir nicht vorstellen.
    Das Ganze mit einer 4 bit CPU zu machen halte ich für ein Unding. Die Firmware wäre erst im Jahr 2010 fertig.
    Nein, da wird eine 32-bit ARM CPU noch drinstecken. Die hat halt kein Fließkomma Prozessor und der muß deswegen emuliert werden. Das ist kein Problem, aber dauert halt länger. Rundungsfehler entstehen nur, bei Benutzung von fester Anzahl von Nachkomma-Stellen um die Berechnung schneller zu machen. Das kann man aber auch wegbekommen mit ein paar zusätzlichen Zwischenschritten(kann aber viel Aufwand bedeuten).

    Das Problem ist die Genauigkeit.
    Nicht zu genau, da zuviel Rechenpower, aber natürlich auch nicht zu schlecht und ungenau.


    Meeus hat da mal etwas entwickelt, aber das ist vielleicht etwas zu genau für dich.
    Und eine gute Beispiel Implementierung dafür kannst hier sehen. In der Datei astro.c

    Hallo Hans,
    kennst du das Programm: GPS-Track-Analyse.Net ?
    Damit kommt man der Sache vielleicht näher.
    download link
    Sorry, mit GTA meintest du wohl genau dieses Tool :(


    Allerdings vergiß nicht die Barometer Tests. Würde mich wirklich interessieren.
    Deine Abweichungen im Stand von 1-2 Metern wäre eine Auflösung von
    ungefähr 0,3 hPa, was ja schon ziemlich gut wäre.
    Habe da mal google gefragt:
    So 08/15 Wetterstationen haben nur 1 hPa Auflösung, und gute Geräte so 0,1 hPa(das wäre im Meterbereich) und sündhaft teure Geräte haben 0,01 hPa.


    Und für die absolute Genauigkeit der Höhe(also um jetzt nicht die relative Abweichung festzustellen sondern die echte Höhe) sind die günstigen Sensoren auch oft nur 1 hPa oder schlechter genau. Das wäre dann eine Differenz von so 8-9 Metern.


    Kennt jemand den Namen des Sensors(Chip), der da eingebaut wurde ?

    Nun, das sieht für mich so aus, als dass die wintec Geräte die Steigung als die Summe aller nach oben gefahrenen Metern definiert.
    Also die abwärts Meter nicht abzieht.
    Und mit dem Barmometer kommen noch mehr hoch/runter Kurven dazu, da genauer.
    Kann doch sein. Oder ?

    Hallo Hans,


    Zitat

    Speziell zur absolute Genauigkeit des Barometer im WSG-1000 werde ich nächsten Woche mal schauen, wo ich ein geeichte Meßstelle finde an der ich mich auch davorstellen kann, sprich gleiche bekannte Höhe.


    Also bei uns(BaWü) gibt es in jedem kleinen Städchen ein Vermessungs- und Katasteramt. Da kann man anrufen und die geben einem den nächsten Höhenfestpunkt zu seiner Wohnung.
    Falls du jetzt allerdings eine "Höhenfestpunkt-Wanderung" machen willst, also mehrere Punkte erfrägst, wollen sie wahrscheinlich eine Bearbeitungsgebühr.
    Die Höhenwerte dürfen übrigens nicht veröffentlicht(Internet) werden, und
    sind auf den mm genau angegeben.

    Übrigens hat die Top50 V5 eine Auflösung von 25 Metern und die V3 eine Auflösung von 50 Metern.
    Mit Auflösung meine ich den Rasterabstand der Höhenwerte.
    Die Höhe sollte auf 1 Meter genau sein.


    Wie gut ist der Barometer im WSG 1000 falls er kalibriert ist ?
    Sollte eigentlich besser als die Top50 sein, falls das Wetter mitspielt. Oder ?