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

2002_ivan · 2020-09-07 11:54:05

-1

Last edited by 2002_ivan (2020-09-07 11:54:35)

Sergey Astakhov · 2020-09-07 14:23:46

2002_ivan wrote:

Sergey Astakhov wrote:
И в чём же она заключается?
Что в коде не перезаписывают выбранные пользователем опции?
в том например, что в PPP Manual using RTKLIB указано Iono-Free LC
которому соответствует IONOOPT_IFLC а не IONOOPT_BRDC (броадкаст) и как итог
реально будет вычисляться поправка не IONOOPT_IFLC и не IONOOPT_BRDC :D а нечто слегка отфонарное :lol:
и т.д. и т.п. ;)

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

Last edited by Sergey Astakhov (2020-09-07 14:24:33)

2002_ivan · 2020-09-07 14:50:24

Sergey Astakhov wrote:

Потому эти строчки и закомментированны

закомментировал я читайте внимательно
в оригинале они выглядят так

	if (opt_.mode!=PMODE_SINGLE) { /* for precise positioning */
#if 0
		opt_.sateph =EPHOPT_BRDC;
#endif
		opt_.ionoopt=IONOOPT_BRDC;
		opt_.tropopt=TROPOPT_SAAS;
	}

Sergey Astakhov wrote:

что это какая-то временная отладка была, которую не вычистили пока.

появились эти строки 10 лет назад, начиная с версии 2.4.0

2002_ivan · 2020-09-07 14:52:19

Sergey Astakhov wrote:

Зачем в коде прописывать какую-то конкретную опцию, если она должна выбираться пользователем библиотеки в настройках?

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

Cтрелок · 2020-09-07 15:32:54

2002_ivan wrote:

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

Смешно . Это файл pntpos.c, функция pntpos(…). Опция PMODE_SINGLE указывает, что пользователь хочет получить автономное решение. В данном режиме можно использовать и высокоточные орбиты, и часы и поправки SBAS и иосноферно-свободную комбинацию (IONOOPT_IFLC) и все настройки которые выбрал пользователь будут применены. Но, когда пользователь выбирает решение PPP или RTK (т.е. opt_.mode!=PMODE_SINGLE), то функция pntpos используется только для контроля целостности (RAIM) и предварительной оценки смещения часов приёмника (всё остальное будет оценено на следующем этапе в фильтре Калмана). А тут всё равно какие опции тропосферы и ионосферы использовать, видно разработчики RTKLIB решили, что так будет наиболее оптимально.

2002_ivan · 2020-09-07 15:59:29

Cтрелок wrote:

Смешно . Это файл pntpos.c, функция pntpos(…).

ржачно
ибо с pntpos(…) в конце концов даже с выключенной RAIM идет вызов prange (psendorange with code bias correction)

/* psendorange with code bias correction -------------------------------------*/
static double prange(const obsd_t *obs, const nav_t *nav, const double *azel,
					 int iter, const prcopt_t *opt, double *var)
{
	const double *lam=nav->lam[obs->sat-1];
	double PC,P1,P2,P1_P2,P1_C1,P2_C2,gamma;
	int i=0,j=1,sys;

	*var=0.0;

	if (!(sys=satsys(obs->sat,NULL))) return 0.0;

	/* L1-L2 for GPS/GLO/QZS, L1-L5 for GAL/SBS */
	if (NFREQ>=3&&(sys&(SYS_GAL|SYS_SBS))) j=2;

	if (NFREQ<2||lam[i]==0.0||lam[j]==0.0) return 0.0;

	/* test snr mask */
	if (iter>0) {
		if (testsnr(0,i,azel[1],obs->SNR[i]*0.25,&opt->snrmask)) {
			trace(4,"snr mask: %s sat=%2d el=%.1f snr=%.1f\n",
				  time_str(obs->time,0),obs->sat,azel[1]*R2D,obs->SNR[i]*0.25);
			return 0.0;
		}
		if (opt->ionoopt==IONOOPT_IFLC) {
			if (testsnr(0,j,azel[1],obs->SNR[j]*0.25,&opt->snrmask)) return 0.0;
		}
	}
	gamma=SQR(lam[j])/SQR(lam[i]); /* f1^2/f2^2 */
	P1=obs->P[i];
	P2=obs->P[j];
	P1_P2=nav->cbias[obs->sat-1][0];
	P1_C1=nav->cbias[obs->sat-1][1];
	P2_C2=nav->cbias[obs->sat-1][2];

	/* if no P1-P2 DCB, use TGD instead */
	if (P1_P2==0.0&&(sys&(SYS_GPS|SYS_GAL|SYS_QZS))) {
		P1_P2=(1.0-gamma)*gettgd(obs->sat,nav);
	}
	if (opt->ionoopt==IONOOPT_IFLC) { /* dual-frequency */

		if (P1==0.0||P2==0.0) return 0.0;
		if (obs->code[i]==CODE_L1C) P1+=P1_C1; /* C1->P1 */
		if (obs->code[j]==CODE_L2C) P2+=P2_C2; /* C2->P2 */

		/* iono-free combination */
		PC=(gamma*P1-P2)/(gamma-1.0);
	}
	else { /* single-frequency */

		if (P1==0.0) return 0.0;
		if (obs->code[i]==CODE_L1C) P1+=P1_C1; /* C1->P1 */
		PC=P1-P1_P2/(1.0-gamma);
	}
	if (opt->sateph==EPHOPT_SBAS) PC-=P1_C1; /* sbas clock based C1 */
	*var=SQR(ERR_CBIAS);

	return PC;
}

