Добрый день.
Во время стоянки объекта раз в 30-270мин отсылаю координаты на сервер.
Валидность данных проверяю по значению "A" в строке RMC NMEA (если "V" - данные недостоверны):
Так вот частенько координата убегает за 300-500м, плюс скорость скачет от 1 до 5км/ч. Во время же движения - все ОК.
Пока на ум только приходит вариант с проверкой значения HDOP.
Может кто-то уже решал подобную задачу?
Спасибо.

Есть такая проблема. Причем она разрослась с появлением девайсов на чипсете MT3329 с высокой чувствительностью.
Пробовал несколько GPS мышек от разных производителей с этим чипсетом - все ведут себя примерно одинаково.
При плохом качестве сигнала - напр. из-под навеса - прыжки вообще бывают на километр.
Старые менее чувствительные чипсеты просто отказывались выдавать валидные координаты, а этот пыжится.

Пока что мы этот вопрос отложили - есть галка в настройках - не писать координаты при стоянке вообще.
Это не есть гуд, но пока выжидаем

передаю координаты при стоянке раз в 120 сек, дрейф есть, но не такой большой, +-30 метров, но никак не 300. Также было замечено, что при включении модуля, при подаче на него питания, редко, но бывают скачки уже на более значительное удаление. 300 метров чтоб прыгнул. это если она был полностью обесточенным с отключенной батарейкой с вывода V_RTCC3V3. Для полной информации должен дополнить, что используется внешняя активная антенна.

Как я понял, альманах, сохраненный в приемнике, имеет свойство стареть и тут уже особо не важно, есть питание на VRTC или нет.
Но вообще я бы хотел обсудить вопрос выхода из ситуации.
Насколько хорош вариант фильтрации данных по HDOP?

В строке $GPGGA есть параметр GPS fix 0 данные не верны, 1 позиция зафиксирована, 2 повышенная точность
В строке $GPGSA тоже 1 — no fix , 2=2D, 3=3D Была мысль во время стоянки считать валидными только координаты с повышеной точностью. Я просто тоже этот вопрос отложил "напатом".

Я тестировал такой алгоритм: устанавливал пороговую скорость, ниже которой считалась стоянка, выше - движение. Каждый раз при переходе из "движение" в "стоянка" запоминал последние координаты "движения" и все время нахождения в "стоянке" их и передавал. Это без энергосбережения (автомобиль): NMEA обрабатывался каждую секунду. Конечно, далеко не идеал. Хотя подход с фильтрацией нравится куда больше, тоже попробую.

PS: Посмотрел внимательнее, идея действительно гуд. Единственно, надо дополнительно парсить GPGSA. И порог по HDOP определять экспериментально, т.к. методика рассчета может отличаться у разных чипсетов.

По какому показателю тогда лучше фильтровать:
1) по "GPS fix=2" из строки $GPGGA?
2) по "режиму работы приемника = 3D" из строки $GPGSA?
Мне приглянулся первый вариант.

Но теперь возникает следующий вопрос, а если повышенная точность (тобишь символ "2") не появится, то что делать?

Наверное, лучше Ваша первоначальная идея - по показателю HDOP (он предпоследний в GPGSA, который выдается обычно по умолчанию). А вот по поводу оптимального алгоритма, это надо подумать. Обычный фильтр слишком примитивно. Вероятно, есть смысл запоминать каждую координату с все большей точностью, до начала движения (по порогу скорости). Тогда прыжки будут только в сторону к реальной позиции объекта.
Если позволяют вычислительные мощности, то можно сравнивать точность с разницей между координатами, и если перемещение значимо, то фиксировать новую, а если недостоверно, то оставаться на старой. Возможно, еще что-то придумаю

Параметр снижения точности DOP (HDOP, VDOP, PDOP) Посетить Утилита Trimble Planning2.9 выдаёт графики изменений DOP. Сам пока не баловался, мож кому пригодится.

ЕЩЕ Trimble Planning 2.9 Там на сайте разработчика еще какие то проги навигации, может конечно ерунда.

У меня не идет загрузка...

