-1
- приемников у меня совсем немного, если скажете где такая таблица находится, то попробую;
- не могу найти готовый haret.exe который показывает загруженные системные (win-CE) библиотеки, выложите где-нибудь свой на пару дней;
- что Вам удалось получить из Гармина, или интерес к нему пропал?
- было бы очень интересно услышать, как Вы предполагаете использовать GSM канал связи купленного трекера,
меня такой вопрос давно интересует для реализации псевдо/полуRTK для бытовых приемников/навигаторов, но знаний по теме =0.
-1
-1
linux
http://geodesist.ru/forum/attachments/gnssmonitor-linux-zip.11842/
win32
http://geodesist.ru/forum/attachments/gnssmonitor3-zip.11334/
win-CE
http://geodesist.ru/forum/attachments/gnssmonitorce-zip.11335/
иллюстрация-скриншот
http://geodesist.ru/forum/threads/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B-%D1%81-%D0%B1%D1%8B%D1%82%D0%BE%D0%B2%D1%8B%D0%BC%D0%B8-%D0%BD%D0%B0%D0%B2%D0%B8%D0%B3%D0%B0%D1%82%D0%BE%D1%80%D0%B0%D0%BC%D0%B8-%D0%B2-%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B5-%D0%B3%D0%B5%D0%BE%D0%B4%D0%B5%D0%B7%D0%B8%D1%81%D1%82%D0%B0.5101/page-15
Программа все еще “в правке”, поэтому что-то может быть не так, как ожидается:
фаза (L1) в RINEX-OBS все еще в метрах, а не в циклах,
время в RINEX-OBS не приведено к “целой” секунде,
доплер в метрах, ане в герцах,
RINEX-NAV пока нет,
зато подробный файл парсинга бинарных сообщенй 
-1
-1
-1
Да, некоторые кнопки пока не имеют своих функций (а ведь я предупредил об этом).
Бороться с segfault не умею, бо я не программист, а за СИ взялся в 58 лет - поверьте, что и у мыслей уже не та резвость.
obs-файла с этого прибора скорее всего и не будет - неоткуда взяться для этого данным.
Я несколько постов назад об этом говорил.
Посмотрите (и расскажите) какие сообщения выводятся в файле парсинга.
Можно и в бинарном файле посмотреть: все гарминовские месседжи начинаются c байта 0x10, затем номер сообщения и его длина.
На сайте геодезист.ру я выкладывал всю накопленную инфу по парсингу сообщений.
А заканчиваются байтами 0x10 0x03, поэтому удобно искать последовательности 0x10 0x03 0x10 … …
Скорее всего Вы найдете 10 33 … … 10 78 … … и 10 99 … … Из них 10 33 - навигационное решени (Time Position Velocity)
Но ни PseudoRange ни Phase в них точно нет.
Если я правильно помню,то Вы говорили о возможности перепрошивки Гарминов на СирфСтар.
Я в этой возможности очень сомневаюсь. Не такие китайцы/тайваньцы люди, чтобы оставить такую возможность юзерам.
Ведь не с бодуна же они лицензировали SirfStar-II и -III чипы и сочинили для них свой бинарный протокол.
SirfStar-овский протокол более “юзерфрендли”, а у Гармина “шаг влево, шагвправо - побег!”
В гарминах на чипчете SirfStar-II были PseudoRange, Phase, Doppler, а в SirfStar-III они это наглухо законопатили.
Это я все к тому, что не в Пролифике дело, а в самом девайсе.
Надо отдать должное этим тайваньским жлобам, что их навигаторы работают до 28 часов (в зависимости от модели) от 2-х пальчиковых АА батареек.
Чем современные (авто)навигаторы никак не могут похвастать - свой Mitac MIO C520 я несу на зарядку через 2 часа и аккум. у него “под капотом”.
Думаю и андро-фоны с включенным GPS-модулем не на многое способны.
А к слову сказать наладонник HP iPAQ 4700 (или PocketLoocks FS 720) с таким же по размеру экраном работает до 10 часов.
Напомню по свою SIRF 2/3/4 дампилку в NMEA/RINEX/RTCM3 sirfdump. В WinCE удобно снимать дампы sirftech’ем.
Недавно мне написал чел из Тасмании. У него был приенмик Altina GBT708 с прошивкой 2.3.2-GSW2-2.05.024-C1Prod1.1 и у него не получался RINEX. Специально для него я добавил поддержку альтернативного порядка байт, используемого в прошивках GSW 2.3.0 - 2.9.9.
У него rtklib полученные дампы принял. Правда, о дальнейших его успехах я не стал расспрашивать.
И правильно, сожрут еще…
В качестве библиотек для софта, кроме rtklib можно рассматривать еще и GPSTk (C++, LGPL) и goGPS (Java, LGPL).
-1
-1
Это не первый подобный проект, их суть - самостоятельная цифровая обработка сигнала (т.е. реализация DSP программными методами). ЕМНИП на обычном компе обработка 1 секунды сигнала занимала около 60 секунд процессорного времени. Это при тщательно оптимизированном коде !
Эти действительно уникальные проекты хороши для студентов, лабораторных работ и диссертаций, но совершенно не годятся для практического применения.
PS: у нас до сих пор никто не реализвал тупой DGPS в реальном времени по каналам GPRS/3G, одни разговоры. А проект по вашей ссылке - вообще из области фантастики. Скачать исходники “про запас” и забыть
Если не переложить часть работы на железку (FPGA), а брать сигнал прямо АЦП, то, как выше уже сказали, всё только тормозить будет.
Живой пример - ресиверы ADS-B (авиационной системы m2m). Примитивные “свистки” тоже что-то декодируют (сейчас вот пытаются как раз на каком-то DVB-ресивере реалтековском сделать), но полную картину удается обработать только на дорогих ресиверах на FPGA.
Свистки ничего не декодируют (есть у меня такой) - тупо гонится поток на CPU. Но вот насчет возможности софтовой реализации на современном железе - есть же GPU , производительность
на всяких DSP задачах там можно получить огромнейшую. Кстати , этот проект основан на gnuradio (хотя наверное 90% софта такого типа на нем) , а там есть модуль для обработки на GPU (под CUDA вроде).
Если вернуться к тематике ветки - как это повысит точность ? Тут дай бог достигнуть точности, выдаваемой бытовым приемником за 30$ 
Это интересные проекты (есть еще fastgps), но, повторюсь, исключительно для академического интереса.
(added)
Вы посмотрите эту ветку - есть готовые приемники (Sirf Star, uBlox), выдающие псевдодальности. Т.е. уже аппаратно (с точки зрения нас как пользователей) решены такие задачи как:
- RF downconversion;
- ADC sampling;
- выделение сигнала (сотни тысяч корелляторов);
- слежение за сигналом;
- измерение псевдодальностей и фазы;
- сглаживание псевдодальностей фазой несущей;
- выделение навигационныхх сообщений;
- первичное решение навигационной задачи (PVT - position/velocity/time);
(наверняка еще что-то упустил)
На этом этапе мы забираем псевдодальности и фазу (там где есть), и пытаемся реализовать более точное решение геодезической задачи (DGPS или static/kinematic survey). Т.е. всего один небольшой пункт - но до сих пор нет готовых решений, чтобы поставил программу в наладонник, запустил - и пошел собирать данные. Желательно с подложкой ОСМ
А указанный проект замахнулся софтово (пусть и с использованием CUDA) реализовать пп.3-8.
Чтобы повысить аппаратную точность, например перейти к L1 Narrow Correlator или хотя бы примитивно начать поддерживать L2, требуется повышать частоту оцифровки в 10 раз, т.е. минимум bandwidth 20MHz. Соответственно в 10 раз больше нагрузка на проц. А заодно выполнить исследовательскую работу, подобную той что проделали производители геодезического оборудования (структура P/Y кода неизвестна - как его выделять ? Там у каждого производителя столько секретов… ).
В случае ads-b - cмотря какие свистки. Если речь о dvb-ресиверах - да, они только оцифровывают аналоговый сигнал.
Если устройство чуть посложнее - там происходит декодирование цифровых посылок (отфильтрованный и перенесенный в НЧ сигнал подается, например, на аналоговый компаратор Atmega48), а уже их “расшифровкой” занимается ЦП, вынимая из них координаты и прочие данные.
Если совсем сложное - то в нем происходит то же самое декодирование, но делается это более эффективно.
Но если это приемлемо в случае plane spotting’а, то в случае решения навигационной задачи таскать с собой ноут с мощной видеокартой - это как-то э…