RTKlib/постпроцессинг

Как геодезисты пытаются делать статику (даже не RTK) в сложных условиях:

Естественно речь о двухчастотнике.

Что я хочу сказать: RTK это вершина эволюции GPS/GNSS. Любительский L1 RTK это тупиковый путь, нельзя пользоваться микрометром не научившись пользоваться рулеткой. SviMik это уже понял ))

Надо двигаться в сторону DGPS и любительских станций по NTRIP. Наработки по u-Blox и SiRF Star не пропадут даром т.к. сырые данные всё-равно нужны.

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

О чем я и говорю - RTK L1 в городе ещё более бесполезен.
Кроме того кто из осмеров в здравом уме будет пользоваться программой-планировщиком и кто способен нарисовать в ней карту затенения. Я вот не смогу на глаз оценить угол возвышения и азимут здания или кроны леса.

А зачем на глаз?
Китайская насадочная линза fish eye для объектива смартфона, пузырьковый уровень, компас и один раз нарисованная сетка полярных координат, которая накладывается на снимок в любом граф. редакторе. И можно перекалывать значения углов возвышения и азимутов. Цена вопроса - $15.

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

DGPS или постобработка по коду - это первый шаг к точной любительской навигации. Никак не одночастотный RTK, требующий кучи телодвижений с непредсказуемым результатом.

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

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

Я не задавал вопрос про то как поднять тарелку или планировать сессии. Это была цитата с форума, ключевая фраза в которой Что получится пока не знаю. Т.е. профессиональный двухчастотник, антенна задрана по самое не хочу, статическая съёмка и геодезист НЕ УВЕРЕН В РЕЗУЛЬТАТЕ. А мы тут рассуждаем про одночастотный RTK в городских условиях. Надеюсь теперь понятно что я имел в виду.

**chnav.**Любительский L1 RTK это тупиковый путь…
Есть такая плата с L1 RTK K500 OEM Board.
Single Baseline RTK¹(<8km)
10 mm + 1 ppm Horizontal
20 mm + 1 ppm Vertical
Так что не совсем тупик…

Вопрос так не стоит, естественно L1 RTK работает при выполнении необходимых условий,
но в данное время это задача не для средних умов.
Есть большое количество вопросов, которые решаются чистым прилежанием,
например, как в статике частота измерений влияет на скорость получения фиксированного
решения, какова скорость сходимости фиксированного решения на расстоянии 5, 10 и 15 км
от станции IGS (базовой), дает ли собственная база с большей частотой чем обычная IGS (30 сек)
улучшение скорости сходимости.
Также есть вопросы о том, какая модель геоида используется в прошивках ublox и sirf
(есть мнение, что EGM96 на сетке 1° или 10°, но нет никаких доказательств).

Грамотно подобранное слово в отношении статики и RTK, ёмко и точно.

Проскочила новость что Россия разворачивает станции СДКМ (кто не в курсе это российский глобальный SBAS) в Китае, Казахстане и Белоруссии. Если всё пойдёт по плану и производители поддержат её новыми прошивками - уточнённый GPS наконец-то станет доступным, без каких-либо дополнительных усилий. Отрадно что разработчики не стали тешить самолюбие и будут передавать поправки на частоте GPS L1.

NEO-M8N при правильной конфигурации стабильно работает у меня в GPS-only режиме с тактовым периодом 52 ms (19.23 Hz),
при 20 Hz есть нестабильность и “перескок” на 10 Hz.
Документация говорит о 18 Hz.
В режиме gps+глонасс 60 ms (16.67 Hz), документация гарантирует 10 Hz, но может есть какие подводные камни.

Формат геоида GSF описан производителем здесь https://update.carlsonsw.com/kbase_attach/716/Geoid%20Separation%20File%20Format.pdf ,
но и так было понятно что там и как.
На том же сайте есть файл геоида для Финляндии, включающий Санкт-Петербург (по крайней мере в bounding box, цифры я не смотрел).
Интересно будет сравнить с официальным и EGM2008.
Форматы Trimble/Topcon GGF и GFF очень похожи друг на друга, geoid undulation хранится без всяких фокусов в 4байтных float,
правда порядок строк разный (снизу вверх и сверху вниз).
Leica GEM, как я писал более изощренный (хранит скалированные 16битные отклонения от среднего значения),
поэтому размер файла ~ в 2 раза меньше.

На выходных провел интересный статический измерительный эксперимент:
GPS/glonass антенна на мини-штативе стояла на крыше автомашины (суммарное высота над землей порядка 3x метров)
в открытом на все стороны поле на расстоянии 35 км от базовой станции (RINEX dt=30 sec, GPS+GLONASS). Антенна присоединена к сплиттеру,
и на его выходах подключены LEA-6T (GPS без SBAS) и NEO-M8N (GPS+GLONASS без BEIDOU-2, QZSS и SBAS). Сырые данные записывались с частотой 10 Hz,
так как официальная версия rtklib для NEO-M8N больше не умеет ) порядка 70 минут.
Измерения были конвертированы в RINEX с помощью convbin, затем обработаны teqc (с децимацией 1s,2s,5s,10s,15s,30s,2Hz,4Hz,5Hz,10Hz, с глонассом и без),
постпроцессированы с помощью rnx2trkp
и результат визуализирован rtkplot.
Таблица видимости спутников ( elevation > 10° ) выглядит вот так


