wariat@chrome.pl

Trudno o protokole LogIt powiedzieć, że jest popularny. Używany jest w kilku GPS loggerach (z których pierwszym był szwajcarski LogIt), czy jakiś czas temu ulubiony odbiornik zawodników GPS: MLR SP24XC. Kto i kiedy wymyślił protokół nie mam pojęcia. Ale obstawiam Szwajcara który zaprojektował LogIt'a i zastanawiam się co on wtedy pił.
Pamiętam jak sam namawiałem Muzzyego aby w MuzzyLoggeRrze wykorzystał istniejący protokół bo będzie łatwiej. Dziś tego żałuję... przyjżałem się protokołowi z bliska.

O co chodzi? Chodzi o to, że nie można było tego bardziej spieprzyć. Mówimy o małym urządzeniu z procesorkiem, które odbiera z GPS dane, zapisuje tracklog w swojej pamięci której jest duuużo i później pozwala go odczytać za pomocą komputera. To trywialne jak się wydaje zadanie LogIt skomplikował do niemożliwości.

Zacznijmy od sumy kontrolnej. Dane NMEA z GPS zawierają sumę kontrolną (1 bajt obliczany jako xor wszystkich znaków w wierszu pomiędzy znakami $ i *), GPS logger musi (powinien) umieć ją obliczać aby sprawdzić czy odebrane dane nie są uszkodzone. Potrafi obliczyć, żeby sprawdzić ale ... nie nie warto wykorzystać tej samej funkcji ponownie. Protokół LogIt przewiduje dodatkowo:

• Suma kontrolna dla komend przekazywanych z komputera
• Suma kontrolna danych wysyłanych z loggera do komputera

Nie dało się bardziej skomplikować prawda? Ale to nie koniec.

Pobieramy dane z loggera. Logger rozmawia do nas stringami różnej długości, transmisję pakietu danych kończy windzianym końcem linii [CR] [LF]. Kłopot polega na tym, że dane przesyłane w paczce są danymi binarnymi nic więc nie gwarantuje, że po drodze nie pojawi się wspomniany koniec linii, nie będący końcem linii.
Ba mamy nawet gwarancję, że się pojawi jeśli loga będzie więcej niż trochę bo już na samym początku paczki mamy jej numer, dwa bajty czyli jeśli nie gdzie indziej na bank wywali się na paczce przesyłającej trackpoint numer 3338.

Ale zaraz, żeby zacząć pobierać dane trzeba przekazać loggerowi komendę rozpoczęcia transmisji - logiczne. Transmisja może odbywać się z prędkościami: 4800, 19200, 38400, 57600 i 115200 bps. Przy czym do loggera rozmawiamy zawsze z prędkością 4800bps. Transmisja może wyglądać tak:

• Komputer -> Logger (4800bps) - wyślij dane z prędkością 57600bps
• sekunda przerwy
• Logger -> komputer (57600bps) - lecą dane, bez żadnej kontroli przepływu, po prostu logger napierdziela a ty musisz zdążyć wszystko odebrać.
• Komputer -> Logger (4800bps) - komenda przerwania transmisji (w jej trakcie)

Efekt jest taki, że w buforze siedzi część danych których nikt nie odebrał, bo trzeba było przejść na inną prędkość w celu przerwania potoku danych.

Pomijam już kłopoty po zapisaniu danych w innej ćwiartce świata. Dane zapisane w Australii wymagają zmiany algorytmu, dane zapisane na granicy S/N czy E/W prawdopodobnie są nie do odczytania, bo wymagają na raz dwóch algorytmów.

Nie wiem, nie znam się na elektronice, ale wydawało mi się, że jeśli mamy malutkie urządzenie z malutką pamięcią na program to powinno się przynajmniej algorytm wymyślić optymalny. Czyli np. użyć jednej znanej sumy kontrolnej do potwierdzenia prawidłowej transmisji we wszystkich kierunkach.
Być może mam też dziwne wyobrażenie o sprzęcie, ale mój pierwszy modem gdzieś pod koniec lat 80tych dopowiadał komputerowi z dokładnie taką samą prędkością z jaką rozmawiał do niego ów komputer. Wtedy się dawało a teraz nie?
Pewnie okażę się nudziarzem kiedy zauważę, że po to ktoś kiedyś wprowadził kontrolę transmisji za pomocą sygnałów RTS/CTS żeby można było wygodnie odczytywać dowolnie duże paczki danych z dowolnie wysoką prędkością i nie martwić się, że się na coś nie zdąży.

Czy to naprawdę takie trudne zadanie zmontować kawałek elektroniki który działałby jak wyżej? Czy to aż taki problem oprogramować go tak aby transmisja miała "ręce i nogi"? Wierzyć mi się nie chce...

No to się wyżaliłem... Wracam do pobierania tracków z MuzzyLoggeRa ... trzeba zaktualizować OpenStreetMap ;-).