в которой стоит проверка

if (opt->ionoopt==IONOOPT_IFLC) { /* dual-frequency */

а поскольку у нас закладка, т.е. всегда

opt_.ionoopt=IONOOPT_BRDC;

то prange всегда будет сваливать на

else { /* single-frequency */

и никогда на dual-frequency а я как раз играюсь с обсервациями PPP dual-frequency, потому и заметил.

Last edited by 2002_ivan (2020-09-07 16:23:46)

Cтрелок · 2020-09-07 17:28:38

2002_ivan wrote:

и никогда на dual-frequency а я как раз играюсь с обсервациями PPP dual-frequency, потому и заметил

Да, абсолютно, верно. И на точности PPP решения это никак не скажется. Так как скорректированные псевдодальности из pntpos в ppp решении не участвуют, я писал об этом выше. В файле ppp.c используется своя функция для вычисления ионосферо-свободной комбинации.

Sergey Astakhov · 2020-09-07 17:35:57

2002_ivan wrote:

и никогда на dual-frequency а я как раз играюсь с обсервациями PPP dual-frequency, потому и заметил.

Ну если вы во всём этом разобрались - может найдёте тогда почему single frequency PPP, работающий в 2.4.2, в 2.4.3 поломался, в то время как dual frequency работает на обоих версиях.

Last edited by Sergey Astakhov (2020-09-07 17:38:04)

2002_ivan · 2020-09-07 17:39:55

Cтрелок wrote:

И на точности PPP решения это никак не скажется. Так как скорректированные псевдодальности из pntpos в ppp решении не участвуют, я писал об этом выше.

а на чем сказывается ?
ибо если сделаем

/* psendorange with code bias correction -------------------------------------*/
static double prange(const obsd_t *obs, const nav_t *nav, const double *azel,
					 int iter, const prcopt_t *opt, double *var)
...
...
...
	*var=SQR(ERR_CBIAS);
	PC = 0;
	return PC;

то PPP решение вообще отсутствует

2002_ivan · 2020-09-07 17:45:22

Sergey Astakhov wrote:

single frequency PPP, работающий в 2.4.2, в 2.4.3 поломался, в то время как dual frequency работает на обоих версиях.

как раз этим и занимаюсь
надо сказать что в 2.4.2 работает весьма коряво
разница между single frequency PPP и Single почти незаметна

dual frequency в 2.4.3 как и в 2.4.2 как уже показал работает через жжжж

Last edited by 2002_ivan (2020-09-07 18:36:03)

freeExec · 2020-09-07 19:09:14

Sergey Astakhov wrote:

почему single frequency PPP, работающий в 2.4.2, в 2.4.3 поломался

нужно подправить функцию udbias_ppp(...)
начальное значение неоднозначности обязательно требует вторую частоту. Если начальное значение отсутствует, то расчёт по спутнику вестись не будет
начальное значение вычислять с использованием ионосферной задержки, полученной через функцию model_iono(...);

2002_ivan · 2020-09-07 20:34:35

-1

Last edited by 2002_ivan (2020-09-07 20:38:58)

chnav · 2020-09-08 09:05:06

usm78-gis wrote:

2002_ivan wrote:
на https://github.com/ более 160 версий RTKLIB
Так как автор в силу своеобразной японской ментальности упорно отказывается
интегрировать патчи (даже поддержки sirf нет!),
а все остальные пишут местечковую отсебятину.
Изменение лицензии с GPL на BSD тоже привлекло коммерческих
"писателей" которые не заинтересованы в развитии необходимых функций
"для всех".

В этом году теме исполняется 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 и пр.

Помянем...

Last edited by chnav (2020-09-08 10:42:05)

freeExec · 2020-09-08 10:49:57

chnav wrote:

спасибо Alexey Illarionov портировал программу на Андроид, выложил исходники - и всё-равно дело не пошло. Не любят программисты писать прикладной софт бесплатно )))

