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

Сообщение отредактировал Alt.F4 - Nov 22 2011, 13:16

Ситуация совершенно обычная, только разбросы что-то большие, обычно не более 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 не проблема, но это если хватает вычислительной мощности.

Сообщение отредактировал GeGeL - Nov 25 2011, 17:16

Попробуйте снять лог на стоянке - порядка +-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: а держится оно полчаса тут, полчаса там, скорее всего потому, что похожий алгоритм УЖЕ ЕСТЬ в чипсете. На самом деле изначально оно должно скакать постоянно. И, скорее всего, от чипсета к чипсету этот алгоритм фиксации различный (т.к. нигде не регламентируется), поэтому и имеем неопределенность.

Сообщение отредактировал GeGeL - Nov 26 2011, 16:03

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



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

Сообщение отредактировал Alt.F4 - Nov 29 2011, 17:54

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

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

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

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

Сообщение отредактировал Alt.F4 - Nov 30 2011, 04:16

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

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


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