-1
В этом году теме исполняется 10 лет, а программе RTKLib и того больше. Когда впервые выложили исходники - все ахнули, вот теперь заживём… Однако за прошедшую декаду не появилось ни одной программы для практического применения - вынос точек, ГИС-съёмка с атрибутикой, CoGo, работа в МСК и пр. С ноутбуком сильно в поле не побегаешь, спасибо Alexey Illarionov портировал программу на Андроид, выложил исходники - и всё-равно дело не пошло. Не любят программисты писать прикладной софт бесплатно )))
Sergey Astakhov в результате тоже плюнул и приобрёл survey grade S-Max Geo (Spectra Precision SP60). Компания Trimble между делом выпустила приёмник R12i, который учитывает наклон вешки с помощью INS и постояной самокалибровки. Это не фуфло типа MEMS-датчиков в смартфонах, там что-то посерьёзнее, раз они гарантируют миллиметровые точности с вешками под 2 метра.
В общем RTKLib осталась академической программой. Основная фишка - RTK - практически никем не используется, а вместо этого постобработка. Но последних программ и без RTKLib навалом. Там тебе и локализация координат, и автоматическое скачивание ринексов с ближайших станций, Stop-n-Go и пр.
Помянем…
Ну справедливости ради там бы прикручен proj+ — забивай МСК на свой вкус, а rtkexplorer добавил в приложение кнопку для внесения точек, в rtkpos их обработку.
Я имел в виду калибровку по местным пунктам. Допустим выносится земельный участок - геодезист с контроллером объезжает несколько ближайших пунктов ГГС (минимум три), собирает на них данные и вбивает в контроллер их каталожные координаты. Контроллер автоматически рассчитывает сдвиг от базовой МСК, параметры масштаба и разворота.
Если просто вбить МСК то забор может улететь на десятки сантиметров.
Кстати у Тримбла чёткое разделение сегментов: работа по параметрам МСК - это ГИС, а калибровка на пунктах это survey software.
Если криворукие (например в emlid) не в состоянии добавить поддержку геодезических RTCM
сообщений, то конечно улетит.
Я тут купил в sparkfun ZED-F9R, посмотрим что это за зверь, он тоже должен так уметь
(за совсем другие денги).
У богатых свои причуды.
Мне вот для поддержки трехчастотников u-blox
пришлось самому rtkgps+ пересобирать (без windows и androidstudio)
и это был ад. Раз никто из “профессиональных программистов” даже актуальный .apk
не хочет поддерживать.
Я тут причитаю, что нет бесплатного полевого софта, потом призадумался - есть же open source QField.
И ещё вопрос - есть ли форки RTKlib, поддерживающие SiRF Star ? Не то чтобы очень надо, для коллекции. Вдруг интерес вернётся ))
Для RTCM требуются всего 3 проекции: GK, Lambert и ObliqueMercator, ради этого
добавлять proj4 через NDK это ужас. И то две последних имеют довольно ограниченное
применение.
Нужен свой нормальный самостоятельный форк rtkgps+rtklib с правильной поддержкой
современных F9H и F9R, и всего того чего почему-то нет в rtklib: sirf, геодезических сообщений,
сетевого RTK и т.д.
Для этих целей это зачетная незаменимая прога 
Вот при помощи RTKPOST на примере трех далеко разнесенных населенных пунктов
наглядно показал что такое в духчастотнике **Iono-Free LC **
А то все буквально помешались на многочастотниках 
Вот как это типично выглядит :
“Все помешались” на бытовых многочастотниках в смартфонах, а вы приводите данные с чужого приёмника геодезического класса NovAtel DL–V3, способного full-carrier L2 и P(Y)-Code, с narrow-corellator и ADC под сотню мегагерц, цена на который для любителей неподъёмная. Технологии L1/L2 Iono-free LC уже более четверти века, но что-то она не дешевеет. А так картинки красивые.
в этом и вся соль
не буду же ездить по различным пунктам и снимать, если уже все установлено и снято
и вообще, я привел данные ТРЕХ приемников
NovAtel DL–V3
NovAtel DL–V3
и
**LEICA GR10 **
наглядно видно как в **LEICA GR10 ** рукоблудит
выдает **не совсем сырые данные **а уже приглаженные 
приглаженные краше выглядят в глазах юзверя 
а ей альтернативы нет для определения хоть как то точных абсолютных координат
нужна только геодезистам, вот пущай и раскошеливаются
а то исписали все заборы, мол в двухчастотнике нет влияния ионосферы, рядовой юзверь и думает,
что все время такой приемник, выдает очень точно, ат нет,** реально **мажет сильнее чем мой копеечный M8T
которым абсолютные координаты определить невозможно даже если он сутками будет неподвижен в идеальных условиях приема.
Кроме ионосферы есть другие факторы, ухудшающие точность. Вы видимо не застали S/A в действии (отключена в мае 2000). Геодезисты обо всём этом знают и никогда не пользуются абсолютными координатами. На заборах кто-то другой пишет. И хватит показывать язык, как дитя, чесслово.
оччень интересно,
если учесть что я использовал brdc2270.20n igs21185.sp3 igs21185.clk_30s igsg2270.20i
что именно я пропустил ? 
скорее всего именно вы еще очень молоды
я юзаю GPS где то с 93 года прошлого века, тогда даже DGPS для компенсации S/A ставил на базе GPS приемника Motorola 
в РФ тогда за юзание GPS приемников отправляли в места не столь отдаленные, как сча помню процесс над забугровым инженером (посадили) который устанавливал под Ростовом базовые DCC которые без привязки по GPS не могли работать
а уж сколько у меня всяких гарминов, сирфов и проч. … было и есть, но счасс фаворит u-blox_ы 
У нас первый Trimble 4000 появился в 1992. Полный список оборудования, софта и послужной список, извиняюсь, приводить не буду, но отечественных и иностранных заказчиков всё устраивало. За GPS сажали лохов, у которых не было лицензии на геодезическую деятельность. Ширпотреб вроде Motorola и Furuno в нашей отрасли не применялись.
Из теории мне интересно устройство GPS-приёмников. Тонкости обработки не интересуют (ещё в 90-е - нулевые наработался с QPS DGPS, QINSy и пр. так что всякие w-test, f-test и поиск блох вылетов в обсервациях для меня пройденный этап).
с GPS гармином нельзя было проехать в авто по городу 
да нормальный был ширпотреб за штуку баксов S/A давил и это было благо, ибо другого с сырыми данными приемника тогда небыло
и кварц был отюстирован и термостатирован, не то что в нынешней фирме
я когда прочел это летом чуть с дивана не упал,
насколько понял, тамошний refot это местный стрелок
номер PRN однозначно связан с С/A кодом, вместо 3-х значных номеров WAAS забиваем 125 и 140 и все должно работать с GPS и ничего не будет работать с GLONASS, для GLONASS SBAS не реализован даже в u-blox
По слухам, сам не проверял, не вижу спутников WAAS, WAAS это единственная SBAS, которая в нарушение интерфейса SBAS, синхронизирована с GPS, т.е. псевдорадиус стоит как укопанный, вследствии чего имеет много недокументированных фичей,
так что лучше перебивать не WAAS.
ничего интересного в устройстве GPS-приёмников нет, если интересно то берем rtl-sdr, к нему цепляем активную антенну и любой фришный GNSS-SDR Когда изучение приемника по исходникам софты надоест, можно приступить к реализации real-time GPS signal simulator, благо опять фришной софты навалом.
Вот с simulator все гораздо интереснее, когда станете смотреть его сигнал u-blox_ом.
Первый вынос мозга будет это когда u-blox от GPS signal simulator в residual для каждого спутника начнет рисовать отменную пилу
Тогда прийдет осознание что изучать теорию устройства GPS-приёмников лишено особого смысла, ибо не все сказано в интерфейсе GPS а если и сказано то далеко от истины. Вот когда вместо пилы в residual ваш GPS signal simulator будет выдавать прямую линию близкую к нулю, как у настоящих спутников, тогда будете считать что с теорией вы разобрались
Номер PRN связан с C/A кодом в таблице ICD-GPS-200, но в кто-то должен проинициализировать DSP/FPGA в чипсете, чтобы задать начальные значения для генератора C/A. Об этом шла речь, так-что мы с refot поняли друг-друга. В прошивке sirf куча проверок типа svid <= 138, я не расчитываю на лёгкое решение. За июль месяц я не смог найти обращение к недокументированным областям памяти (IO), хотя бы близко напоминающим эти значения.
таблицами никто не пользуется, обычно юзается такой код
/* !\brief generate the C/A code sequence for a given Satellite Vehicle PRN
* \param[in] prn PRN nuber of the Satellite Vehicle
* \param[out] ca Caller-allocated integer array of 1023 bytes
*/
void codegen(int *ca, int prn)
{
int delay[] = {
5, 6, 7, 8, 17, 18, 139, 140, 141, 251,
252, 254, 255, 256, 257, 258, 469, 470, 471, 472,
473, 474, 509, 512, 513, 514, 515, 516, 859, 860,
861, 862};
int g1[CA_SEQ_LEN], g2[CA_SEQ_LEN];
int r1[N_DWRD_SBF], r2[N_DWRD_SBF];
int c1, c2;
int i,j;
if (prn<1 || prn>138)
return;
for (i=0; i<N_DWRD_SBF; i++)
r1[i] = r2[i] = -1;
for (i=0; i<CA_SEQ_LEN; i++)
{
g1[i] = r1[9];
g2[i] = r2[9];
c1 = r1[2]*r1[9];
c2 = r2[1]*r2[2]*r2[5]*r2[7]*r2[8]*r2[9];
for (j=9; j>0; j--)
{
r1[j] = r1[j-1];
r2[j] = r2[j-1];
}
r1[0] = c1;
r2[0] = c2;
}
for (i=0,j=CA_SEQ_LEN-delay[prn-1]; i<CA_SEQ_LEN; i++,j++)
ca[i] = (1-g1[i]*g2[j%CA_SEQ_LEN])/2;
return;
}
да какие проблемы ?
забивайте 125 и ловите моменты когда этот PRN SDCM работает
давеча (02.09.20) когда тестировал TRK-MEASX-SEC работали 125 и 140
поскольку шаг SNR был 0.25 то наблюдал **дивное явление в SDCM **
если сигнал 140 стоял как укопанный, хотя он ниже над горизонтом
сигнал от 125 за 40 минут наблюдений плавно возрос по дуге с 38 до 40 а потом опять начал плавно по дуге уменьшаться
чем это вызвано непонятно 
Новател на самом деле тоже не без греха,
но это дела минувших дней.
автор rtklib начинал с функционала precision-gps.org (aka Kinematic) если вы помните,
но по каким-то причинам целенаправленно отрицательно относился к sirf2
и выкинул его вообще из кода.
Также это был “rtklib.com” то есть его целью было создание коммерческого продукта,
где он являлся бы единственным автором, а не community проект,
но потом что-то пошло не так и он забросил это дело.
rtklibexplorer тоже малый предприниматель, единственная цель которого
убедить потенциальных клиентов в своей полезности.
Все это не способствует тем результатам которые вы бы желали видеть.
В F9H (и надо полагать в F9K) его выкинули …