ОК, теперь мнения сошлись, будем проверять по HDOP.
По-моему запоминать некоторое кол-во координат и выбирать с лучшей точностью не стоит. В любом случае, если немного подождать, то координаты вернутся в реальное место.
Таким образом надо определится со значением HDOP, которое будет границей между валидными и невалидными данными.

з.ы. кстати DOP ниже единицы не бывает?

Нет

Вроде бы не должно быть, но меня несколько смутил даташит на приемник SKM55 от Skylab.
Там есть примеры данных и для $GPGSA приведено след.:

Это как? Кстати теорема Пифагора, как и положено, на этих цифрах выполняется
Может быть VDOP может быть меньше единицы?

Нашел интересную доку: жать.
Цитата: "Приемное оборудование GPS должно: иметь такую точность в статическом режиме, чтобы местоположение антенны определялось с погрешностью в пределах 100 м для вероятности 95% с геометрическим фактором ухудшения точности определения двухмерных координат (HDOP) <= 4 (или трехмерных координат PDOP <= б);"

Ну вот вроде и с цифрами определились, попробую фильтровать по HDOP не более 4.
Хотя нужны практические сведения.

Выходит надо забить на валидность в строке $GPRMC (A,V), парсить HDOP и считать координаты валидными если HDOP <= 4.
П.С. у меня при HDOP = 4, картина соответствовала рис.А (где он?)

Вчера HDOP 0,7 видел при >=10 спутниках. Прямо сейчас вижу 0.9 на 8. Приемник на сирфстаре4

Ситуация совершенно обычная, только разбросы что-то большие, обычно не более 100 м. В своих устройствах использую модули на базе SiRF и Ublox, в firmware обоих чипсетов есть функция фильтрации выбросов во время стоянки, которая вполне работает. Может у чипсета, который вы используете, тоже это реализовано?

Ну например, Геос-1м при HDOP=1.7 может наврать на несколько километров, и это замечено если в решении находится менее 5 спутников, так что я еще и кол-во спутников учитываю.

Не удивительно. Я когда прочитал в рекламе Геос-1 "Удалось значительно снизить габариты, за счет применения SMD технологии", чуть не помер от хохота. Во мля как нанотехнология шагнула -применили SMD.

Я ошибался - таки может... Почитал теорию, из полезного почерпнул только то, что разные чипсеты считают HDOP по разному, и величина ошибки при фиксировано HDOP действительно не постоянна, а зависит от к-ва фикс. спутников.
В общем, проще всего выбрать фикс.порог и фильтровать. Но если сигнал постоянно слаб или спутников мало (в помещении), и надо хоть какие-то координаты, то это не выход. Все же оптимальным видится использование координаты с меньшим HDOP при перемещении меньше суммы ошибок точек, рассчитанных по эмпирической формуле (не знаю, для каких она условий и чипсетов): RMS_Error(HDOP)=sqrt((3.04*HDOP)^2+12.75) в метрах.
Для этого в трекере потребуется плавающая математика (как минимум cos и sqrt).

3.14 ?



Во-первых я не понимаю, почему бы просто паспортную погрешность приёмника не домножать на HDOP без PI, квадрата и 12.75 (что за magic numbers?) и не получать ту же 95% вероятность с учётом HDOP.

Во-вторых плавающие числа не нужны и косинусы тем более. sqrt вот целочисленный:

Это не PI
Не я придумывал, см.тут:
http://users.erols.com/dlwilson/gpshdop.htm

И HDOP - не просто множитель, я и сам толком не понял, что...

Этот алго sqrt по моему тот же Ньютона, только со сдвигами. Вот еще:



Но я имел ввиду ежесекундное СРАВНЕНИЕ суммы RMSError (расчитанных по HDOP по формуле выше) для какой-то координаты (назовем ее текущей) и новой координаты с расстоянием в метрах между этими координатами (перемещением). Если перемещение больше суммы ошибок, то можем считать, что объект сдвинулся, и меняем текущую координату на новую. Если нет, но HDOP новой МЕНЬШЕ чем HDOP текущей, то тоже заменяем. Если больше-равно, то игнорируем новую.
Расстояние между координатами считаем по теореме Пифагора, но вот чтобы преобразовать дельту градусов долготы в дельту метров, потребуется косинус широты.
Правде, есть приближенный алго для cos через тангенс двойного угла с заданной точностью, так что отсутствие math не проблема, но это если хватает вычислительной мощности.

