Sajnos most még másfél hétig nincs időm huzamosabb időt a fórumon tölteni, de röviden összefoglalom ezt a kérdést.
Az NMEA protokoll "mondatai" bárhol megnézhetők, elég akár egy NMEA logba belekukkantani. Ha összeadja az ember az 1 másodperc alatt összeszedett adat mennyiségét, akkor kijön, hogy a 4800 elég. Gyorsan megnéztem a BT-s loggerből kijövő NMEA egy "csomagját": 280 bájt, vagyis 2240 bit jött ki. Persze mielőtt elhamarkodottan következtetéseket vonnánk le, fontos kihangsúlyozni azt, hogy ez csak a "fogadott adás". És az NMEA protokoll baudrate-ről beszél, ami nem ugyanaz, mint a bitrate (ezt általánosan keverik az összes adatátviteli témakörben), amibe bele kell érteni a vezérlő jeleket is. A kérdésre van gyakorlati válasz is: a jelek szerint minden NMEA protokollt használó GPS működik 4800-on, tehát tutira elég.
SIRF üzemmódban ez már másként van, ott van jópár huncutság az NMEA "szókincséhez" képest. Erről a legegyszerűbben úgy lehet meggyőződni, hogy megnézi az ember SirfTech-ben, milyen extra információkat mutat a rendszer (persze néhány adat származtatott csupán). Ja, és persze a SIRF protokoll részletes leírása az igazi királyság, abban tényleg minden ott van. Bár kihasználnák a szoftverek azt a sok apróságot, amit ez a protokoll lehetővé tesz!
A késésről: igazad van abban, hogy a Windows Mobile portmegosztása okozhat késést. Ez nyilván függ az oprendszertől (WM5 vs. WM6, gyári romok vs. főzött ROM-ok, GPS vevő szoftveres implementációja stb), de talán leginkább a mögöttes elven múlik minden: ha egy portot a navigációs szoftver nem közvetlenül ér el, (tekintsünk el a portvezérléssel kapcsolatos absztrakciós szintek kérdéskörétől), hanem az oprendszer egy futó szoftverkomponensén, taskján keresztül, akkor nyilván a szoftvernek meg kell várnia, amíg az oprendszer ütemezője "lapot oszt" a szoftveres portsplitternek, és újabb látenciát jelent az is, amíg a navigációs szoftver és a Windows Mobile szépen eljátssza a kommunikációt. Minden "szoftver adatot nyer hardverről" kommunikáció esetén késést okoz egy újabb szoftverkomponens beiktatása. Lehet, hogy ez a késés a user számára nem érzékelhető, de elvi szinten feltétlenül megjelenik, hiszen több program verseng a közös erőforrásért (CPU, memória). Nem teljesen jó példa, de kb. ilyenek a digitális effektek a hangtechnikában. A hang az olcsóbb (gagyibb?) effekteken (legyen az gitárpedál vagy nagy keverőbe beépített) áthaladva az analóg-digitál-analóg konverzió során szükségszerűen időveszteséget szenved, ellenben az analóg effektekkel, ahol színtiszta elektronikai kérdésről van szó, és mint tudjuk, a "villany" gyorsan közlekedik a drótokon.
A gyakorlatban egyik gépen jelentős késést okoz, a másikon pedig érzékelhetetlen a különbség a direkt hardveres és a szoftveres port elérés között. Ez elég nagy valószínűséggel annak köszönhető, hogy PDA és PDA között jelentős eltérések lehetnek oprendszer szinten is, más verzió, picit más ütemezés, na meg a legfontosabb: más futó taskok. Talán az határozza meg a leginkább a késés mértékét, hogy mik futnak még a háttérben, és itt nyilván nem csak a felhasználói programokra gondolok, hanem a rendszer komponenseire is. Ezek prioritása biztosan hatással van a szoftveres portosztás sebességére. A másik gyakorlati tapasztalat pedig az, hogy a windowsos portosztás bizonyos konfigurációk esetén instabil. Én is javítottam már több olyan PDA-t is (Asus, Fujitsu-Siemens), amelyeken a navigációs szoftverek nem látták a GPS vevőt vagy különféle parajelenségeket produkáltak bekapcsolt szoftveres portosztás esetén. És ennek az ellenkezője is igaz: volt a kezemben olyan PDA (már nem emlékszem, hogy pontosan mi volt, de talán FuSi N520), amelyik kikapcsolt portosztás mellett nem látta a vevőt.
Annyi biztos, hogy aki nyugodtan akar aludni (és persze terepre menni), annak a GpsGate a tuti megoldás, nem drága és még extra funkciókat is biztosít.[ előzmény: (29453) SylverRat + Bogee, 2008.05.07 17:02:25] |
