Előzmények

Kolesárhozzászólásai | válasz erre | 2010.09.07 07:16:12 (51565)
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.
[előzmény: (51563) 2010.09.06 22:02:43]

hozzászólásai | válasz erre | 2010.09.06 22:02:43 (51563)
Olyan mintha másfél évig kimaradtál volna a suxx dolgokból ;-)
Nézd meg még 49575, 49437, 49128 hsz-okat GARMIN SUXX-ról

A sirf és mtk csix-ek közötti viszonyról pedig egy ellentétes tapasztalat: 49371

Megj-em:

1. Itt szerintem nem jelet veszít, bár lehetne, hanem
a) vagy vmilyen tevékenység esetén loop-ba kerül, azaz küzd vmivel, az erőforrás (processzor) preferenciasorrendje rosszul volt beállítva 4.00 előtt, ezért nem tud trackpontot menteni, utána pedig megzavarodik egy trackpont erejéig (ez a kisebb vsz-ű)
b) vagy a műholdról érkező adattömegből a szökő mp-ekről szóló infót nem tudja feldolgozni, s innen jon a kimaradás, illetve egy rossz időpont, s vmilyen rejtélyes ok miatt mindig csak 1 rossz időpont van.

Jekaeff megnézte, hogy mikor hagy ki néhány mp-et a logolásban a csix (tehát nem önmagában az időugrást vizsgálta), azt is vizsgálva, hogy kikapcsolt térképnél nem jobb-e a helyzet, de nem, tehát ha igazam is van (a. pont) , akkor sem a térképpel kapcsolatos processzor tevékenység miatt van az egész.

A jel elvesztésén azért csodálkoznék, mert akkor szakadna-a trekk, nem (vagy ez csak akkor van, ha sokáig nem talál pozit)? Vagy még inkább, akkor az újrapozícionálás miatt lenne pár pont, ami kicsit szóródik, nem? Nekem ilyen nem szokott lenni, ha autópályán történt a jelenség, akkor pl. nyílegyenes a trekk (már ha nem volt kanyar). Egy jeleldobás esetén ez több mint furcsa lenne.

[előzmény: (51557) Kolesár, 2010.09.06 17:01:42]

Kolesárhozzászólásai | válasz erre | 2010.09.06 17:01:42 (51557)
Tovább vizsgáltam a gpx-eket, új módszerrel mutatom ki az ugrást, így nem kell a fájlban kézzel keresgélnem. Átteszem garmin_txt-be, majd ahol nem ír a két trackpont közé eltelt időt, ott van a visszaugrás. Veszem az előző és a következő három sort és ennek az idejét írom ki.

find -name '*.gpx' | sort | while read file; do echo $file; gpsbabel -i gpx -f $file -o garmin_txt -F - | grep -B 3 -A 3 -P "m\t\t[0-9.]+ kph" | grep -P -o "([0-9]{2,2}:[0-9]{2,2}:[0-9]{2,2}|--)"; done;

Ilyen eredményeket adott, történetesen ugyanazon napról:

./20100524.gpx
12:10:58
12:10:59
12:11:19
12:11:05
12:11:07
12:11:08
12:11:09
--
13:39:15
13:39:16
13:39:36
13:39:22
13:39:24
13:39:25
13:39:26
--
14:49:50
14:49:51
14:50:09
14:49:55
14:49:57
14:49:58
14:49:59

Majdnem mindig húsz másodperc esik ki (egy esetben 18), aztán mindig 14-et ugrik vissza.

Az egyik ilyen esetnél sikerült két útpontot is találnom, amelyeknél szintén rossz az idő. A CSx beírja megjegyzésbe a pontos időt, nálam ez így nézett ki:

471 09-JUL-10 15:07:41
472 09-JUL-10 15:07:32

A két útpont a helyén van, de az első ideje előreugrott 15 másodpercet.

Ilyenkor tehát nem a track rögzül rosszul, hanem az egész gps rosszul tudja az időt 15 másodperccel. Ahogyan a hivatkozott oldalról kiderül, mostanában éppen 15 másodperc a szökőmásodperces UTC és a szökőmásodpercek nélküli GPS-idő különbsége. Ezekben a trackpontokban tehát a gps UTC helyett GPS időt használ. Garmin suxx.

Ugye nem kell meglepődnöm, hogy az MTK vevőjű gps logjaiban nem találtam visszaugrást? Igaz, itt sokkal kisebb a minta. Megnéztem a 62s-t is ebből a szempontból. A már említett tegnapi nagy ugráson kívül egyetlen esetben volt negatív időugrás, felcserélt két időpontot:

09:12:39
09:12:40
09:12:42
09:12:41
09:12:43
09:12:44
09:12:45

Itt nem tudom eldönteni, hogy mi történt, nem mozgott éppen a készülék, álló helyzetben rögzített másodpercenként.

Összefoglalva: háromféle időugrást láthatunk.

1. CSx (valószínűleg csak a SiRF III) egy pillanatra elveszti a jelet, majd az első trackpontnál GPS időt ír a trackbe, utána visszaáll UTC-re. Ez mindig 15 másodperces eltolódást jelent, ami a következő trackponthoz képest 14 másodpercet mutat, ha éppen egy másodperc telt el időközben.

2. 62s mentés közben beszúrja a trackbe egy tetszés szerinti helyre a mentés helyzetét, ezt láttam tegnap délután.

3. 62s másodperces rögzítés közben felcserél két másodpercet. Remek.
[előzmény: (51554) 2010.09.06 16:21:56]

hozzászólásai | válasz erre | 2010.09.06 16:21:56 (51554)
49222-ben rábukkantam arra, hogy a belső memóriából letöltött fájl annó jó volt.
Ez ugye nem az "ugrik kb. 20 mp-t (valójában pár mp-ig nem képes rögzíteni, s eztán ugrik pontosan 15 mp-et, majd vissza 14-et (hiszen megszűnik a 15 mp-es eltolás)" időugrásos probléma (hogy miért 15 mp, arra ld http://en.wikipedia.org/wiki/Leap_second), hanem az általad a Vértesben tegnap tapasztalt jelenséghez hasonló.

Egyébként ha tényleg beválik Neked is a 4.00, akkor az oldaladon fogod pubikálni a 28ezres 4.00-ra épülő fw-t?
[előzmény: (51546) Kolesár, 2010.09.06 10:53:29]

Kolesárhozzászólásai | válasz erre | 2010.09.06 10:53:29 (51546)
Ezt a .gpx fájlban vagy a belső memóriából garmin protokollal letöltött állományban láttad?
[előzmény: (51545) 2010.09.06 10:52:31]

hozzászólásai | válasz erre | 2010.09.06 10:52:31 (51545)
És a lényeget elfelejtettem. Nekem a csix csinált annó hasonlót, tehát más időpontú, pár perccel korábban valóban bejárt helyet berakott egy másik helyre trackpontként. Ez májusban történt, ráadásul valószínűleg 4.00-val, s nem az április elejétől május közepéig ismételten használt 3.60/3,70 valamelyikvel, de csak egyszeri eset volt, azóta sem láttam ilyet.

Bejelentkezés név:  jelszó:   [regisztráció]