Aktív témák

• #4433 ludsimon veterán whiskey #4432

  2011-05-21 21:19:56 #4433

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ludsimon

  veterán

  válasz whiskey #4432 üzenetére

  Borzalmasan alacsonyan van az az ülés, nemde?
  [link]

  undefined

• #4437 dqdb nagyúr whiskey #4432

  2011-05-21 21:46:58 #4437

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dqdb

  nagyúr

  válasz whiskey #4432 üzenetére

  Külső BT-s és Windows Mobile eszközökbe épített GPS-ekkel van valamennyi fejlesztési tapasztalatom.

  Van olyan chipset, ami hidegindításkor teljesen korrekt módon semmilyen adatot nem ad (sem UTC idő, sem GPS koordináta). Ahogyan egyre több műholdat vesz észre a vevő, úgy előbb megjelenik az UTC, aztán a koordináta, végül a magasságadat.

  Van olyan, amelyik a firmware-be beégetett időponttal elindítja bekapcsoláskor az UTC óráját, és addig a hibás időpontot szolgáltatja, amíg nem kap a műholdaktól jelet (aza induláskor hibás UTC idő, amit a vevő valósnak jelez, nincsen GPS koordináta).

  Olyannal, ami hidegindításnál azonnal adott koordinátát, de az hibás volt, még nem találkoztam, de olyannal, amelyik a kapcsolat elvesztése után hosszú idővel megismételte a legutolsó ismert koordinátát, vagy gyenge vételnél alaposan félrepozicionált, igen.

  Az NMEA protokollban a legtöbb adat két mezőn kerül leírásra: az egyik egy státusz, a másik maga az érték. Elképzelhető, hogy mindkettő üres, ha a vevőnek fogalma sincsen az állapotról. Az is elképzelhető, hogy az érték ki van töltve, de a státuszban jelzi, hogy az érték problémás. És az is előfordulhat, hogy az érték ki van töltve, és a státuszban azt jelzi, hogy valós információt hordoz, közben pedig 2107-ben jár az UTC óra (ez egy tipikus érték, amibe rengetegszer belefutottam). Magában a koordinátában is lehet ennyire hibás adatközlés, de ez annyira nem szokott tipikusan előfordulni. A koordinátához tartozik 3 pontosságérték is (hdop, vdop, pdop), ezek értékét is illik figyelni, és a nem túl pontos koordinátákat nem figyelembe venni (csak nem mindig jó megoldás, ha tipikusan olyan helyen mozogsz, ahol végig gyenge a vétel).

  Amikor tracklogot kellett gyűjtenem, akkor a szerver egy csúszó időablakkal, pontosság-ellenőrzéssel, egy magyarországi koordináta-ellenőrzéssel, és egy maximális elmozdulásvektorral szűrte a beeső adatokat.

  Nem egyszerű ez, pedig itt már a WGS84 krumpli geoid paramétereit és mindenféle reakcióidő, jelerősség és hasonló számításokat már szerencsére nem is kell ismerni, mert a GPS vevőből feldolgozott NMEA0183 adatsor esik ki, valami ilyesmi, rutinosabbak számára szemmel is olvasható formátumban (én emlékeim szerint a GGA, GSA, RMC, GSV, VTG, GLL üzeneteket dolgozom fel ebből):

  $GPRMC,023042,A,3907.3837,N,12102.4684,W,0.0,156.1,131102,15.3,E,A*36
  $GPRMB,A,,,,,,,,,,,,A,A*0B
  $GPGGA,023042,3907.3837,N,12102.4684,W,1,04,2.3,507.3,M,-24.1,M,,*75
  $GPGSA,A,3,04,05,,,09,,,24,,,,,2.8,2.3,1.0*36
  $GPGSV,3,2,11,09,47,229,42,10,04,157,00,14,00,305,00,24,70,154,33*79
  $GPGLL,3907.3837,N,12102.4684,W,023042,A,A*5E
  $GPBOD,,T,,M,,*47
  $GPVTG,156.1,T,140.9,M,0.0,N,0.0,K*41
  $PGRME,8.4,M,23.8,M,25.7,M*2B
  $PGRMZ,1735,f*34
  $PGRMM,WGS 84*06
  $HCHDG,,,,15.3,E*30
  $GPRTE,1,1,c,*37
  $GPRMC,023044,A,3907.3840,N,12102.4692,W,0.0,156.1,131102,15.3,E,A*37

  tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

• #4439 fidig tag whiskey #4432

  2011-05-21 21:53:49 #4439

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  fidig

  tag

  válasz whiskey #4432 üzenetére

  Gyönyörű bringa, jól sikerült a felújítás...

  A remény hal meg utoljára...mert ő a gyilkos :)

Aktív témák