Попробуйте снять лог на стоянке - порядка +-20 плавает при хорошем видимости. На окне за ночь набегает пятно +-50 метров, и HDOP при этом порядка единицы. Так что те 3-5 метров которые предлагает теория при таком НDOP - очевидная ерунда.
Речь идет о сирфстар4. С другими приемниками ситуация с плаванием идентичная, допы правда пристально не разглядывал

Тоже немного поигрался с приемником на МТ3329 в офисе с металлическими жалюзи на окнах. Ситуация примерно такая же.
После холодного старта сначала спутников видит мало, начиная с 4-х, HDOP может достигать и 50-100. Ошибка 100-200м.
Но потом за пару минут находит спутники, HDOP уменьшается до 0.7-2.0 и ошибки снижаются.
На небольших временах около 10мин дрейф 20-30м. За большее время попадаются ситуации с худшими условиями приема и разброс увеличивается.

В чипсете, видимо, есть фильтр - координаты не прыгают хаотично, а все время плавно "плывут".
На картинке пример дрейфа.
Нажмите для просмотра прикрепленного файла

Видимо во время движения этот дрейф не заметен потому, что как-бы "разворачивается" вдоль маршрута движения, который гораздо длинее чем сам дрейф.

Предложенные вычисления довольно интересны, но кажутся малоэффективными - даже при ошибках в десятки метров HDOP меняется очень незначительно.
Наверное достаточно грубой фильтрации по порогу HDOP и кол-ва спутников.
А на стоянке (при скорости <5км/ч) можно просто считать среднее по координатам за какое-то кол-во точек.

Согласен, тот алго, что я выше предложил, особого эффекта при таком раскладе не даст.
Вобще, на сколько я вьехал, показатель HDOP как то связан с матожиданием, и его низкое значение не дает гарантию отсутствия единичного спонтанного скачка. Но вот плавный дрейф свидетельствует о какой-то постобработке (статистическом усреднении) в самом чипсете. Так что на вскидку и придумать ничего, кроме как среднего, у меня не получается

Это скорей CORDIC (Цифра-за-цифрой). Алгоритм Ньютона требует деление и это его фатальный недостаток. Многие небольшие MCU имеют аппаратный умножитель (уже, раньше и того не было), но аппаратное деление до сих по роскошь (да и выполняется, если есть, не быстро). Цикл в CORDIC алгоритме может быть развёрнут, код оптимизирован и может тратиться всего несколько тактов на итерацию цикла (которых 32). В алгоритме Ньютона итераций может меньше, но одно только деление на 8-битном MCU может занять тысячу тактов, например.



Не совсем понял откуда взять сумму ошибок. Вот стоит ночью на одном месте и улетает то на 180 метров туда, то на 180 метров сюда (в две точки, пол-часа там, пол-часа тут) -- как понимать?



Да, нужен. Синус, косинус и арктангенс (верней, atan2(y,x)) считаются тоже кордиком достаточно легко. От безысходности для pic18 писал код. Хотя для более-менее вменяемого компилятора всё считается быстро и в плавучке (раз в секунду-то).



Вот тангенс как раз неудобен тем, что не влезает ни в какой int. Удобней отдельно представлять синусную и косинусную составляющую (получаемую из одной функции угла за одну итерацию на бит, примерно, методом CORDIC).

Я вот что имел ввиду: держим в памяти координату, и ее ошибку (определенную как функцию от HDOP). Ее можно геометрически представить кругом с центром в координате и радиусом ошибки. Это наша рабочая координата, для выдачи, скажем, наружу.
Ежесекундно получаем NMEA новую координату, определяем ее ошибку по ее HDOP. Если полученный круг не пересекается с рабочим, то тогда рабочим становится вновь полученный круг. И если радиус нового круга меньше рабочего, то опять же рабочим становится вновь полученный круг.

Но это уже проехали, т.к. нет прямой функциональной зависимости между HDOP и ошибкой в метрах: если HDOP - это вероятностный показатель, то возможны редкие, но значительные отклонения даже при низкой HDOP (что показали вышеприведенные тесты), а это будет сбивать данный алгоритм.

PS: а держится оно полчаса тут, полчаса там, скорее всего потому, что похожий алгоритм УЖЕ ЕСТЬ в чипсете. На самом деле изначально оно должно скакать постоянно. И, скорее всего, от чипсета к чипсету этот алгоритм фиксации различный (т.к. нигде не регламентируется), поэтому и имеем неопределенность.

Включение EB500 каждые полчаса и выключение сразу после определения координат.
В общем HDOP не показатель - 3, 17, 31 строки.
Да и количество спутников тоже - 3, 7, 24, 31, 38 строки.
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

То что скорость прыгает, можно просто писать 0 до 10км/ч, пусть грубо, но зато не будут потом звонить: "Почему тачка едет, если она стоит?"
А вот по поводу скачков (500м) - даже не знаю...

Немного не понятно: в таблице самые первые валидные координаты после включения, или как?

Если это так, то я бы предложил все-же изменить условия эксперимента и фиксировать координаты только через минуту-другую после появления валидных значений.
Там в чипсете еще какая-то пост обработка координат явно есть, и как она себя ведет после даже "горячего" старта неизвестно.
У меня точность после "горячего" старта через пару минут точно улучшалась.

Да, это так.
А если объект движется? За минуту - другую можно далеко уехать. Определять по скорости движется ли объект? Так ведь и во время стоянки скорость скачет.

Скорее всего лучшим вариантом будет фильтрация на сервере сразу по HDOP и по количеству спутников, так и прошивку трекера не надо менять и статистику можно набить получше.

Во время стоянки скорость скачет до 5 км/ч (скажем так с 95% вероятностью )

Но я как-то основную тему упустил. Топик вроде начинался с вопроса о дрейфе координат во время стоянки.
Я и думал, что эти данные для этой темы. При движении вряд ли есть смысл выключать приемник и фиксировать координаты только раз в 30 мин.
У нас в основной функционал прибора входит подключение к зажиганию - это основной сигнал перехода в активный режим.


Ну, это смотря как у кого система организована. Если вы держатель картографического онлайн сервера - тогда да.
Если только производитель трекеров - тогда нет.
Да и лишние данные (HDOP и по количеству спутников) придется передавать на сервер.

Я тут глянул, что многие юзают продукт белорусской Gurtam, так называемый Wialon. Часто под своим брэндом, но внутренности те же, поэтому перехожу на их протокол обмена, где предусмотрено поле HDOP и на сервере уже существует галочка "Фильтровать по HDOP и по количеству спутников".

Самое адекватное решение задачи - дополнительно к GPS ставить акселерометр. Все остальные подходы содержат подводные камни.

Акселерометр - это хорошо, но по существу не решает вопрос топикастера.
Во-первых, можно качаться, стоя на месте, а во-вторых, даже при спокойной стоянке остается открытым проблема - а какую же координату использовать в качестве стояночной.

Ага. Тогда уж можно сразу ставить инерциальную навигационную систему с самолёта =)

С акселерометром то же есть подводный камень в виде расскачивания авто от порывов ветра и проносящихся мимо других, особенно большегрузных фур.

Не всё ли равно какую? Зафиксировали остановку при помощи акселерометра и GPS и дальше спим спокойно без всякого дрейфа. Точная координата стоянки как правило не сильно нужна - нужен правильно подсчитанный пробег и отсутствие дрейфа.


Вроде щас и самолеты все по GPS летают.


Буду знать.

Да кто бы спорил! Только плата того GPS (с сантиметровой точностью) стоит несколько тысяч $ =)

Я тоже сталкивался с такой неприятностью. Сначала ввел порог по скорости минимальной. Не очень эффективно. Потом ввел порог на расстояние. Стало получше. Идеально имхо по координатам высчитывать расстояние и при небольшом изменении не учитывать. Плюс контроль изменения азимута. С одной стороны мусор не учитывается с другой стороны экономия памяти и трафика. Получается учитываются только приличные изменения.