2012-10-04 8 views
5

Ich habe ein Problem mit der Berechnung der Prüfsumme für NMEA-Sätze. Ich verwende den folgenden Java-Code:NMEA-Prüfsummenberechnung

private static String getSum(String in) { 
    int checksum = 0; 
    if (in.startsWith("$")) { 
     in = in.substring(1, in.length()); 
    } 

    int end = in.indexOf('*'); 
    if (end == -1) 
     end = in.length(); 
    for (int i = 0; i < end; i++) { 
     checksum = checksum^in.charAt(i); 
    } 
    String hex = Integer.toHexString(checksum); 
    if (hex.length() == 1) 
     hex = "0" + hex; 
    return hex.toUpperCase(); 
} 

Dieser Code ist ähnlich wie viele andere Beispiele rund um das Internet und alles funktioniert, bis ich einen Satz wie diesen versuchen ..

$PSRF101,-2686700,-4304200,3851624,96000,497260,921,12,3*1C

Dieser Satz ist von der NMEA Reference Manual und so nehme ich an, die Prüfsumme wird korrekt sein. Aber wenn ich es berechne, bekomme ich * 2F als Prüfsumme und nicht 1C.

Ich denke, das liegt an den negativen Werten im Satz, aber ich habe keine Ahnung, wie ich mit ihnen umgehen soll. Hat jemand einen Vorschlag?

+1

Das '-' Zeichen macht keinen Unterschied: die Prüfsumme wäre immer noch '2F' –

+0

Falsch, jedes Zeichen trägt dazu bei. Wenn Sie jedoch BEIDEN der Bindestriche entfernen, sind Sie in der Tat XORing zweimal ... das bringt Sie zurück, wo Sie waren. Das Entfernen des einen oder anderen absolut ändert das Ergebnis. – Anders8

Antwort

8

Der Unterschied zwischen der angenommenen und der berechneten Prüfsumme ist gleich Null (oder mit einem zusätzlichen Zeichen '3'); Ich wäre also versucht, Fehler im NMEA Reference Manual zu glauben.

Sie können einen Online-NMEA-Rechner ausprobieren, um die Ergebnisse zu überprüfen.
z.B. http://www.hhhh.org/wiml/proj/nmeaxor.html

+0

Das Sirf-Handbuch hat auch mindestens einen anderen fehlerhaften Befehl "$ GPMSK, 318.0, A, 100, M, 2, * 45", der ein zusätzliches Komma hat –

+1

Also könnte dies ein Fehler des Handbuchs sein? Da die "$ PSRF104,37.3875111, -121.97232.0,96000,237759,1946,12,1 * 07" auch fehlerhaft sind, bekomme ich ein "* 06" von meinem Code und dem Online-Rechner, das Handbuch sagt "* 07 ". Hier sind wieder negative Werte, also dachte ich, dass es wegen ihnen falsch sein könnte. – htz

+1

Der Fehler zwischen 06 und 07 ist einfach 01 in Hexadezimal. Dies würde bedeuten, dass einige (vielleicht das letzte Zeichen) 0 statt 1 hätte sein sollen. Dann würde die Prüfsumme übereinstimmen. Die Zeichen "-" scheinen nicht zum Fehler beizutragen. –