Valóban kimaradtam, mert amikor betuszkolták a nüviben megjelent elcseszett, egyedül csak usb háttértárat és gpx-eket ismerő új oprendszerüket, egyúttal elkezdték lespórolni a gombokat az államaikról elnevezett a készülékeken, lemondtam arról hogy valaha is továbblépjek a 60-as sorozattól.
Erre most megjelent egy 60-as családbeli, majdnem eredeti gombkiosztású, majdnem olyan alakú, majdnem olyan kijelzőjű típus, mint a régiek. A változások többsége nagyon idegen, nagy részükről tíz napnyi teszt után is azt gondolom, hogy kár volt változtatni.
Az ügyfélszolgálattal folytatott küzdelembe már előzőleg belefáradtam. Majd akkor fogok újra hibákkal érdemben foglalkozni, ha valaki szerez egy fejlesztőkörnyezetet valamelyik vashoz. Esetleg kimehetne egy lelkes fejlesztő hozzájuk, aztán vagy megold mindent helyben, vagy hazahozza a feladatot.
A 49371-et megerősítem, az MTK-s gps-en az mindig EPE kifejezetten kisebb volt, mint az összes többin, beleértve a 62s-t is. Ennek ellenére nem volt annyival pontosabb, inkább csak kevesebbet ugrált, mint a SiRF III-as. Ruttkay ugyanúgy látta a Vértesben húzott nyomvonalakat, mint én: a 62s húzta a legszebbet. Ha a 62s nem sodródott volna ki egy csomó biciklis kanyarban, akkor a Cartesio vevőt mondanám legjobbnak. Megpróbálom a Mediateket is hasonló helyzetbe hozni, sajnos most már nem lesz mellette a 62s. Szerencsére pénteken dolgoztak együtt a hátizsákban, ott látható pár olyan városi kanyar, amit a mediatek vett jobban.
A 60 CSx időugrásával kapcsolatban felmerült bennem a gyanú, hogy esetleg összefüggésben állhat azzal a tünettel, amikor nyomok egy útpontot és sokáig nem történik semmi, majd körülbelül éppen 10-20 másodperc után tér észhez. Ekkor megjelenik a képernyőn az útpont, tapasztalataim szerint azon a helyen, ahol nyomtam. Valóban a processzor foglaltságát sejtettem eddig, talán éppen egy a flash-lapot töröl és másol olyankor.
A track- és útpont-rögzítés ugyanis közvetlenül NAND flashbe történik, mégpedig egészen izgalmas módon. Leürít 64 kilobájtot, amitől minden bit 1-re áll, vagyis csupa FF lesz minden byte. Ezt a törlést csak nagy blokkokban tudja megtenni. Utána viszont bitenként tud nullázni, vagyis úgy tárolja az adatot, hogy a nullákat írja, az egyeseket meghagyja. Onnan tudja hogy éppen hol az adatsor vége, hogy ahol a következő csomag megfelelő bitje 1-es, akkor oda még nem írt.
Innentől kezdve kicsit különbözik a track- és a waypoint-memória. A track egyszerűbb, pontokat pakol egymás után 16 bájtonként. 4 byte long integer lat (lat/360*2^32), 4 byte long integer lon (ugyanígy), 4 byte float alt, 4 byte long utc. A long első bitje nem használatos, mert a lat csak +90 és -90 között van, oda akkor tesz 1-est, ha szakadás utáni a trackpont. Öregebb gps-ekben csak 3 byte a pozíció, ott 2^24 részre osztja fel a 360 fokot, továbbá float helyett word-ként tárolja a magasságot, így csak 12 byte a trackpont. Amikor teleírt 64k-t, akkor kezdi a következőt. Amikor már mindent teleírt és "wrap when full" be van kapcsolva, akkor gondban lenne, ha nem lenne egy tartalék 64k-ja. Ilyenkor elkezd írni a tartalékba, a végén pedig letörli a legelső lapot. Ezzel nem veszt adatot, mert azon a lapon már biztosan régebbi trackpontok voltak, mint a trackmemória. Ebben a módszerben az a szép, hogy amint rögzítette a pontot, már flashben is van, ha elszáll a táp, minden megmarad.
A waypointok közös memóriába mennek a többi beállítással. Ez is sorban tárolódik, de a csomagok hossza eltérő lehet és a csomagokat egyenként érvényteleníteni lehet egy bit törlésével. Ha tehát nyomok egy útpontot, bepakolja az előző csomag után érvényesként. Ha letörlöm, kikapcsolja az érvényességét. Ha betelik az összes lap, akkor tényleg gondban van, mert az első lapon még érvényes adatok lehetnek, a tracktől eltérően. Ilyenkor lázasan elkezd másolni, a még érvényes adatokat az új lapra pakolja és utána teszi rá az új adatot. Na szerintem ez tart sokáig, eközben várakoztat és ezek szerint a tracket sem tárolja addig.
Ebbe a működésbe ráadásul az is belefér, hogy az egyik lapozás után nem sokkal újra lapoznia kell, mert ha olyan lapot másol, amin majdnem minden adat érvényes, akkor az új lapot is majdnem teleírja és újra lapoznia kell. Mivel nem csak útpontok, hanem beállítások és automatikusan képződő állapot-adatok is vannak benne, például az összegzett útadatok, amelyek gyorsan érvénytelenednek, ezért tippem szerint általában viszonylag hézagos lehet a tartalma, a legelső lapnál mondjuk 10-20% érvényes adattal. Intenzív használatnál, sok útpont rögzítésekor viszont fordul az arány, olyankor sokat kell lapátolnia egy-egy lapozásnál.
Apró megjegyzés: a régebbi gps-ekben, saját flottámból egyedül az V-ösnél még a trackpontok is a waypointok között voltak. Akkoriban 3000 trackpont volt a plafon. Aztán rájöttek, hogy trackpontból időegység alatt sok új keletkezik, nem hatékony állandóan lapozni és újraírogatni minden más adatot kerülgetve, ezért tették külön lapokra a trackpontokat kb. tíz éve, azóta 10000 trackpont az aktív trackmemória, 160k plusz egy 64k-s lap, még a két gigás 62s-ben is. A vicc kedvéért előjeles integerként kezeli a track hosszát, ezért 32767 az elméleti plafon, hacsak nem írom át az összes utasítást, ami ezzel foglalkozik, eléggé reménytelennek tűnik. A lapozás miatt pedig lejön 65536/16=4096, így lett lefelé kerekítve 28000 a bővített trackmemória hossza.
Ettől függetlenül azt is el tudom képzelni, hogy a SiRF III chip bénázik ilyenkor, de ez kevésbé valószínű, mert ha a probléma valóban összefüggésben van a felület megtorpanásával, a központi processzor valószínűleg nem várna a gps chipre. Ennek bizonyítására a CSxS2-n csak a firmware-t fogom 4.00-ra frissíteni, a gps marad 2.80-as, aztán meglátjuk hogy melyik gps-ben marad időugrás. |
