turistautak.hu térképrészleteK+ jelzés GPS-szel
[ english
Előzmények

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ó:   tárolás [regisztráció]

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók