[osm-hu] Fix pontok

[Gergely Matefi]

On Wed, May 27, 2020 at 5:22 PM Samat <samat78 at gmail.com> wrote:

> On Wed, 27 May 2020 at 16:53, Gergely Matefi <gergely.matefi at gmail.com>
> wrote:
>
>> Hobbylistámon szerepel, hogy
>> átalakítsam utófeldolgozásos "nem-valósidejű kinematikára". Azaz terepen
>> naplózni a UBX üzeneteket, és utólag (otthon) korrelálni a
>> referenciaállomásokról érkező bázisjelekkel, és helyreállítani a
>> nagypontosságú lokációs adatokat. OSM szerkesztésre ez így is tökéletesen
>> megfelelne.
>>
>
> Ez jogos. Az utófeldolgozásnak megvan az az előnye is, hogy míg real-time
> adatokat küldő bázisból kevés van, addig az órás vagy napi adatokat utólag
> letöltésre kínálóból jóval több.
> Az RTKlib nem jó erre?
>
> Samat
>

Elvben működnie kell majd, az rtklib-ben az rtkpost kifejezetten erre
szolgál. Csak össze kell rakni a teljes toolchaint, hogy ne kézzel kelljen
mindent. Szeretnék egyszerre valósidejű hagyományos helymeghatározást, és
utófeldolgozásos RTK alapú helymeghatározást. Ehhez a kütyü kimenetéről
szét kell választani a szöveges formájú NMEA üzeneteket és a binárisan
küldött nyersadatokat, letárolni, otthon a korrekciós adatokat
összevadászni a webről, adott esetben az optimális bázis automatikus
kiválasztásával, időablak egyeztetéssel, szükség szerint kivágással. Aztán
toolokat lefuttatni, és valahogy értelmezhetővé tenni, hol mekkora
pontosságot sikerült elérni.

És persze kell majd hozzá némi terepi gyakorlat is, mire kell vigyázni,
hogy valóban sikerüljön a nyersadatokból nagypontosságú végkimenentet
előállítani

Az is elgondolkoztató, hogy mitől stabilabb az F9P belső RTK algoritmusa,
mint az M8T külső rtklib-bel. Okozhatja-e ezt a kétfrekvenciás vétel, vagy
az rtklib-et is lehetne jobban tuningolni

Üdv,
Gergő
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20200528/526bf6e9/attachment.htm>