$ teqc +qcq +sym +l -nav neo8n_rover.nav,neo8n_rover.gnav neo8n_rover.obs
 SV+-|---------------------------|----------------------------|-------------+ SV
 12|^^^^^^^^^^^^^^^^^^^^^^^^^^                                              | 12
 11|cccccccccccccccccccccccccccccccccccccccc^^^^^^^^^^^^^^^^^^^^^^____      | 11
  1|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|  1
 23|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc| 23
 32|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc| 32
 17|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc| 17
 31|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc| 31
  4|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|  4
  9|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|  9
  6|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|  6
 13|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc| 13
 20|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc| 20
 10|                L^^^^^^^^^^^^^^^^^^^^^^^^^^^^ccccccccccccccccccccccccccc| 10
  8|____________________________LL^L^^^L^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^|  8
  2|                                               _LL^^^^^^^^^L^^^^^^^^^^^^|  2
  7|                                                      ___________L^^^^^^|  7
R 6|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|R 6
R 5|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|R 5
R21|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|R21
R20|ccccccccccccccccccccccccccccccccccccccccccccccccccccc^^^^^^^^^^^^^^L^^^L|R20
R14|ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc^^^^^^^^^^^|R14
R22|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|R22
R15|cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc|R15
R 4|????????LLL LL                                                          |R 4
R 7|^^^^^^^^^^ccccccccccccccccccccccccccccccccc-cccccccccccccccccccccccccccc|R 7
R13|???LLLL                                                                 |R13
R16|         ______L^^^^^^^^^^^^^^^^cccccccccccccccccccccccccccccccccccccccc|R16
R23|                                                L??????L??????L?????????|R23
-dn|++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|-dn
+dn|++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|+dn
+10|iiiiiiiiijjjjjjjjjjjjjjjjjjjjjjkkkkkkkkkkjjjkkkkkkkkkkjjjjjjjjiiiiiiiiii|+10
Pos|ooooooo         oooooooooo  oooooooooooooooooooooooooooooooooo   ooooooo|Pos
Clk|                                                                        |Clk
   +-|---------------------------|----------------------------|-------------+   
17:28:49.400                                                        18:44:34.100
2014 Oct  3                                                          2014 Oct  3

Observation interval    : 0.1000 seconds
Total satellites w/ obs : 28
Rx tracking capability  : 0 SVs
Poss. # of obs epochs   :  45448
Epochs w/ observations  :  45448
Mean S1 S2              : 47.88 (sd=3.61 n=863125) 0.00 (sd=0.00 n=0)
      first epoch    last epoch    hrs   dt  #expt  #have   %   mp1   mp2 o/slps
SUM 14 10  3 17:28 14 10  3 18:44 1.262 .10 863126      0   0   n/a   n/a      0

то есть в первые полчаса одновременно были видны 12 спутников GPS и 7 глонасс, а все время 10 спутников GPS и 5 глонасс.
Основные результаты:

  1. глонасс только мешает: с ним fixed решение никак не получается (glonass only и glonass+gps), а при его отключении
    fixed выдается через 7 минут. Возможно это связано с (отсутствием интер-)калибровки IFB.
  2. Если базовая станция дает данные с периодом 30 сек, то никакого смысла в большей частоте (при статике) для ровера нет.

Для статики вообще рекомендуется (прим. компанией Trimble) запись 15-30 секунд, даже если база пишет чаще. Суть в очень высокой корелляции соседних измерений и в результате можно получить слишком оптимистичную точность оценку точности.

Как-то на форуме ixbt обсуждали похожую ситуацию:

http://forum.ixbt.com/topic.cgi?id=64:2826-7#182

http://forum.ixbt.com/topic.cgi?id=64:2826:214#215

http://forum.ixbt.com/topic.cgi?id=64:2826-9#220

Сломал моск, пытаясь угадать, что к чему относится в данном предложении :slight_smile: Так что же оно не умеет - больше 10 Hz, или больше 70 минут?

больше 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.
Решение проблемы пока неизвестно.

Edit
ublox-m8 стало можно купить за совсем небольшие деньги:
http://ava.upuaut.net/store/index.php?route=product/product&path=59_60&product_id=96

Я не усредняю фиксированные решения, а смотрю полную “временную развертку” отдельных решений.
Самые лучшие результаты получаются при полном совпадении временных отметок базы и ровера, т.е. при исключении
какой бы то ни было интерполяции измеренных данных.
В этом примере из исходных данных с частотой 10 Hz (-O.int 0.1) выбираются измерения с шагом 30 сек (-O.dec 30) начиная с
30 секундной эпохи 2013-12-22T10:39:30.00


teqc -O.int 0.1 -O.dec 30 -st 20131222103930.00 foo.obs > foo_dec30.obs

При этом на расстоянии 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) ?


Pj = Rj + ...
Cj = Rj + ...

PVj = RVj + ...
CVj = RVj + ...

Rj =sqrt( (X0-Xj)^2 + (Y0-Yj)^2 + (Z0-Zj)^2 )
RVj=sqrt( (X1-Xj)^2 + (Y1-Yj)^2 + (Z1-Zj)^2 )


Т.е. координаты станции в 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 дали в течение пары дней.

ublox 6h raw memory patch fw 7.03

B5 62 9 1 10 0 F4 40 0 0 0 0 0 0 E7 B9 81 0 0 0 2 10 81 48

B5 62 9 1 10 0 60 43 0 0 0 0 0 0 D3 B9 81 0 0 0 2 11 DD 96