AVGPS Version 2.02 verfügbar

  • AVGPS Version 2.02 (23.5.2009)


    Hier kommt gleich noch die Version 2.02 hinterher, die nun das Problem mit dem Öffnen der seriellen Schnittstelle (auf manchen Rechnern) beheben sollte.


    Ich hoffe, das war's erstmal. ;)

    • Verbesserung: beim Dekodieren von MTK Tracklogdateien wird nun das Bit 3 des RCR Status ausgewertet und falls dieses Bit gesetzt ist, der Trackpunkt als Wegpunkt markiert.
    • Verbesserung: das Ermitteln der Zeitzone hat nicht immer funktioniert (z.B. wenn vom Geoserver Austria/Vienna als Antwort zurückkam). Die Methode zur Auswertung der Antwort wurde
      überarbeitet und die Zeitzonenermittlung sollte nun auch in diesen Fällen funktionieren.
    • Verbesserung: der Fehler, dass auf einigen Rechnern AVGPS die serielle Schnittstelle nicht erfolgreich Öffnen konnte, sollte nun behoben sein.
      Der Grund dafür war, dass AVGPS den Lesepuffer der seriellen Schnittstelle auf 16 KB initialisiert hatte, was offensichtlich einige serielle Chipsätze nicht unterstützen.
      Der Lesepuffer wird nun auf 4 KB initialisiert (so wie es auch bis einschließlich Version 1.8 der Fall war).
    • Verbesserung: für den Fall, dass es mehrere Infodisplays für den Track gibt (wo z.B. die Höhe graphisch dargestellt ist), wurde in diesen Anzeigen die aktuelle Position nur in der ersten Anzeige dargestellt.
      Dieser Fehler ist behoben: es werden nun in allen Infosdiaplays die aktuelle Position dargestellt.


    AVGPS Version 2.01 (22.5.2009)


    Sorry Leute, ich muss doch gleich noch eine Fehlerkorrektur nachschicken.


    Ein Dank an Hans Maurer, der mich auf einen unschönen Fehler beim Schreiben und Einlesen von GPX Dateien aufmerksam gemacht hat. Dieser war der eigentliche Anlass für diese fehlerkorrigierte Version, da GPX m.E. eine sehr wichtige Rolle spielt.


    Ich habe noch was eingebaut, damit ich vielleicht besser verstehen kann, warum bei Einigen das Öffnen der seriellen Schnittstelle nicht funktioniert. Bitte nochmal mit dieser Version testen und mir die Ausgabe in der Meldungskonsole schreiben.


    Hier noch die Änderungen:

    • Fehlerkorrektur: seit Version 1.6 werden GPX Dateien erstellt, die für einige Attribute in der AVGPS spezifischen GPX Extension Gleitkommazahlen mit Komma (',') als Dezimaltrennzeichen verwendet.
      Dies entspricht nicht der XML Konvention (es muss ein Punkt '.' verwendet werden) und sorgt dafür, dass diese GPX Dateien nicht mehr erfolgreich mit AVGPS eingelesen werden können.
      Wie gesagt, diser Fehler betrifft nur die AVGPS Extensions (und auch die Garmin Extensions) und wird dementsprechend anderen GPX Lesern erstmal keine Probleme machen.
      Die Fehlerbehebung, die mit dieser Version kommt, besteht aus zwei Teilen:
      1) Es werden auch Gleitkommazahlen mit Komma als Dezimaltrennzeichen akzeptiert. Damit lassen sich die fehlerhaften Dateien einlesen. Ausserdem wird am Ende des Imports in den Warnmeldungen dieser
      Umstand angezeigt und darauf hingewiesen, dass die Datei sinnvollerweise nochmal neu gespeichert werden soll, damit man eine korrekte Datei hat.
      2) Der Code zum Erstellen von GPX Dateien wurde korrigiert und schreibt nun XML konforme Gleitkommazahlen mit Punkt als Dezimaltrennzeichen.
    • Versuch: im Code für das Öffnen der seriellen Schnittstelle wurden weitere Debugzeilen für die Meldungskonsole hinzugefügt um dem Problem beim Öffnen der seriellen Schnittstelle einiger Benutzer habhaft zu werden.
      Ausserdem wurde das Setzen der DTR und RTS Steuerleitungen ausgeschaltet.


    AVGPS Version 2.00 (22.5.2009)


    Ich stelle hiermit die Version 2.00 zur Verfügung.


    Ich denke, dass der Versionssprung dadurch gerechtfertigt ist, da die Oberfläche eine deutliche Wandlung vom speziellen WinTec Tool zu einem eher universalem GPS Logger Tool vollzogen hat.


    Dies wird vor allem schon dadurch deutlich, dass ab dieser Version MTK Chipsatz basierte Logger (z.B. I-Blue 747 und Holux M-241) insoweit unterstützt werden, dass der Logspeicher ausgelesen und gelöscht werden kann.


    An dieser Stelle besonderen Dank an WOMISA, der mit Eselsgeduld meine vielen Versuche mit dem MTK Logger getestet hat. Da ich keinen MTK Logger besitze, war dies ein nicht einfaches und recht zeitaufwendiges Unterfangen.


    Besonderen Dank auch an die anderen Betatester und Personen, die mir viele Anregungen und Fehlermeldungen zukommen ließen.


    Einige Highlights dieser Version:

    • Wesentliche Überarbeitung der Benutzeroberfläche hin zu einem universalen GPS Logger Programm
    • Unterstützung von MTK Logger (z.B. I-Blue 747 und Holux M-241) bzgl. Trackspeicher lesen und löschen
    • Erkennen und Dekodierung von UBX (u-blox) Paketen (noch unvollständig)


    Wie ihr der untenstehenden Liste entnehmen könnt, wurde auch viele Fehler bereinigt und es kamen ein paar nette Verbesserungen hinzu.


    Wie immer kann das Programm als ZIP Datei am Ende dieses Beitrags heruntergeladen werden.


    Ich wünsche euch viel Spaß und Freude mit dieser Version.


    Hier kommt die Liste der Änderungen (wie immer im Hauptfenster unter "Hilfe->Release Notes" nachzulesen:

    • Verbesserung: das Erkennen von Antworten des Gerätes während der seriellen Kommunikations wurde nochmals verbessert.
    • Verbesserung: das Auslesen des Logspeichers wurde für den WBT-201 geringfügig optimiert.
    • Verbesserung: es konnte manchmal vorkommen, dass das Programm beim Schließen der serielle Schnittstelle hängen blieb. Dieser Fehler sollte nun behoben sein.
    • Erweiterung: die Darstellung der NMEA Sätze wurde um die Darstellung der UBX Pakete erweitert. Wie bereits bei NMEA kann man mit dem Menü der rechten Maustaste
      einzelnen Meldungen pollen und ein- oder auschalten. Das Pollen geht auch mit einem Doppelklick (wie bisher schon).
    • Erweiterung: im Waypoint Editor können nun auch Wegpunkte aus GARMIN ADM Dateien gelesen werden.
      Die Tiefenwerte, der Symbolname und der Kommentar werden zwar gelesen, können aber nicht editiert werden. Sie werden aber beim Schreiben im GPX Format als GARMIN Extension gespeichert ("http://www.garmin.com/xmlschemas/GpxExtensions/v3").
    • Korrektur: beim Laden eines Tracks wurden die Optionen zur Berechnung der Track Statistik (z.B. für Auf/Abkalkulation) nicht auf die aktuell eingestellten Werte gesetzt. Fehler ist nun behoben.
    • Korrektur: falls mit den Pfeiltasten im Track Display der aktuelle Logpunkt gewechselt wird, konnte es passieren, dass bei mehrmaligem schnellen Drücken der Pfeiltasten (oder wenn man drauf bleibt - Auto Repeat)
      die Anzeige in der Logpunktliste und die Höhenanzeige kurzfristig durcheinander kam. Dieser Fehler ist behoben.
    • Verbesserung: Die Benutzeroberfläche wurde im großen Stil überarbeitet. Das Hauptfenster ist ersatzlos gestrichen worden. Es erscheint immer beim Start der Track Editor.
      Die Funktionen des Hauptfenster wurden in die Menuleiste des Trackeditors integriert.
      Die meisten Fenster haben eine Statuszeile am unetren Rand, wo u.a. der Status der seriellen Schnittstelle angezeigt wird. Der Dialog zum Öffnen und Schließen der seriellen Schnittstelle kann man
      entweder im Trackeditor unter "GPS Gerät->GPS Gerät öffnen/schließen" aufmachen, oder indem man auf den Status in der Statuszeile drückt.
      Im Menübaum "GPS Gerät befinden sich alle Funktionen die mit dem GPS Gerät zusammenhängen, auch die gerätetypspezifischen Funktionen.
    • Verbesserung: für die meisten und wichtigen Fenster wird die Fenstergröße und Fensterposition gespeichert, so dass sie beim nächsten Aufruf wiederhergestellt werden können.
    • Korrektur: im Trackeditor konnte es passieren, dass es einen Programmabsturz gab, wenn ein Track aus mehreren Tracks gelöscht wurde. Dieser Fehler ist behoben.
    • Verbesserung: im Dialog für die Benutzerlogeinstellungen gibt es einen zusätzlichen Button in der Menüzeile "Empfohlene Einstellung", die die Werte so einstellt,
      dass man für jeden Anwendungsfall einen passablen Log erhalten sollte (Optimierung für Genauigkeit/und Platz). Die Werte hierfür sind die Werte, die ich verwende.
    • Verbesserung: ab sofort kann man auch den letzten (und/oder einzigen) Track löschen.
    • Korrektur: wenn alle Punkte eines Tracks gelöscht werden sollen, wird der aktuelle Track komplett gelöscht. Bislang stürzte das Program bei dieser Aktion ab.
    • Neues Feature: ab sofort können für MTK basierte Logger (I-Blue 747, Holux M-241, etc.) der Logspeicher ausgelesen werden und er Logspeicher auch gelöscht werden.
    • Neues Feature: es können im Track Editor nun auch Holux M-241 Binärdateien (*.bin) importiert werden. Das Format entspricht weitestgehend dem MTK Format, einige Felder im Format müssen aber anders interpretiert werden.
    • Verbesserung: für das Auslesen des Logspeichers gibt es eine neue Fortschrittsanzeige, die u.a. auch die bisher verstrichene Zeit, die verbleibende Zeit und den voraussichtlichen Endzeitpunkt für die Datenübertragung anzeigt.
    • Verbesserung: in den Trackeditor Optionen kann nun der Zeitraum für die Pausenermittlung in Minuten UND Sekunden angegeben werden.
    • Korrektur: wenn im Trackeditor ein Infodiagramm mit nur einem Wert konfiguriert wurde, gab es einen Absturz. Das Problem ist nun behoben.
    • Neues Feature: im Trackeditor kann man mit STRG-O den Dialog zum Öffnen des Geräts aufschalten. Mit STRG-K bekommt man die Meldungskonsole angezeigt. Dasselbe gilt auch für den Wegpunkteditor.
    • Neues Feature: Wenn man im Dialog zum Öffnen des Geräts STRG-O drückt, wird der Dialog geschlossen.
    • Neues Feature: Wenn man in der Meldungskonsole STRG-K drückt, wird der Dialog geschlossen.
    • Neues Feature: die Meldungskonsole besitzt einen neuen Button "Speichern als...". Damit kann man entweder den selektierten Text oder, wenn kein Text selektiert ist, den gesamten Text in einer Textdatei speichern.
      Der "Speichern als..." kann auch mit STRG-S aufgerufen werden.
    • Verbesserung: das Auslesen des Trackspeichers des WSG-1000 wurde bezüglich der Timeout Fehler der aktuellen WSG-1000 Firmware optimiert. Falls Timeouts auftreten kommt AVGPS nun noch besser mit diesen klar.
  • Hallo Andreas,


    ich habe lange nichts mehr von AVGPS gehört und dachte schon die Weiterentwicklung ist eingestellt. :D :D :D


    Aber das Warten hat sich für mich gelohnt! Das penetrante Nachfragen nach einer Dowload-Funktion für den i-Blue 747 wurde von Dir erhört. Bei mir funktionieren diese Funktionen auf Anhieb! ;D


    Meinen allerherzlichsten Dank dafür vom "EselsTester" ;D


    Viele Grüsse
    Achim

  • Hallo Andreas,
    wenn's nicht schon die 2.0 wäre, müßte sie 1A (!!!) heißen.
    Man denkt sich immer, mehr geht nicht - aber wir kennen ja alle einen begnadeten Programmierer ....


    Gruß
    W.


    :respekt

  • Ich hatte mir auch schon Sorgen gemacht. 2 (oder waren es gar 3?) Tage lang keine neue Version! ;)


    Die Basics (Log vom Gerät laden, KMZ Datei erstellen) klappen auf Anhieb prima. Ein paar Anmerkungen habe ich aber doch:


    • Beim mir (unter Vista Home Premium als einschränkter Nutzer) klappt das mit dem Merken der Fenstergröße leider noch nicht.
    • Coole neue Fortschrittsanzeige beim Laden des Logs! Frage: bps steht für Byte pro Sekunde, oder? Bei 57.600 Baud würde das ja passen. Wenn es Bit pro Sekunde wären, würde es mich wundern, warum bei mir der Download nur mit ca. 5.000 bps läuft.


    Gruß und 1000 Dank!


    FRAC

  • Zitat

    Original von FRAC
    Beim mir (unter Vista Home Premium als einschränkter Nutzer) klappt das mit dem Merken der Fenstergröße leider noch nicht.


    Hmmm.... bin ich gerade sprachlos... ich merke mir die Position und Größe in der Konfigdatei und setze diese beim Öffnen der Form. Das sollte eigentlich auf allen Betriebssystemen unter .NET gleich funktionieren.


    Zitat


    Coole neue Fortschrittsanzeige beim Laden des Logs! Frage: bps steht für Byte pro Sekunde, oder? Bei 57.600 Baud würde das ja passen. Wenn es Bit pro Sekunde wären, würde es mich wundern, warum bei mir der Download nur mit ca. 5.000 bps läuft.


    Jup, ich meine Bytes pro Sekunde.... habe das gerade der Klarheit wegen geändert... ;)


    BTW:
    Gegen die Begriffsverwirrung zwischen Bit pro Sekunde und Baud (Signalwechsel pro Sekunde) kämpfe ich bereits seit über 20 Jahren..... zu Zeiten, wo es noch Analogmodems gab und dies noch viel häufiger falsch verwendet wurde.


    Das einzige, was Du sicher weißt, ist, dass Deine Schnittstelle mit 57600 Bit pro Sekunde läuft. Wieviel Baud das sind, wirst Du wahrscheinlich nie erfahren und willst es auch wohl nicht wirklich wissen. ;)


    Grüße


    Andreas

  • Zur Fenstergröße: Das füllt bei mir immer nur einen Teil des Bildschirms. Ich vergrößere das dann so, dass der ganze Bildschirm genutzt wird. Beim nächsten Start hat ist es aber wieder kleiner. Vielleicht liegts daran, das beim Darstellen mit voller Bildschirmgröße das Fenster jeweils 16 Pixel zu groß in Höhe und Breite gerät, und das Ganze dann im 8 Pixel nach links und nach oben aus dem Bildschirm rausgeschoben ist? Anbei mal der entsprechende Auszug aus der Konfigdatei:



    Zum Thema "Baud" hast du ja Recht, dazu gibt's übrigens einen prima Artikel auf Wikipedia.


    Gruß


    FRAC

  • FRAC,


    heißt das, dass es mit kleineren Fenstergrößen funktioniert, aber nur nicht mit den ganz Großen?


    Andreas

  • Das heißt zweierlei:
    [list=1]
    [*]Wenn ich auf "Full Screen" zoome, fällt das Ergebnis 16 Pixel in beide Richtungen zu groß aus, und die obere linke Ecke wird auf ( -8;-8 ) gesetzt.
    [*]Wenn ich das Fenster von Hand auf Größen bis. ca. 90% der Bildschirmbreite bzw. Höhe aufziehe, bleibt das auch bis zum nächsten Start erhalten. Sobald ich in der Höhe oder Breite oder beidem nach an die Maximalwerte (ab ca. 90%) gehe, startet AVGPS beim nächsten Mal statt dessen mit seiner Defaultgröße.[/list=1]
    Ich habe daraufhin mal die Größe in avgps.cfg von Hand konfiguriert. Siehe da - meine geschätzten 10% waren ein Treffer! Bis 1152 x 720 Pixel klappt alles bestens. Darüberhaus (also 1153 oder mehr Pixel breit oder 721 oder mehr Pixel hoch) wird jeder Größenwunsch über diese Grenzen hinaus abgeschnitten, das Fenster bleibt maximal 1152 Pixel breit oder 720 Pixel groß, was sich so auch in der Konfigdatei wiederfindet. Bei 90% der Maximalwerte meines 1280x800er Bildschirms ist also Schluss.


    Gruß


    FRAC

    Einmal editiert, zuletzt von FRAC ()

  • Hallo Frank,


    ich war auch nicht untätig und habe selber auch einige Versuche gemacht.


    Immerhin funktioniert die Wiederherstellung der Fensterposition und Fenstergröße prinzipiell.


    Mit "Full Screen zoomen" meinst Du wohl das Maximieren des Fensters mittels Maximize Button!?
    Komisch, dass bei Dir das Fenster zu groß ausfällt - bei mir tut das unter XP wie erwartet. Ich sag nur - WinDoof halt...


    Das Problem liegt momentan bei .NET. Ich weise der Form die gespeicherte Position und Größe vor dem Öffnen einfach zu (ich verändere die gespeicherte Werte nicht) aber .NET meint wohl, dass 90% ausreichen müssen. Ich habe einiges noch ausprobiert (z.B. die MaxSize für die Form auf 2000x2000 gesetzt) - aber leider ohne Erfolg.


    Was ich noch einbauen könnte, wäre, dass ich mir noch merke, ob die Form maximiert oder im normalen Zustand war.


    Das Problem, dass ich die Größe nicht über 90% der Bildschirmgröße setzen kann, bleibt erstmal bestehen, solange ich nicht einen wertvollen hinweis im Internet finde.


    Grüße


    Andreas


  • Hm.


    Ist es in "unserem" Fall mit binärer Übertragung nicht doch so, dass jedes bit einen Signalwechsel darstellt, also bit/sec = Baud ist? Nicht, dass das jetzt von überragender Wichtigkeit wäre, aber interessant wäre es doch schon... Ohne hier jetzt ein Nachrichtentechnik Seminar abhalten zu wollen...

  • Zitat

    Original von karomue
    Hm.


    Ist es in "unserem" Fall mit binärer Übertragung nicht doch so, dass jedes bit einen Signalwechsel darstellt, also bit/sec = Baud ist? Nicht, dass das jetzt von überragender Wichtigkeit wäre, aber interessant wäre es doch schon... Ohne hier jetzt ein Nachrichtentechnik Seminar abhalten zu wollen...


    Kann schon sein.... ist es aber höchstwahrscheinlich nicht! Ausserdem ist in der Digitaltechnik jede Signalübetragung binär.... ;)


    Baud ist eine Einheit ist, die die Frequenz des Datensignals angibt. Wenn man jetzt noch weiß, wieviele Bits das Signal kodieren kann (z.B. 2 Bits durch 4 Spannungshöhen) dann kann man die Bits pro Sekunde errechnen.


    Aber das interessiert und eigentlich nie: wir wollen doch lediglich wissen, wieviele Bits wir in einer Sekunde über eine Schnittstelle senden oder empfangen können. Wie das technisch umgesetzt wird ist normalerweise belanglos.


    Der Punkt ist, dass man nicht über etwas eine Aussage machen sollte, was man nicht weiß. Im Spezialfall sind 1 bps = 1 Baud, in den allermeisten Fällen ist es das aber nicht.


    Sorry, dass Ganze ist ziemlich OT.... aber war vielleicht für Einige doch interessant.


    Grüße


    Andreas


  • Das finde ich nicht unbedingt, denn Baud ist schon etwas mir dem wir reht oft herumschmeißen. Und wir aben es soweit ich weiß, bei "unseren" Übertragungen "nur" mit 2 Pegeln - 0 und 1 - und nicht mit z.B. 3, +12V/0V/-12V, oder gar mit noch mehr zu tun.


    Es mag sein, dass bit/sec nicht 100%ig Baud sind, aber - soweit mein Verständnis derzeit - der Unterschied bei uns ist marginal bis unwesentlich/unmerklich.

  • Charly,


    es gibt zwei wesentliche Gründe, weshalb man in unserem Kontext mit Baudrate falsch liegt:


    1) Wir reden hier immer über die Datenübetragungsrate und nicht über die technische Realisierung, wie die Daten übertragen werden. Deshalb ist es in unserem Kontext falsch von Baud zu reden, da wir es schlicht nicht wissen, ob in unserem Fall 1 bps = 1 Baud ist.


    2) Meines Wissens nach beinhaltet die Datenübetragungsrate nicht die Bits, die die physikalische Schicht zur Implementierung der Datenübetragung benötigt. Ich meine sogenannte Preambeln und Endesequenzen und Daten, die zur physikalischen Kommunkation benötigt werden.


    Ein Beispiel hierfür: Ethernet 802.3 10 MBit kodiert die reinen Daten mit einem Bit pro Signalwechsel, das findet in diesem Fall tatsächlich mit 1 Baud statt. Aber zudem wird ein Bit pro Bit für die Clock Synchronisierung benötigt, so dass tatsächlich die Datenübetragung mit 20 MBaud stattfindet - d.h. 1 Baud = 0.5 Bits.


    Lange Rede, kurzer Sinn: man sollte nur von Baud reden, wenn man wirklich Baud meint. Und das ist nur dann der Fall, wenn man über den ISO Level 1 (physical Layer) redet, und das tun wir hier im Normalfall nicht.


    Das es die halbe Welt falsch macht, inklusive z.B. Wintec, Haid, Microsoft, und so viele Andere, macht die Sache nicht richtiger....


    Grüße


    Andreas


  • Danke, Andreas.


    Icvh denke, das war mal notwendig, denn es zeigt - in treuer Vereinigung mit den angezogenen Firmen - dass man mit Baud i.d.R. im Wald steht. Da hilft auch nicht meine Information, die von jemand stammt, der es mir Sicherheit auch weiß. Warum dabei das Sync-Bit nicht zur Sprache kam entzieht sich meiner Kenntnis. Und ein bit/sec oder 1/2 bit / sec. ist mehr als man noch tolerieren könnte.


    Zitat-Auszug:


    "... Machen wir ein Beispiel.
    Wir übertragen die Information HTW, codiert ASCII 8-Bit:
    H: 0100 1000
    T: 0101 0100
    W: 0101 0111

    Seriell übertragen ergibt HTW; 0100 1000 0101 0100 0101 0111 (24Bits)

    Physikalich kann die Übertragung so aussehen; Logisch 0 = 0V, Logisch 1 = +5V
    Auf dem Draht wäre zu messen:
    0V, 5V, 0V, 0V, 5V, 0V, 0V, 0V, 0V, 5V, 0V, 5V, 0V, 5V, 0V, 0V, 0V, 5V, 0V, 5V, 0V, 5V, 5V, 5V (total 24 Spannungswerte/Wechsel (=24 Baud) werden übertragen).. .

    Eine andere Möglichkeit: Wie fassen jeweils drei Bits zusammen und geben folgende Zuordnung:
    000 = 0V
    001 = 1V
    010 = 2V
    011 = 3V
    100 = 4V
    101 = 5V
    110 = 6V
    111 = 7V
    010010000101010001010111 wird zu 010 010 000 101 010 001 010 111 zerlegt und übetragen mit:
    2V, 2V, 0V, 5V, 2V, 1V, 2V, 7V (total sind es jetzt 8 Spannungswerte/Wechsel = 8 Baud)

    Die Baudrate gibt nur die Anzahl der Wechsel pro Sekunde an und nicht die Anzahl der Informationsbit an...."


    Gut, vielleicht ist das Syncbit hierin versteckt...



    Sorry, ich hatte so vor 55 Jahren auch mal was über Nachrichtentechnik gehört, erinnere mich noch an Ortskurven, aber nicht an Baud. :]

    Einmal editiert, zuletzt von karomue ()

  • Hallo AVGPS-Fangemeinde,


    die NEUE Version ist für die i-Blue 747 Gemeinde ein weitererer Meilenstein und funktioniert super!
    Ich glaube die AVGPS Fangemeinde hat großes Potential zum Wachsen :D


    Ich wiederhole mich hier sehr gerne, Andreas ist ein "Vollprofi" und ein Segen für unsere Loggergemeinde...
    Hoffentlich hält der Drang zu neuen Ufern an.



    Herzlichen Dank an Andreas für die neue erweiterte Version und : drink
    Achim