больше 10 Hz, так как округление transmission time сделано не очень аккуратно:
/* time-tag = max(transmission time + 0.08) rounded by 100 ms */
tr=ROUND((tr+0.08)/0.1)*0.1;
Я забыл назвать порядок величины проблемы: ±5 cm, поэтому мне и кажется что дело в
некалиброванных частотных отклонениях фазы http://gpspp.sakura.ne.jp/image/image1362.jpg описанных автором rtklib.
Решение проблемы пока неизвестно.
Я не усредняю фиксированные решения, а смотрю полную “временную развертку” отдельных решений.
Самые лучшие результаты получаются при полном совпадении временных отметок базы и ровера, т.е. при исключении
какой бы то ни было интерполяции измеренных данных.
В этом примере из исходных данных с частотой 10 Hz (-O.int 0.1) выбираются измерения с шагом 30 сек (-O.dec 30) начиная с
30 секундной эпохи 2013-12-22T10:39:30.00
При этом на расстоянии 1 км от базы получилось 100% fixed, а на расстоянии 20 км 50% fixed, 50% float.
Число используемых спутников GPS (ele > 15°) было 6-7.
Все так легко и просто только тогда, когда есть под боком станция IGS/EUREF (хехе, и по совместительству ФАГС).
Для тестирования L1 PPP думаю записывать измерения на открытом месте как минимум 24 часа, при этом конечно как можно дольше
ночью (из-за TEC/ионосферы) и без дождя/снега.
Возвращаясь к теме виртуализации собственной базовой станции, и превращения ее
так сказать в poor man’s VRS.
В общих чертах: что мешает в формулах для P и C http://home-2.worldonline.nl/~samsvl/theory.htm
заменять R для каждого спутника j в каждый момент времени (эпоху)
на расстояние до некой виртуальной точки (X1,Y1,Z1), находящейся недалеко от реального
положения базовой станции (X0,Y0,Z0) ?
Т.е. координаты станции в RTCM передаются как (X1,Y1,Z1)
а из измеренных P и C вычитается разница
Rj-RVj = sqrt( (X0-Xj)^2 + (Y0-Yj)^2 + (Z0-Zj)^2 ) - sqrt( (X1-Xj)^2 + (Y1-Yj)^2 + (Z1-Zj)^2 )
Таким образом, (X0,Y0,Z0) нигде не присутствует, а поправки почти никак не страдают
при небольшом удалении (X1,Y1,Z1) от (X0,Y0,Z0).
usm78-gis
Очень здравая идея.
К слову для тестирования понадобился доступ к NTRIP + RTCM 2.3 - на удивление всё глухо в Москве, только за мани. Ближайшую станцию нашел в Польше, подписку на IGS дали в течение пары дней.
Type 1
В принципе польской станции мне сейчас хватает т.к. нужен был доступ к стандартному протоколу, реальное содержимое (удалённость, созвездие) пока неважны.
Слайды показали всего лишь что RTKLib не умеет работать с GLONASS, ничего более. У тримблов, топконов и др. нормальные такие фиксированные решения. Не надо идеализировать эту программу ))
(added)
В отчете порадовали малые residuals по GPS-дальностям. Если я правильно читаю графики - обычный дифф.режим даст субметровую точность. Но снова всё упирается в антенну.
Слайд 23 показывает, что производитель не откалибровал межканальные отклонения, что делает
глонасс на ublox второсортным продуктом. Впрочем, производитель из этого секрета и не делает.
Я еще раз внимательно пригляделся к GPS приемнику LEA-5S встроенному в TwoNav Aventura:
т.е. внешний последовательный порт, к которому можно подключиться это COM6=UART1 (0x43f90000), а
GPS находится на COM5=UART5 (0x43f90000). Linux запустить так просто не удастся,
так как имеющаяся в ядре поддержка iMX.31 ( arch/arm/mach-imx/clock-imx31.c ) использует
внешний кварцевый генератор 26MHz ( mx31_clocks_init(26000000); ),
а Geosat 6 http://www.geosat6.com пожалел денег на кварц, поэтому придется патчить нетривиальные вещи
в конфигурации частотных делителей …
Читать NMEA@4800 на UART5/COM5 я могу, а вот переключить на UBX никак не удается.
Хотя хотелось бы конечно утереть тримблу нос, поэтому буду думать дальше