Дрейф координат во время стоянки. EB-500 Опции

[Alt.F4]

Добрый день.
Во время стоянки объекта раз в 30-270мин отсылаю координаты на сервер.
Валидность данных проверяю по значению "A" в строке RMC NMEA (если "V" - данные недостоверны):

Код

$GPRMC,181057.000,A,5542.2389,N,03741.6063,E,0.47,74.50,190311,,,A*51

Так вот частенько координата убегает за 300-500м, плюс скорость скачет от 1 до 5км/ч. Во время же движения - все ОК.
Пока на ум только приходит вариант с проверкой значения HDOP.
Может кто-то уже решал подобную задачу?
Спасибо.

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

[GeGeL]

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

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

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

Код

//SQRT using Newton algo for int

s32 mysqrt(s64 l)
    {
      s64 ret=l;s64 div=l;
      if(l<=0)return 0;
      while(TRUE)
      {
            div=(l/div+div)/2;
            if(ret>div)ret=div;else return (s32)ret;
      }
    }

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

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

[Frolov Kirill]

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

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

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

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

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

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

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

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

[GeGeL]

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

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

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

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

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