Ну справедливости ради там бы прикручен proj+ — забивай МСК на свой вкус, а rtkexplorer добавил в приложение кнопку для внесения точек, в rtkpos их обработку.

chnav · 2020-09-08 11:16:42

freeExec wrote:

chnav wrote:
спасибо Alexey Illarionov портировал программу на Андроид, выложил исходники - и всё-равно дело не пошло. Не любят программисты писать прикладной софт бесплатно )))
Ну справедливости ради там бы прикручен proj+ — забивай МСК на свой вкус

Я имел в виду калибровку по местным пунктам. Допустим выносится земельный участок - геодезист с контроллером объезжает несколько ближайших пунктов ГГС (минимум три), собирает на них данные и вбивает в контроллер их каталожные координаты. Контроллер автоматически рассчитывает сдвиг от базовой МСК, параметры масштаба и разворота.
Если просто вбить МСК то забор может улететь на десятки сантиметров.

Кстати у Тримбла чёткое разделение сегментов: работа по параметрам МСК - это ГИС, а калибровка на пунктах это survey software.

Last edited by chnav (2020-09-08 11:25:15)

usm78-gis · 2020-09-08 11:45:06

chnav wrote:

Если просто вбить МСК то забор может улететь на десятки сантиметров.

Если криворукие (например в emlid) не в состоянии добавить поддержку геодезических RTCM
сообщений, то конечно улетит.

Компания Trimble между делом выпустила приёмник R12i, который учитывает наклон вешки с помощью INS и постояной самокалибровки.

Я тут купил в sparkfun ZED-F9R, посмотрим что это за зверь, он тоже должен так уметь
(за совсем другие денги).

Sergey Astakhov в результате тоже плюнул и приобрёл survey grade S-Max Geo (Spectra Precision SP60)

У богатых свои причуды.
Мне вот для поддержки трехчастотников u-blox
пришлось самому rtkgps+ пересобирать (без windows и androidstudio)
и это был ад. Раз никто из "профессиональных программистов" даже актуальный .apk
не хочет поддерживать.

Last edited by usm78-gis (2020-09-08 12:02:49)

chnav · 2020-09-08 13:51:43

Я тут причитаю, что нет бесплатного полевого софта, потом призадумался - есть же open source QField.

И ещё вопрос - есть ли форки RTKlib, поддерживающие SiRF Star ? Не то чтобы очень надо, для коллекции. Вдруг интерес вернётся ))

Last edited by chnav (2020-09-08 21:00:01)

usm78-gis · 2020-09-09 22:06:38

freeExec wrote:

там бы прикручен proj+

Для RTCM требуются всего 3 проекции: GK, Lambert и ObliqueMercator, ради этого
добавлять proj4 через NDK это ужас. И то две последних имеют довольно ограниченное
применение.
Нужен свой нормальный самостоятельный форк rtkgps+rtklib с правильной поддержкой
современных F9H и F9R, и всего того чего почему-то нет в rtklib: sirf, геодезических сообщений,
сетевого RTK и т.д.

2002_ivan · 2020-09-10 11:39:38

chnav wrote:

RTKLib осталась академической программой.

Для этих целей это зачетная незаменимая прога

Вот при помощи RTKPOST на примере трех далеко разнесенных населенных пунктов
наглядно показал что такое в духчастотнике Iono-Free LC

А то все буквально помешались на многочастотниках Вот как это типично выглядит :

chnav · 2020-09-10 12:04:32

2002_ivan wrote:

chnav wrote:
RTKLib осталась академической программой.
Для этих целей это зачетная незаменимая прога
Вот при помощи RTKPOST на примере трех далеко разнесенных населенных пунктов
наглядно показал что такое в духчастотнике Iono-Free LC
А то все буквально помешались на многочастотниках

"Все помешались" на бытовых многочастотниках в смартфонах, а вы приводите данные с чужого приёмника геодезического класса NovAtel DL–V3, способного full-carrier L2 и P(Y)-Code, с narrow-corellator и ADC под сотню мегагерц, цена на который для любителей неподъёмная. Технологии L1/L2 Iono-free LC уже более четверти века, но что-то она не дешевеет. А так картинки красивые.

Last edited by chnav (2020-09-10 12:05:48)

2002_ivan · 2020-09-10 12:33:22

chnav wrote:

а вы приводите данные с чужого приёмника геодезического класса NovAtel DL–V3

в этом и вся соль
не буду же ездить по различным пунктам и снимать, если уже все установлено и снято
и вообще, я привел данные ТРЕХ приемников
NovAtel DL–V3
NovAtel DL–V3
и
LEICA GR10

наглядно видно как в LEICA GR10 рукоблудит
выдает не совсем сырые данные а уже приглаженные

приглаженные краше выглядят в глазах юзверя

2002_ivan · 2020-09-10 12:40:58

chnav wrote:

Технологии L1/L2 Iono-free LC уже более четверти века, но что-то она не дешевеет.

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

chnav · 2020-09-10 13:27:25

2002_ivan wrote:

chnav wrote:
Технологии L1/L2 Iono-free LC уже более четверти века, но что-то она не дешевеет.
а ей альтернативы нет для определения хоть как то точных абсолютных координат
нужна только геодезистам, вот пущай и раскошеливаются
а то исписали все заборы, мол в двухчастотнике нет влияния ионосферы, рядовой юзверь и думает,
что все время такой приемник, выдает очень точно, ат нет, реально мажет сильнее чем мой копеечный M8T
которым абсолютные координаты определить невозможно даже если он сутками будет неподвижен в идеальных условиях приема.

Кроме ионосферы есть другие факторы, ухудшающие точность. Вы видимо не застали S/A в действии (отключена в мае 2000). Геодезисты обо всём этом знают и никогда не пользуются абсолютными координатами. На заборах кто-то другой пишет. И хватит показывать язык, как дитя, чесслово.

Last edited by chnav (2020-09-10 13:44:13)

2002_ivan · 2020-09-10 13:48:36

chnav wrote:

Кроме ионосферы есть другие факторы, ухудшающие точность.

оччень интересно,
если учесть что я использовал brdc2270.20n igs21185.sp3 igs21185.clk_30s igsg2270.20i
что именно я пропустил ?

chnav wrote:

Вы видимо очень молоды, что не застали S/A в действии.

скорее всего именно вы еще очень молоды
я юзаю GPS где то с 93 года прошлого века, тогда даже DGPS для компенсации S/A ставил на базе GPS приемника Motorola
в РФ тогда за юзание GPS приемников отправляли в места не столь отдаленные, как сча помню процесс над забугровым инженером (посадили) который устанавливал под Ростовом базовые DCC которые без привязки по GPS не могли работать
а уж сколько у меня всяких гарминов, сирфов и проч. ... было и есть, но счасс фаворит u-blox_ы

chnav · 2020-09-10 14:22:18

2002_ivan wrote:

я юзаю GPS где то с 93 года прошлого века, тогда даже DGPS для компенсации S/A ставил на базе GPS приемника Motorola...

У нас первый Trimble 4000 появился в 1992. Полный список оборудования, софта и послужной список, извиняюсь, приводить не буду, но отечественных и иностранных заказчиков всё устраивало. За GPS сажали лохов, у которых не было лицензии на геодезическую деятельность. Ширпотреб вроде Motorola и Furuno в нашей отрасли не применялись.

Из теории мне интересно устройство GPS-приёмников. Тонкости обработки не интересуют (ещё в 90-е - нулевые наработался с QPS DGPS, QINSy и пр. так что всякие w-test, f-test и поиск ~~блох~~ вылетов в обсервациях для меня пройденный этап).

Last edited by chnav (2020-09-18 07:32:31)

Announcement

#2451 2020-09-07 11:54:05

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

#2452 2020-09-07 14:23:46

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

#2453 2020-09-07 14:50:24

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

#2454 2020-09-07 14:52:19

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

#2455 2020-09-07 15:32:54

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

#2456 2020-09-07 15:59:29

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

#2457 2020-09-07 17:28:38

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

#2458 2020-09-07 17:35:57

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

#2459 2020-09-07 17:39:55

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

#2460 2020-09-07 17:45:22

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

#2461 2020-09-07 19:09:14

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

#2462 2020-09-07 20:34:35

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

#2463 2020-09-08 09:05:06

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

#2464 2020-09-08 10:49:57

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

#2465 2020-09-08 11:16:42

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

#2466 2020-09-08 11:45:06

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

#2467 2020-09-08 13:51:43

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

#2468 2020-09-09 22:06:38

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

#2469 2020-09-10 11:39:38

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

#2470 2020-09-10 12:04:32

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

#2471 2020-09-10 12:33:22

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

#2472 2020-09-10 12:40:58

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

#2473 2020-09-10 13:27:25

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

#2474 2020-09-10 13:48:36

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

#2475 2020-09-10 14:22:18

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

Board footer