NMEA-szentencia valódiságának ellenőrzése

Wireless

Sziasztok.

Segítséget szeretnék kérni GPS-ügyben.

Adott egy szekvencia az NMEA-mondatok RMC adataiban, a valódiságát szeretném tisztázni magamban. A chip egy Quectel L86-os GNSS-lapka. ( http://www.quectel.com/Qdownload/L86.html ) Ez loggolt nekem folyamatosan egy Raspberryvel, Arch Linuxon nyers NMEA-adatokat, minicommal egyszerűen fájlba írva. Nemrég kíváncsi voltam a maximálisan elért sebességre, és kinyestem egy ponthalmazt.
Ezek vannak alant.

A kérdésem az, hogy a 8. mezőben szereplő adat, azaz a talajhoz viszonyított sebesség adatai szerintetek valósak-e, azaz ha a 7.23 csomót valósnak találhatom, örülhetel-e... Az L86-os cuccomhoz a gyártó manualja egyértlműsíti a csomót: http://docs-europe.electrocomponents.com/webdocs/147d/0900766b8147dbf6… (azaz a 8. mező knots.)
Ugyanezt gpsbabellel gpx-szé konvertáltam, majd megetettem a Viking és a GpsPrune programokkal, azok egészen érdekes módon alacsonyabb értékeket állapítottak meg.

A számított útirány ingadozik ugyan, ennek nem értem az okát. Átlagosan ahogy nézem, +- 2-3 fok. Ha azt veszem, hogy a haladásnak volt egy minimális csellengése, akkor rendben is van...

Szóval minek higgyek? A nyers NMEA-nak, vagy a GIS-programkáknak, chartplottereknek? Nem lehet, hogy a chartplotterek interpolálnak valami egészen egyedi marhaság szerint, ami eltér a lapkáétól? (...mert ugye a sebességet nem a műhold "közli" velünk, a lapka számolja a múlt adatai alapján.)

Íme a szekvencia:

$GNRMC,072343.000,A,3717.4751,N,02525.5356,E,5.23,322.87,110917,,,A*76
$GNRMC,095512.000,A,3723.5083,N,02521.2361,E,5.21,353.25,110917,,,A*78
$GNRMC,095515.000,A,3723.5116,N,02521.2341,E,5.24,346.15,110917,,,A*72
$GNRMC,095516.000,A,3723.5128,N,02521.2334,E,5.45,346.39,110917,,,A*77
$GNRMC,095518.000,A,3723.5151,N,02521.2323,E,5.54,343.05,110917,,,A*7B
$GNRMC,095519.000,A,3723.5164,N,02521.2320,E,5.71,349.07,110917,,,A*70
$GNRMC,095520.000,A,3723.5176,N,02521.2314,E,5.66,346.89,110917,,,A*71
$GNRMC,095521.000,A,3723.5188,N,02521.2314,E,5.26,356.34,110917,,,A*72
$GNRMC,095522.000,A,3723.5201,N,02521.2310,E,5.93,351.15,110917,,,A*7D
$GNRMC,095523.000,A,3723.5211,N,02521.2307,E,5.48,345.06,110917,,,A*7A
$GNRMC,095524.000,A,3723.5220,N,02521.2303,E,5.52,349.43,110917,,,A*7D
$GNRMC,095525.000,A,3723.5233,N,02521.2301,E,5.26,357.21,110917,,,A*74
$GNRMC,095526.000,A,3723.5245,N,02521.2301,E,5.41,1.58,110917,,,A*79
$GNRMC,095527.000,A,3723.5256,N,02521.2301,E,5.06,3.60,110917,,,A*70
$GNRMC,095529.000,A,3723.5275,N,02521.2300,E,5.11,355.38,110917,,,A*75
$GNRMC,095530.000,A,3723.5285,N,02521.2300,E,5.56,359.05,110917,,,A*73
$GNRMC,095533.000,A,3723.5316,N,02521.2297,E,5.03,354.38,110917,,,A*77
$GNRMC,095534.000,A,3723.5329,N,02521.2296,E,5.80,357.80,110917,,,A*76
$GNRMC,095535.000,A,3723.5341,N,02521.2296,E,5.70,0.39,110917,,,A*75
$GNRMC,095536.000,A,3723.5354,N,02521.2293,E,6.35,358.76,110917,,,A*70
$GNRMC,095537.000,A,3723.5368,N,02521.2290,E,6.47,359.77,110917,,,A*78
$GNRMC,095538.000,A,3723.5376,N,02521.2287,E,5.86,4.43,110917,,,A*7C
$GNRMC,095539.000,A,3723.5385,N,02521.2282,E,5.90,359.61,110917,,,A*78
$GNRMC,095540.000,A,3723.5398,N,02521.2281,E,6.15,2.48,110917,,,A*71
$GNRMC,095541.000,A,3723.5404,N,02521.2281,E,5.62,7.81,110917,,,A*71
$GNRMC,095542.000,A,3723.5414,N,02521.2276,E,6.65,359.23,110917,,,A*7F
$GNRMC,095543.000,A,3723.5423,N,02521.2274,E,6.47,7.95,110917,,,A*7D
$GNRMC,095544.000,A,3723.5434,N,02521.2272,E,6.39,5.01,110917,,,A*7C
$GNRMC,095545.000,A,3723.5448,N,02521.2271,E,6.78,1.69,110917,,,A*7A
$GNRMC,095546.000,A,3723.5461,N,02521.2272,E,6.81,5.60,110917,,,A*7A
$GNRMC,095547.000,A,3723.5470,N,02521.2265,E,6.68,3.02,110917,,,A*78
$GNRMC,095548.000,A,3723.5476,N,02521.2265,E,6.56,2.71,110917,,,A*79
$GNRMC,095549.000,A,3723.5482,N,02521.2263,E,6.44,9.72,110917,,,A*7E
$GNRMC,095550.000,A,3723.5496,N,02521.2266,E,7.23,1.10,110917,,,A*7A
$GNRMC,095551.000,A,3723.5507,N,02521.2263,E,6.14,3.24,110917,,,A*77

(checksum mindnél rendben...)

  • 1598 megtekintés

( bzs v | 2017. 10. 31., k – 21:39 )

A 7.23-as SOG-értéket tartalmazó sorhoz kikerestem a megfelelő VTG-sort, íme:

$GPVTG,1.10,T,,M,7.23,N,13.40,K,A*0D

Itt a 7.23,N jelenti, hogy 7.23 vot a sebesség csomóban.

Szóval nem értem, mi alapján megy minden.

Előfordulhat, hogy az RMC és a VTG szekvenciák az esetleges magassági eltéréseket is számítják a sebességhez, míg a GIS-programok meg nem, azért van 3-4 számjegybeli különbség?

( Nyosigomboc v | 2017. 10. 31., k – 23:14 )

Fogsz egy ingat, megmered a periodusidejet egy stopperrel. Aztan megmered ugyanazt 10 periodusra szamitva is. A meresed pontossaga (a stopper most legyen pontos) a reakcioidod miatt +-200ms, ami 10 periodus eseten +-20ms-re redukalodik, mert a meresi hibad a periodusok szamatol nem fugg. Szoval ha tobb periodust egyben mersz, akkor pontosabb lesz a meresed.

Van egy eszkozod, ami idealis veteli korulmenyek kozt 3 meter pontossaggal megallapitja barhol az abszolut poziciodat, es - mondjuk - masodpercenkent ezt megadja. Ha ez alatt az 1 masodperc alatt te 40 metert megteszel (autopalya), az a 3 meter pontossag jo lesz. Ha setalsz (kb. 1.5 m/s), akkor nem. Persze a GPS relativ pontossaga joval jobb 3 meternel (ami az abszolut lenne), meg itt a vevo tud trukkozni dopplerrel meg egyebekkel, de ettol fuggetlenul lesz valamilyen meresi hibaja. Ha ugyanezt az eszkozt ugy hasznalod, hogy nem vallatod ki masodpercenkent a sebessegedet, hanem mondjuk 100 meterre atlagolsz (vagy adott idore), sokkal kozelebb leszel a valosaghoz, mert a meresi hiba az ingaidohoz hasonloan csokken.

A nyers NMEA mondatokban ez a pillanatnyi sebesseg van. A GIS program meg vegig tud menni ezeken a nyers adatokon, kidobja belole a hulyeseget, es szamolhat belole valami olyat, ami kozelebb all a valosaghoz.

Volt mar olyan, hogy fedett teruleten be volt kapcsolva egy GPS tracker, es parszor 10 km-es utat naplozott amig ott voltam, mert a relative gyenge vetel miatt dobalta a poziciojat ide-oda, a tracker meg valos mozgasnak vette ezt. Pedig vegig az epuletben voltam (kozel 0 sebesseggel "haladtam"). De ez eleg extrem pelda.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

+1

A GPS programok meg mind másképpen "javítják" a nyers adatokat, és ezért aztán mindegyikből egy kicsit más maximális sebesség fog kijönni.

Ha magaddal versenyzel, akkor standardizáld, hogy milyen programmal mérsz, és annak az eredményét hasonlítsd össze.

Milyen járműről van szó? Vitorlázol? Vagy mi ez?

Tengeri kajak, ha jol tippelek. Szoval sebessegre nem tul nagy, a GPS hibaja tul nagy ehhez kepest. (osszehasonlitaskent a ferfi K4 1000m kb. 3:30-4:00 alatt van bent a celban nemzetkozi versenyeken, bar ide inkabb a K1 maratoni szamai illenenek)

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

8-9 km/h körüli átlagot számol a viking, gpsprune meg a többi chartplotter. (Ez egy ideális helyzetben egy valós átlag.)
A fentebb adott 2-300 méteres szakaszon valóban repesztés történt, mert még déli szél is volt. Csak éppen meglepődtem, hogy minden másképp értékel ki.

Még egyszer:
Rendben, az RMC sebességeket számol, a VTG is. Kérdés az, milyen algoritmus szerint számol pillanatnyi sebességet, miből. Én is számolhatok sokféle átlagot, egyéni eljárással...

Kérdés.
A fenti kód egy folyamatos szekvencia (A 072343 időpontkivételével, az egy korábbi pillanat, szintén 6 feletti értékkel). Az a mondjuk 100 méter, ami meg van téve, 6.5 knots feletti értékekről szól az RMC mondatokban (is). Tényleg azt mondod, hogy ez itt egy folyamatosan túllőtt hibasorozat, amikor ráadásul egyenes vonalonvannak a pontok?
(Nem kötekedésképpen kérdezem, 1 teljes napot ültem ezen a problémán, de a Quectel chipek manualjait is szétszedtem, hátha találok valamit -- semmi.)

Remelem jol szamoltam:
import math
x1=37+23.5083/60
x2=37+23.5507/60
y1=25+21.2361/60
y2=25+21.2263/60
korr=math.cos((x1+x2)/2.0*math.pi/180)
dist=(((x1-x2)**2+((y1-y2)*korr)**2)**0.5)*40000/360.0
dist
0.07983141978087878
dist/((51-12)/3600.0)
7.36905413361958 az atlagsebesseged km/h-ban

Csomoban (nautical mile/hours) ennyi lenne:
distnm=(((x1-x2)**2+((y1-y2)*korr)**2)**0.5)*60
distnm
0.04310896668167454
distnm/((51-12)/3600.0)
3.979289232154573
Ez nekem inkabb tunik 4-nek, mint 6.5-nek.

(a szamolasnal a Foldet 40000 km keruletu gombnek vettem - ilyen tavolsagon kb. jo lesz, illetve a tengeri merfold definiciojat hasznaltam: az a tavolsag, ami a Fold kozeppontjabol nezve 1 szogperc alatt latszik.. a korrekcios tenyezonel is van egy kis csalas, de az a kb. 80 meter a Fold mereteihez kepest elhanyagolhato, igy nem szamit)

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

( Caro | 2017. 11. 01., sze – 19:36 )

Annyira GPS témában nem vagyok otthon, de ennek az elolvasása után nem jutott volna eszembe a nyers NMEA üzenetekre támaszkodni:
http://esr.ibiblio.org/?p=801

Nem tudom segít-e, de én adnék a gpsd-nek egy esélyt.

Nem akartam használni loggoláshoz, ennek oka egyszerű. Ha a loggerscript elé még egy daemont beállítok, ami itt a gpsd, akkor több minden fut. Aksim meg kevés. Minimalizáltam a futó processzeket.
Mellékesen az aksik úgy vannak megoldva, hogy menet közben töltődik solarpanelen, eddig csak egyszer állt le, mert lejött egy saru a betápnál... Még nem tértem át csavarozásra.