Как настроить GPS-модуль u-blox 6m на повышение точности в стационарном состоянии?

[eddy]

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

Делаю следующее: в CFG-NAV5 задаю маску изменения только динамической модели и моделью делаю стационарную:

	uint8_t stat[44] = {0xb5, 0x62, // header
		0x06, 0x24, // CFG-NAV5
		36, 0, // 36 bytes, little-endian
		1, 0,  // mask: only dynamic model
		2};    // stationary model

В CFG-NAVX5 задаю маску "только PPP" и флаг PPP:

	uint8_t prec[48] = {0xb5, 0x62, // header
		0x06, 0x23, // CFG-NAVX5
		40, 0, // 40 bytes, little-endian
		0, 0, 0x20}; // mask for PPP
	prec[32] = 1; // usePPP = TRUE

Однако, GPS продолжает считать, что движется:

(data valid) time: 20:06:36.00 latt: 43.677032 long: 41.457870 speed: 0.011000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:37.00 latt: 43.677032 long: 41.457870 speed: 0.011000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:38.00 latt: 43.677032 long: 41.457870 speed: 0.011000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:39.00 latt: 43.677032 long: 41.457870 speed: 0.011000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:40.00 latt: 43.677032 long: 41.457870 speed: 0.011000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:41.00 latt: 43.677029 long: 41.457870 speed: 0.011000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:42.00 latt: 43.677029 long: 41.457867 speed: 0.012000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:43.00 latt: 43.677025 long: 41.457867 speed: 0.013000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:44.00 latt: 43.677025 long: 41.457867 speed: 0.013000knots date(dd/mm/yy): 30/06/15
(data valid) time: 20:06:45.00 latt: 43.677025 long: 41.457867 speed: 0.014000knots date(dd/mm/yy): 30/06/15

В какую сторону копать?
Вообще, странно: вроде бы модуль популярный, но не сильно-то по нему чего-нибудь путного найдешь, для работы с ним пришлось велосипед писать.
Даташит хоть и 222 страницы, но черт ногу сломит в этих регистрах!

[Eddy71]

Это ошибки определения координат. Из-за этого (разница координат предыдущей и текущей точки) модуль думает, что его двигают. Я когда то трекер писал, оставил на окне антенну и сутки глядел результат. Он таких кругов вокруг дома наделал.. Метров на 70 гулял. Правда это были ещё старые SAH2217, но проблема осталась, хоть и здорово уменьшилась. Помех много и в єфире и от основного проца..

[eddy]

Дык, по идее же при указании стационарного режима он должен нивелировать эти погрешности!
То ли лыжи не едут, то ли смотрю в даташит, а вижу фигу!

[Yurkin2014]

0, 0, 0x20}; // mask for PPP

Маска двухбайтная, бит PPP в старшем байте, надо бы ещё нолик добавить перед 0х20

[eddy]

надо бы ещё нолик добавить перед 0х20

Да нет, все правильно: формат же little-endian!
Вот там и пишу: 0 - version, 0 - младший байт, 0x20 - старший байт.

[Yurkin2014]

Version тоже двухбайтная величина

[eddy]

Тьфу ты! Спасибо!!! Совсем не обратил на это внимания!
Но все равно что-то остается ненулевая скорость и между местным (только что по NTP синхронизовал) временем и GPS вылезает разница в 180мс при мониторинге RMC и 220мс при поллинге UBX.

[Yurkin2014]

между местным временем и GPS вылезает разница в 180мс

А, по-конкретнее, как Вы сравниваете время?

[pambaru]

Но все равно что-то остается ненулевая скорость и между местным (только что по NTP синхронизовал) временем и GPS вылезает разница в 180мс при мониторинге RMC и 220мс при поллинге UBX.

А как время синхронизирете?
Выход PPS используете (если он есть, конечно в этом модуле)?
Без PPS и будет гулять. Я экспериментировал с разными модулями - задержка выдачи данных в UART очень сильно колеблется - от 0.2С до 0.6с с момента начала секунды.
Зависит еще, в какой момент времени засинхронизировался. Надо использовать выход PPS (секундные импульсы).

[eddy]

Выход PPS используете (если он есть, конечно в этом модуле)?

Нет, там светодиод висит.

задержка выдачи данных в UART очень сильно колеблется

А и правда: что-то я совсем не подумал о том, что на такой низкой скорости (9600) данные будут долго передаваться.
Понятно: для повышения точности нужно будет брать какой-нибудь RTC-модуль и питать его от PPS, а с одноплатником этот модуль должен будет по какому-нибудь более скоростному интерфейсу общаться.