-1
Не надо передавать точные координаты для RTK, так как они необходимы только для выбора выбора станции в CAS и NET, с которой
начнется передача поправок. Сбросил файл по NTRip протоколу, более подробный чем на китайском сайте на русском:
http://files.mail.ru/MHT7U1 . В приложении С исходники для NTRip Clientа.
Зачем проверять и резать упаковку, можно так и отправить.
Может я не так выразился - если я ставлю базовую станцию RTK, то её координаты должен донести до пользователя, неважно это RTCM или NTRIP или что-то третье.
Chnav прочитай главу 3.1 Общая информация - в файле.
Перевожу - главной задачей является передача поправок DGPS (то что я и предлагаю т.к. координаты станции передавать необязательно), ОДНАКО протокол NTRIP может использоваться и для данных RTK (а это не что иное как сырые измерения + точные координаты станции).
Точные координаты базовой станции (message types 1006) - ввели в RTCM SC-104 v3.0 . В остальных версиях их нет. http://tekmon.gr/tag/rtcm-sc-104-version-2-2/ .
umot
Для вычисления абсолютной координаты ровера ОБЯЗАТЕЛЬНО нужны координаты базы т.к. RTK - это относительное позиционирование (вычисляется вектор база-приемник и только потом координаты ровера). В RTCM 2.x для этого есть сообщение Type 3 с координатами ECEF XYZ с точностью 1см.
-1
Та если собирать RTK то все понятно, RtkLib все обеспечит. Там просто не всегда удобно, нужно иметь базу, иметь покрытие для связи, оплатить связь. А так просто навик. Я впринципе собрал на OemStar 10Hz, но как по мне не очень та LowCost приемник, голая платка 500$. Пробовал Обычную антенну юзать, Координата страдает. Купил http://www.ebay.com/itm/Antcom-2G15A-XTB-1-N-Active-L1-GPS-Antenna-/330441586851?pt=LH_DefaultDomain_0&hash=item4cefda78a3 такую антену. Особо точность не улучшилась, но впринципе для многих нужд нормально. Понадобилось еще несколько таких систем, вот теперь и думаю как сделать. Вот недорогую платку нашел http://www.dhgate.com/ublox-lea-4t/p-ff80808129d93e870129ee82838a43d2.html . Что это там кстати за разъем? Теперь думаю как лучше сделать, или RTK строить или поломать голову как сырые данные пофильтровать. В идеале конечно хочется и RTK и если связи нет то чтобы хоть фильтры работали.
В любом случае на навигаторе уже процессорные ресурсы кончились, я брал обычный навик китайский 7’’ на 500 МГц. А для агонавигатора намного больше ресурсов понадобилось. Во первых 10Гц полный редрайв экрана, а во вторых на 10Гц трек очень быстро вырастает, а его нужно в реалтайме показывать, да еще в ВинЦЕ не поддерживается аппаратное ускорение графики.Так что туда RtkLib уже не скомпилить. Сейчас правда уже андроиды доступны на полтора ГГц и аппаратным OpenGLES, но опять же переносить с ВинЦЕ на Андроид…
Я так понимаю что АПИ RtkLib не документированны? Или я не там ищу?
Второй раз отвечаю на вопрос, как геодезист - однозначно RTK. Сбросил 2 файла по ссылке по OEMStar и OEMV-1. http://files.mail.ru/1SQQ3O
В них надо посмотреть только Точность плановых координат:
Точность плановых координат: OEMStar OEMV-1G
Автономное определение по L1 1.5м 1.5м
SBAS 0.8м 0.6м
DGPS 0.6м 0.4м
На остальное не надо обращать внимание.
-1
-1
usm78-gis
У меня возник такой вопрос… если не ошибаюсь, большинство современных смартфонов используют host based GPS, т.е. первичный захват и слежение за сигналом осуществляет специализированный чип, а вся дальнейшая обработка производится силами основного CPU. Так дешевле. Интересно что этим занимается - какой-то драйвер, или это происходит ещё до операционной системы (может у смартфонов есть аналог BIOS) ? Где-то же должен сидеть вычислительный блок… Вот если бы найти low-lewel доступ к этим данным - можно получить raw data с любого современного смартфона.
Все дело в том что на поле АБСОЛЮТНАЯ точность не к чему. Я приехал, создал начало координат (это грубо говоря) и работаю. У меня есть такая система, я ей уже 2 сезона работаю. GL1DE это просто цифровой фильтр. Когда его включаешь, он гарантирует что в течении 15 минут “начало координат” не уползет более чем на 10-15см. Этого достаточно чтобы проехать например с опрыскивателем из края в край, и развернувшись проехать впаралель с достаточной точностью .
Вот нужная строчка:
Measurement Precision C/A code phase GPS: 5 cm GLONASS: 35 cm
L1 carrier phase:
Differential GPS: 0.6 mm GLONASS: 1.5 mm
Я просто еще не разбирался c RtkLib , пока некогда, поверхностно глянул, зимой поковыряю. Кстати обычно с ARM стоит еще DSP ядро для дешифрации видео, вполне можно заюзать при желании.
Я имел ввиду переносить навигационную программу, я ее сам писал, под винЦЕ прошлой зимой на с++, от гуя винды и альтернативных пришлось уйти и написать с прямым доступом во фраймбуфер, так как поиметь на навигаторе с экраном 800х480 с 500МГц, эмуляцию вида “из окна” с рефрешем в 10 Гц оказалось не реально. Впринципе андроид вроде тоже фраймбуфер отдает, но уже не имеет смысла, так как имеет аппаратный ускоритель. Думаю там opengles шустро все отрисует.
-1
Спасибо, именно это и было интересно узнать. Т.е. когда пишут “host-based GPS” - это не означает что расчетами занимается основной CPU.
Measurement Precision - это точность измерения сырых данных. В них присутвуют ошибки за точность часов спутника и приемника, ошибки прохождения сигнала от спутника до приемника.
usm78-gis
отправил свои адрессные данные для пересылки двух EM-500.
umot
Всё верно, Measurement Precision это аппаратная точность измерения в каналах приемника. В том-то весь и прикол что GL1DE обеспечивает относительную точность последовательных измерений координат (разделенных во времени вплоть до 15 минут) на уровне аппаратной точности приемника.
За 15 минут как раз накапливается значительное изменение ионосферы и прочих ошибок (например из-за неточности бродкастных эфемерид), плюс значительно меняется геометрия созвездия. Поэтому они и упоминают такое временнОе ограничение, выявленное эмпирическим путем.
Ublox интересно нормирует такой параметр или нет?