Zoo-Kommunikationsprotokolle für GPS-Tracker (Teil 2)



    Dies ist eine Fortsetzung des Artikels über Netzwerkprotokolle, die mit GPS-Trackern verwendet werden. Wenn wir uns im ersten Teil mit Frame-Decodern befasst haben, dann betrachten wir im zweiten Teil Optionen zum Codieren verschiedener Arten von Nutzdaten. Viele Hersteller von GPS-Überwachungsgeräten entwickeln ihre eigenen Protokolle auf Anwendungsebene, um Daten vom Gerät auf den Server zu übertragen, und manchmal greifen Entwickler auf verschiedene ausgefeilte und nicht immer klare Lösungen zur Datencodierung zurück.

    Für diejenigen, die den ersten Teil nicht gelesen oder vergessen haben, gibt es zwei Hauptgruppen, in die alle Protokolle unterteilt werden können: Text und Binär. In Textprotokollen werden Informationen in Form von ASCII-Codes übertragen, und in Binärform werden alle Daten in Big-Endian- oder seltener in Little-Endian-Binärform codiert.

    Bytereihenfolge (Endianität)


    Die Reihenfolge von Senior zu Junior (Big-Endian) ist Standard für TCP und UDP, sie wird in den Headern von Datenpaketen und in vielen Protokollen einer höheren Ebene verwendet. Daher wird die Bytereihenfolge von hoch nach niedrig oft als Netzwerk-Bytereihenfolge bezeichnet und ist der De-facto-Standard für die Codierung von Binärdaten in Netzwerkprotokollen.

    kurz i = 1; // 0x00 0x01 - Big-Endian (Netzwerk-Bytereihenfolge)
                 // 0x01 0x00 - Little-Endian

    Das Problem ist, dass Zentralprozessoren am häufigsten die Reihenfolge vom jüngsten zum ältesten (Little-Endian) verwenden und daher viele Hersteller von GPS-Trackern beschlossen, die Daten in demselben Format zu codieren, in dem die Daten im Speicher gespeichert sind (d. H. Little-Endian). . Die Liste solcher Hersteller ist ziemlich umfangreich, daher möchte ich nur einige Beispiele nennen: Baltic Car Equipment (BCE, litauische Firma), Cellocator (ein großes internationales Unternehmen mit Hauptsitz in Israel) und GalileoSky (ein bekannter russischer Hersteller von GPS-Trackern mit Hauptsitz in Perm).

    Einige Hersteller gehen sogar noch weiter und verschlüsseln einen Teil der Daten mit einer Bytereihenfolge und einen Teil mit einer anderen. Beispielsweise senden Geräte des chinesischen Unternehmens Topflytech und des polnischen Herstellers Tytan GPS alle Daten in der Standard-Netzwerk-Bytereihenfolge, mit Ausnahme von Gleitkommazahlen, die im Little-Endian-Format gesendet werden. Fairerweise sollte beachtet werden, dass Tytan GPS das Problem in der zweiten Version seines Protokolls behoben hat.

    Geographische Koordinaten


    Koordinaten (Breitengrad von -90 ° bis + 90 °, Längengrad von -180 ° bis + 180 °) können auf verschiedene Arten dargestellt werden. GPS-Empfänger geben normalerweise den Wert in Grad und Minuten mit Dezimalstellen zurück, wobei die positiven Koordinaten durch die Buchstaben „N“ (nördlicher Breitengrad) und „E“ (östlicher Längengrad) und die negativen Koordinaten durch die Buchstaben „S“ (südlicher Breitengrad) und „ W ”(westlicher Längengrad).

    Die größte Auswahl an Koordinatenkodierungsoptionen finden Sie in Textprotokollen. Das Vorzeichen der Koordinaten kann entweder durch einen Buchstaben oder durch ein Vorzeichen vor dem Wert in Grad dargestellt werden (in einigen Fällen wird ausdrücklich ein positives Vorzeichen angegeben). Der Wert kann entweder in Grad mit Dezimalbrüchen oder in ganzzahligen Grad und Minuten mit Dezimalbrüchen angegeben werden. Dezimalpunkte können weggelassen werden, und das Trennzeichen zwischen Breite und Länge kann auch fehlen. Hier sind zum Beispiel mehrere Darstellungsoptionen für Pentagon-Koordinaten:

    38.870989, -77.055961 // Grad dezimal
    3852.25934, N, 07703.35766, W // Grad (2 Zeichen für Breitengrad und 3 Zeichen für Längengrad) und Minuten in Dezimalzahl
    W77.055961, N38.870989 // Halbkugel und Dezimalgrad
    + 38.870989, -77.055961 // explizite Angabe des nördlichen Breitengrads durch ein Pluszeichen
    3852.2593N07703.3577E // Kein Trennzeichen zwischen den Koordinaten

    In binären Protokollen werden geografische Koordinaten normalerweise entweder durch eine Ganzzahl dargestellt, die durch einen bestimmten Faktor geteilt werden muss, um die Koordinaten zu erhalten, oder durch eine Gleitkommazahl (normalerweise 4 Byte).

    0x04 0x2b 0x9f 0xa4 -> 69967780 -> (/ 60/30000) -> 38.870989 // Ganzzahl
    0xc2 0x9a 0x1c 0xa7 -> -77.055961 // Gleitkommazahl (float)

    Das Koordinatenzeichen kann getrennt vom Koordinatenwert gespeichert werden. Zum Beispiel werden im Protokoll von Tzone Digital Technology die Bits der Längen- und Breitengrade mit dem Richtungswert in 2 Datenbytes kombiniert:

    0x03 0x0E // 0 0 0 0 0 0 1 1 0 0 0 1 1 1 0
              // | | | Richtung (9 Bits) - 270 Grad
              // | | Vorzeichen der Länge - minus (westliche Länge)
              // | Breitengradzeichen - Plus (nördlicher Breitengrad)

    Eine weitere interessante Option zum Kodieren von Koordinaten in Binärform ist der Binär-Dezimal-Code (binär-kodierte Dezimalzahl oder nur BCD). Das Wesentliche bei der Codierung ist, dass jede Dezimalstelle einer Zahl in Form ihres 4-Bit-Binärcodes geschrieben wird. Beispielsweise sieht der Breitengrad des Pentagons in den Protokollen der chinesischen Unternehmen KHD oder Gator folgendermaßen aus:

    0x03, 0x85, 0x22, 0x59, 0x34 -> 38 Grad, 52,25934 Minuten

    Beachten Sie, dass die hexadezimale Schreibweise genau mit dem Dezimalwert übereinstimmt. Es stellt sich heraus, dass die in BCD codierten Daten von einer Person relativ leicht gelesen werden können. Leider erschwert diese Art der Codierung das Lesen dieser Daten durch den Computer und erhöht auch die Größe der Nachricht.

    Datum und Uhrzeit


    Die überwiegende Mehrheit oder sogar alle Protokolle bei der Übertragung von Koordinaten an den Server enthalten einen oder mehrere Zeitstempel. Normalerweise ist dies die Zeit zum Bestimmen der Koordinaten des GPS-Empfängers, aber manchmal können das Datum und die Zeit der internen Uhr des GPS-Trackers zu dem Zeitpunkt, als das Paket gebildet wurde, sein. Einige Tracker senden zwei oder mehr Zeitstempel.

    In Textprotokollen werden Uhrzeit und Datum fast immer in separate Komponenten unterteilt. Hier einige Beispiele für die Darstellung des Zeitpunkts der letzten Zeitübertragung in Russland (26. Oktober 2014, 14.00 Uhr):

    2014/10 / 26.02: 00: 00 // Datum und Uhrzeit mit Begrenzern
    020000.000, ... 261014 // Zeitgenau auf Millisekunden
    141026 ... 020000 // Datum und Uhrzeit ohne Begrenzer
    20141026020000
    14/10/26 2:00 // Datum und Uhrzeit auf Minuten genau

    Ein wichtiger Punkt ist, dass die Zeit normalerweise in GMT (UTC- oder GMT-Zeitzonen) übertragen wird. Dies ist wichtig, da sich Server und Tracker in unterschiedlichen Zeitzonen befinden können. Bei einigen GPS-Trackern können Sie die Zeitzone konfigurieren. Gleichzeitig meldet ein Teil von ihnen die ausgewählte Zeitzone an den Server und ein Teil nicht. Für diejenigen, die keinen Bericht erstellen, müssen Sie die Zone auf dem Server manuell festlegen.

    Ein interessantes Beispiel für ein Problem mit Zeitzonen ist das namenlose Protokoll, das in vielen billigen chinesischen Trackern verwendet wird. Der Tracker sendet das lokale Datum (Jahr, Monat, Tag) und die Uhrzeit (Stunden, Minuten, Sekunden) sowie eine millisekundengenaue GMT-Zeit. Das Interessante in diesem Fall ist, dass Sie mit diesen Daten das GMT-Datum für Zeitzonen von GMT-12 bis GMT + 12 berechnen können. Wenn am Eingang beispielsweise 2016-01-01 01:00:00 (Ortszeit) und 59: 00: 00.000 (GMT) angezeigt werden, lautet die Ausgabe 2015-12-31 59: 00: 00.000 (GMT). Leider funktioniert diese Methode nicht für Zeitzonen mit einer Abweichung vom Greenwich von mehr als 12 Stunden.

    Eine andere bemerkenswerte Zeitdarstellung wird im Standard-TAIP-Protokoll verwendet. Ab dem 6. Januar 1980 wird die Zeit in Wochen, Tagen und Sekunden angegeben. Die Bedeutung dieses Datums ist nicht ganz klar, aber es ist der Standard für viele GPS-Empfänger.

    Einige Protokolle übertragen nur die aktuelle Uhrzeit an den Server. In diesem Fall kann nur das aktuelle Datum entsprechend der Serverversion ersetzt werden. Dementsprechend kann dies zu Problemen führen, wenn sich die Uhrzeit von Server und Gerät unterscheidet oder wenn sich die Datenübertragung verzögert. Beispielsweise kann das Gerät die Uhrzeit 23:59:59 übertragen, und wenn Sie diese Nachricht erhalten, beginnt der Server bereits am nächsten Tag. Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, den empfangenen Zeitstempel mit der aktuellen Serverzeit zu vergleichen. Wenn die Differenz mehr als eine Stunde oder mehrere Stunden beträgt, müssen Sie einen Tag zum empfangenen Datum hinzufügen oder davon abziehen.

    In binären Protokollen werden Datum und Uhrzeit entweder in separate Komponenten sowie in Textkomponenten unterteilt oder als UNIX-Zeitstempel (die Anzahl der Sekunden oder Millisekunden seit Mitternacht (00:00:00 GMT) am 1. Januar 1970) gespeichert.

    Fazit


    Alle in diesem Artikel enthaltenen Informationen wurden während der Arbeit am GPS-Überwachungsserver gesammelt. Das Projekt ist komplett Open Source, und wenn jemand daran interessiert ist, kann der Quellcode mit der Implementierung aller oben genannten Protokolle auf GitHub gefunden werden .

    Auch könnte jemand sein Interesse an der Dokumentation der Protokolle für den GPS-Tracker . Leider kann ich nicht alle verfügbaren Dokumente öffentlich zugänglich machen, da einige davon vertraulich sind.

    Jetzt auch beliebt: